I have approximately 900 applications running on the server where each one points to a folder that contains content that is about 215MB in size.

When I noticed that my server's hard drive was almost full, I did a scan with WinDirStat and found the C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files folder to be 300gb in size.

In the base of that folder, I have one folder for each application I have, which is normal I imagine. However, under this I have many folders that look to be different hashes:

\Temporary ASP.NET Files
        \ ... (10 more)
        \ ... (4 more)

When I inspect the various folders some look to be from years back.

My typical workflow when I deploy a new version is I create a new folder with the web files, and then I will point an existing IIS application to the new folder. I am wondering if that is what is causing my artifacts above.

Currently to mitigate the issue I am deleting the older files manually, I can also create a script to do so, but to me it seems to be a fragile solution to something that shouldn't even be a problem to begin with.

Why is my temporary ASP.NET folder growing wildly? It seems ASP.NET is not managing it properly. Is there an expectation that I should be monitoring this (even though it's in the Windows folder)?

  • 1
    The software I am hosting is leveraging ASP.NET dynamic compilation. I'm not sure that 'leveraging' is an accurate description, but you crystallized one of the main reasons why pre-compiling is useful. – Greg Askew Jul 29 '16 at 15:33
  • Sorry @GregAskew I used the wrong terminology, my MVC views are compiled dynamically, my applications binaries are pre-compiled by our build server. I have updated the question to remove this. – Alex Denysenko Jul 29 '16 at 15:40
  • Given the large number of applications and some of data is old, I'm not seeing this as a problem. You could probably implement a one-line computer startup script that clears out the folder on each restart to prevent the accumulation. – Greg Askew Jul 30 '16 at 15:06

Your Answer

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

Browse other questions tagged or ask your own question.