[wix-devs] Supporting MSBuild Core

[Rob Mensching]

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/Nerdbank.GitVersioning.Tasks/ContextAwareTask.cs).
Then they have some custom logic to find the native dll ( https://github.com/dotnet/Nerdbank.GitVersioning/blob/master/src/Nerdbank.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/