MsBuild copies dlls from its current/bin folder and app failes at startup.

Question

Hello!

There are some lines from output:

Target "_CopyWebApplicationLegacy" in file "C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets" from project "<..projectDir..>\TenantService.csproj" (target "CopyFilesToOutputDirectory" depends on it)

>

....

>

19:44:31 Copying file from "C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Current\Bin\System.Threading.Tasks.Extensions.dll" to "<..outDir..>\System.Threading.Tasks.Extensions.dll".

It is very strange for me. It breaks our runtime, because correct newer version (4.2.0.1) of System.Threading.Tasks.Extensions.dll from Nuget packages cache is not used. Why does MsBuild decide to put this dll from its own Current\Bin (version 4.2.0.0) despite of project's dependencies? Why doesn't it take it from Nuget packages cache instead (like it does for all other dlls)?

Same thing happens for Microsoft.Bcl.AsyncInterfaces.dll.

P.S. These two dlls or its packages are not referenced by TenantService.csproj directly. They come via some other dependencies, but it has bindingRedirects for these dlls in config file.

Earlier in output we se that correct (newer) version of dll is located successfully:

19:44:25 Primary reference "System.Threading.Tasks.Extensions, Version=4.2.0.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51".
19:44:25 Resolved file path is "C:\MightyPackages\system.threading.tasks.extensions\4.5.4\lib\netstandard2.0\System.Threading.Tasks.Extensions.dll".
19:44:25 Reference found at search path location "{HintPathFromItem}".
19:44:25 This reference is not "CopyLocal" because at least one source item had "Private" set to "false" and no source items had "Private" set to "true".

Almost complete msbuild output is here:

[151046-msbuild-output.txt][2]

Project file: [151083-tenantservicecsproj.txt][1]

I can provide any other info or files.
Thank you!

Ilya.

Answer 1

This is a common issue with quite a few packages. Bcl was notorious for this. Ultimately it isn't MSBuild per se but rather the task(s) that build up the dependencies have ultimately decided the version in the path you gave are the best choices (likely from the Bcl reference).

The only workaround in most cases is to explicitly reference the newer Nuget package in your project. This will cause it to take precedence over any transient package references. However you should probably look at the MSBuild diagnostic level logs to see where it looked for the dependencies.

I notice that MSBuild is saying your app is a .NET Core app. Therefore Bcl shouldn't be needed at all. I also wonder if you have a dependency on a package that doesn't support your framework and is falling back such that it would need this dependency. If you can fix that dependency to use the .NET Core version (if any) then the problem should be resolved as well.