InstallShield 2011: "ISSQLServerCosting" action changes Temp path. Error pops up: Could not open SQL script file <SQL script filename> - sql

I have an MSI application with 2 versions v1 and v2 created using InstallShield 2011.
The application executes a SQL script (AddRoleMember.sql)
error 27505: Could not open SQL script file
AddRoleMember.sql executes successfully through v1 but throws an error in v2 for the same user with similar rights and permissions.
AddRoleMember.sql succeeds to execute in v2 only when v2 MSI is executed with Run as Admin command.
The SQL script is same for the both the installers.
There are no changes in v2 from v1 execpt ProductCode and ProductVersion.
Findings from troubleshooting:
Logs from v1 (success):
{
InstallShield 12:14:01: Setting Costing Info Location ISSearchReplaceRollback : C:\Users\APPCSE~1\AppData\Local\Temp\~18F9.tmp
MSI (s) (E8!AC) [12:14:01:445]: PROPERTY CHANGE: Adding ISSearchReplaceRollback property. Its value is'C:\Users\APPCSE~1\AppData\Local\Temp\~18F9.tmp'.
Action ended 12:14:01: ISSearchReplaceCosting. Return value 1.
MSI (s) (E8:F8) [12:14:01:445]: Doing action:ISSQLServerCosting
Action 12:14:01: ISSQLServerCosting.
Action start 12:14:01: ISSQLServerCosting.
MSI (s) (E8:04) [12:14:01:445]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI195B.tmp, Entrypoint: ISSQLServerCosting
1: Beginning SQL Server Costing Process...
1: Reading the SQL script data from ISSQLConnection table...
1: Finished SQL Server Costing Process...
1: Setting Costing Info Location ISSQLServerInstall : C:\Users\APPCSE~1\AppData\Local\Temp\~1948.tmp
MSI (s) (E8!A8) [12:14:01:508]: PROPERTY CHANGE: Adding ISSQLServerInstall property. Its value is 'C:\Users\APPCSE~1\AppData\Local\Temp\~1948.tmp'.
}
Logs from v2 (failed):
{
InstallShield 17:45:50: Setting Costing Info Location ISSearchReplaceRollback : C:\Users\APPCSE~1\AppData\Local\Temp\~96CD.tmp
MSI (s) (34!AC) [17:45:50:900]: PROPERTY CHANGE: Adding ISSearchReplaceRollback property. Its value is 'C:\Users\APPCSE~1\AppData\Local\Temp\~96CD.tmp'.
Action ended 17:45:50: ISSearchReplaceCosting. Return value 1.
MSI (s) (34:54) [17:45:50:900]: Doing action: ISSQLServerCosting
Action 17:45:50: ISSQLServerCosting.
Action start 17:45:50: ISSQLServerCosting.
MSI (s) (34:FC) [17:45:50:916]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI9736.tmp, Entrypoint: ISSQLServerCosting
1: Beginning SQL Server Costing Process...
1: Reading the SQL script data from ISSQLConnection table...
1: Finished SQL Server Costing Process...
1: Setting Costing Info Location ISSQLServerInstall : C:\Windows\TEMP\~97C8.tmp
MSI (s) (34!B4) [17:45:51:180]: PROPERTY CHANGE: Adding ISSQLServerInstall property. Its value is 'C:\Windows\TEMP\~97C8.tmp'.
}
It can be seen from the logs that after the execution of "ISSQLServerCosting" action, the path of Temp location changes in the case of failed installation. The path changes from user specific location to the machine location. Due to this, SQL script succeeds to execute only when executed as Run as Admin. In v1, the path fro Temp location remains user specific before and after the execution of "ISSQLServerCosting" action.
Question: Can anyone please suggest what might be the reason of this change in path in one of the installation? This is the major cause of failure of SQL script in my MSI project.

In the first log the temp is the user temp directory, and in the second it's the system temp directory. Since that action appears to be a custom action, and assuming that nothing else has changed, the first install may have been per-user and the second a per-system.
It's not clear what elevation may or may not have occurred: an MSI configured for elevation will show that elevation dialog after the UI sequence. I'd guess that the first was per-user and didn't need elevation and the second was per system and does need elevation (to access the system temp location).

Related

Installer flags file in use when it is not

