SharePoint 2010: System DLL (System.Collections.Generic) is not in the GAC - how do I add it?

Question

I have a SharePoint project (named MyProject for this example) with an Application Page that references the namespace System.Collections.Generic. When I try to deploy the project, I get this error message.

Cannot add the specified assembly to the global assembly cache: MyProject.dll

If I remove the reference to System.Collections.Generic, it works fine.

I looked in the GAC on the SharePoint server, and the System.Collections.Generic DLL is not there! I assume that is the cause of my problem. How do I fix it?

EDIT: I just removed the solution, using the Central Admin web page. Then, I used the sharepoint commands Add-SPSolution and Install-SPSolution to install it again. That worked. The deployment was successful. The System.Collections.Generic DLL is still not in the GAC, as far as I can tell. That seems strange to me. I'm looking in C:\Windows\assembly. Is there another place this DLL could be?

EDIT 2: I made a small code change and tried to update the solution, using Update-SPSolution. The error is back. I tried removing from the Central Admin page, and adding and installing, as above. I still got the error.

To fix it this time, I did this:

1. Removed the solution using the Central Admin page.
2. Rebuilt the solution WITHOUT the reference to System.Collections.Generic.
3. Added and installed the solution using Add-SPSolution and Install-SPSolution.
4. Rebuilt the solution WITH the reference to System.Collections.Generic.
5. Updated the solution using Update-SPSolution.

I am glad to have a workaround, but this is not an ideal process. Is there something I can do to fix this problem?

EDIT 3: If I remove the solution before I get an error, it seems to be easier to get it to work. In that case, instead of running Update-SPSolution, I should just remove it using Central Admin, and then run Add-SPSolution and Install-SPSolution. It works, but I would still like to know what is going on.

EDIT 4: I found a possible cause and solution. I had been building the WSP file by running this command in the Developer Command Prompt:

msbuild MyProject.csproj /p:IsPackaging=True

However, if I instead right click on the solution in Visual Studio and select "Deploy", I don't seem to have any problems with deploying. I'll play around with it some more, but so far it looks promising.

What is the difference between that command and selecting "Deploy" in Visual Studio?

Answer 1

The classes in the System.Collections.Generic namespace is in System.dll and mscorlib.dll, so you won't find a DLL named System.Collections.Generic.dll.

Generics were introduced in .NET 2.0, so because SP 2010 requires .NET 3.5 to run, the namespace should be present in those DLLs. Make sure you're targeting the right framework in the project's build options (Right click on the project and select "Properties").

Edit:

To address your 4th edit, if you go to the project properties in VS and go to the SharePoint tab you can see (and configure) the steps that occur during the Deploy action.

The default configuration is:

• Run Pre-Deployment Command (if configured)
• Recycle IIS Application Pool
• Retract Solution
• Add Solution
• Activate Features
• Run Post-Deployment Command (if configured)

According to Tips & Tricks: Verify VS 2010 Packages WPSs [sic] Properly if you are building a project file using the msbuild command you should use the /t:package switch instead of the /p:IsPackaging=true switch.

The msbuild line you are running rebuilds the solution's WSP, but you're giving it a target of a project file. That may be your issue.

Answer 2

It sounds like you are dealing with a really old .Net 1.1 installation and need to update it to at least 2.0 in order to access Generics. Download and install the proper version and then try your deployment again.

You also might need to change your framework reference in Visual Studio as it likes to default to the latest it can get its hands on, regardless of what is available on the server. If you are trying to deploy a solution compiled for .Net 3.5 to a .Net 2.0 or 1.1 farm it will also throw errors like this.

Answer 3

There could be other reasons for the error message that you are getting:- "Cannot add the specified assembly to the global assembly cache: MyProject.dll"

Personally I think removing the System.Collection.Generic using directive was just a red herring.

Normally this error happens because a process is using the assembly and its locked.

What I suggest you do if you get the problem again is do the following:-

• IISReset or Recycle SharePoint Application Pools
• Stop and Start SharePoint Timer Service
• Stop and Start Web Analytics Service

The final culprit for locking the dll can actually be Visual Studio itself, particularly if you are developing on a server and any debugging has been going on. Unfortunately you will need to shutdown Visual Studio to release.

Hope that helps

EDIT: *Question 4 thoughts*

The msbuild command with /isPackaging:true parameter that you use will just package up the project into a .wsp, however it will not deploy the solution in the SharePoint Farm. An equivalent command in Visual Studio would the be the Package Solution (wording is something like that) command which is available via the right-click menu.

The Deploy action will depend on the command you have selected but, and this links in with my previous explanation, the command also does a application pool recycle which will release any references to the assembly as part of the deployment. So that might be way you have less problems with using Visual Studio deployment method.