`dotnet some.dll` randomly fails on Windows with System.IO.FileSystem v4.0.1.0 not found error

This is driving my nutty. There is no consistent repro. When it starts to fail, it seems to continually fail when the dotnet.exe is spawned from my (full) MSBuild.exe Task. But once I dotnet build (which also spawns my Task but from Core MSBuild Core, it works and then (full) MSBuild will work for a while as well. Then it will start failing again randomly later.

Steps to reproduce

git clone https://github.com/AArnott/libgit2sharp.git
cd libgit2sharp
git checkout portable
MSBuild /t:restore
msbuild

Expected behavior

The build succeeds.

Actual behavior

C:\Users\andarno.nuget\packages\codegeneration.roslyn.buildtime\0.3.13-gfce1c8ba1e\build\CodeGeneration.Roslyn.BuildTime.targets(20,5): error MSB6003: The specified task executable “dotnet” could not be run. Could not load file or assembly ‘System.IO.FileSystem, Version=4.0.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a’ or one of its dependencies. The system cannot find the file specified. [C:\git\libgit2sharp\LibGit2Sharp\LibGit2Sharp.csproj]

Environment data

dotnet --info output:

.NET Command Line Tools (1.0.3)

Product Information: Version: 1.0.3 Commit SHA-1 hash: 37224c9917

Runtime Environment: OS Name: Windows OS Version: 10.0.15063 OS Platform: Windows RID: win10-x64 Base Path: C:\Program Files\dotnet\sdk\1.0.3

[rainersigwald]

Ok, I know what’s happening, including why this is intermittent.

GenerateCodeFromAttributes is a netstandard assembly, compiled against the transitive closure of dependencies of MSBuild’s netstandard flavor, which includes System.IO.FileSystem. On full framework, that is a facade assembly that forwards types to the installed framework, but it still needs to be reachable in order to load the task.

In cases where the task succeeds, it is because something else has already loaded System.IO.FileSystem into memory, so the loader doesn’t attempt to find it again. The Roslyn compiler Csc task does this, loading it from (on my machine) C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\bin\Roslyn\System.IO.FileSystem.dll. In cases where the failure happens, prior instances of Csc have been skipped and the assembly hasn’t been loaded into the MSBuild.exe process.

At the moment, the “right” way to deliver a portable MSBuild task is to ship two versions–one published for full framework, and one for netstandard–and select the right one via UsingTask. That way, the assembly loader can find the facades required to use the task in full framework next to the full framework copy of the assembly (which can be bit-for-bit identical to the netstandard copy, but needs to live in a separate folder).

This is awful, of course. The expected long-term solution is https://github.com/Microsoft/msbuild/issues/1542.

[AArnott]

Thanks. I had worked very hard to get my netstandard1.3 task working in both worlds so I didn’t have to deal with the complexity you describe. Bummer that it was doomed to fail before I started without my realizing it.

Thanks for the tip.