I have a WIX installer which updates an SNMP Agent dll. I have a custom action which stops the SNMP service. When the installer runs the log file always says the file is in use when it is not. When reviewing the installer log the log entries appear to be bassackwards. File copy log entries are written after the installed services and SNMP service have all already started. The file is updated and the SNMP Service starts with the newly copied file. No reboot is necessary however MSI is setting the reboot flag. Here's a snippet of my log file. Can anyone make sense of this order of operations issue?
`
...
Action ended 14:59:57: StopSnmpService. Return value 1.
...
MSI (s) (4C:04) [14:59:58:982]: Doing action: InstallFiles
...
MSI (s) (4C:04) [14:59:59:029]: Doing action: InstallServices
Action 14:59:59: InstallServices. Installing new services
Action start 14:59:59: InstallServices.
InstallServices: Service:
Action ended 14:59:59: InstallServices. Return value 1.
MSI (s) (4C:04) [14:59:59:029]: Doing action: StartServices
Action 14:59:59: StartServices. Starting services
Action start 14:59:59: StartServices.
StartServices: Service: Starting services
Action ended 14:59:59: StartServices. Return value 1.
...
MSI (s) (4C:04) [14:59:59:045]: Doing action: StartSnmpService
...
MSI (s) (4C:04) [14:59:59:560]: File: C:\Program Files\Corner Bowl\Server Manager 2022\cbsmsnmpagent.dll; Overwrite; Won't patch; Existing file is a lower version
MSI (s) (4C:04) [14:59:59:560]: Source for file 'cbsmsnmpagent.dll' is compressed
InstallFiles: File: cbsmsnmpagent.dll, Directory: C:\Program Files\Corner Bowl\Server Manager 2022, Size: 19968
MSI (s) (4C:04) [14:59:59:560]: Re-applying security from existing file.
Info 1603. The file C:\Program Files\Corner Bowl\Server Manager 2022\cbsmsnmpagent.dll is being held in use. Close that application and retry.
MSI (s) (4C:04) [15:00:02:919]: Verifying accessibility of file: cbsmsnmpagent.dll
...
`
This is a downside of reinventing the wheel with a custom action. If you used the ServiceControl element then MSI would know that this service will be stopped and the file won't really be in use. But since your doing it out of process with custom code it doesn't know this and you get an erroneous message.

Is launch Condition shown in silent mode?

Using WixSharp to build installer,
Is LaunchCondition shown when running in silent mode? (e.g "msiexec /i /qn /quiet")
MSI GUI: MSI has many UILevels - degrees of visible GUI (more on this here). When a setup is run in silent mode, any errors from Launch Conditions will show up in the MSI log instead of a dialog.
This makes sense since you must avoid dialogs showing up when there might be nobody to dismiss them (for example in automatic package deployment systems).
Essentially you can run with basic GUI /qb or reduced GUI /qr or completely silently /qn. When you run silently no dialogs should be shown, and you should consult the log file for results:
Silent MSI installation:
msiexec /i MySetup.msi /qn /L test.log
Test Project: https://github.com/glytzhkof/WiXLaunchConditionTest (MYVALUE is defined in the Property table - change it there to 0 or 1).
Here is a sample log output:
=== Logging started: 28.10.2021 13:07:12 ===
Action start 13:07:12: INSTALL.
Action start 13:07:12: FindRelatedProducts.
Action ended 13:07:12: FindRelatedProducts. Return value 1.
Action start 13:07:12: LaunchConditions.
MSI (s) (F4:DC) [13:07:12:491]: Product: WiXLaunchConditionTest -- Value for MYFLAG must be 1 (true) or 0 (false)
Value for MYFLAG must be 1 (true) or 0 (false)
Action ended 13:07:12: LaunchConditions. Return value 3.
Action ended 13:07:12: INSTALL. Return value 3.
MSI (s) (F4:DC) [13:07:12:493]: Product: WiXLaunchConditionTest -- Installation failed.
MSI (s) (F4:DC) [13:07:12:493]: Windows Installer installerte produktet. Produktnavn: WiXLaunchConditionTest. Produktversjon: 1.0.0.0. Produktspråk: 1033. Produsent: -. Installasjonens resultatstatus: 1603.
=== Logging stopped: 28.10.2021 13:07:12 ===
Admin Rights: It should be noted that an MSI should be run from a cmd.exe with admin rights - or you get no message from the silent installer that the setup failed because of lacking admin rights (the failure is from lacking admin rights, not because of the launch conditions).
This registry script adds context menus in Windows Explorer which can open a cmd.exe in any folder with or without admin rights: https://github.com/glytzhkof/all/blob/master/HKCU_Run-CMD-Shell-Extension.reg. Just merge the registry file and then right click an empty space inside Windows Explorer in any folder. See the commands towards the bottom of the dialog:

How can I stop an .exe on repair, update and delete in wix?

