6

I have a .NET Core console application and a .NET Core class library. Both are extremely simple, single class projects. Both are freshly built, with a fresh install of the latest .NET Core. Both target .NET Core 1.1.

This error occurs at runtime whenever I include a .NET Core class library in an application:

System.IO.FileNotFoundException: 'Could not load file or assembly 'NAME, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'. The system cannot find the file specified.

Building either projects are fine, and Intellisense shows me the contents of the class library after including a using... statement. With the reference and code written there are no issues at compile time.

I've set the Copy Local to Yes for the referenced assembly in my console application. The referenced DLL exists in the bin folder of the console application during run time.

Here is the csproj reference:

<Reference Include="NAME">
  <HintPath>path\bin\Debug\netcoreapp1.1\NAME.dll</HintPath>
  <Private>true</Private>
  <SpecificVersion>false</SpecificVersion>
</Reference>

This only happens with .NET Core DLLs, I have absolutely no issues with .NET Framework 4.5.* and up.

Could anybody shed some light on this issue? Any SO/MSDN pages I've found regarding this have been specific problems like targeted the incorrect version of a DLL, which doesn't help.

James Gould
  • 4,492
  • 2
  • 27
  • 50
  • Use .NetCore 2.0. You will be able to find this support in it. Preview Version is already available. https://www.microsoft.com/net/core/preview#windowscmd – Haseeb Jadoon May 25 '17 at 11:47

3 Answers3

5

Referencing DLL files in a .NET Core application is not supported using the pre-2.0 tools.

The reason is that the dependency graph (deps.json file) generation does not include these files and most likely wouldn't work anyway since it cannot consolidate references / dependencies of the referenced DLL anyway.

For the upcoming 2.0 release, this scenario should work as long as you also reference all DLLs / packages that the original package is using. The syntax would be:

<Reference Include="path/to/my.dll" />

.NET Core 2.0 will also support referencing assemblies that have been built for .NET 4.6.1 this way, but it may fail at runtime if the DLL uses unsupported API calls.

Martin Ullrich
  • 94,744
  • 25
  • 252
  • 217
3

After lots of digging, I found a solution for .NET Core 2.0 that works for me.

The core issue: I added the project references through Visual Studio 2017. In my web application, I referenced two .NET Core libraries; while everything compiles, at runtime, I get a FileNotFound exception pointing to one of the two DLLs.

The solution that worked for me:

  • Close Visual Studio
  • Open the .csproj with the references in it. Delete the references to the projects.
  • From a terminal, cd into the project folder and add the references by hand, using dotnet add reference ..\..\foo\bar.csproj
  • Start Visual Studio, build and run your (web) application

For me, this resolved the issue.

nightblade9
  • 354
  • 2
  • 15
  • This is adding the reference in the same way that the accepted answer does, just via the command line. Should work in the same way though. – James Gould Nov 15 '18 at 16:38
  • I agree that it sounds the same. I can also testify that, at least in my case, there was a difference; adding through Visual Studio created an error at runtime, while adding through `dotnet` didn't. I didn't have the first version checked in, so I'm not sure what the difference in the `.csproj` was, but I would have really liked to see it for myself. – nightblade9 Nov 15 '18 at 18:19
  • Also, there is a difference; perhaps it's .NET Core 2.1, but the tag is `ProjectReference`, not `Reference` – nightblade9 Nov 15 '18 at 18:20
  • 1
    Strange that those would be so out-of-sync. Thanks for the reference though, I'm sure someone else will solve their issue with this. – James Gould Nov 19 '18 at 09:29
  • I hope so. This issue is awfully difficult to resolve, there's not much other info on the interwebz about it. Thanks for the comment/discussion BTW. – nightblade9 Nov 19 '18 at 13:43
2

Not sure if this would count as a fix but it's a workaround at least.

Rather than referencing the DLL I've simply added the project for the class library to the console application, included a dependency reference to the class library project in the console application and clean/rebuilt. Working fine.

Obviously this isn't a fix for DLLs that are proprietary, but it may help.

James Gould
  • 4,492
  • 2
  • 27
  • 50
  • I do not understand, what you did? Please clarify. For my small C# project I did not use Visual Studio, I prefer CLI. – Vitaly Zdanevich May 03 '19 at 08:54
  • I'm not sure about using the CLI, but instead of clicking `Add -> Reference` in Visual Studio, I attached the DLL as a new project as part of the overall solution. – James Gould May 07 '19 at 08:22