Wednesday 27 July 2011

SharePoint 2010 / Visual Studio 2010 - Error Occurred In Deployment Step - Access Denied

Occasionally, while developing a SharePoint 2010 Solution in Visual Studio 2010 I would be faced with the following error when hitting "Deploy":


Error occurred in deployment step '[various]': Access to the path '[path to a hive file]' is denied.


An IIS reset would fix the problem but I felt that this had to be just a workaround for a more specific issue - the error only occurred at certain times so there must had to be a specific cause for the file(s) being locked.


Short answer
The debugging web application that you chose when creating the SP2010 project in VS2010 is the only web application that is reset (well, its application pool is recycled, to be specific) when deploying a solution.  If any other web applications that use a different application pool lock any of the files that you are working on within your project then they will hold on to those files, causing the access denied error.



Long answer
When creating a SharePoint 2010 project within Visual Studio 2010 you are required to enter a URL that will be used for testing purposes.  This URL is then used to determine a number of things including: which web application to deploy to if/when the solution contains Web Parts, etc.; where to automatically activate features; and, crucially, which application pool to reset before carrying out the deploy.


If you choose a debugging web application that you then don't use for testing and instead use a different web application then you are at risk of seeing exactly this issue.  Bearing in mind this will only happen if the debugging web application has a different application pool to the one you are using for testing, when you start to make use of server templates, for example a site definition, the application pool will open one of the files (e.g. default.aspx) and keep it locked.  When you choose to deploy through Visual Studio it will recycle the application pool for the debugging web application but if this application pool is not being used for your testing, then the application pool for your test site will hang on to those files and you will receive the error.


Solutions
1) Update the debugging URL in your project properties to the web application that you are using.  Of course, if you are using more than one web application for testing purposes then if possible just re-use the same application pool and if this isn't possible then solution 3 may help


2) Ensure that the debugging web application's application pool is the same as the one you are using for testing.  I tend to create an application pool that I then use for as many web applications as possible as this is easier to manage and less intensive on memory usage.


3) Use WSPBuilder and use the context menu options to recycle the application pools.


4) IIS Reset (heavy handed but has the same effect as solution 3)