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.

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:

Get-ExecutionPolicy

You can change it to Unrestricted by typing:

Set-ExecutionPolicy Unrestricted

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).

Similar Posts:

VN:F [1.9.22_1171]
Rating: 4.0/5 (4 votes cast)
VN:F [1.9.22_1171]
Rating: +2 (from 2 votes)
Automatically Clean Up Temporary ASP.NET Files, 4.0 out of 5 based on 4 ratings
Tags: , , , .

10 Responses to Automatically Clean Up Temporary ASP.NET Files

  1. Jan Reilink says:

    PS: You can also change the default Compilation path for .NET with AppCmd.exe, for both 64-bit and 32-bit:

    `C:Windowssyswow64inetsrvappcmd.exe set config /section:compilation /tempDirectory:D:temp /commit:WEBROOT /clr:4`
    `C:Windowssystem32inetsrvappcmd.exe set config /section:compilation /tempDirectory:D:temp /commit:WEBROOT /clr:4`

    and this also goes for .NET 2:
    `C:Windowssyswow64inetsrvappcmd.exe set config /section:compilation /tempDirectory:D:temp /commit:WEBROOT /clr:2`
    `C:Windowssystem32inetsrvappcmd.exe set config /section:compilation /tempDirectory:D:temp /commit:WEBROOT /clr:2`

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    VA:F [1.9.22_1171]
    Rating: +1 (from 1 vote)
  2. Jan Reilink says:

    If you have a larger partition available you can move the “Temporary ASP.NET Files”, just as you can move the SoftwareDistribution folder. See https://www.saotn.org/windows-server-2012-r2-disk-cleanup-dism/ for information on that.

    Steps to take to move Temporary ASP.NET Files to D:
    1. shutdown IIS (`iisreset /stop`)
    2. create “D:Temporary ASP.NET Files” (`mkdir “D:Temporary ASP.NET Files”`)
    3. remove the “C:WindowsMicrosoft.NETFrameworkv4.0.30319Temporary ASP.NET Files”
    4. create a junction poining from the old location to the new: `mklink /J “C:WindowsMicrosoft.NETFrameworkv4.0.30319Temporary ASP.NET Files” “d:Temporary ASP.NET Files”⁠`

    Of course you have to make sure file permissions on “D:Temporary ASP.NET Files” are set up correctly. Then start IIS again: `iisreset /start`, and everything should work fine.

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    VA:F [1.9.22_1171]
    Rating: +1 (from 1 vote)
  3. Nehemiah Jeyakumar says:

    Nice and Simple !

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    VA:F [1.9.22_1171]
    Rating: +1 (from 1 vote)
  4. Boris Schubert says:

    Nice, simple and useable. 🙂

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    VA:F [1.9.22_1171]
    Rating: +1 (from 1 vote)
  5. saddam says:

    please upload video i can’t understand

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    VA:F [1.9.22_1171]
    Rating: 0 (from 0 votes)
  6. BillV says:

    Thanks. Very informative and helpful.

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    VA:F [1.9.22_1171]
    Rating: 0 (from 0 votes)
  7. Armand says:

    Nice one! One command did the trick, now I can run it even without an IIS RESET. Thumbs up thanks for sharing

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    VA:F [1.9.22_1171]
    Rating: 0 (from 0 votes)
  8. Brendan says:

    Thanks for sharing TF!

    VN:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    VN:F [1.9.22_1171]
    Rating: 0 (from 0 votes)
  9. TF says:

    Hi,

    Just wanted to mention that with more recent versions of PowerShell (2.0) you can user a parameter instead of changing the ExecutionPolicy for the entire system. Makes it safer to just bypass for the script you want to run.

    If you use the following parameter you don’t need to change ExecutionPolicy:

    powershell -executionpolicy bypass -file c:script.ps1

    This allows you to run code without signature and from network locations (so you could use powershell -executionpolicy bypass -file \server01Folder01script.ps1)

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    VA:F [1.9.22_1171]
    Rating: 0 (from 0 votes)
  10. Anuj Eohila says:

    Hello,

    Thank for this post It’s really help full for me.

    Asp.net Temporary data is the problem.
    .

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    VA:F [1.9.22_1171]
    Rating: 0 (from 0 votes)

What are your thoughts?