I have heard from 2 customers this past week who were trying to pre-install the .NET Framework as part of the T13 phase of OS setup (in their cases, Windows XP). They were including the .NET Framework 2.0 setup command line in svcpack.inf and then copying svcpack.inf into the i386 directory of their OS install location. Their svcpack.inf looks similar to the following:
dotnetfx.exe /Q /C:”install.exe /Q”
However, both customers found that the .NET Framework 2.0 setup failed in this scenario. The error in the verbose MSI log file for .NET Framework 2.0 setup is the following:
Error 1406.Could not write value DW0200 to key \Software\Microsoft\PCHealth\ErrorReporting\DW\Installed. System error . Verify that you have sufficient access to that key, or contact your support personnel.
One of the customers worked around this first error by deleting the DW key during OS setup before installing the .NET Framework 2.0. However, when doing this, they then encountered the following error:
MSI (s) (9C!A8) [23:03:15:484]: Product: Microsoft .NET Framework 2.0 — Error 25007.Error occurred while initializing fusion. Setup could not load fusion with LoadLibraryShim(). Error: The handle is invalid.
Unfortunately, I don’t know of a way to workaround this second error.
This scenario used to work with .NET Framework 1.0 and 1.1 setup, but it has been broken by some of the changes made to setup in .NET Framework 2.0 (the registry key listed above and the custom action to install assemblies are both new in .NET Framework 2.0 setup).
I don’t have much experience with customizing OS installations using the various methods that are available, so I asked these customers why people might want to use svcpack.inf to install the .NET Framework as part of OS setup as opposed to other methods that have been shown to work for the .NET Framework 2.0 (such as using the GuiRunOnce section of winnt.sif or setting a RunOnceEx registry value to launch .NET Framework 2.0 setup on first boot of the OS). Here is what they told me:
- Many prefer using svcpack.inf because it allows them to avoid setting OEMPreinstall=Yes in winnt.sif, which breaks F6 functionality for mass storage drivers
- It was common with the .NET Framework 1.0 and 1.1 because it worked reliably, and installing it through svcpack.inf meant it would alread be installed so that other setups that rely on the .NET Framework will also install correctly afterward
I am going to try to look into possible workarounds to get .NET Framework 2.0 setup to work when launched by svcpack.inf in the T13 phase of OS setup. However, for now, please be aware of this limitation and update your OS install scripts accordingly. In addition, if this scenario is important to you, please go to the bug form for this issue on the MSDN product feedback site and click on the link to vote on this bug so that the product team will better understand the importance of making this type of scenario work.
Also, if anyone has any tips and tricks that can be used to get this to work, please post a comment on this blog post or contact me and let me know.