Deploying the DLLs in a SharePoint solution to the GAC is pretty straightforward.
Firstly, ensure the assembly is signed by opening the Signing tab on the project properties in Visual Studio. Create a new key file (no password) and make sure the Sign the assembly box is checked. If you do this, you don't need to go through the whole sn -K and AssemblyKeyFile attribute process--Visual Studio takes care of it all.
Next, open the solution manifest (the SharePoint solution, not the Visual Studio solution...) and change the value of the DeploymentTarget for the DLL to be GAC'd from WebApplication to
GlobalAssemblyCache.
Rebuild your CAB file and re-deploy specifying the -allowGacDeployment stsadm flag with the deploysolution operation. Browse to %windir%\assembly and your GAC'd assembly should be present. The local \bin directory won't contain the DLL in question.
What about debugging and symbol (pdb) files? Apparently they can remain in the \bin directory but I haven't had much joy with this myself. Instead, I map a drive to \\{machine_name}\c$\windows\assembly\gac_msil\{version_publickey} and copy .pdb files across either manually or using a deploy script (see my debugging tricks).
Copy/paste internet code kills. Runtime comments on .net development, SharePoint WCM, and software engineering
Wednesday, 20 February 2008
Deploying SharePoint DLLs to the GAC
Labels:
MOSS,
SharePoint,
Software Development,
Things to Remember
Subscribe to:
Post Comments (Atom)
How exactly do you open the Sharepoint Solution Manifest?
ReplyDelete@Anonymous: a .wsp file is just CAB file with a different extension. You can either rename the .wsp file extension to .cab or use a utility like 7zip to open the .wsp as-is. From there you should find a file named manifest.xml, which you can edit manually--if you're old skool. If you're using VS2010 and SP2010, you can make this change directly in VS on the properties sheet for the solution.
ReplyDelete