[wix-devs] Supporting MSBuild Core

[Sean Hall]

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/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/
> ____________________________________________________________________
> WiX Toolset Developer Mailing List provided by FireGiant
> http://www.firegiant.com/
>