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).

The Visual Studio Installer custom actions are fairly useless if you want to control when your custom action is executed (outside of the options provided by Visual Studio). So instead of using a Visual Studio Installer custom action, I used a post build step for the installer and used my own program to modify the MSI post build. What I really want to do: Execute a custom action before the Installer UI is displayed to the user Execute a custom action after the user chooses to install the product, but before files are copied to the computer. Execute a custom action after all files have been copied to the computer. Tools Needed: Orca (Views and edits MSI databases visually) MSI.Interop (If you want to write the Installer post build step in managed code) Using the Orca program, open your MSI file (already built). The two tables we will be working with are InstallUISequence and InstallExecuteSequence. The InstallUISequence and InstallExecuteSequence tables are actions executed by the inta...

Recently, I came across a problem where one of our software vendors does not support a component in 32-bin (x86) but they could provide us executables (managed and unmanaged) in 64-bit (x64) that would replace the component on a 64-bit system. The only problem is that the Visual Studio installer complains if there are 64-bit executables in a 32-bit installer and won't build (I believe the unmanaged 64-bit binaries were just warnings, but the managed code built specifically for AMD64 caused the installer to error out). The solution: Build the installer in Visual Studio with the TargetPlatform set to x64. Since this installer is set to x64, it will not run on a 32-bit machine. So, as a post build step, I have a program that opens the MSI database and changes the Template in the Summary Information section and changes the installer back to 32-bit. Voila, the 64-bit executables are copied to the machine during installation for whichever platform you are running on.