When does the CLR try to load a referenced assembly?

Question

I want to write a small installer app that installs a web site and creates IIS virtual directories. The app should run on Windows XP/Server 2003 (IIS 6) as well as on Vista/2008 (IIS 7).

The problem is: for IIS 6 we create virt dirs by calling WMI/Metabase API, for IIS 7 there is a much better API: Microsoft.Web.Administration, but its assembly is available only on IIS 7 systems.

Naive approach:

...
if (OperatingSystem == old)
{
    call metabase API...
}
else
{
    call Microsoft.Web.Administration...
}
...

Nice, isn't it? But how can I make sure that this does not crash on a old system just while trying to load the Microsoft.Web.Administration DLL? Or is an assembly just loaded, when it is first used? When a method that is calling into the assembly is first used?

I guess, testing does not help without some determinism being guaranteed by CLR/.NET spec.

I am really looking forward to hearing your experiences, hints or solutions for this topic. I have not found anything remotely usable on the web so far.

Answer 1

I have not been able to find the definitive answer as in a specification stating when assemblies must and must not be loaded. However, according to

http://msdn.microsoft.com/en-us/magazine/cc163655.aspx (section "Load Fewer Modules at Startup")

and the book extract at www.informit.com/articles/article.aspx?p=30601&seqNum=5 (extract from "Essential .NET, Volume I: The Common Language Runtime").

the JIT of the CLR will load a needed assembly only when needed to compile a method. Thus, you should move any use of Microsoft.Web.Administration... to a seperate method which is only called when your confident that the assembly exists on the system. That is,

   setup()
   { 
       if ( Operating.System == Old )
          call metabase API
       else
          doIIS7Setup()
   }

   void doIIS7Setup()
   {
     call Microsoft.Web.Administration ....
   }

Answer 2

Personally, rather than trying to rely on any inbuilt behaviour of the JIT, I'd move the dependency on Microsoft.Web.Administration to another assembly altogether.

Then, somewhere in the calling assembly, I'd check to see if %systemroot%\inetsrv\Microsoft.Web.Administration.dll is present. If so, then I'd assume I'm using the managed interface and call the assembly; if not, I'd revert to the metabase API.