[wix-users] Debugging managed BA

Wed Dec 7 06:08:31 PST 2016

Interesting.  I would not have guessed that one.

________________________________
From: Goran Malovic <malovicg at yahoo.com>
Sent: Wednesday, December 7, 2016 6:48:42 AM
To: Phill Hogland; WiX Toolset Users Mailing List
Subject: Re: [wix-users] Debugging managed BA

Hi all,

it was exactly as you described, but did not work. So I decided to go compare the project settings with the one from last year, and I found out where the problem is.

I forgot that every time I wanted to debug my managed BA, I needed to switch from .NET Framework v3.5 to v4.0, and to adjust the BootstrapperCore.config (remove SupportedFramework="v3.5"). Only then I was allowed to debug managed BA.

I need to write this into the note, so that I do not forget it next time. :-/

Thanks

On Tuesday, December 6, 2016, 7:34:19 PM GMT+1, Phill Hogland <phill.hogland at rimage.com> wrote:
Yes that looks like the code that I used to use in my projects, before I switched to using the -burn.clean.roo switch.

________________________________
From: wix-users <wix-users-bounces at lists.wixtoolset.org<mailto:wix-users-bounces at lists.wixtoolset.org>> on behalf of John Cooper <JoCooper at jackhenry.com<mailto:JoCooper at jackhenry.com>>
Sent: Tuesday, December 6, 2016 12:24:34 PM
To: WiX Toolset Users Mailing List
Subject: Re: [wix-users] Debugging managed BA

Another way that works for me:

1)

/// <summary>
        /// Private method to attach the debugger necessary after <c>WiX 3.10.2</c>
        /// </summary>
        /// <example>
        /// 1) Add a line of code early in the mba Run method to call this method.
        /// 2) Compiling the managed <see cref="BootstrapperApplication"/> and
        /// then the bundle.exe, (which is configured in the managed
        /// <see cref="BootstrapperApplication"/> project as the executable to
        /// load the managed <see cref="BootstrapperApplication"/> library), I
        /// then:
        /// 3) Open the Solution in another instance of Visual Studio IDE, only
        /// for 'launching' a debug session.  My practice is to close all
        /// documents in this second IDE instance.
        /// 4) In the second instance select the managed
        /// <see cref="BootstrapperApplication"/> project (or set it as the
        /// Startup Project) and hit F5.
        /// 5) When Attach to Process dialog is presented select the first
        /// instance of your VS IDE (where you are doing your work).
        /// </example>
        [Conditional("DEBUG")]
        private static void AttachDebugger()
        {
            string noDebug = Environment.GetEnvironmentVariable("NODEBUG");

            if (string.IsNullOrEmpty(noDebug) || !noDebug.Equals("1"))
            {
                Debugger.Launch();
            }

            return;
        }

2) for my Debug builds, my bundle includes all of the relevant PDB files.

When I start a debug bundle, it attaches, I select the VS I want to use, and away I go.

--
John Merryweather Cooper
Senior Software Engineer -- Integration Development Group -- Enterprise Notification Service
Jack Henry & Associates, Inc.® | Lenexa, KS  66214 | Office:  913-341-3434x431050
JoCooper at jackhenry.com<mailto:JoCooper at jackhenry.com>

-----Original Message-----
From: wix-users [mailto:wix-users-bounces at lists.wixtoolset.org<mailto:wix-users-bounces at lists.wixtoolset.org>] On Behalf Of Phill Hogland
Sent: Tuesday, December 6, 2016 12:20 PM
To: Goran Malovic <malovicg at yahoo.com<mailto:malovicg at yahoo.com>>; wix-users at lists.wixtoolset.org<mailto:wix-users at lists.wixtoolset.org>
Subject: Re: [wix-users] Debugging managed BA

The e-mail below is from an external source.  Please do not open attachments or click links from an unknown or suspicious origin.

OK on not using the pdbs to step into the Burn/wix code, if you are not doing that.

Is "E:\My Solution\MyProject.Bootstrapper\bin\Debug\ApplicationName.exe" pointing ay your bundle.exe?  , which then loads your MyProject.Bootstrapper.UI managed DLL library?  If so then yes in the MyProject.Bootstrapper.UI project Properties, on the Debug tab, you would pass the -burn.clean.room= switch pointed at the same bundle.exe path.

The reason for this is that to resolve the DLL Hijacking Security vulnerability, since the change in wix v3.10.2  (and you should certainly use v3.10.3 or later) when a user launches your bundle.exe it then copies itself to a 'clean room' and re-launches itself in the 'clean room' to protect against 'drive-by' malicious code being injected into your bundle.  So when debugging you now need to also pass the -burn.clean.room path to the bundle which you are launching within your VS debug session, but only when you need to debug it.

Eeach time after I change the -burn.clean.room= in my UI project (which I use with many different bundle.exe executables) I compile the UI project and then compile the bundle project before hitting F5 in VS on the UI project, which launches my UI project in a debug session of VS.

I'm not sure why you are having issues, but I hope this explanation helps.  (Of course when I do this my UI project in the Properties Build tab, Advanced has Debug Info set to Full, but these .Net debugging details are needed in any case and are not related to the v3.10.2 change.)

Another more complex approach which I used to use was to:

1) Add System.Diagnostics.Debugger.Launch(); to the Run() method of my startup class in my mba UI DLL project (and set a break point below it).

2) Compile that UI project and then Compile the bundle.exe which imports the UI dll.

