More custom action issues

[bobmcm]

I'm trying to create a BasicMSI to install my NT Service, and Web Service.

I thought that my Custom action problems had been solved, but I'm still running into execution problems. Everything worked fine until we started trying to run the installation on Vista. Now I am getting the following information in the MSI log.

[CODE]MSI (s) (34:DC) [13:47:02:525]: Executing op: ActionStart(Name=ServiceModelReg,,)
Action 13:47:02: ServiceModelReg.
MSI (s) (34:DC) [13:47:02:525]: Executing op: CustomActionSchedule(Action=ServiceModelReg,ActionType=1122,,Target="C:\Windows\Microsoft.Net\Framework\v3.0\Windows Communication Foundation\ServiceModelReg -i",)
MSI (s) (34:DC) [13:47:02:525]: Note: 1: 1721 2: ServiceModelReg 3: 4: "C:\Windows\Microsoft.Net\Framework\v3.0\Windows Communication Foundation\ServiceModelReg -i"
Info 1721.There is a problem with this Windows Installer package. A program required for this install to complete could not be run. Contact your support personnel or package vendor. Action: ServiceModelReg, location: , command: "C:\Windows\Microsoft.Net\Framework\v3.0\Windows Communication Foundation\ServiceModelReg -i"
MSI (s) (34:DC) [13:47:02:525]: Executing op: ActionStart(Name=RegisterServicei,,)
Action 13:47:02: RegisterServicei.
MSI (s) (34:DC) [13:47:02:525]: Executing op: CustomActionSchedule(Action=RegisterServicei,ActionType=1106,Source=C:\Program Files\FutureSoft\Traffic Monitor\tmService.exe,Target=-i,)
MSI (s) (34:DC) [13:47:02:883]: Note: 1: 1721 2: RegisterServicei 3: C:\Program Files\FutureSoft\Traffic Monitor\tmService.exe 4: -i
Info 1721.There is a problem with this Windows Installer package. A program required for this install to complete could not be run. Contact your support personnel or package vendor. Action: RegisterServicei, location: C:\Program Files\FutureSoft\Traffic Monitor\tmService.exe, command: -i
MSI (s) (34:DC) [13:47:02:883]: Executing op: ActionStart(Name=RegisterServicer,,)
Action 13:47:02: RegisterServicer.
MSI (s) (34:DC) [13:47:02:899]: Executing op: CustomActionSchedule(Action=RegisterServicer,ActionType=1106,Source=C:\Program Files\FutureSoft\Traffic Monitor\tmService.exe,Target=-r,)
MSI (s) (34:DC) [13:47:02:915]: Note: 1: 1721 2: RegisterServicer 3: C:\Program Files\FutureSoft\Traffic Monitor\tmService.exe 4: -r
Info 1721.There is a problem with this Windows Installer package. A program required for this install to complete could not be run. Contact your support personnel or package vendor. Action: RegisterServicer, location: C:\Program Files\FutureSoft\Traffic Monitor\tmService.exe, command: -r
[/CODE]

I looked around online and found some references to the 1721 error talking about setting the msidbCustomActionTypeNoImpersonate bit. I have made that change by changing to Deferred Execution in System Context, but no joy. The custom actions still will not execute. If I try and run the exes from the command line after the install completes, they execute with no problems.

Any suggestions would be appreciated.

Thanks,

[joshstechnij]

This could be one of two possible issues that I can tell. The 1721 indicates that Windows Installer could not launch the exe (i.e., their call to CreateProcess failed). If this is only happening on certain platforms, such as Vista, it could be:
- The EXE requires admin privileges. This can be confirmed if double-clicking the EXE in Explorer causes a UAC prompt to appear. Setting the action to deferred in system context typically resolves this issue.
- There are dependencies required for the EXE to load successfully that are missing on Vista. Normally the dependencies can be installed with the product and the EXE launched after the dependencies are installed. However, if the dependencies are Win32 side-by-side assemblies (like the VC8 and 9 runtimes) or .NET assemblies installed to the GAC, these are only available after InstallFinalize has run.

Since setting deferred in system context did not appear to resolve the behavior, you may try using the Process Monitor utility to determine if any dependencies are not found around the time the 1721 error occurs.

[bobmcm]

Changing the custom actions to Commit in System Context seems to have solved the problem getting them to run correctly, but I am still having a problem with the Mime type. I thought that I had solved the problem by putting the mime type directly into the registry as I had no luck getting it to work in the File types tab, but I have found that it still does not get set properly for IIS to see it. How do you go about adding a mime type in Installshield so that it is added properly to IIS?

Thanks

[joshstechnij]

The MIME type would need to be registered with IIS directly since it maintains its own information separate from the Windows registry. InstallShield does not currently provide support for configuring MIME types in IIS. An enhancement request was previously submitted under work order number 1-G7VZH.

[bobmcm]

Then this brings up another custom action problem. I have created a VB Script to try and register the mime type. Not matter what I do, the script will not run as a custom action. According to the log, the custom action is run (no errors shown in the log), but the mime type is not registered. I have added some display options in the VB script, and they are never displayed. If I run the script from the command line, it executes properly, and the mime type gets added. I can find no reason that the script should not execute.

[CODE]
Option Explicit

Dim objShell
Dim strCommand, objExecObject, strText

Set objShell = WScript.CreateObject("WScript.Shell")
strCommand = "cmd /c c:\windows\system32\inetsrv\appcmd.exe set config "
strcommand = strCommand & "-section:system.webServer/staticContent /+""[fileExtension='xap',mimeType='application/x-Silverlight-app']"""

set objExecObject = objShell.Exec(strCommand)
Do While Not objExecObject.StdOut.AtEndOfStream
strText = objExecObject.StdOut.ReadLine()
if strText <> "" then
wscript.Echo StrText
End if
loop
set objShell = Nothing
[/CODE]

Thanks,

[joshstechnij]

If there are any anti-virus utilities running on the machine(s) you are testing on, they should be disabled before running the installation. Anti-virus utilities can block the execution of VBScript custom actions. In addition, running the script from the command line usually results in cscript.exe or wscript.exe hosting the script. Windows Installer scripting custom actions are run directly by the Windows Installer engine, which can cause different behavior to occur.