How to debug custom bootstrap application?

Question

I am using Burn for MSIs package. I am using Votive (Visual Studio) & my own custom BA instead of WiXBA. I tried to debug custom BA using Debugger.Launch(). But when I start debugging, error messages occur.

No symbols are loaded for any call stack frame. The source code cannot be displayed

I realized that package.exe links CustomBA dll which located at C:\Documents and Settings\user\Local Settings\Temp\{GUID}\. {GUID} is always changed. So, whenever I run package.exe, always directory is changed.

I think that is the reason to occur errors.

In Visual Studio, When I started package.exe with CustomBA dll which located at absolute path (.../Debug/bin/CustomBA.dll). But after execute the package.exe, it links to Local Settings\Temp\{GUID} directory. So, when we start debugging and attached to CustomBA dll, CustomBA dll's directory is dynamically changed and No symbols are loaded error occurs.

• Why package.exe links dll which located at C:\Documents and Settings\user\Local Settings\Temp\{GUID}\? Can we choose the path for dll statically?
• If we can't choose the dll path statically, how can I use debugging functions for CustomBA?

Answer 1

You cannot run your custom BA in debug mode from Visual Studio.

What you can do is to run the generated exe file and then attach Visual Studio to the process which would let you debug it. (In the menu: Tools > Attach to Process > Find your exe in the list)

Answer 2

To debug a Bootstrapper Application, you'll want both your Bundle .wixproj and BA .csproj (or .vcxproj if you're doing a native .dll) in the same solution and the Bundle project should be dependent on the BA project so rebuilds work correctly. The following steps should allow you to step into your code.

Note: Ensure you are not running Visual Studio elevated. If you have UAC disabled, re-enable it. These steps will not work correctly if Visual Studio is running elevated.

1. Rebuild the project. This ensures you have a Bundle created with an updated BA.dll inside it.
2. Right click on the BA .csproj in Solution explorer and select Set as StartUp Project. The BA .csproj should be bold.
3. Right click on the BA .csproj and choose Properties.
4. On the Properties for the BA .csproj select the Debug tab.
5. In the Debug tab, choose the radio button labeled Start external program
6. Browse to the path where your Bundle is built.

Now, you can press F5 and start debugging. Remember that any time you change the BA .csproj, you also need to ensure the Bundle .wixproj is rebuilt. Otherwise, the Bundle will launch with your old BA in it and the debugger will find the newly built BA's .pdbs don't match.

Extra credit: if you disable Just My Code in the debugger settings and download the pdbs.zip and sources.zip for the matching build of your WiX install, you can actually step through the Burn code as well as your BA to see how everything works together.

Answer 3

I followed Rob's suggestion in this post but sadly i couldn't get it to work for me (Visual Studio 2015, Wix 3.10.3, managed Bootstrapper Application using WixWPF). No breakpoints are ever hit. I noticed the debugger attaches itself to the wrong process, the installer has two running processes (im guessing the BA and the Bundle). When I changed the process the breakpoints were hit but my managed BA has code i want to debug before the debugger actually gets attached

Ive managed to find a solution where the application will not start until the debugger is attached. I put this code in my constructors code-behind file (in the DEBUG block) for my managed BA like so...

public MainWindow()
{
#if DEBUG
    // Do not start until debugger attached
    while(!System.Diagnostics.Debugger.IsAttached)
    {
        System.Threading.Thread.Sleep(1000);
    }
#endif
    InitializeComponent();
    InstallData = new InstallerInfo();
}

Now when i compile my managed Bootstrapper Application (with Debug) along with the Bundle and run it, the application will not start until you attach to the managed Bootstrapper Application Tools > Attach to Process > Find your exe in the list.

Answer 4

Rob's solution doesn't work. Approach of AhmedBM works but it still can be further streamlined so that VS runs WiX bootstrapper process and then immediately attaches to the child process.

public void Run(EnvDTE80.DTE2 DTE, Microsoft.VisualStudio.Shell.Package package)
{
    //kill old ones if any
    System.Diagnostics.Process.Start(@"c:\Windows\System32\taskkill.exe", "/F /IM Bootstrapper.exe /T");
    System.Threading.Thread.Sleep(1000);
    //start new one
    System.Diagnostics.Process.Start(@"<solution path>\src\Bootstrapper\bin\Debug\Bootstrapper.exe");
    System.Threading.Thread.Sleep(1000);

    foreach (Process proc in DTE.Debugger.LocalProcesses)
    {
        if (proc.Name.ToString().Contains(@".cr\Bootstrapper.exe"))
        {           
                proc.Attach();
                return;  
        }
    }
    System.Windows.MessageBox.Show("Bootstrapper Process was not found.");
}

The only problem is that you need DTE object. In earlier versions of VS we had Macroses where it was accessible. But in VS 2017 we don't have them. So, you can quickly make simple VS extension and add the command running the code there. Or use already existing extension, some of them allow to make custom commands.

Answer 5

As many other answers suggested above, the debugger is attached to the process that runs installer executables. You will need to manually attach the debugger to the UI process that is spawned under a temp folder like many have done before.

To allow for child processes to be attached automatically without all the extra code mentioned, you do can as mentioned:

1. Install the visual studio extension called MicrosoftChildProcessDebuggingPowerTool.
2. Set the executable in debug start action just like Rob mentioned.
3. Enable native code debugging (important)
4. Turn on Child Process Debugging by Debug -> Other Debug Targets -> Child Process Debugging Settings -> Enable child process debugging -> Save

Answer 6

The only thing which really works is:

protected override void Run()
{
    Debugger.Launch();
}

in your bootstrapper UI application (BootstrapperApplication descendant). Then start the built bootstrapper.exe from the explorer and reuse your Visual Studio instance in "Choose Just-In-Time Debugger" window. Don't forget to clean the solution before re-building. This prevents sometimes from debugging correctly.

PS: when there are problems with finding the correct pdb's of your bootstrapper UI assembly, choose the same architecture than the bootstrapper setup. Mixing architectures can lead to debugging problems.

Cheers

Answer 7

Stick a MessageBox as the first line in your BA. Run the BA and the MessageBox will show up. Before hitting OK, From the menu DEBUG|Attach to Process, select your BA and Attach. Then hit the MessageBox's OK. Now your debugging!