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
- :
- Enable32bitAppOnWin64 not set in IIS7
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
Oct 28, 2010
10:39 PM
Enable32bitAppOnWin64 not set in IIS7
I thought I'd share a discovery that IS support was not able to provide help with.
We experienced a problem when installing on x64 machines where the installer would abort and rollback the install. Our app is x32, so we had to create a custom app pool and turn on the 'enable 32bit apps'.
In the log it's failing on the following lines:
InstallShield 15:38:40: Value returned for Enable32bitAppOnWin64: 0
InstallShield 15:38:40: SetAspversion: machine is 64-bit and IIS running in a bit mode other than the currently selected mode
InstallShield 15:38:40: Error with IISRT: -2172
Action ended 15:38:40: InstallFinalize. Return value 3.
Also worth mentioning,.. If you perform the install a second time, the installer completes successfully. So as a workaround, one could install twice, then navigate to the IIS manager and turn on the 'enable 32 bit mode' on the custom app pool and also set the application to use the custom app pool.
Here's what was happening:
If IIS6_COMPATIBILITY is turned on in a x64 platform (this is set in the control panel's add remove features) the first install aborts with a rollback. Even though we are installing to II7, it's acting like II6 which didn't support application pools that allowed 32bit applications, and so our property set "enable 32bit apps" is ignored. The installer is doing bitness validation (our app is x32, application pool is set to x64; abort and rollback).
We may be able to override this IIS6_COMPATIBILITY behavior by setting a property in the installer. (I don't have that property on hand, perhaps I'll update this post when I figure out a fix!)
UPDATE:
It turned out that the build engineer prior to myself added IISPREFERLEGACYOBJECTS=1 and that was the cause of this behavior. He originally did this to become compatible on x64 machines that used application pools, before Installshield had added support for app pools in basic msi.
We were able to get the installer to disregard the IIS6 compatibility the user enabled under the control panel > add remove windows features with the following:
Add a property to the project with a value of 0. IISPREFERLEGACYOBJECTS = 0 (or remove it entirely)
http://kb.flexerasoftware.com/selfservice/viewContent.do?externalID=Q113487
Very simple fix! We previously told our customer's to enable this setting so our application would run on iis7 before we added application pools to our project. Now that we have added application pools, this setting was making our upgrade deployments fail as discussed above. Adding this property with a value of 0 was the fix!
We experienced a problem when installing on x64 machines where the installer would abort and rollback the install. Our app is x32, so we had to create a custom app pool and turn on the 'enable 32bit apps'.
In the log it's failing on the following lines:
InstallShield 15:38:40: Value returned for Enable32bitAppOnWin64: 0
InstallShield 15:38:40: SetAspversion: machine is 64-bit and IIS running in a bit mode other than the currently selected mode
InstallShield 15:38:40: Error with IISRT: -2172
Action ended 15:38:40: InstallFinalize. Return value 3.
Also worth mentioning,.. If you perform the install a second time, the installer completes successfully. So as a workaround, one could install twice, then navigate to the IIS manager and turn on the 'enable 32 bit mode' on the custom app pool and also set the application to use the custom app pool.
Here's what was happening:
If IIS6_COMPATIBILITY is turned on in a x64 platform (this is set in the control panel's add remove features) the first install aborts with a rollback. Even though we are installing to II7, it's acting like II6 which didn't support application pools that allowed 32bit applications, and so our property set "enable 32bit apps" is ignored. The installer is doing bitness validation (our app is x32, application pool is set to x64; abort and rollback).
We may be able to override this IIS6_COMPATIBILITY behavior by setting a property in the installer. (I don't have that property on hand, perhaps I'll update this post when I figure out a fix!)
UPDATE:
It turned out that the build engineer prior to myself added IISPREFERLEGACYOBJECTS=1 and that was the cause of this behavior. He originally did this to become compatible on x64 machines that used application pools, before Installshield had added support for app pools in basic msi.
We were able to get the installer to disregard the IIS6 compatibility the user enabled under the control panel > add remove windows features with the following:
Add a property to the project with a value of 0. IISPREFERLEGACYOBJECTS = 0 (or remove it entirely)
http://kb.flexerasoftware.com/selfservice/viewContent.do?externalID=Q113487
Very simple fix! We previously told our customer's to enable this setting so our application would run on iis7 before we added application pools to our project. Now that we have added application pools, this setting was making our upgrade deployments fail as discussed above. Adding this property with a value of 0 was the fix!
(1) Reply
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Dec 10, 2010
12:17 PM
Thanks for this post! I, too, was directed by InstallShield support to add the MSI property IISPREFERLEGACYOBJECTS=1 to my installation while using InstallShield 2010 Pro. When I upgraded to 2011 Pro, the IIS app pool creation failed and the install rolled back, leaving the IIS web app behind. I have 5 web appsin this package, so it was the 6th install that completed successfully. However, as you noted, the app pool's "Enable 32-bit Applications" property is set to False, contrary to what I set it to in IS. Removing the IISPREFERLEGACYOBJECTS property solved these problems.
