Add AssemblyResolver to Tasks libraries targeting .NET Framework

[weshaggard]

See dotnet/buildtools#1943. Without this resolver it will become very difficult to align our assembly dependencies across our tasks when running on .NET Framework.

[natemcmaster]

Should we do something similar for .NET Core too using AssemblyLoadContext? See @AArnott's https://github.com/AArnott/Nerdbank.GitVersioning/blob/dc1fb805c6694a2ef7a6ab557c509384f1756085/src/MSBuildExtensionTask/ContextAwareTask.cs for example.

[weshaggard]

From a quick look that seems to be trying to add support for loading native assets side-by-side with the managed assemblies. We may end up needing something like that but for now lets not complicate things.

We will definitely need the .NET Framework assembly resolver if we want to have any hopes of unifying dependent assembly versions that don't have the exact version.

[AArnott]

Having tried so many ways to isolate my tasks, control the versions I load, etc., I've come to this (sad) conclusion: if you care about controlling your assembly loads, just write a tool and have your MSBuild targets invoke it (possibly through a simple MSBuild Task). It's far too much work wasted in the (futile) attempt to get your MSBuild task's environment right. MSBuild wasn't built for tasks that care about multiple assemblies, their versions, etc.

For instance, even if you did everything perfectly, all it takes is two projects to build from the same top-level MSBuild call that bring in different versions of your MSBuild tasks assembly (via nuget package or whatever) and it all blows up anyway (non-deterministically) because MSBuild will only load one of your two task assemblies. Of course that has a workaround too, but then that breaks other workarounds you've used...

Thus I filed multiple issues against msbuild to make this better... but nothing has happened yet.

[natemcmaster]

I've come to a similar conclusion too -- msbuild tasks with dependencies is a thorny path. That said, we have a bunch of tasks already written, and shelling out to a new process has its own problems, too. Maybe we can use Arcade as another chance to nudge MSBuild on this.

[jaredpar]

Shelling out isn't always an option. Take Roslyn as an example. We specifically avoid shelling out during build because it's costly. Yet we also have dependencies not included in the core MSBuild install (pipe ACLs in particular). Loading dependencies is a necessity for us.

Maybe we can use Arcade as another chance to nudge MSBuild on this.

It's as much of a CoreClr problem as MSBuild. Loading dependencies under full framework requires no particular effort. Our assemblies go into the LoadFrom context and hence assemblies deployed beside us just work. For CoreClr though we end up deploying runtime specific assets and hence have to add nasty probing logic to make it work.

[weshaggard]

I agree there is no great answer but at least for the tasks in Arcade we want to agree on dependencies and try to avoid most of these problem. I know that is easier said then done but I think we have to try.

[markwilkie]

@weshaggard - anything more actionable here?

[weshaggard]

Yes we need to port the AssemblyResolver we currently use in BuildTools to Arcade (https://github.com/dotnet/buildtools/blob/master/src/common/AssemblyResolver.cs) it is general purpose and we are going to need it for all the build tasks we use in arcade.

[michellemcdaniel]

Closing because the parent Epic was closed. If you believe this issue should still be worked on, please re-open.