Saturday, July 6, 2013

Automatically Clean Up Temporary ASP.NET Files

The Problem

One of the test environments I help maintain is subject to dynamic and regular changes in .NET applications. The development team are constantly releasing new builds that are slightly different.
You may not be aware that .NET applications go through a compilation process when they first start up. I’ve also been told on application pool recycle however I haven’t confirmed this. However, after the application has been removed or updated, the compilation temporary files remain. On a test environment similar to my above scenario, a total of 50GB of disk space can be easily wasted, doing nothing. So if you’re in a similar scenario, you may need to routinely clean up these files.
I know of four locations where these files can build up:
  • C:\Windows\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files
  • C:\Windows\Microsoft.NET\Framework64\v1.1.4322\Temporary ASP.NET Files
  • C:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files
  • C:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files
  • C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files
  • C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files
If you application pools run in 64bit mode, you’ll find the “Framework64″ locations more applicable. If your application pools use 32bit mode, you’ll need to consider the “Framework” locations.

A Few Notes

A reminder that files in these locations are normal. Don’t go over the top trying to clean them up.
It should be noted that while the files are in use by the web server, you will not be able to delete them – this is fine; the goal is to clean up unused files.
You should also be aware the next time the application fires up, on app pool start, the application will re-compile again. This may lead to a longer than average initial page load. If this is of concern, consider only removing files that are older than 30 days.
Of course, this script is provided as is. You should test it thoroughly in a test environment before use in production (though I certainly do).

No comments: