I'm trying to create a simple Blazor client server app using EF, similar to this article.
So I've got a client, server, and common libraries, and this worked fine. But then I added the EF component to the common library, so that I could use real data from my database, instead of toy data from the demo.
I tried making them all Core 3.0, but this doesn't work because Blazor seems to require .NET Standard 2.0. Without that, I get all kinds of errors.
But then the common library can't use EF, because (if I'm reading this right) EF6 isn't supported on Standard 2.0. If I try, I again get tons of errors.
So I'm not sure, but I can't find any scenario that would allow me to share EF objects between client and server--which is a major rationale for Blazor.
Is there some other way to accomplish this?
The shared library should not use or reference EF.
Add EF to the Server project only and make the data available through an API controller.
You should make the common project netstandard and use EF core (not EF 6)
Related
I have created a new application, using the SPA templare of .netcore, to this solution i want to add another project to handle the database connection(DAL).
When i am adding ASP.net core Web Application to this solution, i then want to add to id an ADO.net entityframework template, but in the data section, it dont appear:
So I end-up adding a class Library(.net framework)
and to it i can add an ADO.net Entity Data Model
So now in the solution, i have 2 projects, 1 is .net core 2.1 for the API's, models and views(by angular).
The second project is a .net framework 4.6.1, class library project.
My question is, is it suppose to be like that?
is it a good thing to mix different frameworks
Please see this article regarding what each framework is, and what each is specifically designed for.
https://learn.microsoft.com/en-us/dotnet/standard/frameworks
In a nutshell, your requirements drive which framework you choose.
I would recommend sticking with EF Core (just my personal opinion, take it or leave it) The EF Core method of database first is only recommended if you require a 1 time migration from a source database. Microsoft Doc
If you need to CONTINUE working with an entity model past the first migration, it would be in your best interest to use Entity Framework 6, on a .NET Framework library like you have. But that doesn't stop you from using EF Core as your OR/M, because you can indeed have .NET Core reference .NET Framework.
I have a database that I created using EF6. I have a VS project (library) that includes only my models and DbContext. Whenever I need to use my database I just reference that library DLL.
I have a few questions about that:
What happens if I lose this DLL somehow, but still have my models? Am I able to recreate my library?
What if I want to start using .NET Core? As far as I understand, I would have to use EF Core, right?. How can I get the same experience as I had with my DLL (same models).
When you still have the Code of your Models you can simply recreate the DLL. It gets recreated as you rebuild anyway.
You can also use the full entity framework together with .Net Core but that would make your application depending on classic .Net again.
The entity framework core works similar in many ways and also a lot of the old annotations work. You should be able to port you Model easily from EF6 to EF Core if it is not to complicated. Just be aware of some limitations regarding group by that will be resolved in 2.1
Because .Net Core is independent of the OS you won't be shuffeling around DLL's for you dependencys. One way is to use independet projects and release them as packages. So you can consume them in other projects with the package manager.
Is it possible to deploy / install Entity Framework Core 2.0 alongside traditional Entity Framework 6? Is it fully possible, or possible but with some hang-ups, or not possible? Is this documented somewhere? I think I've seen they said they designed it to be side-by-side, but I'm having a hard time fully confirming this. Thanks.
The official documentation says the following:
It is possible to use EF Core and EF6 in the same application. EF
Core and EF6 have the same type names that differ only by namespace,
so this may complicate code that attempts to use both EF Core and EF6
in the same code file.
If you are porting an existing application that has multiple EF
models, then you can selectively port some of them to EF Core, and
continue using EF6 for the others.
This means of course that you can install both EF6 and EF Core in the same project. I have done this in a few simple cases myself and it was working ok.
I have a Asp.Net webapi 2 system that works with sql server. I developed it using entity fraework 6.1.3 code first data models and fluent mappings with the typical workflow of add-migration/update-database. I love it.
I have a need to create the exact same software with a lighter weight db to run on a raspberry pi device. It's the disconnected version of the software that will replay/resync all of its data to the cloud version (sql server).
I realize I may need to relax some of my constraints, but starting at the extreme, I would like to target the exact same code base with something like sqlite and xcopy deploy it to my raspberry pi and run in on mono under kestrel web server.
Ideally, I'd just like to change my connection string to point to an empty sqlite db, do a update-database and have the exact same software initially run on my windows development box (and then xcopy it over).
I have read a lot about sqlite entity framework support but a) it doesn't seem to support migrations b) it doesn't seem to support fluent mapping
I could get by using a tool to convert my sql server db to sqlite (every time I change schema) and thus avoid the need to update-database. But the lack of fluent mappings would still prevent the data model to be properly mapped to the existing sqlite schema.
Does anybody have some thoughts/recommendation for sqlite that my help me accomplish my goals?
Do you have any other database recommendations that would help me accomplish my goals - for instance I looked at vistadb, but I don't think they support fluent either.
The devart sqlite driver seems to support everything I need but their examples are all old school and AFAIK they don't have one single example that is a modern code first model with fluent mappings. And even if they did fully support code first wth fluent I am concerned there would be some syntax differences and I am not sure my existing sql server targeting code would be compatible with it. I asked the question on their forums and sent an email but haven't received a response yet.
Thanks
You could consider using EF7, which is a API compatible new version of Entity Framework, that fully supports migrations and fluent mappings with SQLite. EF7 runs on .NET 4.6 and .NET Core. Depending on what features in EF6 you use, it could be an easy upgrade, in particular since you already use Code First.
http://ef.readthedocs.org/en/latest/getting-started/linux.html
I am developing a (free, open-source) Entity Framework tool, it is basicaly an ADO.NET provider, but it uses some higher abstractions too (e.g. ObjectContext, EntityConnection). I want it to support almost all the legacy version of EF (EF4=<). Until EF5 came out it was quite easy, because I had been able to develop it by targeting only .NET40.
EF5 made the things more complicated, because some of the new features requires the .NET45 framework. On the other hand, EF5 supports .NET40 too. An on the top of that, EF is now developed independently from the .NET framework.
For now, It is obvious that targeting both .NET40 and .NET45 is inevitable. But currently I have no idea what is the best way to setup a multi-target environment that can comply with the independently developed EF. I also haven't found any good document about this problem.
Should I use multiple solution files? Multiple project files? Multiple solution configurations? Reference all version of EF somehow? Create an universal build script? If yes, how? How to run my unit test against different configurations? How to indicate that a test can/should fail in a specific configuration? What about the changed namespaces (e.g. ObjectContext)? Should I use #if directive to solve this conflict? What if a new EF release requires to implement a feature that will break the compatibilty with previous versions? I am really uncertain at this point.
Take a look at the EF6 code base at http://entityframework.codeplex.com/. We build EF6 for .NET 4 and .NET 4.5 in essentially the way you are suggesting--using multiple build configurations.
Some other points to consider:
If you don't make use of any .NET 4.5 APIs or behaviors, then you may be able to just target the .NET 4 version. If you are using anything from EntityFramework.dll, then this may require a binding redirect to use the 5.0 version, but in a lot of cases if you ship as a NuGet package then NuGet will handle this for you.
If you plan to support EF6, then keep in mind that the core types have been moved out of the .NET Framework. This means, for example, that the EF5 ObjectContext is a different type from the EF6 ObjectContext. You will likely have to compile your provider code twice to create EF6 and EF5 versions in order to handle this. More information can be found here: http://entityframework.codeplex.com/wikipage?title=Rebuilding%20EF%20providers%20for%20EF6