[wix-devs] Supporting MSBuild Core

Mon Jun 1 05:12:53 PDT 2020

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/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/
>>
>