[wix-devs] Supporting MSBuild Core

[Rob Mensching]

Cool. It'd be good to see the performance difference using the in-proc vs out of proc solutions on Framework. Doesn't sound like we have a chose for Core.

-----Original Message-----
From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of Sean Hall via wix-devs
Sent: Wednesday, May 27, 2020 3:33 PM
To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
Cc: Sean Hall <r.sean.hall at gmail.com>
Subject: Re: [wix-devs] Supporting MSBuild Core

Why? wix.exe for full framework is only 9kb which is actually smaller than its config file at 19kb.

On Thu, May 28, 2020 at 6:36 AM Rob Mensching via wix-devs < wix-devs at lists.wixtoolset.org> wrote:

> Oh, I forgot about that part. There is only wix.exe for dotnet.
>
> Yeah, scratch that.
>
> -----Original Message-----
> From: Bob Arnson <bob at firegiant.com>
> Sent: Wednesday, May 27, 2020 12:20 PM
> To: Rob Mensching <rob at firegiant.com>; WiX Toolset Developer Mailing 
> List <wix-devs at lists.wixtoolset.org>
> Subject: RE: [wix-devs] Supporting MSBuild Core
>
> Today the Framework tasks don't and can't be out of proc -- they don't 
> ship wix.exe, just the core. Are you proposing we make both Framework 
> and Core tasks run wix.exe?
>
> -----Original Message-----
> From: Rob Mensching <rob at firegiant.com>
> Sent: Wednesday, 27 May, 2020 14:54
> To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
> Cc: Bob Arnson <bob at firegiant.com>
> Subject: RE: [wix-devs] Supporting MSBuild Core
>
> Sounds like for "dotnet build"/MSBuild Core we'll need to go out of proc.
> The performance boost isn't worth the apparent backflips needed to 
> make it work in-proc. Which (as Bob hints) leads to the question, 
> should we go "always out of proc" now that there is a single 
> executable invocation. In v3, I remember it was a noticeable build 
> improvement when someone (I forget who... JRock or Derek probably) loaded the tools in-proc.
>
> Sounds like--since we need to for MSBuild Core--it is time to 
> re-measure the performance hit of running out of proc. If it isn't too 
> bad (given the single executable) then we can move to out of proc 
> always. That consistency would be very nice.
>
> Wiring the messages through MSBuild should be pretty straight forward 
> as wix.exe already spits out messages in MSBuild's preferred format. 
> IIRC, the ToolTask might already handle the message processing.
>
>
> -----Original Message-----
> From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of 
> Bob Arnson via wix-devs
> Sent: Wednesday, May 27, 2020 6:25 AM
> To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
> Cc: Bob Arnson <bob at firegiant.com>
> Subject: Re: [wix-devs] Supporting MSBuild Core
>
> Process creation is relatively slow. However, if the tasks were to 
> wrap wix.exe, it would reduce the number of processes created compared 
> to WiX v3 (candle, candle, candle, candle, light).
>
> -----Original Message-----
> From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of 
> Sean Hall via wix-devs
> Sent: Wednesday, 27 May, 2020 08:30
> To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
> Cc: Sean Hall <r.sean.hall at gmail.com>
> Subject: [wix-devs] Supporting MSBuild Core
>
> I've done some research into how MSBuild Core handles custom tasks and 
> it's not looking good for us. .NET Core does not make it easy for an 
> application like MSBuild to dynamically load arbitrary assemblies with 
> all their dependencies, especially when those dependencies are 
> platform specific.
> Even if https://github.com/microsoft/msbuild/issues/5037 was already 
> implemented, we'd still have issues with Core.Native locating wixnative.exe.
>
> If we want to keep everything in-proc, then we'll have to follow what 
> NerdBank.GitVersioning's did. They create a completely separate 
> AssemblyLoadContext (.NET Core's counterpart to AppDomain), and then 
> reinstantiate the task inside of there with some reflection ( 
> https://github.com/dotnet/Nerdbank.GitVersioning/blob/master/src/Nerdb
> ank.GitVersioning.Tasks/ContextAwareTask.cs
> ).
> Then they have some custom logic to find the native dll ( 
> https://github.com/dotnet/Nerdbank.GitVersioning/blob/master/src/Nerdb
> ank.GitVersioning.Tasks/GitLoaderContext.cs
> ).
> We'd also have to modify how Core.Native locates wixnative.exe.
>
> Handling dependencies would be much easier to do things out of proc, 
> which is what Roslyn does. This lets us continue to rely on .NET 
> Core's built-in functionality for dependency resolution. I'm not sure 
> how hard it would be to hookup the messaging so that messages from WiX 
> are properly logged in MSBuild. I know we were trying to avoid doing 
> this for performance reasons, but were there any other reasons we 
> tried to go fully in-proc in v4? I'm curious where the performance penalties come from.
> ____________________________________________________________________
> WiX Toolset Developer Mailing List provided by FireGiant 
> http://www.firegiant.com/ 
> ____________________________________________________________________
> WiX Toolset Developer Mailing List provided by FireGiant 
> http://www.firegiant.com/ 
> ____________________________________________________________________
> WiX Toolset Developer Mailing List provided by FireGiant 
> http://www.firegiant.com/
>
____________________________________________________________________
WiX Toolset Developer Mailing List provided by FireGiant http://www.firegiant.com/