Which is better for IIS administration in ASP.Net : WMI or ADSI or Managed API? and what's the difference?

Question

I am working on Configuring and manipulating and controlling IIS 6.0 and later versions using ASP.Net based web application. I am considering WMI, ADSI, Managed API as my options.

I have a target Windows System WIN2k3 or later versions. The choice of language is C# and the application has to be built using ASP.Net.

This article on Provisioning Options in IIS 7 describes each of the methods, but I am a bit unsure about a couple things:

1. Which is better or more powerful for the stated goal?

   • ADSI (System.DirectoryServices) or
   • WMI (Microsoft.Web.Management) or
   • Managed API (Microsoft.Web.Administratoion)?

   Correct me if i am doing something wrong here.

2. Which option or technology is likely to be supported for later versions of IIS?

3. Which option has the most flexibility and scalability?

4. From where can i find the resources for any of the suggested/chosen technology?

I am less likely to work on II5.1 or below. So the compatibility zone starts from IIS 6.0 and above. The application has to be built using ASP.Net and un-managed code may be used if unavoidable.

Answer 1

For IIS 7 and up, you probably want IIS Management API. I assume you've already read the MSDN comparison of administration technologies. Considering only 1 project, I would use whichever tool you are most familiar with. Everything involving direct manipulation of the IIS metabase requires a dedicated effort to learn.

Given the learning curve, I choose to use WMI. It is used broadly beyond IIS and mastering it feels like a good investment. C# supports its well. If you know a little PowerShell, you can easily explore it using the "gwmi" object. If using WMI from .NET start with the managed code generator.

Answer 2

For IIS6 I'd use the System.DirectoryServices namespace which is a managed wrapper around ADSI. I find this simpler to use compared to working with the IIS WMI providers.

For IIS7, and as Precipitous suggested, I'd use the new IIS 7 Managed Code Administration API (Microsoft.Web.Administration et al) . You can use the IIS6 compatibility components on IIS7 which maintain the old style ADSI API's for consumers (but are a wrapper around the new IIS7 components) and they mostly work.

However you do encounter problems with the ADSI wrappers. For example they are ignorant of Handler Mapping (analogous to an IIS6 Script Map) properties such as preConditions which, for example, permit multiple versions of ASP.NET's handler mapping definitions to co-reside in the same site or application. The ADSI compatibility layer will create objects known as AboMapperCustom objects which are sub-optimal in their configuration and are not aware of these new features.

Having two code-bases (one for IIS6 and one for IIS7) may seem like a lot of work, but to be honest it isn't too bad. I work for a hoster, have been down this road, and we bit the bullet and decided that we'd maintain the old IIS6 code but start afresh with IIS7.