This question already has answers here:
Entity Framework Core 2.0 on .NET 4.6.1
(4 answers)
Closed 4 years ago.
We are working on bringing an old web forms application into the MVC world. The old application was using an ORM called EntitySpaces, which we will now be switching to EntityFramework as well. Recently we ran into an issue because we are doing code first migrations in EF6 currently but it has no support to set default values via the fluent api, instead you must generate the migration and eidt it to have the default values. This feels dirty to us so we looked into EF core and found that it has a HasDefaultValue() method in the fluent API just like we want.
We are using .net 4.6 for this project because we still need webforms in the project until all the pages are migrated to razor views, then we can look at upgrading to .net Core. In the meantime can we use EF Core with .net 4.6 or does it require .net Core?
Yes, it is. The Microsoft.EntityFrameworkCore package (https://www.nuget.org/packages/microsoft.entityframeworkcore) targets .NET Standard 2.0, which means it can be used by any runtime that supports it, such as .NET 4.6.1. See also https://learn.microsoft.com/en-us/dotnet/standard/net-standard.
Related
We are currently migrating our ASP.NET MVC Web Application to ASP.NET Core Web Application. We have several base projects referred in our MVC Application. So in order to use the same MVC base projects in our new Core application, we planned to choose Core 2.0.
We can able to refer all the Base project built in entity framework in our Core application except our Database base project. Our database base project was built using Database first approach and contains the entity. So while referring that project, we are facing issues in using DB Context.
Is it possible to refer a Project which contains entity classes in .NET Core Web Application?
First don't use Core 2.1 as it reached EOL. Second check the EF Core compatibility table - you can use EF Core 3.1 with .Net Framework 4.7.2+. You can also use EF 6.3 with .Net Core 3.1.
I'd recommend you to start from migrating EF 6 to EF Core 3.1 and only after that migrate ASP.Net to ASP.Net Core 3.1 or 5.0 (probably 6.0 will arrive before you finish with EF Core, if so, take it because it's going to be LTS version).
You can use both EF 6 and EF Core in same ASP.Net service so migration can be done in small chunks rather than whole DAL at once. Refer to this answer.
This question already has an answer here:
Compatibility of dynamically loaded assemblies
(1 answer)
Closed 3 years ago.
So I have an existing .NET Framework 4 DLL that I would like to reference from a new .NET Core 2.2 application. Is this possible?
I have added the DLL as an assembly in the .NET Core project. It compiles fine, but when I run the project I'm getting this error:
"Could not load file or assembly 'System.Data.Linq, Version=4.0.0.0...".
Wondering if I need to try to convert the .NET Framework DLL to .NET Standard?
Wondering if I need to try to convert the .NET Framework DLL to .NET Standard?
That is exactly what you want to do. Since .Net proper and .Net core are "implementation" frameworks they cannot reference each other. However, .Net standard is more of an "interface" so it can be referenced from both .Net proper and .Net core.
The version of .Net standard is going to depend on which framework version you are targeting. The lowest common denominator should win.
Have a look at this documentation.
I had similar problem some time ago. I had to use .NET 4.0 because of compatibility with Windows XP.
.NET Core 2.2 requires at least .NET 4.5.
Solution is to upgrade to .NET 4.5 or above or to leave concept with .NET Core 2.2 inside .NET 4.0 project
I am new to .Net Core 2.X. I was writing some authentication related code in controller.And I wrote the business logic in .Net Framework 4.6 class library. When I tried referencing the .Net Framework library, my .Net Core 2.1 project started loosing all of the system, Linq references.
Then I created took a .Net Core 2.0 class library project. And when I reference it, the same happens. I could get more information or anything.
Below is the image when I referenced .Net Framework 4.6/.Net Core 2.1 proejcts.
Could anyone please tell me the reason and fix for this.
Thanks in advance
.Net Framework and .Net Core are fundamentally different enviroments, and while the for the programmer for the biggerst part everything looks the same under the hood it is not. While you can expect mose code to seamlessly be ported over to .Net Core, references and some NuGet packages wont work. Especially refering to .Net Framework specific assemblies which dont exist in .Net Core wont work.
I'm building an ASP.NET Core Web API project. I will be heavily using EF Core with the connection with SQL Server. I want to organize the project around 3 main tiers: Core/Logic/Domain, Data/Infrastructure and Web/API.
Web/API will be definitely a .NET Core project, but I'm struggling with the decision whether Core and Data projects should be .NET Core library or .NET Standard library.
My question is, will I lose any features or anything while building my data persistence in .NET Standard library?
For a class library, the target framework simply specifies a compatibility layer. The ultimate functionality comes from the target framework of the project that references the class library.
For example, let's say that you create a .NET Standard library, and then you include that in a .NET Framework project. Everything you do happens on .NET Framework, and for all intents and purposes you could've targeted .NET Framework from your class library as well. The choice of .NET Standard simply says that you're going to use APIs from some .NET Standard-compliant target. That's all. As a result, the functionality of something like EF Core, ultimately depends on what you drop the library into, not what framework your library targets.
As to whether to choose .NET Standard or .NET Core as the target framework for your library, simply: use .NET Standard unless you have a good reason not to. If you target .NET Standard, you can drop it into any project that targets any framework that is compatible with the version of .NET Standard your library targets. If you choose .NET Core, you can only use the library in .NET Core projects.
Things get a little murkier when you start looking at .NET Core 3.0, though. You can technically target .NET Standard 2.1 and get all the goodness of .NET Core 3.0, but nothing but .NET Core 3.0 actually supports .NET Standard 2.1. You can target .NET Standard 2.0, but then you're stuck with .NET Core 2.2. In other words, if you want to use .NET Core 3.0, right now, there's no functional different between choosing .NET Standard 2.1 or .NET Core 3.0 as the target framework of your library. In either case, it will only work in .NET Core 3.0 projects.
Adding even more confusion, Microsoft is moving the next version of everything under the .NET 5 umbrella. What becomes of .NET Standard at that point hasn't been discussed, by I'd imagine it largely goes away. Once there's a .NET 5, any project can target .NET 5 and be used by any other project that targets .NET 5. That's still a ways off, though. The reason I bring it up, is that if you want to use .NET Core 3.0 today, there's not much point in targeting anything but .NET Core 3.0. Most of the stuff in .NET Standard 2.1 is not back-portable to things like .NET Framework and Unity, so those will never be on .NET Standard 2.1. The path forward for those frameworks is making them .NET Core compatible, to eventually end up with .NET Core 4.0, which Microsoft will call .NET 5.
Long and short, the best performance and features are with .NET Core 3.0, as long as you can go 100% .NET Core 3.0, then that's what you should target. If you need to use your library in something like an Xamarin or .NET Framework app, then stick with .NET Standard 2.0.
From the .NET Standard Microsoft Docs
The .NET Standard is a formal specification of .NET APIs that are intended to be available on all .NET implementations.
From the .NET Core Microsoft Docs
.NET Core is an open-source, general-purpose development platform
What this means in relation to your question.
Creating a .NET Standard library, you would be able to pull that library into a .NET Core project or a .NET Framework project assuming that the .NET Core/Framework project would adhere to the same .NET Standard version of your library or greater. So, the .NET Standard library would give you more flexibility regarding the projects you would be able to pull that library into(good if this needs to be pulled into legacy applications running on .NET Framework >=4.6.1 as well as new applications that would be written in .NET Core).
The only hiccup I've encountered with this approach is regarding migrations. If you want to use EFCore Migrations through the dotnet ef commands, it expects you to target a project with a .NET Core version. So, if you create your DbContext in the .NET Standard library and want to create migrations from it, you will either have to give it a startup project that is a .NET Core project or implement a 'Design-time DbContext Creation'. As an aside, this last option does have a few limitations, one of which is documented in an issue on GitHub.
I have a ASP.NET MVC 5 / .NET 4.7 project that I want to upgrade to ASP.NET Core.
The MVC frontend references a service layer project (SL) which in its that uses a datalayer (DAL) project built using Entity Framework.
Our assessment is that Entity Framework Core is still missing features that we need and that we should not upgrade the DAL project to .NET Core.
What framework should my projects target to be able to work together? Can we upgrade just one project to .NET Core and keep the rest in .NET Framework?
If you want to switch to .NETCore and still be able to use older libraries you should tagret .NETFramework.
So when creating new project select:
ASP.NET Core Web Application (.NET Framework)
In addition this month(actually yesterday) .NETCore 2.0 along with EFCore 2.0 is released.
Both frameworks have much more features, so I suggest migrating to 2.0 project.
Also EFCore 2.0 should now have most features that were needed so I would go with that as well.
What framework should my projects target to be able to work together? Can we upgrade just one project to .NET Core and keep the rest in .NET Framework?
You don't need to make any of your projects target .NET Core in order to use ASP.NET Core. I'd recommend using the .NET Core SDK (and associated csproj file format) but you can set the target framework to a desktop framework version (e.g. net47) and then you should be fine.