[wix-users] WiX v3.10.2 Important Security Fix Release breaks Debugging?

[Jürgen Schäpker]

Hi,

thanks for the answer.

The method seems to be unnecessarily complicated compared to before.

Would it be a lot of work to make it possible to optionally disable the clean-room technique via a burn argument for easier debug purposes?


Best regards,
Jürgen Schäpker

-----Ursprüngliche Nachricht-----
Von: wix-users [mailto:wix-users-bounces at lists.wixtoolset.org] Im Auftrag von Phill Hogland
Gesendet: Montag, 25. Januar 2016 14:42
An: WiX Toolset Users Mailing List
Betreff: Re: [wix-users] WiX v3.10.2 Important Security Fix Release breaks Debugging?

Wix Online meeting (held prior to the release of 3.10.2) details the breaking changes including that debugging a mba is a little more difficult).
https://www.firegiant.com/blog/2016/1/20/wix-v3.10.2-released/

I also posted this info last week, but here are the steps which I use (in addition to the typical debug process that I was doing prior to the 3.10.2 Release):
1) Add a line of code early in the mba Run method to 

[Conditional("DEBUG")]
        private static void AttachDebuger()
        {
            System.Diagnostics.Debugger.Launch();
            return;
        }
        protected override void Run()
        {
            // Comment out when attaching to a debugger is not desired.
            //AttachDebuger();

2_Compiling the mba and then the bundle.exe, (which is configured in the mba project as the exe to load the mba 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 mba 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).

At that point you can debug as you have done in the past (whether local or remote).

When I don't want to attach a debugger, but still run a project in my 'first' working session of the IDE, I launch DebugView to see what used to be displayed in the Output windows of the VS IDE.

Phill



-----Original Message-----
From: wix-users [mailto:wix-users-bounces at lists.wixtoolset.org] On Behalf Of Jürgen Schäpker
Sent: Monday, January 25, 2016 4:13 AM
To: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
Subject: Re: [wix-users] WiX v3.10.2 Important Security Fix Release breaks Debugging?

Hello,

WiX310_3.10.2.2516 breaks the ability to correctly debug my custom BA.

Visual Studio 2013, C# project. With WiX310_3.10.1.2213 it worked fine with "Start external Program" set to the BA_Setup.exe.

With the new WiX all I can do is start the Setup and then "Attach to Process" when it has already started.


Best regards,
Jürgen Schäpker

-----Ursprüngliche Nachricht-----
Von: wix-users [mailto:wix-users-bounces at lists.wixtoolset.org] Im Auftrag von Rob Mensching
Gesendet: Donnerstag, 21. Januar 2016 00:36
An: WiX Toolset Users Mailing List
Betreff: [wix-users] WiX v3.10.2 Important Security Fix Release

All,

We just finished releasing WiX v3.10.2. If you are using Burn it is *highly* recommended that you upgrade to mitigate Windows issues recently reported. For more information see: https://www.firegiant.com/blog/2016/1/20/wix-v3.10.2-released/

It is important to note that there are two potential breaking changes in this security update. These breaking changes are necessary to mitigate the security issues. Copied the link above:

* A bundle cannot be named Setup.exe. When an executable is named Setup.exe, Windows loads additional DLLs in an insecure manner. To prevent such a guaranteed vulnerability, Light.exe now yields an error if the bundle output is named Setup.exe. As Setup.exe might be a common file name, this breaking change is especially annoying. Unfortunately, Windows loads the additional DLLs in a way that Burn code cannot mitigate.

* The process that loads the bootstrapper application is no longer the process the user started. Attempts to use ::GetModuleFileName to locate the source media (i.e., with loose files next to the bundle .exe) will fail. A workaround is to use the new WixBundleSourceProcessPath and WixBundleSourceProcessFolder variables to find the original process. In general, this shouldn't be a serious problem-bootstrapper applications can already carry all the files they need using Payload elements.


Again, if you are using Burn it is *highly* recommended that you upgrade to WiX v3.10.2 as soon as possible: https://wix.codeplex.com/releases/view/619491


Regards,

  Rob Mensching
  CEO
  FireGiant
_______________________________________________________________
FireGiant  |  Dedicated support for the WiX toolset  |  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/

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