Due to the lack of some functionality, I wrote a class library which contains some extension methods for the SPWeb object. At that time the problems began.
- VMWare machine with MOSS 2007 on a Win2003 machine for development and test purposes
- Visual Studio 2008 with WSPBuilder extension
- Solution with several WSPBuilder web part projects
- Custom class library SPExtensions.dll
The deployment of the first WSPBuilder project deployed the class library into the GAC. This will affect the build process of the other two WSPBuilder projects. Those two wsp-packages do not have the class library dll in it. This happens even the referenced dll property "copy local" is set to "true". This was/is a real PITA! Because after updating the SPExtensions project, the new dll was not updated in the GAC for the 2nd and 3rd project (because the dll is not included in the wsp file).
So I want the SPExtentions.dll deployed to the WebApplication bin and not in the GAC. After some search and trial and errors I found the solution to get this job done.
- Make sure the SPExtensions.dll (or whatever your class library is called) is not present in the GAC anymore. You can use gacutil to uninstall the assembly.
- Created a '80' folder with a 'bin' subfolder inside all of the projects (e.g. ..\ProjectFolder\80\bin) that uses the SPExtensions.dll.
- Create for each of these project a post build event:
move /Y "$(TargetDir)SPExtensions.dll" "$(ProjectDir)80\bin"
NOTE: You should use the "move" command and not the xcopy. The WSPBuilder (by default) sets the DeploymentTarget of the assemblies found in folders, other than GAC and 80\bin to GlobalAssemblyCache. So make sure you move the SPExtensions.dll from the ProjectFolder\bin\release (or debug) to the 80\bin folder created in step 2.
- Now you can build the project, create the wsp-files and deploy (or upgrade) them. After step 3, I used the "clean" option, just to be sure that I do not get messed up with some left crap.
Post a Comment