Compilation error CS0016: Could not write to outpu

Question

In Brief

When I attempt to browse my website, I get the following error message:

CS0016: Could not write to output file 'c:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files\www\xxx\yyy\zzz\a.b.dll' - 'The directory name is invalid'

In Detail

I have two web-sites on my Development PC (fictitious names):

• Web2 - this is written in ASP.NET using .NET 3.5 and runs in an AppPool that addresses the v2.0 .NET framework and runs in an Integrated mode. This is developed using Visual Studio 2010
• Web4 - this is written in ASP.NET using .NET 4.5 and runs in an AppPool that addresses the v4.0 .NET framework and runs in an Integrated mode. This is developed using Visual Studio 2012.

Recently, I've been working in VS2012 on Web4 almost constantly and it works fine, however the other day I tried to run Web2 and got the exception displayed above.

Bizarrely, part of the path (which I replaced above with letters "zzz") appear to point to a German language path, since it's "\de-DE\" - I'm not operating in German, so I've no idea where it got this idea from.

One thing that is almost certainly un-related, but for some unknown reason I feel it's important to mention: I was using the Performance Analysis tool in Visual Studio 2012 the day before this problem first appeared and I don't know if this might have made some changes to my computer...??

Attempted fixes

There are quite a few threads regarding this on the internet; some threads end in success where file access permissions have been altered whilst others finish on a somewhat desperate sounding note... I have gone through the process of comparing the NTFS permissions on all relevant sounding directories on my PC with that of a colleagues on whose machine this is still working. Unfortunately, no joy to be had there.

I have also un-installed asp.net 2.0 and re-installed it using:

C:\Windows\Microsoft.NET\Framework64\v2.0.50727\aspnet_regiis.exe -u
C:\Windows\Microsoft.NET\Framework64\v2.0.50727\aspnet_regiis.exe -ir

and again, no joy to be had there either.

My Web4 continues to run unaffected.

Also FYI: using IIS 7.5 on Win7 x64.

I'm now turning to the this wider audience in the hope of turning my current state of despair into one of success.

Thanks everyone

Griff

Answer 1

In IIS Manager, in the advanced settings of the Application Pool, make sure "Process Model > Load User Profile" is set to "True".

I had this exact same problem. I tried changing permissions, disabling anti-virus, creating a new app pool, and reinstalling .NET. I even created a new site with just a "Default.aspx" page and tried to view that site. Even that site had the compilation error. Finally, I noticed that my app pools (clean test site and main site) had the non-default value "False" for the Load User Profile setting. I set that back to true and the issue went away.

Answer 2

In case the above answers didn't fix it for you, check your environment variables (right-click on Computer -> Properties -> Advanced System Settings -> Advanced tab -> Environment Variables

Make sure the temp variables are pointing to a folder with all the necessary permissions. (full access for Network Service, IIS_IUSRS)

Note: don't check just the two variables at the top, look inside the scroll menu under System Variables. You might find the variables configured there too.

Answer 3

The answer was found using ProcMon:

http://technet.microsoft.com/en-us/sysinternals/bb896645

The temporary asp.net files are first created in the user's temp folder and then moved into this folder. For some as yet unknown reason, the compilation for my Web2 site (.NET 2 AppPool) now uses the same folders as my Web4 (.NET 4 AppPool) site.

I used ProcMon to identify all results for "access denied" and gave the IIS_IUSRS group write permissions (and in one case - C:\Users\ASP.NET V4.0 Integrated - modify permissions).

I have no idea why the compilation is using the "wrong" folders and I suspect I may have over-elevated the permissions in some cases, but for now it's working.

Answer 4

It may not be the cause, but this error started occurring for me after trying to run VS 2010 Performance Wizard with the Instrumentation method.

A quick fix in my DEV environment: changed the Identity of the Application Pool of the app to LocalSystem.