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 posted an updated version of the .NET Framework cleanup tool that now contains support for automatically cleaning up the .NET Framework 1.0, the .NET Framework 1.1, the .NET Framework 2.0, the .NET Framework 3.0 and the .NET Framework 3.5.
This tool automates the manual cleanup steps for the .NET Framework 2.0 that I posted a while ago. These steps have helped solve most of the known .NET Framework 2.0 beta uninstall issues that I know of. In addition, the tool can be useful to return your system to a known (relatively clean) state in case you run into any .NET Framework 2.0 installation failures so that you can try to install again.
The updated version of the cleanup tool contains options to clean up the .NET Framework 1.0, 1.1, 2.0, 3.0 and 3.5 separately and all versions simultaneously in a single step. The cleanup tool contains logic so that if it is run on an OS version that includes the .NET Framework as an OS component, it will not offer the option to clean it up. This means that running the cleanup tool on Windows XP Media Center Edition or Tablet PC Edition will not offer the option to clean up the .NET Framework 1.0, running it on Windows Server 2003 will not offer the option to clean up the .NET Framework 1.1 and running it on Windows Vista will not offer the option to clean up the .NET Framework 2.0 or the .NET Framework 3.0.
There are a couple of very important caveats that you should read before using this tool to cleanup .NET Framework bits on your machine:
I have been using this tool for a while, and it has proven reliable, but there may still be bugs in it in certain scenarios. Please contact me if you run into any issues while using the cleanup tool or if you are still unable to install the .NET Framework (or any service packs or hotfixes) after running it.
The tool has a command line switch that allows it to be run in silent mode if needed. There is more information about how to run it in silent mode in the .NET Framework Cleanup Tool User's Guide.
<update date="8/22/2007"> Added information about removing the .NET Framework 3.0 because the tool now supports this version of the .NET Framework in addition to 1.0, 1.1 and 2.0. </update>
<update date="9/13/2007"> Added information about removing the .NET Framework 3.5 because the tool now supports this version of the .NET Framework in addition to 1.0, 1.1, 2.0 and 3.0. </update>
<update date="12/3/2007"> Added a link to the silent install instructions for the cleanup tool </update>
<update date="2/28/2009"> Added links to the .NET Framework Cleanup Tool User's Guide, which contains download locations and detailed information about how to use the cleanup tool. </update>
PingBack from http://www.vitarn.com/134.htm
I am running Windows XP Home Edition Version 5.1 SP2. I have been running .NET Framework 2.0. I tried to install the SP1 update from Microsoft and it hosed my system. I tried the msicuu2.exe, but it still wouldn't work. Then I tried your dotnetfx_cleanup_tool. I was able to reinstall .NET Framework 2.0 and the computer and all programs work great. Thank you. However, if I try to install the SP1 update, it won't work and a lot of programs (Adobe, mostly) won't work. As soon as I run your tool and reinstall .NET 2.0, everything is fine again. Why can't I install the SP1 update from Microsoft? Thanks.
Hi Jane2001 - I'm sorry for the hassle that this issue is causing for you. The .NET Framework 2.0 SP1 setup creates a set of log files that will hopefully help narrow this issue down further so we can try to figure out the cause. The list of logs for .NET 2.0 SP1 setup is located at http://blogs.msdn.com/astebner/archive/2008/04/30/8445569.aspx.
Could you please gather the logs from this list that are on your system, zip them, upload them to a file server and then reply here and post a link to your upload location so I can take a look at your logs and see if I can figure out what is causing this?
I zipped all of the logs into a file that is 2.26MB. I don't have a server that I can upload them to. Could I email them to you or do you have another suggestion? Also, it was interesting. I tried to do this update to SP1 twice - once in June (using another method - not yours) and again in August (this time using your method). All of the log files were dated June. Do you think the reason that your method didn't work was because I didn't erase these files before I started? Thanks.
Hi Jane2001 - There are a lot of free file servers available (for example, you get a free gigabyte of storage at http://skydrive.live.com). If you cannot use one of those for some reason, please contact me at http://blogs.msdn.com/astebner/contact.aspx instead.
Some of the setup logs will append if a file with the same name already exists, and some will be created with unique names each time you run setup. The safest way to make sure you have updated logs is to move/rename/delete all of the existing logs, then re-run setup and let it fail once more, then gather the logs that it creates.
Is there any harm in leaving the computer running .NET Framework 2.0 without the SP1 update? Thanks.
Hi Jane2001 - The .NET Framework 2.0 SP1 contains some security fixes, and there is also a .NET Framework 2.0 SP2 package available too that contains additional fixes. You'd be missing out on those fixes if you don't install it.
Can you post the log files you mentioned previously so I can take a look and see why the SP is failing to install in your scenario?
PingBack from http://blog.rustice.com.br/2008/09/02/desinstalando-o-net-framework-a-forca/
On XP/PRO with SP3, I had all versions of NET installed up through 3.5 SP1 Beta, plus VS2008.
I ran the 'service pack prep tool' before upgrading to 3.5 SP1 RTM.
I installed VS2008 SP1, and ever since, 1] Creating a new WPF project causes immediate VS2008 crash. and 2] Previously built and running apps fail immediately with similar 'failed to initialize' fault (0x8000003).
I uninstalled 3.5 SP1, and then VS2008 using autunisntall, then verified manual uninstall procedure. I also scrubbed NET totally from the system using your utility, as well as DirectX SDK (Aug 08). I thought I'd try one step short of a complete re-pave.
I reinstalled NET from 1.1, 2.0/2.0 SP1, 3.0/ 3.0 SP1 and verified install at each step, and noted a single 'donotload_mscoree.dll' exception in 1.1, but manually 'fixing' that keeps coming back after further upgrades through 2.0, so it seems safe to ignore as the only verify error.
A second time through this cycle, instead of installing VS2008 RTM and 3.5, I installed 3.5 first. This verified through 3.5, and in this state, the previously failing apps intialized normally. When I then installed VS2008 (Team DevEd) RTM, it correctly detected 3.5 already installed, installed successfully, but immediately after that(without rebuild, just installing VS2008 on top of 3.5), a] the previously built apps failed to init again, and b] the new install of VS2008 with 3.5 still crashes as soon as a new WPF project is created. This time, without 3.5 SP1 reinstalled.
Further installing 3.5 SP1 doesn't help/hurt, it's the same behaviour, but appeared above with just reinstall to 3.5, but only after installing VS2008.
I still see residue in the winSxS associated with earlier versions of C++ runtimes. Uninstalling the associated runtimes, or uninstalling and reinstalling them, seems to have no impact on the issue (or the residue in the WinSxs), but seem to take a long-ish time. But, these always seem to take a long time to install/uninstall (4-5 minutes), so did not seem odd.
A run with FusLogVW enabled on this machine and a machine next to it that still has 3.5 SP1 Beta and VS2008 installed(and which does not fail when WPF project is created) looks similar except for 3.5 SP1/3.5 SP1 beta version differences, plus the following additional binding failure (WhereRefBind...)on the system that does not crash(SP1 beta)
On the system with the crash, would only see bind failures for:
Finally, on a remote comparison to a similar devo box with these same apps built on it, a loaded module scan immediately prior to the failure point(stepping through with debugger)yields identical file versions/dates( just versions on the JIT compiled native assemblies, they were built at two locations, but the versions were identical.)
A manual comparison by inspection of the loaded module scan after the point of failure(on the remote devo box) only yielded one obvious difference, 'Apple Bonjour' installed on that devo box eventually dragged into build, but deep in the process, long after failure. Installing Apple bonjour on problem system made no impact, probably a red herring.
The primary difference is, NET 3.5 SP1 Beta had never been installed on the remote devo box.
Any suggestions are welcome, would like to avoid a complete repave, but have already spent a day chasing this.
Hi Frediano - I'm sorry, but I don't have much expertise troubleshooting this type of issue where a crash occurs when using VS after a successful install - my expertise is related to troubleshooting setup failures. I'd suggest posting this question on one of the Visual Studio forums at http://forums.microsoft.com and hopefully someone there can suggest some workarounds for you to try for this. I'm sorry I'm not able to be more helpful in this scenario.
PingBack from http://www.monclovacaliente.com/programas/cleanup-tool-remove-net-framework
こんにちは！ フォーラム オペレーターの服部清次です 今日は久々に晴天が広がり、気分爽快ですねー。 祝日が終わり、僕は、また今日から頭の中の OS を英語モードに切り替えました。 ^_^; さて、今日は久々に
Seguimos con los problemas que nos vamos encontrando al instalar el .NET Framework 3.5, hay que tener
I am just curious why there are so many problems with the .NET (every version) installs. It seems that every time a new patch comes out I have to rip .NET out and reinstall it, because the install frequently fails.
Hi JohnDiego - I'm not sure how to answer this. There are definitely issues on some systems related to the .NET Framework installation process, but that is definitely not the norm and the vast majority of users experience no problems with installing any version of the .NET Framework or any hotfixes.
What kind of errors do you see when attempting to install new .NET Framework hotfixes that have led you to remove it and re-install it? Maybe we can figure out the root cause of the issue so that you won't have to resort to these steps in the future.