Visual Studio and .NET Framework Home
Publish web site fails with "Access Denied" error when the config file contains impersontation credentials..
David A Nelson
as By Design
5/1/2008 8:23:46 AM
User(s) can reproduce this bug
A web site which is set (in the web.config file) to impersonate a user which does not have access to the logged in user's temp directory cannot be published. The only explanation is that Visual Studio is using the impersonation credentials from the web.config file during publishing, which makes no sense given that the impersonated user may not even exist on the development machine.
Visual Studio 2008 (All Products and Editions)
Windows XP Professional
Operating System Language
Steps to Reproduce
1. Create a new web site project. Set the location to http, and the path to a site in the local IIS web site.
2. Add a web.config file.
3. Right-click the project in Solution Explorer and select "Publish Web Site". Use the default options.
4. Add '<identity impersonate="true" username="User" password="password"/>' to the web.config file, where the user is a machine or domain user that is not an administrator.
5. Right-click the project in Solution Explorer and select "Publish Web Site". Use the default options.
Step 3 succeeds. Step 5 fails with the error message "Access to the path 'C:\Documents and Settings\<user>\Local Settings\Temp\<temp dir>\Default.aspx' is denied.
Step 3 and Step 5 should both succeed.
TAP Code (if applicable)
You can indicate your satisfaction with how Microsoft handled this issue by completing this quick
3 question survey
to post a comment.
Please enter a comment.
on 11/4/2010 at 1:26 PM
At the very least one should be able to set in the Visual Studio IDE 'where' the Temporary ASP.NET Files are getting written prior to publishing.
An IDE as evolved as VS2010 should have the ability to change from the default path 'C:\Users\[myLogin]\AppData\Local\Temp\~6c14\bin' or compile in the original (local) website folder.
Makes no sense to run around my hard drive granting write permissions in random places just to publish a website.
on 10/7/2009 at 7:55 AM
I am have the same problem in Windows 7. I have tried to give user permissions to temp as well as web app. One way I have found to go around this is to start vs2008 as administrator. I would hope there is a easier answer, as it will be a pain to remember which sites need impersonation. Always starting vs2008 with run as administrator just doesn't seem right, as this was one of many complaints against Vista. Granting rights to folders works fine in XP. Any other ideas?
David A Nelson
on 7/3/2009 at 6:48 PM
Seeing that it is 14 months after I initially reported this issue, I have not worked on the project in which it was initially observed in quite a while. I do not remember the particulars of the impersonation behavior during development. I will attempt to reproduce the development behavior I described when I have time.
HOWEVER, whether or not the development behavior works as I described in my most recent comment is NOT relevant to the bug as it was initially reported. I will state it again, for the fifth time: there is no reason to use a run-time impersonation identity to perform a compile-time task. Not only is it simply unnecessary, but it significantly complicates the development and publish process, for no benefit whatsoever.
on 7/1/2009 at 7:22 PM
Thank you for your response and feedback.
We are trying to test out a scenario similar to yours.
- Windows XP Pro SP3, joined to a domain
- VS2008 Version 9.0.30728.1 SP, with Microsoft .NET Framework 3.5 SP1 (In VS2008, go to Help -> About Visual Studio)
- System.web.dll has file version: 2.0.50727.3053 (Start windows explorer, go to \windows\microsoft.net\framework\v2.0.50727\, right click on System.Web.dll and choose “Properties”, then click on the “Version” tab)
- Impersonated identity does not have any special rights on the machine.
1. Login as a domain user who is also the administrator of the machine.
2. Start VS2008.
3. File -> New -> Web Site
4. .NET Framework 2.0, HTTP, C#, http://localhost/website2
5. From solution explorer in VS, open (double-click) web.config.
6. Add the following to web.config (using a valid existing domain user that does NOT have any special rights on the local machine):
<identity impersonate="true" userName="mydomain\myuser1" password="mypassword"/>
7. Build -> Rebuild Web Site
8. Get the following error:
Error 1 Access to the path 'D:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\website2\49bdbf3c\cd8ab1ab\default.aspx.cdcab7d2.compiled' is denied.
9. Build -> Publish Web Site
10. Choose the default path:
[. . .]\My Documents\Visual Studio 2008\Projects\WebSite2\PrecompiledWeb\WebSite2
11. Get the following error:
Error 1 Access to the path 'D:\Documents and Settings\[someuser]\Local Settings\Temp\~b98\bin\default.aspx.cdcab7d2.compiled' is denied.
12. In solution explorer, right click Default.aspx, and choose “View In Browser”.
13. Get the following error in the browser:
The current identity (mydomain\myuser1) does not have write access to 'D:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files'.
We get errors when building (step 7-8), publishing (steps 9-11), and running (steps 12-13).
To clarify, are you getting errors only when publishing from VS, but not during building and running? If that is the case, perhaps that could mean the impersonated identity you are using has permissions to the Temporary ASP.NET Files folder, but not the user's local temp folder?
David A Nelson
on 7/1/2009 at 5:35 PM
I misspoke. We operate in a domain, so technically all of the users "exist" on every machine, and they cannot be deleted. But giving the impersonated user access to a particular directory is not a valid solution. We operate under a policy (which is not unusual across the industry) that any developer should be able to check out and use any project at any time, to make sure that no single developer or machine is a point of failure. What is going to happen when the next developer tries to check the project out from source control and can't publish it?
It should also be noted that there is no problem with developing the web site, even with the impersonated user in the web config. It is ONLY when publishing that this problem occurs.
on 7/1/2009 at 4:58 PM
Thank you for your feedback.
Our testing has shown that on a Windows XP machine, if you precompile a http web site in VS2008 using an impersonation identity that does NOT exist on the build machine, or an identity with incorrect credentials, then precompilation will succeed without errors. However, trying to run the web site (using “View in Browser”, or by accessing http://localhost/website1 ) will report a logon error saying that the user token cannot be created.
Suppose you are doing development, and using an impersonation identity that DOES exist on the machine, but does NOT have sufficient rights to the necessary folders. You will be getting access denied errors when you try to precompile the web site, AND when you try to run the web site (using “View in Browser”, or by accessing http://localhost/website1 directly, thus triggering dynamic compilation). Once you grant the necessary permissions, both precompilation and running will work without errors.
If you are doing only a build, then you can delete the user you are trying to impersonate from the build machine, since that impersonation identity is NOT required on the build machine during precompilation. Note that the impersonation identity should exist on the server the web site is deployed to.
Your repro steps mention in step 4 that for impersonation, “the user is a machine or domain user that is not an administrator”. However, you also mentioned in your previous message that “The impersonated identity doesn't even exist on the machine on which the code is being developed and precompiled”.
If you are doing development, then the recommendation is to grant the required permissions to the impersonated identity, so that you can build and run the web site.
If you are only doing a build, then the recommendation is to use an identity that does NOT exist on the build machine (or an identity with incorrect credentials).
David A Nelson
on 6/30/2009 at 1:29 PM
We seem to be having difficulty communicating. I am aware of the ASP.NET compilation process, both dynamic compilation and precompilation. I am aware that the compilation process needs access to the Temporary ASP.NET Files folder. I am aware that the error message I am seeing is because the impersonated identity does not have access to that folder. What I am trying to tell you is that I shouldn't be getting the error because precompilation should not be impersonating at all!
Impersonation is a run-time setting; it controls the security context under which I want my code to run. Precompilation is, redundantly, a compile-time process; it occurs BEFORE the code runs to prepare the code to be executed. The two contexts are completely separate. There is no reason to be using the impersonated identity during precompilation. The impersonated identity doesn't even exist on the machine on which the code is being developed and precompiled! It only exists on the server. It makes no sense to use a run-time identity to perform a compile-time task. THAT is the bug.
Removing the impersonation identity and using Web Deployment Projects to add it back might work, but that is a very heavyweight mechanism to fix a very simple bug, and it will complicate testing and deployment significantly.
on 6/26/2009 at 8:39 AM
We apologize for the delay, and are sorry that the previous explanations were inadequate.
ASP.NET compilation has several compilation modes depending on how the web site is set up. For a normal web site that is NOT precompiled for deployment, but is deployed directly to the server, dynamic compilation happens on the server during runtime to generate code for aspx/ascx pages into assemblies so that they can be served. During dynamic compilation, code and assemblies are generated into the Temporary ASP.NET Files.
When a web site is precompiled for deployment, what happens is that the compilation process is normally invoked during runtime is now invoked, and for all the files. There is still code generation involved for the aspx and ascx files, which are generated into the Temporary ASP.NET Files folder, and compiled assemblies go into the Temporary ASP.NET Files foler as well. After all the necessary assemblies are compiled, the assemblies are copied from the Temporary ASP.NET Files folder to the destination folder.
If you try to run your web site as it is WITHOUT precompilation, by browsing to http://localhost/website/ , you will see an error message to what you are seeing when you try to publish. This is because the impersonated identity needs both read and write access to the Temporary ASP.NET Files folder.
A possible workaround is for you to grant read/write permissions to the impersonated identity to the Temporary ASP.NET Files folder.
Another workaround is to remove the impersonation identity from web.config, and either add it back manually upon deployment, or use Web Deployment Projects to automatically add back the in the impersonation identity to web.config during publishing. Note that on the server you will also need to grant read/write permissions to the impersonated identity to the Temporary ASP.NET Files folder.
David A Nelson
on 6/23/2009 at 11:50 AM
Another nine months, and still the problem has not been addressed...
I still don't understand why you are writing to the Temporary ASP.NET Files folder. That folder is used by the ASP.NET process for website operation. Pre-compilation occurs before the website is run and does not involve the ASP.NET process. You should be writing You should be writing to the system temp folder, which all users generally have access to.
But regardless, there is no reason to perform the pre-compilation using the impersonated identity. That identity only needs to be used at run-time to execute the website. There is no reason to use it during the publishing process, and especially not for compilation!
on 6/23/2009 at 10:52 AM
Publishing involves precompilation, requires writing to the Temporary ASP.NET Files folder. This is because we need to generate actual C#/VB code for markup in the pages and controls, and a place holder for compiled assemblies before they eventually get copied over to the destination folder.
on 12/17/2008 at 12:37 PM
I was able to get publishing to work with impersonation enabled by adding write permissions to the account being impersonated to the directory where my project is located and applying those additional permissions to the child objects.
David A Nelson
on 9/18/2008 at 12:14 PM
You took 4 and a half months to respond WITHOUT addressing the problem...
This problem is occurring during the publishing phase. There is no reason why publishing should need to write anything to Temporary ASP.NET Files. The article you refer to only applies to web applications running under the ASP.NET process; but that process is not (or should not) be involved in publishing, which is merely the process of precompiling and pushing files to the appropriate place on the server.
on 9/18/2008 at 5:58 AM
Thank you for your feedback.
The impersonation identity needs access to the Temporary ASP.NET Files folder, as described in the following article:
The workaround would be to compile and publish without the impersonation first, and then add in the impersonation later. You can also try using Web Deployment Projects to modify the web.config upon publishing.
David A Nelson
on 7/1/2008 at 1:51 PM
Two months later...any progress on this?
on 5/2/2008 at 12:34 AM
Thanks for your feedback.
We are escalating this issue to the appropriate group within the Visual Studio Product Team for triage and resolution.
These specialized experts will follow-up with your issue.
Visual Studio Product Team
to post a workaround.
Please enter a workaround.
on 10/12/2011 at 2:16 PM
Workaround: Uninstall KB2446708
Note: Uninstalling critical windows updates is probably a bad idea. It will fix the issue, though.
on 1/5/2011 at 7:32 AM
Grant everyone write permissions to the temp folder.
© 2013 Microsoft