Mailbag: Temporary files can be left behind after running .NET Framework 3.0 or 3.5 setup

  • Article

Question:

I have tried to install the following versions of the .NET Framework on various different computers running Windows XP or Windows Server 2003:

  • .NET Framework 3.0
  • .NET Framework 3.0 SP1
  • .NET Framework 3.5
  • .NET Framework 3.5 SP1

In some cases, I have noticed that a folder gets left behind on the root of one of my drives.  The folder has a randomly generated name, and it contains a copy of the setup files used to install the .NET Framework.

I do not see this behavior for the .NET Framework 1.0, the .NET Framework 1.1 or the .NET Framework 2.0.

Why is this folder left behind at this location after installing these versions of the .NET Framework?  Can I safely delete this folder after I install the .NET Framework?

Answer:

The installers for the .NET Framework 2.0 and earlier uses a legacy self-extracting EXE technology called IExpress.  That technology creates a folder in the %temp% directory named something like IXP000.tmp (it will increment the number if a folder with this naming pattern already exists).  Then it extracts the contents of the EXE to that folder and runs the setup EXE from within that folder.  After the setup EXE completes, it will attempt to delete that folder.

The installers for the .NET Framework 3.0 and later use a different self-extracting EXE technology, which is why you have observed different behavior depending on what version of the .NET Framework you are trying to install.  The self-extracting logic for these versions of the .NET Framework does the following:

  1. Find the drive on your system with the largest amount of free disk space
  2. Create a randomly named folder on that drive
  3. Extract the contents of the EXE to that folder
  4. Run the setup EXE from within that folder
  5. After the setup EXE returns, attempt to delete that folder

One of the prerequisite packages for the .NET Framework 3.0 and higher - the XML Paper Specification (XPS) Shared Components Pack 1.0 - has a problem that causes the randomly named folder that it creates to fail to be deleted in step 5 above.  Those files are temporary and only needed during the initial installation of this component, so it is safe to delete this randomly named folder if it ends up getting left behind on your system after .NET Framework installation completes.

I have heard of a few cases where attempting to delete the randomly named folder fails with a permission problem.  I am not sure what causes that type of permission problem in the first place, but you will need to manually update the permissions on that folder in order to be able to delete it.  Tools such as Cacls or SubInAcl could be useful to update these permissions if you run into this issue.

The XPS component is only installed by the .NET Framework setup package on Windows XP and Windows Server 2003, so the issue where this folder gets left behind at the end of .NET Framework setup will not affect newer operating systems such as Windows Vista, Windows Server 2008 or Windows 7.

<update date="12/21/2009"> Added more specific information about the root cause of this problem (the XPS setup package that is chained in during .NET Framework 3.0 and higher setup on Windows XP and Windows Server 2003). </update>