Client-Server Extensibilty Notes

This is just an overview of my personal experience with IIS7’s Extensibility capabilities.

I’m breaking this down into 3 sections:

1.       Tips and Tricks with the GAC and how to avoid being confused

2.       What’s in an Async Call?

3.       Advantages of breaking the new module into two separate DLL’s

                This is more about troubleshooting your GAC entry and including your GAC information in the module provider section of administration.config.  Recently, I ran into a problem with porting and modifying an experimental module and the GAC information was my sticking point.  My problem was registering the module in administration.config.

                Here are the steps for making sure your module is in the GAC and in IIS:

1.       Follow the steps given in the Extensibility Demos.  Specifically, make sure that the binaries are signed and the Post-Build event is:

CALL "%VS80COMNTOOLS%\vsvars32.bat" > NULL

gacutil.exe /if "$(TargetPath)"

2.       Use gacutil to determine the information needed for administration.config. For example:

C:\Windows\assembly\GAC_MSIL>gacutil /l ExtensibilityDemoMicrosoft (R) .NET Global Assembly Cache Utility.  Version 2.0.50727.12Copyright (c) Microsoft Corporation.  All rights reserved.             

The Global Assembly Cache contains the following assemblies:  ExtensibilityDemo, Version=1.0.0.0, Culture=neutral, PublicKeyToken=3a197a7356d6a88, processorArchitecture=MSIL              

Number of items = 1              

The essential line is the assembly information line.  Also make sure that the name of the class and the assembly name match exactly.

3.       Figure out the name of the Module Provider class and name it something very clear.

4.       Add the new line with the into administration.config in the following manner:

NameSpace.ModuleProviderClassName, AssemblyName, Version, Culture, PublicKeyToken

Now the created module should appear inside of the IIS UI.

                Again, while developing an experimental module and following the steps used in the demos a stumbled on another point.  The demo module makes a single StartAsyncTask call in order to read the config.  My experimental module was reading a number of config sections so I decided that instead of having one single call I should make one call per UI section I was displaying.  This way if there are any remote failures or timeouts I’ll get some settings.  My example had nine individual StartAsyncTasks.  This is bad for the following reasons:

1.       Every async task takes a thread away from the thread pool.  This means I was using nine threads from a limited pool.

2.       Only one asynchronous task is supported at a time.  If another async task starts the first one will be canceled.  I haven’t been able to prove that, but that is something that Carlos explained to me.

3.       This method doesn’t take full advantage of Property Bags.

The best practice for accessing multiple config sections is to fill a single property bag. 

                In the Extensibility Demo Articles it isn’t perfectly clear what is happening with the client and server portions.  If these steps are followed literally the resulting project will contain a single DLL.  It is important to note that this works, but it limits functionality in remote scenarios.

                To create two separate DLLs two separate projects should be created within a Visual Studio Solution.  The naming convention around here is <ModuleName>UI for the server component and <ModuleName>UIClient for the client code. 

      ModuleNameUIClient Contains:   The actual module, with appropriate UI code and the Module Service Proxy