3) Then open an additional instance of your VS Solution (so that you have two VS IDEs open for the same projects (bundle and UI project).)

4) In one VS IDE hit F5 to launch the Start up project (the bundle) related to UI dll.

5) .Net will hit the above code and ask you to attache a debugger, giving you a list of VS IDE instances.  Select the other VS IDE instance which you already opened, and use the Debug 'Attach to Process' to attach that instance, and then proceed to debug it.  (Prior to making any changes to your project, close the extra IDE session and open it again after saving the changes and prior to repeating the above steps.)

But using the -burn.clean.room is simpler than trying to manage to instances of the same Solution in separate VS IDE sessions.

________________________________
From: Goran Malovic <malovicg at yahoo.com<mailto:malovicg at yahoo.com>>
Sent: Tuesday, December 6, 2016 11:21:37 AM
To: Phill Hogland; wix-users at lists.wixtoolset.org<mailto:wix-users at lists.wixtoolset.org>
Subject: Re: [wix-users] Debugging managed BA

Hi Phill,

I am not quite sure where to put this switch. Here is how my scenario looks like:

I have MyProject.Bootstrapper and MyProject.Bootstrapper.UI projects. In the properties of MyProject.BootStrapper.UI I, under the Debug option I have set Start action to Start external program and pointed to E:\My Solution\MyProject.Bootstrapper\bin\Debug\ApplicationName.exe

I have tried pasting below switch into command line arguments of the Bootstrapper.UI, but that did not help.

-burn.clean.room="E:\My Solution\MyProject.Bootstrapper\bin\Debug\ApplicationName.exe"

I did not have to provide any pdbs previously, since I did not require the option to debug through the burn code.

Where exactly should I add the switch you are talking about?

On Monday, December 5, 2016, 3:29:47 PM GMT+1, Phill Hogland <phill.hogland at rimage.com<mailto:phill.hogland at rimage.com>> wrote:
When you say that debugging used to work about a year ago and now you cannot debug, I think you are referring to the 'breaking change' which was documented in the 10.3.2

http://lists.wixtoolset.org/pipermail/wix-users-wixtoolset.org/2016-January/001251.html

There are several possible solutions, but I think the preferred solution is that when you want to debug, add the following switch to your bundle (or rather to your 'start external program' settings for your mba.dll project).

-burn.clean.room=<path to the external bundle to debug your mba>\bundle.exe

With this change you do not need to make any other changes to your bundle authoring or to the approach used to debug your mba.  Presumably if you were able to debug previously you already had VS configured to find the pdbs, etc, otherwise the steps you did previously to configure VS are still relevant.

________________________________

From: wix-users <wix-users-bounces at lists.wixtoolset.org<mailto:wix-users-bounces at lists.wixtoolset.org><mailto:wix-users-bounces at lists.wixtoolset.org<mailto:wix-users-bounces at lists.wixtoolset.org>>> on behalf of Goran Malovic <malovicg at yahoo.com<mailto:malovicg at yahoo.com><mailto:malovicg at yahoo.com<mailto:malovicg at yahoo.com>>>
Sent: Saturday, December 3, 2016 11:07:26 AM
To: wix-users at lists.wixtoolset.org<mailto:wix-users at lists.wixtoolset.org><mailto:wix-users at lists.wixtoolset.org<mailto:wix-users at lists.wixtoolset.org>>
Subject: [wix-users] Debugging managed BA

Hi,
I have a problem with debugging managed BA. It used to work without problems, but i haven't been using it for the last year, and don't know when it was broken.
So, I have been using suggestion from Rob on SO, and that stopped working. I have ensured that all is built, I run the app, I place breakpoint on BootstrapperApplication.Run() method (and on lots of other different places), but it is not hit. However, the placed breakpoint itself is red, so it is givining an impression that it is "active and loaded". After the F5 Setup.exe is started and shown on screen, which is correct, but I cannot step through the managed BA code.
My BA is built on .NET framework 3.5 Client Profile. I am using VS 2015, and Wix 3.10.3 Here is BootstrapperCore.config:
  <configSections>
    <sectionGroup name="wix.bootstrapper" type="Microsoft.Tools.WindowsInstallerXml.Bootstrapper.BootstrapperSectionGroup, BootstrapperCore">
      <section name="host" type="Microsoft.Tools.WindowsInstallerXml.Bootstrapper.HostSection, BootstrapperCore" />
    </sectionGroup>
  </configSections>
  <startup useLegacyV2RuntimeActivationPolicy="true">
    <supportedRuntime version="v2.0.50727" />
    <supportedRuntime version="v4.0" />
  </startup>
  <wix.bootstrapper>
    <host assemblyName="Project.Bootstrapper.UI">
      <supportedFramework version="v3.5" />
      <supportedFramework version="v4\Client" />
      <supportedFramework version="v4\Full" />
    </host>
  </wix.bootstrapper>
</configuration>
Any ideas?
Thanks,Goran

____________________________________________________________________
WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/

____________________________________________________________________
WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/

____________________________________________________________________
WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/

NOTICE: This electronic mail message and any files transmitted with it are intended
exclusively for the individual or entity to which it is addressed. The message,
together with any attachment, may contain confidential and/or privileged information.
Any unauthorized review, use, printing, saving, copying, disclosure or distribution
is strictly prohibited. If you have received this message in error, please
immediately advise the sender by reply email and delete all copies.

____________________________________________________________________
WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/

____________________________________________________________________
WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/