[wix-devs] Supporting MSBuild Core

Mon Jun 1 15:39:20 PDT 2020

Easy enough. The next question is how we want to configure the .NET Core
tools to roll forward. This seems to be the place where documentation
should be but seems to be missing information -
https://docs.microsoft.com/en-us/dotnet/core/versions/selection - because I
know .NET Core 2.x had different options than 3.x. Looks like this has more
info - https://github.com/dotnet/docs/issues/12237.

P.S. For Nano, they're still releasing new versions of the container and it
says there's 100M+ downloads -
https://hub.docker.com/_/microsoft-windows-nanoserver

On Tue, Jun 2, 2020 at 2:49 AM Rob Mensching <rob at firegiant.com> wrote:

> There are enough hedging comments--like " As long as we don't bring in
> more dependencies "--that I don't feel better about trying to run the build
> in-proc on .NET Core.
>
> I really don't want to be fighting MSBuild design limitations. It tends to
> lead to headaches that I'd prefer to avoid. If they are not designed to run
> extensible MSBuild Tasks in-proc, then let's not do that.
>
> PS: ARM32 that's a different can of worms. Is Nano server still a thing?
>
> -----Original Message-----
> From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of Sean
> Hall via wix-devs
> Sent: Monday, June 1, 2020 5:13 AM
> 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
>
> So is targeting .NET Core 3.1 acceptable for the build tasks? The only
> difference in supported platforms between the two is that 3.1 doesn't
> support 2008 R2 (server counterpart to Win7).
>
> As an aside, when looking at the supported OS's for 3.1 now I see where
> ARM32 is supported - Nano server. These days Nano server is available as
> containers only and doesn't have Windows Installer. Also, it appears that
> you can run ARM32 UWP apps on Win10 ARM64 devices (
> https://docs.microsoft.com/en-us/windows/uwp/porting/apps-on-arm). The
> Debugging section here makes it seem like VS does support debugging ARM32
> in some fashion -
>
> https://docs.microsoft.com/en-us/windows/uwp/porting/apps-on-arm-troubleshooting-arm32
> .
>
> So ARM32 doesn't appear to be dead, but it doesn't seem like there's
> anywhere that you can run ARM32 custom actions. Burn could theoretically be
> able to run on ARM32 Nano server, but we'd probably have to have a special
> build configuration to ifdef out all the code that relies on subsystems
> that aren't in Nano.
>
> On Sat, May 30, 2020 at 6:31 PM Sean Hall <r.sean.hall at gmail.com> 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/Ne
> >> > rdb 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/Ne
> >> > rdb 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/
>