Last month (March 2016) I was building an InstallShield 2015 project with a component whose .NET Installer Class
property was set to Yes
, and everything seemed to be working well. This month I suddenly started getting Error 1001 while running the same install. Seeing that the error was coming from this .NET Installer Class
component, I decided to turn off the .NET Installer Class
property as a test. Indeed that fixes the problem. But we have another build system where we can build exactly the same code, and everything still works, suggesting an environmental problem.
After some additional research, I find that the file _isconfig.xml
is showing different values for the supportedRuntime
version
attribute between the two systems, which I believe is a closely related indicator of the problem. Additional research indicates that this version may be coming from InstallUtilLib.dll
, which indeed matches the versions I see in _isconfig.xml
on the two systems. The install works fine with <supportedRuntime version="v4.0.30319"/>
, and fails with <supportedRuntime version="v4.6.1055"/>
. BTW, the newer InstallUtilLib.dll
is dated 2015-11-05 so I guess the problem could theoretically be a result of any update since that date.
I see that my system has recently installed some .NET Framework Updates, but I'm coming up empty-handed when searching Google for Microsoft Updates that affect InstallUtilLib.dll
. So how do I nail down this problem to determine the cause and/or solution?
The MSI log reports the error like this:
MSI (s) (58:14) [14:17:27:958]: Executing op: CustomActionSchedule(Action=_1A0C0EC89595D04ACFD3852EF29B12BD.install,ActionType=3073,Source=BinaryData,Target=ManagedInstall,CustomActionData=/installtype=notransaction /action=install /LogFile= "M:\MfgSys\System\FourthShift.SDKAdministrator.dll" "C:\Users\bmarty\AppData\Local\Temp\{C449BDEA-AA73-4FDE-A6AF-9116E1D7DEBB}\_isconfig.xml")
MSI (s) (58:20) [14:17:27:973]: Invoking remote custom action. DLL: C:\windows\Installer\MSI7282.tmp, Entrypoint: ManagedInstall
Error 1001.
You have correctly diagnosed the immediate causes of the problem. The rest of it is due to InstallShield using the incorrect version of the framework at which it's pointed. (I believe in older versions it mistakenly uses a file version instead of a CLR version.) Here are your options as I see them: