Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

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?

share|improve this question
add comment

3 Answers

up vote 1 down vote accepted

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.

share|improve this answer
    
Thanks for the tip on the DLLs. The namespaces must be there, because I can get it to work eventually. See EDIT 2 in the question. –  Jeremy Jan 31 '13 at 19:45
    
Yes, the VS project has a reference to System.dll. –  Jeremy Jan 31 '13 at 19:52
    
No, I am not deploying from VS. I use VS to build a wsp file. I copy that wsp file to the server and run Update-SPSolution (or Add-SPSolution and Install-SPSolution if it doesn't exist.) –  Jeremy Jan 31 '13 at 19:59
    
Are you running the shell as an administrator? Other than that I'm out of ideas. Most of the time an error like this occurs is if the deployment either can't remove the old DLL from the GAC (DLL in use, permissions, falls over) or if it can't add a new DLL to the GAC (permissions, falls over). You could try the force switch on Update-SPSolution if you haven't yet, but no guarantees. –  RJ Cuthbertson Jan 31 '13 at 20:11
    
I am running the shell as administrator. I do have one other idea - see the latest edit (EDIT 4). –  Jeremy Feb 1 '13 at 19:12
show 1 more comment

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.

share|improve this answer
add comment

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.

share|improve this answer
    
Just curious, is it even possible for the SharePoint server to not have at least .NET 3.5 installed? –  RJ Cuthbertson Jan 31 '13 at 19:35
    
2007 required .Net 3.0, 2010 required 3.5 SP1 and 2013 requires 4.5. However, I'm pretty sure that SP 2003 could run using 1.1 though the actual requirements page is somewhat vague : technet.microsoft.com/en-us/library/… –  Dave Wise Jan 31 '13 at 19:42
    
The server has .NET 4.0. See my latest edit (EDIT 2) - I can get it to work, eventually. So that reference must be there. –  Jeremy Jan 31 '13 at 19:43
    
@DaveWise, didn't even think about WSS 3.0 or 2007. I (foolishly) assumed 2010... –  RJ Cuthbertson Jan 31 '13 at 19:51
    
Jeremy, if you look in the Project Properties in visual Studio, does the target .Net version there match the server? If not, that will also cause the error you show –  Dave Wise Jan 31 '13 at 20:03
show 2 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.