2

Using VisualStudio 2019.

There are 3 assemblies:

  • .Net Framework 4.7.2 - main app
  • .Net Standard 2.0 - common interface library
  • .Net Core 3.1 - library that implements common interface library

Also following is true:

  • .Net Framework 4.7.2. references .Net Standard 2.0 common library through Nuget
  • .Net Core 3.1. references .Net Standard 2.0 common library through Nuget (and implements it)

I am trying to create an instance of .net core 3.1 assembly and then call the method of that instance from the Framework 4.7.2 application. The Framework app knows which interface methods to invoke.

Instance creation works fine, but then, when I try calling a method of that instance - following exception is thrown:

{"Could not load file or assembly 'System.Runtime, Version=4.2.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.":"System.Runtime, Version=4.2.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"}

Following the advice mentioned in this thread How do you reference a netstandard project from .net project in VS2017? I have added a Nuget reference to NETStandard.Library v2.0.3 to the main .Net Framework application, but it did not resolve the issue.

is it possible to operate with .net core libraries within .net framework app domain? What am i doing wrong?

Alex
  • 4,607
  • 9
  • 61
  • 99
  • .NET Core is a separate platform. You cannot combine .NET Core and .NET Framework assemblies in one process, unless those assemblies happen to be .NET Standard assemblies (which is why .NET Standard is a thing in the first place) or unless the Framework assembly "happens to work" on Core due to compatibility shims (the other way around is definitely not possible). That means the *implementation* has to be .NET Standard too; you can't get around the incompatibility by sliding in interfaces that reside in a .NET Standard lib. – Jeroen Mostert Jul 07 '20 at 08:46
  • @JeroenMostert is it still true even if I publish the .net core app as a self-contained application? – Alex Jul 07 '20 at 08:50
  • @Alex yes, basically – Marc Gravell Jul 07 '20 at 08:52
  • You can compile the .NET Core code as its own app, but then you will end up with two separate processes (one Framework, one Core) that you have to do communication between. This resolves any incompatibility, of course, at the cost of a more complicated architecture and having to do IPC. – Jeroen Mostert Jul 07 '20 at 08:53
  • @MarcGravell thank you for the quick responses. I will close the question. edit: too late for that? :) – Alex Jul 07 '20 at 08:53

1 Answers1

2

Ultimately, the problem can be traced to here:

.Net Core 3.1 - library that implements common interface library

This is a platform specific library that implements common interface library; you can only use it from netcoreapp3.1 (or above).

If you want to use that library from the .NET Framework codebase, that library should do one of:

  1. target netstandard2.0 - if you don't need anything framework-specific in the implementation
  2. multi-target netcoreapp3.1 and netstandard2.0 - if you want to use netcoreapp3.1 features when they are available, or use a down-level common implementation otherwise
  3. multi-target netcoreapp3.1 and net472 - if the implementations are completely platform specific and no common implementation is possible

Multi-targeting is as simple as changing the csproj:

<TargetFramework>netcoreapp3.1</TargetFramework>

to

<TargetFrameworks>netcoreapp3.1;netstandard2.0</TargetFrameworks>

You automatically get a NETCOREAPP3_1 or NETSTANDARD2_0 build symbol you can test for with #if, or you can make other decisions in the csproj via conditions, for example:

<ItemGroup Condition="'$(TargetFramework)'=='netstandard2.0' OR '$(TargetFramework)'=='netcoreapp3.0'">
    <PackageReference Include="System.Data.SqlClient" Version="4.6.1" />
</ItemGroup>
Marc Gravell
  • 1,026,079
  • 266
  • 2,566
  • 2,900
  • good explanation.. now that I think of it - it makes perfect sense.. CLR must be different for all implementations within .Net family. and the "standard" is something every implementation agreed on having in common. – Alex Jul 07 '20 at 10:35