I have a raygun error on an Azure Web App that baffles me.

d:\local\Temporary ASP.NET Files\root\8c572dab\d52156ac\
error CS1528: Expected ; or = (cannot specify constructor arguments in declaration)

The error itself makes sense -- it's just a generated razor file that has a syntax error. It's the location of the generated file that baffles me.

This webapp is running a single instance. When I go to kudu for the app and browse around, though, I can't find that path. Instead, I see:

D:\local\Temporary ASP.NET Files\root>ls

Is there something fundamental about Azure that I'm missing? If this web app were able to scale out to multiple instances, I'd understand that I was maybe hitting the wrong instance with kudu. With there being only a single instance, though, I really don't get it.

  • the role might have recycled? – CtrlDot Jul 9 '16 at 22:25
  • @CtrlDot: thanks for commenting! I haven't done much with the role recycling, so please let me think aloud for a bit. If I am able to reproduce error multiple times, but the raygun error logs always show the same directory, but kudu never has that location, would that mean it's probably not a recycling issue? And, if the locations are changing in the logs, that might be more of an indication that recycling could be the issue? I'll read more into it. – rarrarrarrr Jul 11 '16 at 14:15
  • Yeah probably not related to role recycling the way you are describing it. – CtrlDot Jul 12 '16 at 2:49
  • Looks like its just a temp file generated by the compiler, and its lifetime will be very short - maybe for the duration of the request. – Russell Young Jul 12 '16 at 21:28
  • Yeah, perhaps temp files are handled differently in Azure vs local. I ended up running everything locally and could find the local temp file. That showed me the compilation issue I was having, so the Azure side is kind of moot for me now. I'm still curious, but I think this is one mystery I'll just have to let go. – rarrarrarrr Jul 13 '16 at 13:50

The location of temporary files for Azure Web Apps seems to always be D:\local\Temp. However, the entire D:\local folder is MOUNTED on different places for each web app by Azure.

This means that each web app will see a different D:\local, which is perhaps not too surprising. However, the real trick is that KUDU is by itself running as a separate process and gets its own private D:\local. So you are actually browsing KUDU's private D:\local and not that of your application.

Someone must have realized this can be a problem in debugging scenarios, so there is way to avoid this: add an app setting with name "WEBSITE_DISABLE_SCM_SEPARATION" and value "true" to your application through the Azure portal.

After the application has restarted then when using KUDU you should be able to see the same D:\local (including temporary files) as your application sees.

You should probably turn off this setting when you are done, as the default separation could be there for a reason.


Just found a (official) source, and further clarification, to the WEBSITE_DISABLE_SCM_SEPARATION(unsupported!) flag mentioned in Ole Tolshave's answer.

Kudu wiki page: Understanding the Azure App Service file system

Another important note is that the Main site and the scm site do not share temp files. So if you write some files there from your site, you will not see them from Kudu Console (and vice versa). You can make them use the same temp space if you disable separation (via WEBSITE_DISABLE_SCM_SEPARATION). But note that this is a legacy flag, and its use is not recommended/supported.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.