Using Setup Logs to Explain Failed .Net Installations
Posted by William Diaz on July 3, 2010
When we began moving from .Net 3.5 to 3.5 with SP1, we started encountering issues where the update was failing on many workstations. Although we were able to work around this by uninstalling all versions of .Net , this was too lengthy a process and also had to be done a case by case basis. When you install .Net, a series of setup logs is written to C:\Documents and Settings\username\Local Settings\Temp. The answer for us resided in dd_NET_Framework30_Setup####.txt, the .Net 3.0 component that could not be uninstalled.
Why is the setup failing? Behind the scenes, the .NET Framework 3.5 SP1 attempts to uninstall older versions of the .NET Framework 2.0, 3.0 and 3.5. The removal of 3.0 is failing because one or more of the msi files it needs to perform the uninstall cannot be found.
When a .Net setup fails, you can find an entry in the Windows Event Viewer. It won’t tell you what is missing but it will tell you which log to look at:
The log is fairly large and I was not sure what to look for. I turned to Aaron Stebner at Microsoft (http://blogs.msdn.com/b/astebner/) for help and provided him with the setup logs for the failed installation and he provided the answer. What we were looking for was “Failed to resolve source” in the text file:
You can see above that the .Net installation was looking for but failing to find wf_3.0_x86.msi. To correct the problem, I extracted wf_3.0_x86.msi from the 3.0 redistributable (dotnetfx3.exe) and copied it to c:\WINDOWS\Microsoft.NET\Framework\v3.0\Windows Workflow Foundation. Afterwards, I ran the setup for 3.5 SP1 and it completed successfully. Why some workstations were missing the installer files is unknown.
To extract the required msi files from the .Net installer package, go to the command shell and run the exe with the /x switch and the desired extraction path like in the example here:
Now simply go to the extract location and grab the missing msi file(s) indicated in the setup log and place them in the appropriate .Net folder. If you are not sure which folder they should go into, look at a workstation that has a successful .Net install.
To automate the process of getting the missing msi files to the affected systems, a simple batch file was created that could be run before the .Net install was started that would copy the missing msi file to the workstation.