Visual Studio deployment with webdeploy causes permission issue

For certain applications, you might need to write/modify files on your site, e.g., logging, file based database, etc.  Recently, we have seen some customers reporting an access denied error when their application tries to write/modify files within their website.

We found that when you deploy your website using the WebDeploy feature of Visual Studio 2010, the deployment package actually contains couple of SetAcl rules

1. change the aspnet user to only have read access.
2. Change the aspnet user to have change (RW) access to the app_Data directory

This means that if the file you are trying to change is not within the app_Data directory, you’ll get an access denied error.

In theory, this concept is good because it makes your site more secure, however, there are some problems associated with it.

• You cannot tell VS.NET to change the rule to allow write permission to directory other than app_Data.  As a result, you will need to rewrite your application to store the updatable file within the app_Data directory.
• There’s no UI configuration to tell VS.NET to not mess with permission on the server

So…what do we do?

After some research, it looks like you can configure VS.NET to not change the NTFS permission when deploying using webdeploy.  The process is not very straightforward, but works nonetheless:

• Open your project file (.csproj or .vbproj) in notepad or any other text editor
• Navigate to the proper property group (you get one node for each compile configuration)
• Within this element
  • <propertygroup condition=” ‘$(Configuration)|$(Platform)’ == ‘Release|AnyCPU’ “>
  • Add <includesetaclproviderondestination>False</includesetaclproviderondestination>
  • You’ll need to add this line for each configuration that you want SetAcl disabled.
  • Save the project file
  • Reopen it with VS.NET
  • Note that by adding this, it will not “Fix” the permission on the server.  If any previous deployment changed the permission, you’ll have to contact our support team to reset the permission.

I am sure Microsoft will make some enhancements to VS.NET in the future releases.  In the meantime, you’ll have to use this rather tedious workaround.

Frank Cheung
CTO