What choices do we have?
In the days of MOSS 2007 and WSS 3.0 you had a couple of choices when deploying code to your server farm, Full Trust GAC deployment or bin/CAS deployment. With SharePoint 2010 you have another two options.
The two new options in SharePoint 2010 are Sandboxed solutions and a hybrid approach that gives you the ability to develop Sandboxed solutions that can call out to full trusted proxies.
For more reading to get an understanding of the execution models in SharePoint 2010 check out this MSDN article http://msdn.microsoft.com/en-us/library/ff798421.aspx
In part one I will discuss Full Trust deployment which is the easiest and most straightforward was of deploying solutions mainly because of the added complexity of getting the Code Access Security policies right in the bin/CAS model.
Most .Net developers will be familiar with deploying their assemblies to the GAC, we will all know that the assemblies have to be strongly named and we all know as SharePoint developers how to deploy our solution assemblies into the GAC but below I will outline exactly how to do this with SharePoint 2010.
We will create a basic event receiver and deploy this as a Full Trust solution to the farm then I will outline exactly how deploying our solution as Full Trust affects what the event receiver can do and what it can access.
- Create a new Event Receiver project in Visual Studio
- When you click ok you will be prompted to either deploy the solution as a Sandboxed solution or as a Farm Solution. We want to choose a farm solution which is basically saying we want to create a Full Trust solution that will be deployed to the server farms solution store. That also means that the assembly will be deployed to the GAC on every web server in the farm.
- VS will now ask you what type of event receiver you want to create, it doesn’t matter at this point because we are deploying a Full Trust solution which means that we can create any type of SharePoint component we like.
- VS will now create your project structure and give you some default code for your event receiver. We won’t create any functionality as our goal is just to show how to deploy the solution as full trust and what that actually means.
- Right click on the project file and select “Package” this will create our solution file (.wsp) in the bin folder of our project.
- When we open up the manifest.xml file within the solution file we can see that our assembly is being deployed to the global assembly cache (GAC)<?xml version=“1.0“ encoding=“utf-8“?>
<Solution xmlns=“http://schemas.microsoft.com/sharepoint/“ SolutionId=“a12ef36a-3f79-4d8f-801f-
<Assembly Location=“EventReceiverDeploymentExample.dll“ DeploymentTarget=“GlobalAssemblyCache“ />
<FeatureManifest Location=“EventReceiverDeploymentExample_Feature1\Feature.xml“ />
Great our assembly is in the GAC but what does this mean?
Well it means that any process can now load and use this assembly, only being restricted by the identity the process is running under. For example this means that it can be loaded by the, IIS worker process (w3wp.exe), the timer job process (owstimer.exe) and the workflow engine process. It also means that the code has no restrictions on what it can access outside of the assembly i.e. WCF web services and databases etc. Most importantly though it means it can access the full SharePoint object model and the full .Net framework class library.
Assemblies in the GAC will not be subject to the CAS policies defined in the web applications web.config file
That’s all good so why isn’t every solution a full trust solution?
Well in my experience nearly all MOSS 2007 solutions were deployed to the GAC as full trust solutions. This is mainly because the bin/CAS approach was hard to get right and most of the time offered little benefit over a GAC solution, bear in mind though that for security conscious applications like shared web applications and public facing internet sites that you may want to put in the effort to isolate your custom code at the web application level and deploy your solutions to the applications bin folder. I will cover this further in part 2.
In SharePoint 2010 however we get the option of a Sandbox solution and hybrid approaches which could offer you the best of both worlds.
In summary full trust solutions are often the easiest and straightforward solutions to deploy, however you must make sure that you fully trust the code being deployed as it can have farm wide performance and stability issues if the code crashes or causes memory leaks. The other issue is of course a potential security flaw in your code can compromised your whole server farm.
Another downside to full trust solutions is that I.T policies may be in place that mean full trust solutions are prohibited or may be subject to a full code review before being deployed.
For further reading on full trust solutions you can check out the MSDN article here which gives you some nice diagrams on exactly how SharePoint handles loading full trust assemblies. http://msdn.microsoft.com/en-us/library/ff798425.aspx