Errors in referencing .net standard library projects in .net framework based projects is a rather common occurrence. This runtime error “Could not load file or assembly or one of its dependencies. The system cannot find the file specified” has to be one of the most frustrating error. Everything works fine on your machine and moment it gets deployed, BAM !! Lets fix this error.
WHY
As .NET standard and .NET core are gaining popularity it is common to see old projects getting converted to one of these. Often a solution will be there where some projects are now converted to .NET core, some to .NET standard and rest remain the classic .NET framework. Problem is that the way Nuget used to work with old .NET framework projects has changed.
In older classic windows desktop projects package.config was used where all the nuget dependencies were listed. And there used to be a packages folder in the project folder where all the packages used to live.
In the .NET standard and core projects, PackageReferences based package management is used which means that:
- There is no Packages.Config.
- The packages live in C:\Users\FrustratedEngg\.nuget\packages
- There will be no packages folder in the application
Fun begins when we start referencing .net standard library projects in .net framework based projects. If the referenced project had any nuget packages then those packages will not be visible to the .NET framework project. And you get a “Could not load file or assembly or one of its dependencies. The system cannot find the file specified” error.
HOW
Remedy is NOT TO install missing nuget package into the .NET framework project. It leads to other errors. Real solution is to use PackageReferences based package management.
Old projects which are using Nuget Packages.Config have to be migrated to use the Nuget PackageReferences as package manager format. There are more than one way of doing this. Nuget team has provided a migration tool for this. I prefer to using that. Right click on the References section of the project having Packages.Config. You will see the migration option as shown below. It is as simple as that.
There will be occasional naughty packages (I am looking at you Fody) who will not play nice. But then you can simply uninstall them before migration and then reinstall after migration. Packages.Config will disappear once the migration is done.
Some prefer to get their hands dirty in csproj. You can check that out. But I have had mixed results with that.
Way forward
For new classic desktop projects you get an option of choosing the Packages.config or PackageReferences as package manager format as shown below.
Always choose package reference. This is the way forward. Otherwise be ready for errors in referencing .net standard library projects in .net framework based projects.
Note that this option is not available in Visual Studio 2015 and before. So you might have to upgrade to higher version of Visual Studio. If you do not have this option then enable it in the nuget package manager.