[wix-devs] Supporting MSBuild Core

Sat May 30 03:44:31 PDT 2020

Unsubscribe

On Sat, May 30, 2020, 3:32 AM Sean Hall via wix-devs <
wix-devs at lists.wixtoolset.org> wrote:

> I've been thinking more on this. As long as we don't bring in more
> dependencies, it's looks like Core.Native is the only one with platform
> specific dependencies. If we change the target of WixToolset.BuildTasks to
> netcoreapp3.x, we can gain access to AssemblyDependencyResolver. This class
> is provided by the framework to help you resolve dependencies from your
> .deps.json. We could probably add an optional API to Core.Native to
> initialize based on that instead of the normal probing. Of course, we'd
> have to define a custom interface for this API since we wouldn't be able to
> access AssemblyDependencyResolver from netstandard2.0. It's not perfect,
> but I think that would solve our specific problem where in-proc wouldn't
> work.
>
> On Thu, May 28, 2020 at 12:45 PM Rob Mensching <rob at firegiant.com> wrote:
>
> > 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/
> >
> ____________________________________________________________________
> WiX Toolset Developer Mailing List provided by FireGiant
> http://www.firegiant.com/
>