Down the IT Rabbit Hole

When building an installer in Visual Studio 2008 SP1 and including the bootstrapper installer for .NET Framework 3.5 SP1, you may get 2 warnings when building stating: 'PublicKey' attribute in '.NET Framework 3.5 SP1' does not match that of file 'C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bootstrapper\Packages\DotNetFX35SP1\dotNetFX30\XPSEPSC-x86-en-US.exe ' and 'PublicKey' attribute in '.NET Framework 3.5 SP1' does not match that of file 'C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bootstrapper\Packages\DotNetFX35SP1\dotNetFX30\XPSEPSC-amd64-en-US.exe' For some reason in the product.xml file for DotNetFX35SP1, the XPSEPSC files have a different PublicKey than all of the other files in the dotNetFX30 packages for the DotNetFX35SP1 bootstrapper. To fix the issue replace the XPSEPSC PublicKeys with one of the other keys (they are all the same).

In response to my previous posting about Problems Installing .NET 3.0 Runtime , we have seen at other customer locations now admins not knowing that you must be a Domain Administrator to install .NET runtimes (since it is considered a Windows Update), and have seen other errors that don't make sense such as MSXML 6.0 not being installed. So really, in general if theres an issue installing .NET runtime, it's most likely that you are on a domain but not a Domain Administrator.

Recently I received a support call from a user trying to install our software but it was failing for .NET Framework 3.0 Runtime. In the logs for the installer it mentioned WIC (Windows Imaging Component) failing to install, but in reality all the problem turned out to be was that the computer was on a domain and still set up as a domain computer (but not actually hooked up to the domain). The local administrator account would not allow for updating any core Windows components without a Domain Admin being logged in. Solution? Change the computer back to workgroup instead of being a member of a domain.