Thoughts about setup and deployment issues, WiX, XNA, the .NET Framework and Visual Studio
All postings are provided AS IS
with no warranties, and confer no rights. Additionally, views expressed
herein are my own and not those of my employer, Microsoft.
I have tried to install the following versions of the .NET Framework on various different computers running Windows XP or Windows Server 2003:
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?
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:
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>
How can I delete those temp folders automaticly?
I have around 600 servers in me environment so I won't do it manually on each server.
Is is possible do find a way to install .Net Framework 3.5 SP1 and not getting those temp folders.
Hi Blakedue - You would have to write a tool/script to clean up the folders afterwards if you need them to be removed. The folders have randomly generated names, so your tool would need to look for folders at the root of the drive letter with the largest amount of free space, then check inside the folder to see if it is from .NET Framework 3.5 SP1 setup, and if so, delete the files and folder.
If you would like to avoid the folder being created in the first place, you can pre-install the XPS package before running the .NET Framework 3.5 installer. Here are the download locations:
For the x86 XPS package - http://go.microsoft.com/fwlink/?LinkId=123098
For the x64 XPS package - http://go.microsoft.com/fwlink/?LinkId=123099
This randomly named folder is also referenced all over the registry... is it safe to delete the folder and leave all registry references to it?
Hi TH - There are a few different cases I know of where temporary files can be left behind like this. What are the exact files that you see listed in your registry, and what locations do they appear at in your registry?
So the folder is always randomly named... in one case it is:
then when searching through the reistry this location is referenced in the following keys:
HKLM\Software\Microsoft\Updates\Windows Server 2003\SP4\KB954550-v5\Filelist\0
The key is:Location
The value is: d:\09cb04b43b693cd9fa19\update\..\amd64
HKLM\Software\Microsoft\Updates\Windows Server 2003\SP4\KB954550-v5\Filelist\1
HKLM\Software\Microsoft\Updates\Windows Server 2003\SP4\KB954550-v5\Filelist\10
The value is: d:\09cb04b43b693cd9fa19\update\..\i386
HKLM\Software\Microsoft\Updates\Windows Server 2003\SP4\KB954550-v5\Filelist\11
HKLM\Software\Microsoft\Updates\Windows Server 2003\SP4\KB954550-v5\Filelist\12
HKLM\Software\Microsoft\Updates\Windows Server 2003\SP4\KB954550-v5\Filelist\13
HKLM\Software\Microsoft\Updates\Windows Server 2003\SP4\KB954550-v5\Filelist\14
HKLM\Software\Microsoft\Updates\Windows Server 2003\SP4\KB954550-v5\Filelist\2
HKLM\Software\Microsoft\Updates\Windows Server 2003\SP4\KB954550-v5\Filelist\3
HKLM\Software\Microsoft\Updates\Windows Server 2003\SP4\KB954550-v5\Filelist\4
HKLM\Software\Microsoft\Updates\Windows Server 2003\SP4\KB954550-v5\Filelist\5
HKLM\Software\Microsoft\Updates\Windows Server 2003\SP4\KB954550-v5\Filelist\6
HKLM\Software\Microsoft\Updates\Windows Server 2003\SP4\KB954550-v5\Filelist\8
HKLM\Software\Microsoft\Updates\Windows Server 2003\SP4\KB954550-v5\Filelist\9
For every server its a different random folder names and then its refenced in these registry keys... Let me know if it would help ou if I supplied the value of the FileName Key in each of the locations above.
what I dont want to do is delete this random folder and have all these entries in the registry still there, referencing a location that I have deleted.... doesnt seem like good practice, especially on a Terminal Server.
The other option I guess is too just run the XPS package before installing .Net 3.5 SP1?
Hi TH - If you want to eliminate these temporary files, I think the cleanest option would be for you to run the XPS installer before installing the .NET Framework 3.5 SP1. If that isn't an option, I believe it would be safe to remove those registry keys in addition to removing the temporary files.
Hi astebner, thank you very much for your assistance... That is the plan then, to run the XPS installer beforehand :)