Harmjan Greving’s Blog

On many websites you read about installing FeatureReceiver assembly inside the Global Assembly Cache (GAC) instead of placing the assembly inside you’re web application bin folder. In this post I will explain why it is necessary to use the GAC.

Inside a SharePoint webapplication on site collection level or site level you can activate and deactivate features. If you activate a feature in this context and you’re assembly is located in the web application bin folder everything will be fine. The assembly can be found because you’re inside the context of you’re web application that has the dll (in the bin folder). The .Net framework checks the GAC first, when the assembly cannot be found in the GAC, the local bin folder is checked. So the assembly can be found in this situation.

But when you decide to activate you’re feature from STSADM command or you’re feature will be activated by another site definition feature which contains FeatureActivation dependency, the feature will be activated from within the Central Admin by creating a site collection. In both scenarios the context is different. So the .Net framework checks the GAC first and will find no assembly in the GAC. After the GAC the local bin folder (from stsadm or Central Admin web application) is checked and the assembly cannot be found there. Because the assembly resides in the bin folder of you’re web application.

This is the message you get:
System.IO.FileNotFoundException: Could not load file or assembly '<assembly>' or one of its dependencies. The system cannot find the file specified.

SOLUTION:
Put all you’re FeatureReceiver assemblies in the GAC.

As a SharePoint 2007 developer you have to use the stsadm command line tool to add a solution to the SharePoint solution store. You can do this with the following command:

stsdm -o addsolution -filename <the name of your solution (*.wsp) file>

This simple command takes up to 15 seconds on my development server. So I tried a simple stsadm command without parameters. And this command also takes 15 seconds.

I realised me a situation that the stsadm command was ready in 1 second. So I thought maybe it has something to do with the internet connection. (Because my development server is disconnected from internet)

I started googling and found this: “When you use authenticode signed assemblies in an application, the application needs to go out and check the certificate revocation lists (CRLs) to verify that the signature is still valid the first time it loads up the authenticode signed assembly. If the server, serving your asp.net application, doesn’t have internet access or if the internet connection is slow this can lead to issues where you stall the process during startup or when the assembly in question first loads.”

My experience in a disconnected scenario is that not only the first time the assemblies loads slow. It loads always slow, because the CRLs cannot be found and the network timeout is reached. Behind a firewall or proxy the stsadm commands are 2 times slower! The commands will always take place after the timeout period. So why should we wait for that?! 

For more information read the article:
http://blogs.msdn.com/tess/archive/2008/05/13/asp-net-hang-authenticode-signed-assemblies.aspx

SOLUTION:
The solution is to avoid checking the CRLs by adding the following code to the machine.config:

<configuration>
    <runtime>
        <generatePublisherEvidence enabled=“false”/>
    </runtime>
</configuration>

Be sure you have .Net Framework 2.0 SP1 installed. 

For more information about the hotfix visit the following website:
http://support.microsoft.com/default.aspx/kb/936707