Thursday, 22 July 2010

Deploying to GAC vs bin folder in SP 2010

Problem: Do we deploy our to the GAC or the bin directory.

Answer: It depends on what the dll is, who needs to use it and is the SharePoint farm dedicated. You need to understand Code Access Security (CAS). Key point is dlls in the GAC (Global Assembly Cache) have full privileges. dll's in the bin have restricted privileges. You can change the level of permissions for dll's in the bin using CAS policies. SharePoint has 2 policys you can use by default: WSS_Minimal or WSS_Medium (same options as in MOSS). You can also use ASP.NET's policies, there are about 5 of these policies in .NET and the highest level is the "Full Trust" CAS policy. You can also create your own policy. Change the CAS relating to you dll's in the bin via your applications web.config.

Only code that runs in the IIS workprocess can be placed in the bin.  Deploying to the bin minimises permissios but certain tasks such as timer jobs, workflows, service applications and event receivers only work in the GAC.  Deploying to the GAC allows for multiple versions of the dll to exist in the GAC provided versioning is used.  Bin deployment can't have multiple versions.

Note on Sandboxed solutions - runs is the "Microsoft SharePoint Sandboxed Code Service", sandboxed solutions have restricted rights to what it can do. It can permorm basic SP Server side OM's unde the SPSite (Site collection) object under the current SPSite which makes sense. Sandboxed code is deployed to the solutions gallery under the current SPSite. You can also use sandboxed solutions with code proxyies to achieve higher rights operations.  So as you can see sandboxed solutions do not go into the GAC or the bin and CAS is not an issue.  Real option is between GAC + using a Sandbox solution.

Sandbox solutions are good in restricted high usage environments as they allow SharePoint Administrators to validate (manually and via solution validators) the code being uploaded.  Developers are limited in what they can do to the environment.  The counter stop inefficient code once the threshold has been passed.  Administrators can monitor sandboxed solutions to easily identify poorly performing code.

My general rule is: Deploy my custom code to the GAC except if it's not trusted i.e. 3rd party code or there is a business reason/policy not to. It makes dev easier but is not ideal in that best practice decitates that you should apply the minimal levels of security permissions to your code.
Additional Info: Microsoft SharePoint Team Blog on application development.
Great blog on sandboxed solutions

2 comments:

kalpana said...

very useful

Chaitanya Sandeep said...

Point to Point. So clear. Thanks dude

Post a Comment