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.
Below is an example of a production environment using nearly 13GB:
Powershell Script to Automatically Delete Temp Files
As system administrators, we need to automate and script our workload so we can focus on the important stuff! So we devised a simple implementation of Powershell script which takes care of this clean up problem in one line:
Get-ChildItem “C:\Windows\Microsoft.NET\Framework*\v*\Temporary ASP.NET Files” -Recurse | Remove-Item -Recurse
If you’re reading this and thinking, EWWWW Powershell. Don’t mock it until you try this single line command.
I saved the above command into a file names CleanUpASPNETTempFiles.ps1 and saved it to D:\Tools\. Name and save yours as you see fit.
To take a load off, you can schedule this script with a scheduled task. You can click on these screenshots if you need more detail:
(I opted to run on the first Saturday of the month. Use your own preferences.)
(My powershell.exe was at %SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe)
(Note you need to tick the option box to get to the next screenshot or load the properties on the newly created task.)
Execution Policy Errors
If you’re being told to sign your newly created script, you can either do that for high security environments or you can turn off the signing requirement. It’s great to have this option build into the language but in the typical environment I’ve found it a burden.
In a Powershell command window, type the following to check your current ExecutionPolicy:
You can change it to Unrestricted by typing:
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).
- How to delete ASP.NET temporary files from shared server
- ISAPI Filter ‘C:\Windows\Microsoft.NET\Framework\v4.0.30319\\aspnet_filter.dll’ could not be loaded due to a configuration problem
- Renaming files with –– at the start
- 2 Reasons Why I Am rolling Back From Windows 8.1 to Windows 7
- What application pool is using all that CPU?
- Restore SQL Azure Backup to MSSQL Server
- How to Stop sidebar.exe Using Lots of Memory (Edited 14 May 2011)
- Windows sidebar.exe Memory Leak