Unable to build a netstandard2.0 project from a net8.0 unit test

[DarkDaskin]

I have a unit test which builds several projects targeting net46 and netstandard2.0. net46 ones build successfully, but netstandard2.0 ones fail with the following error:

C:\Program Files\dotnet\sdk\8.0.315\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.targets(284,5): error MSB4018: The "GenerateDepsFile" task failed unexpectedly.
System.IO.FileLoadException: Could not load file or assembly 'Microsoft.Extensions.DependencyModel, Version=8.0.0.2, Culture=neutral, PublicKeyToken=adb9793829ddae60'. Could not find or load a specific file. (0x80131621)
File name: 'Microsoft.Extensions.DependencyModel, Version=8.0.0.2, Culture=neutral, PublicKeyToken=adb9793829ddae60'
 ---> System.IO.FileLoadException: Could not load file or assembly 'Microsoft.Extensions.DependencyModel, Version=8.0.0.2, Culture=neutral, PublicKeyToken=adb9793829ddae60'.
   at System.Runtime.Loader.AssemblyLoadContext.LoadFromAssemblyPath(String assemblyPath)
   at System.Runtime.Loader.AssemblyLoadContext.ResolveUsingLoad(AssemblyName assemblyName)
   at System.Runtime.Loader.AssemblyLoadContext.Resolve(IntPtr gchManagedAssemblyLoadContext, AssemblyName assemblyName)
   at Microsoft.NET.Build.Tasks.GenerateDepsFile.WriteDepsFile(String depsFilePath)
   at Microsoft.NET.Build.Tasks.TaskBase.Execute()
   at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
   at Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask(ITaskExecutionHost taskExecutionHost, TaskLoggingContext taskLoggingContext, TaskHost taskHost, ItemBucket bucket, TaskExecutionMode howToExecuteTask) [C:\Users\DarkDaskin\Documents\Development\UnityModStudio\UnityModStudio.Build.Tests\bin\Debug\net8.0\Projects\Correct\MultiVersionMultiTarget\MultiVersionMultiTarget.csproj]

The same projects can be built with dotnet build without problems.

I also tried to switch my unit tests to net9.0, but the same error persists (with different assembly version).

I use MSBuildLocator.RegisterDefaults(); to locate an MSBuild instance.

Installing the Microsoft.Extensions.DependencyModel package into the unit test project allows to build everything successfully, but I guess that MSBuildLocator should have loaded this assembly from the SDK directory automatically.

[teo-tsirpanis]

I took a look at the issue (presuming that your project is this), and it looks like the behavior is by design.

By the use of MTP, your project took a dependency to Microsoft.Extensions.DependencyModel version 6.0.2. As part of running a task, MSBuild tried to load its private copy of version 8.0.2 into its task's isolated AssemblyLoadContext. However, as a dependency of the main application, the version 6.0.2 assembly was included in TRUSTED_PLATFORM_ASSEMBLIES, and as I learned today, the runtime will not allow loading a newer assembly version than the one in TPA, even on a separate AssemblyLoadContext¹, and even if the TPA assembly has not been loaded before. This is what caused the FileLoadExceptions you observed.

A minimal reproduction of the issue follows:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net8.0</TargetFramework>
	<ImplicitUsings>true</ImplicitUsings>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.Extensions.DependencyModel" Version="6.0.2"/>
  </ItemGroup>
</Project>

using System.Runtime.Loader;

// Adjust for your environment:
const string AssemblyPath = @"C:\Program Files\dotnet\sdk\8.0.418\Microsoft.Extensions.DependencyModel.dll";

var asm = AssemblyLoadContext.Default.LoadFromAssemblyPath(AssemblyPath);
Console.WriteLine(asm);

I'm going to open an issue in dotnet/runtime to follow up; this behavior looks odd to me, and at the very least it should be documented and give a more helpful error message. If the runtime team determines that this behavior is expected, the list of prohibited package references might have to be expanded to include all assemblies installed in the .NET SDK folder.

Your workaround of referencing a newer version of Microsoft.Extensions.DependencyModel seems to be the best right now. The hypothetical alternative of setting ExcludeAssets="runtime" to the package reference wouldn't be right, because MSTest might use it.

Footnotes

1. If the user tries to load an older version of the assembly, it will be ignored, and the TPA assembly will be loaded. ↩

[teo-tsirpanis]

As it turned out, my initial analysis was not entirely right, and I opened a PR to MSBuild that fixed the test failures locally.