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

[Hoover, Jacob]

This is "by design" with the clean room.  You'll either have to attach after the fact, or embed a Debug.Assert/Debugger.Launch into the code.

-----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/