Compiler Error Message: CS0016: Could not write to output file 'c:WINDOWSMicrosoft.NETFrameworkv1.1.4322Temporary ASP.NET FilesMyAppfadda49ebbdb0b87eqdatzch.dll' -- 'Access is denied.'
What I like about the above error message is the part which says 'Access is denied.' These are some of the easiest issues to fix!! Right?? Well in most cases 'Yes'. All you have to usually do is give the Process Account or Impersonating thread identity required NTFS access to the resource. The reason I like working here in PSS is because you get to work on issues which will blow your mind (EVERYDAY). Most customers would have already Googled for a solution and tried an extensive list of things trying to fix the issue. If they haven't already done that, then they are calling because the WebSite is down and the business impact $$$$$$$$ is "HUGE".
In this case the customer was of the former type. He had tried everything to fix the issue but to no avail. To give you a little background on the issue, the Web Server was a Windows 2003 SP1 server(IIS 6.0) running an ASP.NET WebService. The App used to work fine until it threw the above error. According to the customer, the only way to recover from the problem was to repeatedely reboot the machine and the error would go away. I had never heard of anything like this before. Neither have the 3 Engineers who worked on this issue before engaging me to have a go at the problem heard of anything like this. The typical way to troubleshoot this problem would be to verify that all the permissions and policies were in place as per the knowledge base article Process and request identity in ASP.NET: https://support.microsoft.com/kb/317012 .
The AppPool identity was the default "Network Service" account. After verifying kb317012 a dozen times we were still getting the error. The bizzare part was that "Network Service" account had Full Control on "c:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files" folder but running Filemon would still show Access Denied for the "Network Service" account on "c:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files" folder. The Engineers had tried various way to troubleshoot the problem. They tried changing the AppPool Identity to a domain account but this resulted in the same error and Filemon now showed Access Denied for the domain account. This is about when I came in and I requested the customer to allow us to view his desktop via a Live Meeting.
Working here for over 2 yrs has taught me never to trust anyone, especially customers. In this case I didn't trust my fellow Engineers as well so I went through all the same troubleshooting steps they had done (I dont like making assumptions without hard facts). This dosen't go down too well with customers as nobody wants to try the same steps repeatedely, if you already know its not going to help. While I was checking the NTFS permissions for the Network Service account on "C:\Windows\Temp" something caught my EYE and I made sure I took a PRINTSCREEN so that I can share this information with you :)
RESOLUTION
===========
If you notice clearly, the "C:\Windows\Temp" location is not a folder but a Mounted Drive. If you then click the Security Tab for "C:\Windows\Temp" you can see the Network Service account present with FULL CONTROL. Instinct tells me that this may be related to the issue so the next logical step would be to isolate the problem and see if changing the "C:\Windows\Temp" helps.
I changed the values of the TMP and TEMP System Environment variables to point to "C:\TEMP" instead of "C:\Windows\Temp" and this resolved the issue.
IIRC they had the "C:\Windows\Temp" location set up as a mounted drive to store huge number of files there which were getting writin by some other application. Somehow ASP.NET didnt like it.
Now you might still wonder, why do we get the error if all the permissions seem to be in place?? As much as I would have liked, I couldn't invesitigate further since we already had an acceptable solution as it is not worth the time and effort to find out why mounted volumes are causing the issue.