Windows Package Manager error on Windows 7 x64

[nitsev]

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

[joshstechnij]

Pkgmgr.exe is not an executable we launch from our IIS custom actions. It may be possible that using ASP.NET version (which launches aspnet_regiis.exe) could be calling this. Besides aspnet_regiis.exe, we don't launch any other executables from our code.

Does this issue occur if you don't use the legacy IIS support (delete IISPREFERLEGACYOBJECTS from the project)?

[nitsev]

I have the property IISPREFERLEGACYOBJECTS property set to 0 (not used)

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

[joshstechnij]

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.

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.

[nitsev]

joshstechnij wrote:
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.

[joshstechnij]

There are only two usable states for IISPREFERLEGACYOBJECTS:
- 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.

[Christopher_Pai]

I have seen this in the lab also. On an x64 Vista machine, calling the aspnet_regiis.exe -ir from a command line generates the error message


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.

[nitsev]

I believe this is fixed in IS 2010. I don't remember if it was with the SP or directly in IS 2010 but there is no need at all to use the IISPREFERLEGACYOBJECTS flag anymore. Regardless if you are installing on IIS 7 or IIS 6.

[mloebl]

Was there any resolution to this? I'm running IS2010 SP1 with hotfix 52410 and I'm still seeing this on 2008 R2 and I removed the IISPREFERLEGACYOBJECTS=1 property without any behavior change. Were you able to get IIS updates workng on 64bit?

Thank you,

-Mike

[nitsev]

Yes, my installer now works on all platsforms and versions of Windows.

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?

[manicfiddler]

I have just managed to get this working on 2008-64:

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.

[Bluetonic]

I'm having the same problem on Windows 7 x64. I've set the platform to 32-bit and created an AppPool with Enable32 Bit Applications set to true too.

Does anyone have any idea how to fix this?

[BuilderBee]

I decided to just document that my installer requires "IIS Metabase and IIS 6 configuration compatibility". When that component of IIS is installed, it works.

Steps to add this IIS component on Windows Vista and Windows 7:
1. Open the Control Panel > Programs > Turn Windows features on or off (found under Programs and Features).
2. Expand the Internet Information Services feature.
3. Verify that "IIS Metabase and IIS 6 configuration compatibility" is checked.

[Christopher_Pai]

I'm still seeing this problem with IS2010 on Win 7. Basically the image doesn't have ASP.NET installed and InstallShield calls the x86 version of aspnet_regiis which in turn calls the 32bit version of pkgmgr.

If I call the x64 version of aspnet_regiis it works. Also if I install ASP.NET through Programs and Features before running the 32bit version of aspnet_regiis there is no error.

This seems like a bug in either Microsoft or InstallShield to me. It seems like a 32bit EXE from MSFT shouldn't throw an excpetion and/or that InstallShield should recognize it's running on a 64bit platform and call the 64bit version of the EXE.

Am I missing something?

[Christopher_Pai]

I do now wonder a few more things...


The help topic "Setting the ASP.NET version for a Web Site, Application or Virtual Directory" says that Aspnet_regiis.exe isn't reccomended. I don't see the custom action in my installer so I assume InstallShield is doing it by default.

I see there is a value called ASPNET.Platform on Web Sites and VDir's but I'm not sure what to make of it. I have a 32bit MSI that could potentially be installed on either a 32bit or 64 bit version of Windows.

I guess I've been getting lucky and I'm a little confused. At the end of the day I want to run 32bit web services on either a 32 or 64bit windows. I seem to be rolling just fine as long as ASP.NET is already installed otherwise I get the error.

Am I supposed to have two components for each website and make the mutually exclusive using component conditions or something? It seems like either that or call aspnet_regiis myself on 64bit machines before IS calls it.

[nitsev]

Have you tried installing IIS 6 metabase compatibility?

[Christopher_Pai]

I've tried many things and many of them work. However, isn't IS2010 supposed to have Native IIS7 support? Why should I make IIS6 compatibility a prerequisite for my install?

[deramor]

What is more frustrating is that IS2010 uses the settings you provide to build the path used to asp_regiis.exe. If you are targeting 32-bit ASP.Net, you get this error. If you target 64-bit you are fine but then you can't install an app pool with Enable32bitAppOnWin64 set to true. Is it safe to assume that if we create an installation which targets a single bitness, we will be ok?

This is not a valid workaround for me but it may be for others. Either way, this is very frustrating. Have there been any patches or hotfixes that address this?

[nitsev]

Christopher Painter wrote:
I've tried many things and many of them work. However, isn't IS2010 supposed to have Native IIS7 support? Why should I make IIS6 compatibility a prerequisite for my install?

I agree 100%. IS support for IIS 7 is limited at best and I have pointed out this and other issues as well. For me the metabase compatibility is required to get things to work on all IIS version from 6 to 7