In SharePoint 2010 there are more ways to deploy custom code than in its predecessors, the reason is the introduction of the Sandboxed solutions. There are basically now three different ways to deploy custom assemblies:

  • Full trust solutions, aka Farm solutions - The assemblies are registered in the GAC and runs under full trust
  • Partial trust solutions, aka Web Application solutions - The assemblies are deployed to the bin folder of a specific Web Application
  • Sandboxed solutions, aka User code solutions - The assemblies (solutions) are deployed to the Site Collection gallery

These are the basic variants of how to deploy custom assemblies. There are actually a few variants of them, but more about them later. So which one should I use and when? Let’s go through them all and look at the pros and cons.

SharePoint 2010 is still in beta (RC for some) and there are no best practices of this. It’s hard to create a best practice before the product is released and actually tested in all situations. I guess we have to wait a few months until we have general best practice. Meanwhile consider this…

Sandboxed Solutions

The Sandboxed Solutions runs inside the a special service, called Microsoft SharePoint Foundation Sandboxed Code Service, which is a completely and separate application domain than the SharePoint application pools. The Sandboxed solutions are monitored and if they consume to much resources or fails to many times SharePoint automatically shuts the solution down. The code running in a Sandboxed assembly does not have access to the full SharePoint API, basically it’s just the classes from Site Collection level and below. The sandbox is also protected with a very minimal CAS policy which for example prohibits the user code solutions from calling web services, making database calls or accessing the file system.

Sandboxed solutions are deployed into the Solution gallery of a Site Collection and only access that Site Collection. They can be deployed without having any downtime of the farm or web application. Anyone within the Site Collection Administrators group can upload solutions to the gallery and activate them. Farm administrators controls how much resources each Sandbox can use and can also block specific solutions from running at all.

Pros

Cons

Can easily be deployed by Site Collection Administrators

Very limited CAS policy

Resource usage is monitored

* Current uncertainty about the monitoring stability

Secure

Hard to deploy in a farm

Great support in Visual Studio 2010

 

Only crashes the Sandbox if it blows

 

* There are currently many discussions in the blogosphere and on Twitter about how good the monitoring actually is. There is a timer job running that calculates the resource usage every 15 minutes, by default, and during 15 minutes a lot of things can happen.

I must admit that I was very skeptical at first to the Sandbox but the more I have tested and experimented with it the more satisfied I am. Also looking at my current day-job assignment I so much would like to have the Sandbox right now!

Farm Solutions

The Farm solutions or full trust solutions adds the assembly to the Global Assembly Cache, GAC, which means that they can run without any CAS policies, i.e. under full trust. The assemblies can be accessed from any application in the farm. Full-trust solutions are (was?) the most common way to install solutions since it is easy and requires no knowledge of for instance CAS policies. The code running in a full trust solution has the same access as the application pool account to the local server and can do almost what it want with the server. Deploying Farm solutions should only be done with code that you really trust.

Only farm administrators can upload new farm solutions to the configuration database and most often an application pool recycle is needed, especially when updating solutions.

Pros

Cons

Easy to implement

Only Farm Administrators can add new solutions (can be a pro also :-)

Great support in Visual Studio 2010

Downtime when updating

Runs in full trust

Have to much privileges

 

Can crash the whole server

Web Application Solutions

Solutions deployed to the web application bin directory was the way to go in SharePoint 2007 when you wanted/needed to secure you application using CAS. This partial trust option is still valid in SharePoint 2010. Web application deployed solutions by default only have a very minimal CAS policy applied. Using custom CAS policies it is easy (“CAS is easy!” - Todd Bleeker) to give more privileges to assembly. Installing these solutions also requires a Farm Administrator but they are only applied to specific Web Applications. Updating the assembly does not require an application pool recycle.

Visual Studio 2010 have support for Web Application deployment but not for custom CAS policies. If you need custom CAS policies you need to hack some XML and you cannot use the F5-debugging experience in Visual Studio. Instead you have to install the solution using PowerShell or create your own Visual Studio SharePoint Deployment Steps.

Pros

Cons

Security policies can be configured and kept minimal

Only Farm Administrators can add new solutions (can be a pro also :-)

Minimal downtime when upgrading

No support OOB for custom CAS policies in Visual Studio 2010

Only crashes the web application

 

Sandboxed Solutions with User Code Proxies

There is actually a fourth option of deployment. And that is to use Sandboxed Solutions in combination with a full-trust User Code Proxy. A User Code Proxy is a special assembly and class that is registered in the GAC and running under full trust. This class exposes an operation that can be called by the Sandboxed code. Since it runs under full trust we can easily create a Proxy Operation that calls a web service or access other protected (from the Sandbox) sources. The proxy has to be registered by a farm administrator and is accessible to the whole farm, which means that all developers who knows about the assembly, class and operation can use the operation.

Since the User Code Proxy runs under full trust you need to be careful about that one. But if you design your application carefully the proxy operations should be kept to a minimum and quite small. This allows you to make the thorough code review on only a fraction of the whole application.

Tip: Make the User Code Proxies as Farm solutions which are registered using Feature activation and unregistered using deactivation of the Feature. Then your farm administrators can enable and disable them easy!

My Recommendation

Which one to choose is up to you, your client and the SLAs. Based on my experience with SharePoint 2010 so far is that I do recommend that you always start with building your solutions as Sandboxed Solutions. If that is not enough then try to add one or more User Code Proxies. Only use full-trust solutions when you have no other option. And pleas do still consider Web Application deployment - even though Visual Studio doesn’t have that good support (right now, let’s see what the CKS:DEV team have up their sleeves)

What do you think?