Failure due to Assemblies in the GAC

Feb 19, 2008 at 12:51 PM
I am trying to upgrade WSPBuilder from 0.9.7.1205 to the latest version 0.9.8.0206. But I now get an error that I did not use to get.

The Assembly 'MyAssembly, Version=1.1.0.0, Culture=neutral, PublicKeyToken=XXX' has been found in the Global Assembly Cache, please remove this from the Global Assembly Cache before continue building the WSP package.
at Keutmann.SharePoint.WSPBuilder.WSP.SolutionHandler.GetAssembly(String file name)....

The problem is that we install the dlls into the GAC when deploying the SharePoint Solution. Why cannot the DLLs be in the GAC anymore? It used to work. Why not just look at the version in the GAC folder and ignore the GAC itself?

// Mats
Coordinator
Feb 20, 2008 at 8:09 AM
This is by design, properly because you have referenced the assembly from another dll, the WSPBuilder is therefore not able to add the DLL to the WSP package if the DLL is located in the Global Assembly Cache.
The solution is to remove the problem DLL from the Global Assembly Cache and then build again.

However I'm currently looking at using Mono.Cecil to solve this kind of problems and assembly reflection in general.

/keutmann





boisen wrote:
I am trying to upgrade WSPBuilder from 0.9.7.1205 to the latest version 0.9.8.0206. But I now get an error that I did not use to get.

The Assembly 'MyAssembly, Version=1.1.0.0, Culture=neutral, PublicKeyToken=XXX' has been found in the Global Assembly Cache, please remove this from the Global Assembly Cache before continue building the WSP package.
at Keutmann.SharePoint.WSPBuilder.WSP.SolutionHandler.GetAssembly(String file name)....

The problem is that we install the dlls into the GAC when deploying the SharePoint Solution. Why cannot the DLLs be in the GAC anymore? It used to work. Why not just look at the version in the GAC folder and ignore the GAC itself?

// Mats

Feb 20, 2008 at 10:10 AM
Ok, but the then strange thing is that is used to work with version 0.9.7.1205.

// Mats
Jun 27, 2008 at 3:57 AM
We had the same problem. It looks like it happens when you have two assemblies, both included in the solution and one of them referencing the other one plus having the referenced assembly deployed to the GAC at the time you try to run wspbuilder.

Things were even worse for us as we have the WSPBuilder as a post build action in VS.NET and even that wspbuilder didn't succeeed, VS would still report that the build was successful.

To resolve the issue we added calls in the post build actions to gacutil.exe to remove the assembly from the GAC before running wspbuilder and then optionally adding it back in the GAC after that. Also you could check whether %ERRORLEVEL% == 0 in after wspbuilder call returns. A non zero value will indicate an error and you could make the VS build to fail in that case.

Hope this helps someone.

Cheer,
Hristo Pavlov
Jun 4, 2009 at 7:34 PM
Edited Jun 4, 2009 at 7:35 PM

In my case, I'm getting this error only after adding a required dependency to be copied local (so that wspbuilder would pick it up and package with the wsp).

 

The strange thing is .. the other 2 assemblies which were already copied local AND being successfully built into the WSP are also in the GAC, yet i did not recieve the error.

 

ideas? :(