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?
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.
- Rebuild the project. This ensures you have a Bundle created with an updated BA.dll inside it.
- Right click on the BA .csproj in Solution explorer and select
Set as StartUp Project. The BA .csproj should be bold.
- Right click on the BA .csproj and choose
Properties.
- On the
Properties for the BA .csproj select the Debug tab.
- In the
Debug tab, choose the radio button labeled Start external program
- 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.
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.
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)
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.
