[wix-devs] Supporting MSBuild Core

Sean Hall r.sean.hall at gmail.com
Wed May 27 05:29:55 PDT 2020


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.


More information about the wix-devs mailing list