In my wix I use the following declaration:
<ComponentGroup Id="BinComponents" Directory="BIN">
<Component Id="BinComponent" Guid="23D229D0-06EE-49f4-80B4-6D7136500721">
<File Id="MyProjectOutput" Name="MyProject.exe" Source="MyProject\bin\MyProject.exe"/>
<ServiceControl Id="RemoveService"
Stop="both"
Remove="both"
Name="MyProject.exe"
Wait="yes" /> <!-- Stop running MyProject instances -->
</Component>
</ComponentGroup>
My Repro:
At first, I run my installation as usual. After the installation, I start my web application. An .exe appears in the task manager as usual:
I want to end this .exe on a repair, update or uninstall. So I start my .msi again and choose repair:
Now my problem: After pressing 'Repair', I expect the following dialog because of the declared ServiceControl:
But it doesn´t. Instead, the following dialog appears:
When I log the setup, the log shows the following lines:
MSI (s) (A8:DC) [10:16:28:227]: Executing op: ActionStart(Name=StopServices,Description=Stopping services,Template=Service: [1])
Action 10:16:28: StopServices. Stopping services
MSI (s) (A8:DC) [10:16:28:228]: Executing op: ProgressTotal(Total=1,Type=1,ByteEquivalent=1300000)
MSI (s) (A8:DC) [10:16:28:228]: Executing op: ServiceControl(,Name=MyProject.exe,Action=2,Wait=1,)
MSI (s) (A8:DC) [10:16:28:228]: Executing op: ActionStart(Name=DeleteServices,Description=Deleting services,Template=Service: [1])
Action 10:16:28: DeleteServices. Deleting services
MSI (s) (A8:DC) [10:16:28:228]: Executing op: ProgressTotal(Total=1,Type=1,ByteEquivalent=1300000)
MSI (s) (A8:DC) [10:16:28:229]: Executing op: ServiceControl(,Name=MyProject.exe,Action=8,Wait=1,)
MSI (s) (A8:DC) [10:16:28:229]: Executing op: ActionStart(Name=InstallFiles,Description=Copying new files,Template=File:
[1], Directory: [9], Size: [6])
[...]
MSI (s) (7C:28) [09:06:21:950]: RESTART MANAGER: Did detect that a critical application holds file[s] in use, so a reboot will be necessary.
MSI (s) (7C:28) [09:06:21:950]: Note: 1: 1610
MSI (s) (7C:28) [09:06:21:950]: Note: 1: 2205 2: 3: Error
MSI (s) (7C:28) [09:06:21:950]: Note: 1: 2228 2: 3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 1610
Next to a Repair I also have tried an Update with the same results.
Perhaps any declaration missing?
Note: When I close the MyApp.exe in the task manager, the message does not appear, so the MyApp.exe is definitely responsible for the problem.
You should post the entire log somewhere. The root cause is that a repair shouldn't routinely require files to be replaced. So if you literally installed your product, ran the exe, and then a repair needs to replace files, then the issue is not that files-in-use dialog - it's that the installed product is broken, so required files or registry entries have been removed. The application event log should have MsiInstaller entries that describe a missing component. So look at that root cause first.
After fixing that it should be very rare for a repair to need to replace files, so it may not be worth worrying about. But you could look at integrating your app with Restart Manager or using the WiX util CloseApplication.
The warning dialog that you are seeing is from "InstallValidate" standard action.
I have run into a similar issue in the past . I fixed it by making use of a single service control element instead of multiple service control elements, for the same service id.
In my case, i had multiple service control elements for the same service id.
This is as per the link at
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Upgrade-uninstall-restart-issue-td7586315.html
This did the trick for me. Numerous users have reported the same behavior, though its not officially documented.
Having a single service control element makes Restart Manager take note of the entry in the Service Control table and will prevent Restart Manager from listing the service in the RMFilesInUse dialog box or will prevent Restart Manager
from throwing up warning messages informing the user that a restart might be required.
Here is one more link
Can't start windows service with WiX
My experiments have shown me that there is definitley a link between the number of service control elements and Restart Manager
http://microsoft.public.windows.msi.narkive.com/OOuQQAsw/controlling-restart-manager-behaviour
The other option was to totally disable Restart Manager using the property RESTARTMANAGERCONTROL, In case, you disable the RestartManager, you might be prompted for reboots(you might want to test it once) and the legacy "Files in Use" mechanism kicks off. Disabling Restart Manager is a conscious decision by the concerned msi developer and at times becomes necessary.
I am not sure about how your Service Control table looks like. Just wanted to share my experience with you.
Hopefully it helps.
Regards,
Kiran Hegde

No SQL scripts during MSI installer on Japanese Windows XP

