HOW TO: Detect if the Visual C++ 2010 redistributable package is installed with WiX

As noted by Aaron Stebner, there is now a registry key you can search for to detect if the Visual C++ 2010 redistributable package is installed a machine, when installing your application.

There are 3 different (but very similar) registry keys for each of the 3 platform packages. Each key has a DWORD value called “Installed” with a value of 1.

  • HKLMSOFTWAREMicrosoftVisualStudio10.0VCVCRedistx86
  • HKLMSOFTWAREMicrosoftVisualStudio10.0VCVCRedistx64
  • HKLMSOFTWAREMicrosoftVisualStudio10.0VCVCRedistia64

Here’s an example of using this in WiX, detecting the presence of the x86 version of the redistributable:

<?xml version="1.0" encoding="utf-8"?>
    <Include>
        <!-- Visual C++ 2010 x86 -->
        <Property Id="HASVCPP2010">
        <RegistrySearch Id="HasVCPP2010Search" Root="HKLM" Key="SOFTWAREMicrosoftVisualStudio10.0VCVCRedistx86" Name="Installed" Type="raw" />
    </Property>    
    <Condition Message="This application requires Microsoft Visual C++ 2010 Redistributable Package (x86).">Installed OR (HASVCPP2010)</Condition>
</Include>

When someone runs your installer and they don’t have this package installed, they will get something like this message box when the installer initializes:

image

It’s a good idea to have a setup bootstrapper that automatically installs this package if it’s missing, but this WiX snippet is a good safe-guard for if someone directly runs your MSI.

Reference: http://blogs.msdn.com/b/astebner/archive/2010/05/05/10008146.aspx

HOW TO: Debug a Windows Installer custom action

Prerequisites:

  • Determine the name of the custom action you want to debug
  • Ensure you have the source code and debug symbols for your custom action

Steps

  1. Set the MsiBreak environment variable (user or system) to the name of the custom action. For example:

    Setx MsiBreak MyCustomActionName

  2. Run your installer
  3. At the point where your custom action is about to run, you should get this message box prompt:

  4. Now you can use Visual Studio or another debugger such as WinDBG to attach to the specified process.
  5. Click OK on the message box
  6. This should break into your debugger. This is a good time to set your breakpoints in your custom action code.
  7. When ready, run/continue the debug session.
  8. Your custom action should run and your breakpoint(s) will be hit.

References:

Debugging Custom Actions @ msdn.microsoft.com

Building Visual Studio 2010 Solutions in Team Foundation Server Build 2008

Visual Studio 2010 and Team Foundation Server 2010 have been out for a while. But what if you still have Team Foundation Server 2008 but want to build Visual Studio 2010 solutions on it?

You can do so by updating the Team Foundation Build Service configuration to use the latest version of MSBuild that comes with the .NET Framework 4.0.

  1. Open up %Program Files%Microsoft Visual Studio 9.0Common7IDEPrivateAssembliestfsbuildservice.exe.config in a text editor
  2. Find the MSBuildPath property, which will likely be empty, and enter the path to the .NET Framework 4.0 folder (C:WINDOWSMicrosoft.NETFrameworkv4.0.30319):
  3. Save the file
  4. Restart the  Visual Studio Team Foundation Build service

Reference: http://blogs.msdn.com/b/jimlamb/archive/2009/11/03/upgrading-tfs-2008-build-definitions-to-tfs-2010.aspx