Skip to main content

Asp.Net 2 and 4 default application pool generates CS0016 IIS7.5

Before I start – if you’ve found a bunch of other articles about this around the net, tried the fixes that are mentioned and still not getting any joy – then read on – you might find this solves your problem.

Earlier today I discovered that when I run any ASP.Net 2 or 4 application through IIS7.5 using the default application pools (which use ApplicationPoolIdentity) on Windows 2008 R2 x64 I get an error message similar to this:

 

Server Error in '/MvcApplication31' Application.

Compilation Error

Description: An error occurred during the compilation of a resource required to service this request. Please review the following specific error details and modify your source code appropriately.
Compiler Error Message: CS0016: Could not write to output file 'c:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\mvcapplication31\222b4fe6\4e80a86\App_global.asax.clb4bsnc.dll' -- 'The directory name is invalid. '
Source Error:

[No relevant source lines]

Source File: Line: 0

(When running an ASP.Net 2 app, the version folder is of course different)

Now, I only just picked this up today (despite doing web dev on this machine build for the last 18 months) because early on I changed the Asp.Net 2 ‘DefaultAppPool’ to use Network Service as I needed the server to make web requests to web services (PayPal etc) through a corporate proxy that uses AD authentication.

Today, however, I started a project that will be using Asp.Net 4 for, and so I was using that app pool for the first time (and hadn’t touched it all since installing .Net 4.0, VS2010 etc).

I tried uninstalling .Net completely, reinstalling it, (re)installing Asp.Net 2 & 4 but no matter what, this always kept happening.

However, with either app pool set to use Network Service it all worked fine.

Now, using my google-fu I found a few links (http://support.microsoft.com/default.aspx?scid=kb;en-us;825791, http://dudesdoingdotnet.blogspot.com/2007/11/compiler-error-cs0016-could-not-write_2486.html and http://wiki.evident.nl/Default.aspx?Page=Compiler%20error%20CS0016%20The%20directory%20name%20is%20invalid), most of which suggest that the problem is to do with %TMP% or %TEMP% folder access for Network Service, or that the folder isn't present.

Well, clearly that wasn’t the case here as these run as the dynamic IIS APPPOOL\[app pool name] built in accounts that are created for the app pool, and not Network Service.  That said, I realised it's possible that the dynamic account didn't have access (or the group it belongs too), so I granted it full permissions on my %TMP%folder (it and %TEMP% both equal to C:\windows\temp) and tried again.


Still no joy.

Now the strange thing was that the folder had some pdbs and compiler traces in it – just no DLLs.  So clearly files were getting created and the identity was able to write to the folder – but what was so special about the DLLs?


I tend to swear quite a lot in the office to be honest, even when something not very bad happens; but after about the 5th or 6th time of failing to fix it I was raging.


So I came home, had some dinner and decided to jump on again.  This time I loaded up Process Monitor, set the filter to w3wp.exe only and watched as I generated the error again.  After more filtering I found entries for the file reported in the error, with the result ‘NAME NOT FOUND’ – but noticed that other files that were also successfully created also had this, so that couldn’t be it.


Then it dawned on me that the process to watch was not w3wp – but csc.exe (if using c#).  So I changed the filter and found loads of entries that referenced c:\Windows\ServiceProfiles\NetworkService\AppData\Local\Temp, with a status of ‘ACCESS DENIED’ – the user listed as IIS APPPOOL\Asp.Net v4 (for .Net 4 – it would be IIS APPPOOL\DefaultAppPool for .Net 2 on a default install of Windows Server 2008 R2).


So I gave the IIS_IUSRS groups full control of that folder – IISRESET for safety, and hit the site again.


Yay!  It worked!


So, in some cases, it’s not the root temp folder C:\Windows\Temp that you need to be looking at – but this other one that belongs to the NetworkService user profile.  The question is: why was this not already properly configured on my machine or, equally, is this actually the correct folder for the built in Asp.Net accounts?


My colleague’s machine didn’t have the same problem at all – so I have no idea why my machine (and I do look after it!) did.  Either way at least it’s now fixed!

Comments

  1. All I can say is thanks...would not have found this myself and u got me up and running in < 30 min after googling for about 3 hours.

    ReplyDelete
  2. I feel your pain. That sinking feeling when Google doesn't know the answer, and you're trying to craft your query endlessly to find it!

    Glad to have helped :)

    ReplyDelete
  3. Hi, Count.

    That process internals advice works for Windows Azure dotnet 4.0 cloud too :)

    Nice one. Microsoft are perverse.

    ReplyDelete
  4. Thank you! This happened to me too. I had to grant the local ASPNET user permissions to C:\Docs and Settings\{server}\ASPNET\Local Settings\Temp, restarted IIS, and it fired right up.

    ReplyDelete
  5. Thanks, it worked like charm! Couldn't figure out the process is csc.exe in process monitor :)
    Thanks a lot.

    ReplyDelete
  6. Thank you! After spending 8 hours chasing this issue this solution worked for me. I spent all day upgrading windows 7, reinstalling IIS, .net frameworks, and visual studion but nothing fixed this problem. This solution fixed!

    ReplyDelete
  7. All i want to say is...
    THANKS A LOT
    :)

    ReplyDelete
  8. This is great ! .. u really really helped me today.

    ReplyDelete

Post a Comment

Popular posts from this blog

Shameless plug - Use the new JobServe Web API to search for jobs your way

As my signature states - I work for JobServe in the UK.  Over the past few months I have been working on a new REST API (using the ASP.Net Web API from pre-beta to RTM) and it is now in official public beta. Now of course, this isn't just so your good selves can start running your own job searches using whatever web-enabled client takes your fancy, but that is one of the cool benefits that has come out of it - and that's why we're calling it a public beta. At the time of writing, you can use the API to run almost any job search that you can on the website.  As you would expect, you can get the results in XML or JSON (also GET requests with search parameters in the query-string are supported as well).  Note that JSONP is not currently supported - but it's slated for a future release. Sounds great, how do I get in? In order to get cracking with this - you need to request an API token .  This is not an automated process but we should be able to get you set up in a

Serializing to attributes in WCF with DataContractSerializer

It’s a common problem – you want to return an object from a WCF service as XML, but you either want, or need, to deliver some or all of the property values as XML Attributes instead of XML Elements; but you can’t because the DataContractSerializer doesn’t support attributes (you’re most likely to have seen this StackOverflow QA if you’ve done a web search).  Most likely you’ve then migrated all your WCF service code to using the XmlSerializer (with all the XmlElement/XmlAttribute/XmlType attributes et al) – and you’ve cursed loudly. Well, I’m here to rescue you, because it is possible – and the answer to the problem is actually inferred from the MSDN article entitled ‘ Types supported by the Data Contract Serializer ’. The example I’m going to give is purely for illustration purposes only.  I don’t have a lot of time, so work with me! Create a new Asp.Net WCF service application, you can use Cassini as your web server (probably easier – otherwise you might have to enable Asp.Net