Entries in "Microsoft .NET Framework"
Installing Assemblies Into Global Assembly Cache (GAC)
Overview:
If you are part of a development team that has created common assemblies that you reference in other projects, you should consider installing these assemblies into the Global Assembly Cache (GAC). Installing them in the GAC is especially helpful if many projects are referencing the same assemblies, because you only need to maintain your code in once location. No longer do you have to keep a copy of your referenced DLL(s) in each projects /bin folder.
Instructions:
We can break down the steps for installing an assembly into the GAC to:
1. Creating a key pair
2. Creating a strong named assembly
3. Installing the assembly into the GAC
4. Configuring Visual Studio .NET (optional)
1. Creating a key pair
Using the Strong Name tool (sn.exe) provided with the Visual Studio .NET SDK, we can create a public/private key pair that we will use to sign our assembly. The image below shows you how to create a key pair. Pay attention to the path, as the Strong Name toll will be located where you installed Visual Studio .NET.
Note: If other users need access to these shared assemblies, you need to verify that the key pairs you create are accessible at the machine level and not the user level. You can test this with "sn -m", and if you server is not already configured appropriately, an "sn -m -y" will enable your key pairs to be machine specific. You may also need to modify NTFS permissions or Local Security Policies for you developers so that they can access these shared assemblies.
2. Creating a strong named assembly
Now that you have create the key pair, the next step is to give you assebly a strong name. The simplest way is to modify the AssemblyInfo.vb or AssemblyInfo.cs file by providing some additional parameters, and then compile the project. The image below shows you what parameters to add (AssemblyKeyFile & AssemblyKeyName) and the values they need for our example. Once you compile, you have now created a strong name for this assembly.
3. Installing the assembly into the GAC
Now that your assembly has a strong name, you can install it into the GAC. The .NET Framework will not permit you to install an assembly without a strong name into the GAC. Once you build your assembly (StrongName.dll) in this example, you will need to create a location on the server to keep it. One approach is to create a folder under C:\WINDOWS\Microsoft.NET\Framework and place the DLL there. Once you have place the DLL there, using Windows Explorer, you can drag it to the C:\WINDOWS\assembly folder. The assembly folder is a special folder where the .NET Framework stores assemblies for the GAC. The images below shows you what the assembly folder looks like after dragging our assembly there.
4. Configuring Visual Studio .NET (optional)
As an optional step, you may configure your development server so that the assemblies you add to the GAC will automatically show up when you need to add a referenc to them via Visual Studio .NET. To accomplish this, you will need to modify the registry on you development server. The image below shows you the location and value for the new key we created for this example.
Now, when you open Visual Studio .NET (close & reopen if you already have an instance running), and go to add a reference to a project you will see that the assembly you added to the GAC shows up (just like the DLL included in the .NET Framework) without the need to browse for it. The image below illustrates this for our example.
Failed to start monitoring directory changes.
Overview:
The following information may be helpful if you are using Microsoft's .NET Framework to run an ASP .NET application from a Network Attached Storage (NAS) device via Universal Naming Convention (UNC) paths.
Description of Symptom:
Over time, upon requesting files (i.e. aspx, html, etc. - any you are processing with the .NET Framework), you receive the following message:
Failed to start monitoring directory changes.
This message appears to occur randomly.
Description of Problem:
The problem actually has to do with the number of simultaneous Server Message Block (SMB) connections that are allowed between the client (the Web server) and the server (NAS device). This parameter is controlled from the client via the following registry key
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\parameters\MaxCmds
and from the server via the following registry key (assuming this is a Windows Server)
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\parameters\MaxMpxCt
When establishing an SMB connection the lower of these two values is used to determine the maximumn number of simultaneous connections. The default value for the client (MaxCmds) is 50, so without manually adding this registry key, your Windows server (and thus your ASP .NET application) will be limited to 50 simultaneous connections to the NAS device. In practice, a one-to-one relationship exists between the number of folders beginning from the root of your application to the number of SMB connections. So if your application does not have more than 50 folders, you will never experience this problem. However, if you do have more than 50 folders in your ASP .NET application, you will receive the message noted in the symptom upon requesting the 51st folder. You can always monoitor the number of SMB connections opened from your Windows server via perfmon by the Redirector\Current Commands performance counter. Furthermore, you can always identify the maximum number of simultaneous SMB connections allowed between your server and the NAS device by examiming the network traffic from your server. If you run network monitoring software for some amount of time, you will then be able to find the exact value being used. The image below shows that during the session setup (SMB session between your server and the NAS device) the "Max MPX Requests" block will show you at the network level how many connections you will be able to utilize concurrently. It took some effort for us to get to 2048 (128 was "hard-coded" in the EMC NAS appliance we are connecting to), but this effort was worth it just for the knowledge I acquired.
