12

In a Visual Studio solution, I need to have a desktop winforms application project (.Net framework 4.0) depending on a .Net Core library project. I can't migrate the application to .Net core yet, but I need functionalities from .Net core (ie Microsoft.EntityFrameworkCore). That's why I created a new project as a dependency.

It seems to cause a problem at build time:

Reference to type 'Object' claims it is defined in 'System.Runtime', but it could not be found

Idem with DateTime, Enum, Decimal, ...

As if object wasn't the same in both project. I tried to use Microsoft.Windows.Compatibility but it doesn't seem to be a solution.

Is there a way to have both projects build and run together?

EDIT 1

I tried with a .Net standard project instead of .Net core, but in this case I can't even add a reference from .Net framework app to .Net standard library.

Project "Std.csproj" targets "netstandard2.0", it can't be referenced by a project that targets ".NetFramework,Version=v4.0"

EDIT 2

I still get the same error with my dependency in .Net core 2.0 and my app in .Net Framework 4.6:

Project "Std.csproj" targets "netstandard2.0", it can't be referenced by a project that targets ".NetFramework,Version=v4.6"

EDIT 3

I finally got rid of the error with .Net Framework 4.6.1. But, according to required configuration for this framework, it means I can't deploy to Windows XP anymore. To study...

As my goal is to migrate gradually to .Net Core, any advice is welcome.

Improve this question
8
  • 2
    No. If you want to share code, create a .NET Standard library. EF Core 3.1 works with .NET Old though - it's a .NET Standard 2.0 package. You probably need to upgrade your EF Core version. Commented Feb 25, 2020 at 8:59
  • Yeah. EfCore 3.1 is supposedly (never tested it) compatible with NetStandard 2.0 Commented Feb 25, 2020 at 9:05
  • @TomTom it's the package's target. It couldn't use higher-version classes even if someone tried Commented Feb 25, 2020 at 9:09
  • 1
    Wait - .NET 4.0 is unsupported for many years now. It never got any kind of .NET Standard support - it can't, as it doesn't even support async/await. You need to upgrade to .NET 4.6.1, preferably .NET 4.7.2 to avoid problems with compatibility libraries. Commented Feb 25, 2020 at 10:09
  • 1
    Preferably 4.7.2 or 4.8 if you don't like fun assembly binding exceptions. Commented Feb 25, 2020 at 10:12

3 Answers 3

Reset to default
5

I need to have a [...] .Net framework 4.0 depending on a .Net Core library project.

Is there a way to have both projects build and run together?

No

Sorry. That's not the way it works. You cannot directly reference a .NET Framework assembly from .NET Core or the other way round a .NET Core assembly from .NET Framework.

(I have a slight deja vu, I will try to find the duplicate on this).

What you can do is create a shared assembly in .NET Standard that both can reference, but in this case it would not actually help you, because you would need a higher .NET Framework version to be able to use .NET Standard 2.0.

What would work is creating a connection between your assemblies that is not a direct assembly binding via reference. One could call the other via REST over HTTP or via memory mapped files or in any other way that you would use to have two otherwise incompatible technologies communicate.

Improve this answer
Sign up to request clarification or add additional context in comments.

10 Comments

EF Core 3.1 is a .NET Standard 2.0 package, so it will work. The real problem is that the OP is targeting .NET 4.0
"... cannot directly reference a .NET Framework assembly from .NET Core" this is not entirely true, .NET Core does support running some Framework assemblies that target 4.6.1 or below.
.NET Core can use .NET Old assemblies on Windows. I'm using AlphaFS in my .NET Core apps simply because there's no other way to access advanced NTFS features. You get a warning on every build but the assembly works
The documented behaviour allows for some references from Core to Framework.
@nvoigt no, because the .NET/VS teams explicitly added that support in .NET 2.0. It's not ideal, but for many cases there's no alternative yet.
|
4

The .NET Framework version must be at least 4.6 in order to reference a .NET Standard project or nuget package.

Additionally, you will need Visual Studio 2017 or newer to be able to use the reference. Visual Studio 2015 will not work.

Improve this answer

5 Comments

The practical minimum is 4.7.2. From the docs : For .NET Framework projects that need to use such libraries, we recommend that you upgrade the project to target .NET Framework 4.7.2 or higher
Why the downvote? This is the only solution. .NET 4.0 is unsupported, it can't use any .NET Standard or Core feature. As for Visual Studio, all Community editions are free and offer the same features as Professional.
We have some legacy products using .net standard in a 4.6.2 that's why I answerd it as the minimum. But I agree 4.7 is the better choice.
Then you've seen what "fun" it is to fight all those compatibility libraries...
This answer as written is somewhat misleading. .NET 4.5 and above can use some level of .NET Standard, though you need 4.6.1 minimum (for a volatile app) or 4.7.2 (for a more stable one) to use a .NET Standard 2.0 assembly such as EFCore. There is also some level of tooling available for VS2015.
2

YES, it is possible to use both .net Core and .net Framework within the same process, provided you keep them as quite separate assemblies and you are willing to interact through COM.

An example of how to interact in this way is provided in https://github.com/dotnet/samples/tree/main/core/extensions/NetComSxS .

If you have DLLs that need to be included, it is best to incorporate them in the calling assembly so as to avoid .net Framework/core clashes.

Improve this answer

1 Comment

I checked this myself, its was very difficult to find this information but thanks for the info.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.