This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Problems with installer classes and Windows 10 Build machine
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 14, 2016
02:57 AM
Problems with installer classes and Windows 10 Build machine
Hello,
we have a new build system using Windows 10, Visual Studio 2015 and Installshield 2015 Limited Edition. When I use this system to build setups, the installation fails. On our old system (Windows 8.1, Visual Studio 2013 and Installshield 2013 Limited Edition), the setups are working.
I found out that the installer classes are the problem. This is the install log (sorry, german Version):
[CODE]
Aktion 09:40:22: _9A5620CD129E3151E4D774038F720BB0.install.
MSI (s) (90:4C) [09:40:22:251]: Executing op: CustomActionSchedule(Action=_9A5620CD129E3151E4D774038F720BB0.install,ActionType=3073,Source=BinaryData,Target=ManagedInstall,CustomActionData=/installtype=notransaction /action=install /LogFile= "" "C:\Users\admin\AppData\Local\Temp\{15D30051-403F-459A-B997-E612F15F8E95}\_isconfig.xml")
MSI (s) (90:4C) [09:40:22:251]: Creating MSIHANDLE (940) of type 790536 for thread 2636
MSI (s) (90:98) [09:40:22:251]: Invoking remote custom action. DLL: C:\Windows\Installer\MSIA749.tmp, Entrypoint: ManagedInstall
MSI (s) (90:04) [09:40:22:251]: Generating random cookie.
MSI (s) (90:04) [09:40:22:251]: Created Custom Action Server with PID 3624 (0xE28).
MSI (s) (90:58) [09:40:22:251]: Running as a service.
MSI (s) (90:58) [09:40:22:251]: Hello, I'm your 64bit Elevated Non-remapped custom action server.
MSI (s) (90!F8) [09:40:22:313]: Creating MSIHANDLE (941) of type 790531 for thread 2808
MSI (c) (20:5C) [09:40:22:516]: Font created. Charset: Req=0, Ret=0, Font: Req=MS Shell Dlg, Ret=MS Shell Dlg
Fehler 2869. Für das Dialogfeld SetupError ist das Fehlerformatbit festgelegt, es handelt sich jedoch nicht um ein Fehlerdialogfeld.
MSI (c) (20:5C) [09:40:38:865]: Produkt: Server-Setup -- Fehler 2869. Für das Dialogfeld SetupError ist das Fehlerformatbit festgelegt, es handelt sich jedoch nicht um ein Fehlerdialogfeld.
Fehler 1001.
MSI (s) (90!F8) [09:40:38:865]:
MSI (s) (90:98) [09:40:38:865]: Leaked MSIHANDLE (941) of type 790531 for thread 2808
MSI (s) (90:98) [09:40:38:865]: Note: 1: 2769 2: _9A5620CD129E3151E4D774038F720BB0.install 3: 1
Information 2769. Die benutzerdefinierte Aktion _9A5620CD129E3151E4D774038F720BB0.install hat 1 MSIHANDLEs nicht geschlossen.
CustomAction _9A5620CD129E3151E4D774038F720BB0.install returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
MSI (s) (90:98) [09:40:38:865]: Closing MSIHANDLE (940) of type 790536 for thread 2636
Aktion beendet um 09:40:38: InstallFinalize. Rückgabewert 3.
MSI (s) (90:4C) [09:40:38:865]: Note: 1: 2265 2: 3: -2147287035
[/CODE]
I found out that there was a bug in earlier Installshield LE versions that used the wrong SupportedRuntime Tag in _isconfig.xml. This is the problem here, my _isconfig.xml looks like this:
The Release Notes of Installshield 2015 LE lists an Issue IOJ-1737004, which is an issue similar to our problem. It is listed as fixed, but somehow this is not working for us.
One thing is also strange, I somehow got a working setup yesterday: I removed the file and added it again, then built the setup manually. This setup could be installed. The .isl had a few changes the I checked in, the GUID of the file changed, but not much more was changed.
However, the nightly build still does not produce a working setup.
What else can I check or do to get our setups working with a Windows 10 build Environment?
UPDATE: I found a few threads addressing the same problem. However I downloaded and installed the version of Installshield 2015 LE last week, so it should be the latest version, right?
SECOND UPDATE: I found out that I can manually build my setups and they work. The nightly build uses MSBuild to build the setups. When I use MSBuild (Version 12 or 14, no difference), the setup isn't working, it stores the wrong _isconfig.xml (with supportedRuntime version="v4.6.1038") in my MSI. We need to get our build running, so any ideas?
I can also reproduce the problems using the command line:
Not working:
Working:
So it seems to be a problem when we use MSBuild. Am I missing something?
Thanks for your help!
Jan
we have a new build system using Windows 10, Visual Studio 2015 and Installshield 2015 Limited Edition. When I use this system to build setups, the installation fails. On our old system (Windows 8.1, Visual Studio 2013 and Installshield 2013 Limited Edition), the setups are working.
I found out that the installer classes are the problem. This is the install log (sorry, german Version):
[CODE]
Aktion 09:40:22: _9A5620CD129E3151E4D774038F720BB0.install.
MSI (s) (90:4C) [09:40:22:251]: Executing op: CustomActionSchedule(Action=_9A5620CD129E3151E4D774038F720BB0.install,ActionType=3073,Source=BinaryData,Target=ManagedInstall,CustomActionData=/installtype=notransaction /action=install /LogFile= "
MSI (s) (90:4C) [09:40:22:251]: Creating MSIHANDLE (940) of type 790536 for thread 2636
MSI (s) (90:98) [09:40:22:251]: Invoking remote custom action. DLL: C:\Windows\Installer\MSIA749.tmp, Entrypoint: ManagedInstall
MSI (s) (90:04) [09:40:22:251]: Generating random cookie.
MSI (s) (90:04) [09:40:22:251]: Created Custom Action Server with PID 3624 (0xE28).
MSI (s) (90:58) [09:40:22:251]: Running as a service.
MSI (s) (90:58) [09:40:22:251]: Hello, I'm your 64bit Elevated Non-remapped custom action server.
MSI (s) (90!F8) [09:40:22:313]: Creating MSIHANDLE (941) of type 790531 for thread 2808
MSI (c) (20:5C) [09:40:22:516]: Font created. Charset: Req=0, Ret=0, Font: Req=MS Shell Dlg, Ret=MS Shell Dlg
Fehler 2869. Für das Dialogfeld SetupError ist das Fehlerformatbit festgelegt, es handelt sich jedoch nicht um ein Fehlerdialogfeld.
MSI (c) (20:5C) [09:40:38:865]: Produkt: Server-Setup -- Fehler 2869. Für das Dialogfeld SetupError ist das Fehlerformatbit festgelegt, es handelt sich jedoch nicht um ein Fehlerdialogfeld.
Fehler 1001.
MSI (s) (90!F8) [09:40:38:865]:
MSI (s) (90:98) [09:40:38:865]: Leaked MSIHANDLE (941) of type 790531 for thread 2808
MSI (s) (90:98) [09:40:38:865]: Note: 1: 2769 2: _9A5620CD129E3151E4D774038F720BB0.install 3: 1
Information 2769. Die benutzerdefinierte Aktion _9A5620CD129E3151E4D774038F720BB0.install hat 1 MSIHANDLEs nicht geschlossen.
CustomAction _9A5620CD129E3151E4D774038F720BB0.install returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
MSI (s) (90:98) [09:40:38:865]: Closing MSIHANDLE (940) of type 790536 for thread 2636
Aktion beendet um 09:40:38: InstallFinalize. Rückgabewert 3.
MSI (s) (90:4C) [09:40:38:865]: Note: 1: 2265 2: 3: -2147287035
[/CODE]
I found out that there was a bug in earlier Installshield LE versions that used the wrong SupportedRuntime Tag in _isconfig.xml. This is the problem here, my _isconfig.xml looks like this:
The Release Notes of Installshield 2015 LE lists an Issue IOJ-1737004, which is an issue similar to our problem. It is listed as fixed, but somehow this is not working for us.
One thing is also strange, I somehow got a working setup yesterday: I removed the file and added it again, then built the setup manually. This setup could be installed. The .isl had a few changes the I checked in, the GUID of the file changed, but not much more was changed.
However, the nightly build still does not produce a working setup.
What else can I check or do to get our setups working with a Windows 10 build Environment?
UPDATE: I found a few threads addressing the same problem. However I downloaded and installed the version of Installshield 2015 LE last week, so it should be the latest version, right?
SECOND UPDATE: I found out that I can manually build my setups and they work. The nightly build uses MSBuild to build the setups. When I use MSBuild (Version 12 or 14, no difference), the setup isn't working, it stores the wrong _isconfig.xml (with supportedRuntime version="v4.6.1038") in my MSI. We need to get our build running, so any ideas?
I can also reproduce the problems using the command line:
Not working:
"C:\Program Files (x86)\MSBuild\14.0\bin\MSBuild.exe" /nologo "C:\TFSBuilds\TFSEntwicklung\Release\Sources\N-Dev\Setups\Server\Server-Setup.root\Server.sln" /nr:False /fl /flp:"logfile=C:\TFSBuilds\TFSEntwicklung\N-Dev-Release\Sources\N-Dev\Setups\Server\Server-Setup.root\Server.log;encoding=Unicode;verbosity=normal" /p:OutDir="C:\TFSBinaries\Setups\x64\Server\\" /p:Configuration="SingleImage" /p:RunCodeAnalysis="False"
Working:
"C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv" "C:\TFSBuilds\TFSEntwicklung\N-Dev-Release\Sources\N-Dev\Setups\Server\Server-Setup.root\Server.sln" /Build SingleImage
So it seems to be a problem when we use MSBuild. Am I missing something?
Thanks for your help!
Jan
(2) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 25, 2016
12:10 PM
Hi,
Is that a custom action from a merge module?
Also, does that custom action have a 0 length string?
Is that a custom action from a merge module?
Also, does that custom action have a 0 length string?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 03, 2016
09:04 AM
Hi,
it's not a merge module, we have .NET libraries that include .NET Installer Classes. We add these .dlls to the setups and mark them as Installer Class (Right click on File -> Properties).
We found a workaround, let's hope Flexera will release a patch soon. But looking at the count of reads (and replies) over the last three weeks I don't think they are even reading this forums.
Regards
Jan
it's not a merge module, we have .NET libraries that include .NET Installer Classes. We add these .dlls to the setups and mark them as Installer Class (Right click on File -> Properties).
We found a workaround, let's hope Flexera will release a patch soon. But looking at the count of reads (and replies) over the last three weeks I don't think they are even reading this forums.
Regards
Jan
