Could not load file or assembly 'System.IO.FileSystem…'

Question

I'm using .NET Standard 1.3 and .NET Framework 4.6.

Most importantly, I'm trying to access these classes from System.IO.FileSystem:

Directory class (i.e. Directory.Delete();)
File class (i.e. File.Exists();)
FileInfo class (i.e. FileInfo fi = new FileInto();)

But I always end up getting errors like:

Could not load file or assembly 'System.IO.FileSystem, Version=4.0.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

I've installed System.IO.FileSystem 4.3.0 for the .NET Standard 1.3 libraries.

I've tried deleting bin files, cleaning, rebuilding, restoring nuget packages, editing the .csproj file, etc. Nada.

These are basic classes that are present in all versions of System.IO. You've got a more mundane problem where your build is misconfigured, like referencing assemblies that don't match your platform (which then indirectly reference System.IO). The .NET Framework assemblies are not the same as the .NET Standard versions of those assemblies; in that sense they are not "equivalent" and you can't mix and match. A .NET Standard project must reference .NET Standard assemblies only. — Jeroen Mostert
Thanks for your response, @JeroenMostert! So would it work if in my .NET Framework class A(), I create an object from my .NET Standard class B() that calls method b.Delete(); (which it calls Directory.Delete();)? That's pretty much how my current logic is right now. — susieloo_
Yes, the basic setup should work. Given the error message, it seems probable that something in your project is ending up with a hard (non-compatible) reference to version 4.0.1 of the System.IO.FileSystem package, while 4.3.0 is installed. Diagnosing the exact cause from a distance is hard, though. NuGet dependency resolution is notoriously tricky. It will often not automatically "do the right thing" with regards to versions across projects. — Jeroen Mostert
Use assembly redirection in app.config to address the issue. It has nothing to do with the API surface. Besides, if you don't use any .NET Standard based assemblies you don't even need to add a reference to System.IO.FileSystem. — Lex Li
@LexLi I have tried assembly redirection. Also does not work :\ — susieloo_

AaronLS AaronLS · Accepted Answer · 2017-07-31T21:28:58

Remove the reference under References.

Go up to your packages folder and search for that assembly in any packages.
Look for any offending wrong version of the assembly. If you locate it, then you can see what nuget package it is being pulled in under. If you find one that is the wrong version, then go in VS and uninstall that nuget package from all projects.

Another troubleshooting step is to open the project file as XML and look for the Reference tag. Usually there is a HintPath such as this that will clue you in to the offending package or hard reference. (By "offending", I mean to allow us to determine where it is finding the assembly that is the wrong incompatible version)

<HintPath>..\packages\Microsoft.Bcl.1.1.10\lib\net40\System.IO.dll</HintPath>

This is how you'd find a bad hard coded path as a result of someone using the "Browse" option when adding an assembly, which is a bad practice when dealing with BCL assemblies.

Note I never edit the project file at this point to repoint the reference. This is just to figure out where the offender is at and remove either the package or the bad assembly if another dev has checked in the binary to the solution(another terrible practice for BCL libraries).

Clean+Rebuild and it should be broken because there is no assembly reference.

At this point I've cleaned out the bad reference. It used to be now I would use the Add Reference -> and select from the Framework section. This basically is a GAC reference.

These days I now get the appropriate nuget package, which should add the correct reference based on your target framework, you can explicitely choose the version of the assembly you want, just make sure all related projects in your solution are using the same version to avoid problems: https://www.nuget.org/packages/System.IO/

This can be difficult to work out because often their is not an official package for your single assembly, but is contained in a larger package named something like Microsoft.BCL or Microsoft.AspNet.WebAPI.Client(Which I have used to get Http assemblies). This is what I find to be the most difficult part, but looks like the above link should give you the specific version you need(hopefully).

Installing the nuget package should add the reference to your project now(this is why we removed any other reference that would prevent the correct one from being added). Double check your Output tab and the various "Show output from:" sections to make sure there were no errors during the nuget install.

These days most of these are pulled in through a nuget package to get the versions in sync across all your related projects. I honestly don't understand why BCL classes are being pulled in through Nuget now when they are part of the installed framework, but this is the way it seems things are done now and the way I get them to consistently work.

Could not load file or assembly 'System.IO.FileSystem…'

2 Answers