Installing .NET Framework 3.5 SP1 can succeed in cases where the .NET Framework 3.0 or 3.5 fail
I previously posted a couple of items about how to troubleshoot and work around issues in .NET Framework 3.0 and .NET Framework 3.5 setup that can be caused by failures in the ServiceModelReg.exe custom action:
- How to use setup log files to diagnose .NET Framework 3.0 and 3.5 setup failures related to ServiceModelReg.exe
- ServiceModelReg.exe failures caused by failure to create files in the temporary directory
Both of the above blog posts require digging through log files and event logs on your system in order to accurately narrow down the cause of .NET Framework 3.0 and 3.5 setup failures. In order to hopefully make resolving this type of issue quicker for most people, I wanted to post another option that is much more straightforward:
If you run into errors when installing the original version of the .NET Framework 3.0, the .NET Framework 3.0 SP1 or the original version of the .NET Framework 3.5, it will sometimes help to simply try to install the .NET Framework 3.5 SP1 instead.
The reason this can help is that the .NET Framework 3.5 SP1 installs the .NET Framework 3.0 SP2 behind the scenes as a prerequisite. There is a logic change in the .NET Framework 3.0 SP2 installer that will cause it to continue installing if the ServiceModelReg.exe custom action fails, whereas in previous versions of the .NET Framework 3.0, this failure would cause the entire installation process to fail and roll back.
If the ServiceModelReg.exe custom action fails during your .NET Framework 3.5 SP1 installation, you may not ever notice if none of the applications you use requires Windows Communication Foundation HTTP activation functionality. If it turns out that you do need this functionality later on, but the custom action failed during setup and things are not registered correctly, you can manually run the ServiceModelReg.exe tool because it is also installed as a part of the .NET Framework 3.0 and higher.
I want to mention one caveat here that I typically include in all of my .NET Framework troubleshooting blog posts - there are many possible causes for .NET Framework setup failures, and this blog post only describes one of them. The above workaround will likely not help solve all possible installation issues. If this workaround does not help in your scenario, then I suggest looking at the .NET Framework setup troubleshooting guide for links to other possible installation issues and workarounds, links to log file locations, links to readme files, etc.