fredrik.vestin asked a question.
Windows Package Manager error on Windows 7 x64
Hi,
Trying to install our basic MSI installer on Windows 7 x64 I get the following error message when the installer is trying to create a site and then once more when it is trying to create an application in IIS.
Windows Package Manager
Operation failed with 0x8007000B
An attempt was made to load a program with an incorrect format.
When clicking OK on the error message the installer continues and does not indicate the the installation failed. There are no errors in the verbose log either. The error does not occur on Windows 7 x86 or on Windows Server 2008 x86 or (x64 without R2). Although the error messages are displayed it appears that all properties are still applied. I am also puzzled why the error occurs only when creating the site and application. I also create an app. pool, a service extension and a virtual dir beneath the appliction but those actions does not cause an error.
I have the IISPREFERLEGACYOBJECTS option set to 0 and I have the "IIS Metabase and IIS6 Configuration Compatibility" option enabled in the IIS.
I see that the installer does fire the 32-bit version of the pkgmgr.exe which I believe is the root of the problem. See the following post.
http://social.msdn.microsoft.com/Forums/en/windowscompatibility/thread/796396fa-977d-4709-8ef3-a125c6ed68ca
Has anyone successfully installed a site on Windows 7 x64 or Windows Server 2008 x64 R2?
Thanks
Frede
Does this issue occur if you don't use the legacy IIS support (delete IISPREFERLEGACYOBJECTS from the project)?
When I set the ASP.NET platform version to 32-bit it works! I did not use this property before and it still installed fine on Windows Server 2008 x64, I wonder how that could be.
Some relatead questions
the help text for ASP.NET Version for a website says
"If you specify an ASP.NET version for a website, IIS uses that same version number for any of the web site's virtual directories"
The help text for an application or a virtual directory says
"If you specify an ASP.NET version for a website, IIS uses that same version number for any of the web site's applications and virtual directories"
I assume the different explanations are of no importance but I wonder how it handles the ASP.NET version settings on the apps and virtual dirs of a site.
1. If there is nothing specified in the sites apps or virtual dirs, is the sites ASP.NET version value always used?
2. Does the virtual dir of an app also inherit from the app and if there is nothing specified in the app the virtual dir inherit from the site? I mean if you have ASP.NET version set to 2 on the site and the sites app does not have the ASP.NET version set. Does the apps virtual dirs also get the ASP.NET version set to 2 by inheriting it from the site?
3. Does these rules also apply to the ASP.NET platform setting so if I want the same settings on the site, all apps and all virtual dirs I need just set this on the site and can leave everything below the site blank?
4. Is this behaviour the same in IIS 7 and IIS 6.
btw, there is no way to clear the value of the ASP.NET platform setting but you have to edit it in the table I guess.
Regards
/Frede
Regarding ASP.NET version information, I'm not sure if applying this to a website results in virtual directories in that site inheriting the ASP.NET information. On IIS 6 and earlier, this may happen. However, for IIS 7, the ASP.NET version on a site or application is controlled by the version specified in the application pool associated with the site/application. As such, specifying ASP.NET versions for websites or applications and installing on IIS 7 will have a limited effect.
Note that having the IISPREFERLEGACYOBJECTS property defined (regardless of its value), the IIS support will use the IIS 6 compatibility interfaces when installing on an IIS 7 machine. This property needs to be deleted if native IIS 7 interfaces should be used.
"
This sounds strange. So you're saying there's actually 3 ways to control the behaviour?
1. Not having IISPREFERLEGACYOBJECTS property defined at all
2. Having IISPREFERLEGACYOBJECTS value set to 0
3. Having IISPREFERLEGACYOBJECTS value set to 1
Please explain in detail the difference between not having the property defined at all and having it defined with value 0.
- The property is defined with a non-empty value. This indicates that the InstallShield IIS support should attempt to use IIS 6 style interfaces on IIS 7.x machines to install any IIS resources. The IIS support does not look at the value of the property, only that its returned length is greater than 0 (an empty or null string has a 0 length).
- The property is not defined (it has no value). This indicates the IIS support should use the native IIS 7.x interfaces.
Therefore, if IISPREFERLEGACYOBJECTS has a value of 1, 0, or any other non-empty value, the legacy IIS interfaces are used during installation on IIS 7.x machines (setting the property to 1 is a convenient way of notating the property). To ensure the native 7.x interfaces are used, this property needs to be undefined.
I'm trying to understand the underlying cause here though. Sure, an x64 installer ( which we don't have yet ) should call the exe from the Framework64\v2 directory but surely Microsoft put this file in the Framework\v2 directory so that legacy 32bit installers and programs would continue to work.
Thank you,
-Mike
I have removed the IISPREFERLEGACYOBJECTS altogether but I think that my problem was that I had not set the ASP.NET platform to 32-bit. Have you tried that?
I was suffering the same problem with aspnet_iisreg invoking the 32bit pkgmgr.exe.
To get round it I created my own 64bit vbscript custom action to invoke pkgmgr to install the ASPNET role service before ISIISInstall is called.