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.
A couple of months ago, I posted a set of debugging instructions for the .NET Framework setup that describes how to use MsiBreak to set a break point and then gather callstack information for some setup custom action failures. One of the troubleshooting tips I listed towards the top of that post seems to have gotten lost in the shuffle because I've had a few customers post comments or send me email about .NET Framework setup failures that we ended up tracking back to international language settings. The tip at the top of that post would have resolved the problem much sooner if it wasn't buried and easy to miss like it is there. So I'm going to post it here separately in the hope that it will get some hits in search engines and help some people who would have otherwise missed it.
If you see a failure to register System.EnterpriseServices.dll or a problem running RegSvcs.exe /bootstrapi during .NET Framework 1.0 or 1.1 setup, it might be caused by the international language settings for the operating system that you are installing on.
If you are running Windows 2000, Windows XP or Windows Server 2003, you can use these steps to resolve this issue. Note that my post that lists the workaround specifically describes the bug in the context of Windows XP SP2, but the steps to resolve the issue are the same for all of the other operating systems as well (assuming that you have a non-default user or system locale configured on your machine and you are hitting this instance of the bug).
On other operating systems such as Windows NT 4, you can workaround the issue by doing the following to manually verify that the data in the registry:
One interesting note here - just this week I noticed that the custom action that runs RegSvcs.exe /bootstrapi in .NET Framework 2.0 setup is now configured to allow setup to continue even if it fails. Therefore, you should no longer see .NET Framework setup fail due to this custom action starting in .NET Framework 2.0. Of course, the problem is that since there is generally some underlying bug in the runtime itself when this custom action failed, setup will now fail in some new place in 2.0. I'll have to research a bit more and figure out what the new point of failure will be for this type of problem in .NET 2.0....