AssemblyLoadContext-related task errors in 16.5

[rainersigwald]

Background

Before 3.1.200, MSBuild tasks and their dependencies were loaded into the default ALC. Since an ALC can have only one assembly loaded for the same name (not including version), this forced all tasks to use the same version of dependencies, and that version had to match the one delivered in the .NET Core SDK (if the assembly was there). This was very annoying and broke people.

In MSBuild 16.5/SDK 3.1.200, we isolated plugins in their own ALC (#4916). We planned to extend this in the .NET 5 timeframe to use an AssemblyDependencyResolver, to further improve the situation for native dependencies (#5037).

There is an environment-variable-based workaround MSBUILDSINGLELOADCONTEXT=1 available to revert to the previous behavior.

Problems

This change broke some tasks that use reflection or fancy assembly loading inside the task implementation. All users of affected tasks are broken, not just the maintainers of the tasks.

Known failures are:

• GitVersionTask (457 NuGet downloads/day)
• Fody <6.0.4 (2730 downloads/day, but I don’t know the version breakdown)
• SpecFlow (3215 downloads/day)
• MSBump (92 downloads/day, repo archived)

Related issues

• .NET Core SDK 3.1.200 breaks build which is using GitVersionTask sdk#10878
• SpecFlow doesn't work with .NET Core 3.1.200 SDK SpecFlowOSS/SpecFlow#1912
• the combination of VS 2019 Version 16.5.0 Preview 2.0 and .NET Core 3.1.200-preview-014883 fails dotnet build GitTools/GitVersion#2063 (fixed in upcoming 5.3.0)
• Fody .NET Core SDK 3.1.200 breaks build which is using GitVersionTask sdk#10878 (comment) (fixed in 6.0.4+)
• MSBump .NET Core March 16, 2020 Update - 3.1.200 SDK core#4404 (comment)
• coverlet.msbuild 2.6.3, resolved in at least 2.8.1 (reported Upgrading .NET Core SDK from 3.1.103 to 3.1.200 breaks code coverage collection sdk#11274) possibly fixed by Fix 'Failed to resolve assembly' cecil issue coverlet-coverage/coverlet#625
• microsoft.web.librarymanager.build 1.0.163 (AB#1093418). No repro in latest 2.1.76.

[rainersigwald]

Figured out the SpecFlow case: SpecFlowOSS/SpecFlow#1912 (comment).

In short, this is an expected behavior of Assembly.LoadFile that was sort of worked around before because MSBuild could find dependencies in AssemblyLoadContext.Default.

[AArnott]

@rainersigwald It turns out it isn't solved by coverlet.msbuild 2.8.1. This PR is blocked in updating to .NET SDK 3.1.201 because of this same break, and updating coverlet didn't fix it. So I'm still blocked.

dotnet/Nerdbank.Streams#180

[rainersigwald]

@AArnott sorry it took me a while to get to this, but I don't see anything that looks like an MSBuild task failure in that PR. Can you point me to what you think is failing?

[AArnott]

Quite right. I forgot in that PR that updating to coverlet.msbuild 2.8.1 also changes the filenames of the coverage files generated, so there's more to adapting to the task loader change than just updating the package reference.

[rainersigwald]

Closing: all of the known active-development tasks that had problems have been fixed in new releases.

[marcpopMSFT]

For gitversion, recent exceptions customers have been facing have been the below: Adding a comment to help with customer searches.
Error Exception in initialization: System.IO.FileNotFoundException: Could not load file or assembly ‘System.ValueTuple, Version=4.0.2.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51’ or one of its dependencies. The system cannot find the file specified.