`dotnet some.dll` randomly fails on Windows with System.IO.FileSystem v4.0.1.0 not found error
See original GitHub issueThis 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
Issue Analytics
- State:
- Created 6 years ago
- Comments:9 (9 by maintainers)
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 includesSystem.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 compilerCsc
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 ofCsc
have been skipped and the assembly hasn’t been loaded into theMSBuild.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.
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.