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 while back, I posted a list of instructions that can be used to enable Windows Installer verbose logging in order to troubleshoot MSI-based setup issues. Since then, some people have tried to follow those instructions in order to gather Visual Studio and .NET Framework setup log files and found that they did not produce any logs named %temp%\msi*.log like I described in that post.
Unfortunately, I neglected to explain a subtle but important point in that previous blog post. Some MSI-based setups are packaged with a setup bootstrapper package (also known as an external UI handler) that uses the Windows Installer MsiEnableLog API to enable verbose logging by default. When this API is used, Windows Installer will create the log file with the specified name and the specified logging attributes, regardless of the logging policy set in the registry on the system. For reference, Windows Installer system policy settings are described in more detail in this MSDN topic.
The net result of this logic is that the steps listed in my previous blog post do not need to be used to enable verbose logging for some product setups, and in fact will not cause logs named %temp%\msi*.log to be generated.
The following is a list of some products that I know of that use an external UI handler and the MsiEnableLog function, and that therefore create their own log files regardless of the Windows Installer logging policy on the system. Each link contains information about the names and locations of the logs that the products create:
Many other MSI-based products, including the .NET Framework 1.0 and 1.1, will create a log named %temp%\msi*.log if you use the steps listed in my previous blog post.
PingBack from http://blogs.msdn.com/astebner/archive/2005/03/29/help-me-help-you-if-you-have-setup-bugs.aspx
I often get questions from fellow employees or customers who find my blog regarding how to troubleshoot
PingBack from http://justindevine.wordpress.com/2008/11/30/visual-studio-2008-sp1-installation-errors-and-error-code-1603/
There is a trick I use very often when trying to figure out why an MSI-based setup is failing that I