Why I prefer WebApplication deployments over GAC deployments

Why I prefer WebApplication deployments over GAC deployments

This article is written with scope on SharePoint 2013. With SP 2013 the default TrustLevel in the web.config is set to “FullTrust”. On previous version the value is “WSS_Minimal”.

When you develop Farm-Solutions for SharePoint, you can deploy assemblies to the Global Assembly Cache (GAC) or configure the solution for a “bin-Deployment”.

The bin-way puts assemblies into the bin folder of the WebApplication, where the solution is deployed to.

You can switch the target of the assemblies by modifying the properties of a SharePoint project. The default value is GlobalAssemblyCache.

What does the changed property do to your solution?

Changing the value to WebApplication will deploy the assembly to the bin-directory of your IIS directory, as mentioned earlier. Because of the narrowed scope of the assembly, only the associated application pools needs to be recycled.

The classes you implemented, will be available only to your Website, which is fine in most cases. Assemblies within the GAC are available for all processes on the server.

In the past (prior SharePoint 2013) assemblies did not have FullControl permissions if they were deployed to the bin-directory. Instead Partial Trust was granted with the “WSS_Minimal” policy. A custom Code Access Security (CAS) had to be configured.

An advantage was the least privileges approach, a disadvantage the overhead of creating this CAS.

This is a list with advantages and disadvantages for bin-deployments. Pick your items and weight them the way you prefer.

My result was to deploy to bin, if possible. The faster development and deployment together with minimal impact on productive servers was worth it.


  • Faster Deployment – With a GAC Deployment all application pools (incl. CentralAdministration) will be recycled
  • Less impact on other components


  • TimerJobs need assemblies within the GAC
  • Using Feature Receivers, you’ll need to recycle the CentralAdministration application pool as well. Otherwise activating a Feature through the UI, could load the old assembly
  • Only one version of an assembly

What do you think? Why do you deploy to bin or to GAC?


jeff angama



Thx you for your article explaining the web / gac deployment ! It helped me !

Personnally I abuse deploying everything to GAC

-If I want to make a feature available for all the farm (never know, some feature could be implemented on other web applications)

-No cons for me regarding the deployment on production deployment because we deploy at a time when nobody use the websites
-Security wise ? probably

See ya !


Georg Begerow


I have come to hate GAC Deployment with SharePoint. In normal Webapplications you have a turnaround time of a few seconds, SharePoint without GAC a few minutes. But withe the assembly in GAC you much more often than not need to reboot the whole machine to get rid of locks from TimerJob, Custom BCS provider or EventReceiver and last but not least Visual Studio. Even if your deploy runs without failure, you might have just changed a shadow copy and your next request grabs the old version. But you only see it after recycling and rejitting the whole SharePoint. Unittests of this library are more or less impossible or at least hard to use.

If you have to have GAC Deployment, try to minimize sharing of that library. If you need to share with a Webapplication or Unittest, consider to include those classes via “Add as Link”, instead of adding a reference to the dll, and only deploy after full test coverage.


Leave a Reply