Pitfalls installing Web Setup .msi on IIS 7

I created a Web Setup project in Visual Studio 2010 for a .Net 4 web application to install on a Windows 2008 Server running IIS 7. The prerequisite knowledge is described in my previous posts.

Upon starting the .msi file (or the accompanying setup.exe), I received the error message

“The installer was interrupted before Application could be installed. You need to restart the installer to try again.

Click “Close” to exit.”

This Social MSDN entry brought the first step to the solution: activate logging using the command line

msiexec /i <path to msi file> /l*vx C:\SomeDirectory\SomeFilename.log

I needed to register the .Net 4 framework in IIS using the commands

cd C:\Windows\Microsoft.NET\Framework\v4.0.30319
aspnet_regiis.exe -i
aspnet_regiis.exe -ga MyDomain\MyUserName

After registering the framework version, the next error showed in these lines in the log file:

INFO   : [SetTARGETSITE]: Custom Action is starting...
INFO   : [SetTARGETSITE]: CoInitializeEx - COM initialization Apartment Threaded...
ERROR  : [SetTARGETSITE]: FAILED: -2147221164
ERROR  : [SetTARGETSITE]: Custom Action failed with code: '340'
INFO   : [SetTARGETSITE]: Custom Action completed with return code: '340'

The cause for these errors was that the IIS 6 Management Compatibility feature was not installed on the server.

Installation of this feature is easy: go to Control Panel\Programs and Features\”Turn Windows features on or off” and check the IIS 6 Management Compatibility checkbox. (on Server 2008, this can be done in the Server Manager, under Roles, Webserver (IIS)).

Visual Studio requires IIS 6 Management Compatibility to be installed on the developer machine:

To enable Visual Studio to create and use local IIS Web sites, you must enable metabase compatibility. This lets Visual Studio interact with the IIS metabase and with the IIS 7.0 configuration store.

I also found a similar statement in the IIS forum:

Visual Studio 2010 web setup project still only targets older IIS versions. This is why the compatibility features are required.

So how can a developer detect if the IIS 6 Compatibility feature is installed?

The registry path HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\InetStp contains the IIS version in the keys MajorVersion and MinorVersion.

This page contains the list of IIS components that can be detected under the registry path HKEY_LOCAL_MACHINE\Software\Microsoft\InetStp\Components. (see also SO, CodeProject), and the relevant keys seem to be Metabase and ADSICompatibility (both 1 of the compatibility feature is installed).

This page on Metabase compatibility explains the architecture of this feature:

It supports the Admin Base Objects (ABO) interface, also known as IMSAdminBase, as well as the ADSI and WMI providers that were built on top of ABO in IIS 6.0.

This component is not installed by default because IIS 7.0 itself is not using it.

My understanding is that the DirectoryEntry class which queries ADSI can only work if ABO is installed. ABO itself is a COM library, so the required classes and interfaces must be stored in the registry.

The file Iadmw.h of the IIS SDK contains the definition

DEFINE_GUID(IID_IMSAdminBase_W, 0x70b51430, 0xb6ca, 0x11d0, 0xb9, 0xb9, 0x0, 0xa0, 0xc9, 0x22, 0xe7, 0x50);

and indeed, the key HKEY_CLASSES_ROOT\Interface\{70B51430-B6CA-11D0-B9B9-00A0C922E750} has the default value IADMCOM if the Metabase compatibility is installed.