we have to install our product with InstallShield on several systems. During installation we have to execute some SQL scripts, this works properly in nearly every case.
Except a Japanese Windows XP we have (x86 with SP3).
(It doesn't fail on every machine, just on some).
First it happen that, even the installation was running and end without an error output, the application was not running because of missing database and SQL instance settings.
In the MSI I first found no problem.
I found registry entries which has expand the log file a little more, and because of that I was able to see an error on one place.
The installer is not possible to extract the SQL scripts out of the installer temp files.
This is how a working installation looks:
MSI (s) (D0:CC) [06:32:27:394]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI2B17.tmp, Entrypoint: ISSQLServerCosting
1: Beginning SQL Server Costing Process...
1: Reading the SQL script data from ISSQLConnection table...
1: ISSQLRequirement table does not exist...
1: ISSQLRequirement table does not exist...
1: Finished SQL Server Costing Process...
1: Setting Costing Info Location ISSQLServerInstall : C:\Users\UserName\AppData\Local\Temp\~2B44.tmp
MSI (s) (D0!9C) [06:32:27:465]: PROPERTY CHANGE: Adding ISSQLServerInstall property. Its value is 'C:\Users\UserName\AppData\Local\Temp\~2B44.tmp'.
...
(There are some more "Setting Costing Info Location" lines with "PROPERTY CHANGE: Adding".)
But on the not working Japanese XP it looks like:
MSI (s) (8C:E0) [14:51:37:031]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI30.tmp, Entrypoint: ISSQLServerCosting
1: Beginning SQL Server Costing Process...
1: Reading the SQL script data from ISSQLConnection table...
1: ISSQLRequirement table does not exist...
1: An unhandled exception occurred in ExtractScriptFile()
1: An unhandled exception occurred in ExtractScriptFile()
1: An unhandled exception occurred in ExtractScriptFile()
1: An unhandled exception occurred in ExtractScriptFile()
1: ISSQLRequirement table does not exist...
1: An unhandled exception occurred in ExtractScriptFile()
1: Finished SQL Server Costing Process...
1: Setting Costing Info Location ISSQLServerInstall :
1: Setting Costing Info Location ISSQLServerUninstall :
There we see unhandled exceptions and no result for the actions.
In a MS help page I saw for "unhandled exceptions" that this may caused by errors in the netapi32.dll, so I tried to replace it with another version. This has not changed anything, further was during installation the newer version replaced by the original one anyhow.
There are the same amount of temp files during installation (in %temp%) which will be created on working systems as well.
On a virtual machine with the Japanese Windows XP it works normally, I find no difference.
All works find and without errors, just the missing SQL scripts happen on that system. The installation itself does not end with an error.
I'm out of ideas :-/ Please help
I figured out, it works if I change the "TEMP" and "TMP" paths to anything else.
I don't know why the original temp paths has problems, temp files can be written and deleted, only extracting of the SQL files (or check in which temp script files are located) failes.
I compared with a working machine and the system user has no different rights or something.

How to debug WiX installer

I am adding to build to your WiX installer to include a multi-website deployment based on custom dialog selection.
I am running into this issue when i run in debug mode and not sure how to tackle the problem to find what the issue is, I am getting a Failed to load XML Error:
MSI (s) (D0:60) [10:25:14:945]: Executing op:
ActionStart(Name=ExecXmlFile,,) Action 10:25:14: ExecXmlFile.
MSI (s) (D0:60) [10:25:14:960]: Executing op:
CustomActionSchedule(Action=ExecXmlFile,ActionType=3073,Source=BinaryData,Target=ExecXmlFile,CustomActionData=20C:\Program
Files\Company Name,
Inc\18.4.007\Navigator\bin\hibernate.cfg.xml30//property[#name='connection.connection_string_name']Workbench_PROD2130/
+ MORE SIMILAR STUFF
MSI (s) (D0:30) [10:25:14:976]: Invoking remote custom action. DLL:
C:\Windows\Installer\MSI5E32.tmp, Entrypoint: ExecXmlFile
MSI (s) (D0:B0) [10:25:14:976]: Generating random cookie.
MSI (s) (D0:B0) [10:25:14:976]: Created Custom Action Server with PID
3980 (0xF8C).
MSI (s) (D0:8C) [10:25:15:163]: Running as a service.
MSI (s) (D0:8C) [10:25:15:163]: Hello, I'm your 32bit Elevated custom
action server.
ExecXmlFile: Error 0x8007006e: failed to load XML file:
Since your error occurs when running a custom action, I would add a Debugger.Launch(); for C# or s.t. equivalent for other languages at the very start of your custom action method. This would allow you to debug in Visual Studio as usual.
The only advice I can give you is to use Orca, which is a low-level tool for creating and editing MSI file. At least it will validate your msi and show you any errors or warnings it finds.