In the past It's been easy to set a connection in LinqPad to a custom assembly that had EF model. Linqpad looks for a that is based on System.Data.Objects.ObjectContext which doesn't exist
How (if at all) does one make their model assembly compatible with LinqPad.?
Right now, LINQPad does not support the EF CTP's code-first: there's a feature request here.
It's almost certain that support will be added in the future - if this EF feature makes it past CTP (and maybe sooner with sufficient demand).
Edit: LINQPad now supports code-first with EF 4.1.
Related
I am wondering about designing a EF core model of the SAP B1 database. I realize that this is a major undertaking, but I aim to start small.
This is mainly as an exercise, which may lead to something in the future.
My main issue right now, is to ensure that the DbContext is read-only.
I have found several suggestions, like this one:
How to make Entity Framework Data Context Readonly
However, that is for the Entity Framework "standard" not core, and the accepted solution does not seem to be possible with EF Core.
So, aside from using a login without write permissions, how would I go about making a read-only DbContext?
I am using EF Core 5.0.
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.
When I read posts about db-first vs. code first approaches, I get the impression that code-first is the rising star and superior to db-first so that db-fist is about to be deprecated in the future releases of Entity Framework.
I could not find an official statement from Microsoft but they seem to be endorsing code-first by things like Identity Framework etc. Would it be a mistake to start a new project using EF DB-first?
You have EF 6 for the more traditional EF and EF 7 which became EF Core.
In my opinion you are better off focusing your effort on using EF independent from either approach.
Here's a link to an article written by EF Expert Julie Lerman.
https://msdn.microsoft.com/en-us/magazine/dn890367.aspx
I'm trying to move an ASP.NET MVC 5 application to MVC 6 (ASP.NET vNext).
My existing application uses EF 6 and has some EF code first migrations. I want to port these migrations as well, because I want to be able to continue using the existing databases with the existing migrations already applied, without breaking the upgrade path.
It seems that the "new" EF Core migrations (k ef migration add ...) have quite the different format compared to the "old" EF 6 migrations:
No more Designer partial class
No more RESX file
Is there already an "official" way to upgrade these migrations? Is it supported at all? Will it be supported in the future?
There isn't really a way to do this yet. In general we strongly recommend against trying to upgrade an EF6 application to EF7 yet. EF7 is still very much pre-release.
We will have some guidance on how to do this when we get closer to RTM. We may provide some tools to help or just some guidance on how to do it.
Date: 13/April/2016
As of now it is not advisable to use EF7 in production because of following limitaions
"Because of the fundamental changes in EF7 we do not recommend attempting to move an EF6.x application to EF7 at this stage. If you want to move to EF7 to make use of new features, then make sure you are aware of the limitations of EF7 before you start. You should view the move from EF6.x to EF7 as a “port” rather than an “upgrade” ".
One area of RC1 that has a number of outstanding issues is our query pipeline. The majority of issues result in an exception when you attempt to execute a LINQ query that contains a particular pattern. There are often ways to workaround these issues by expressing the same query using different patterns, or evaluating parts of the query client-side. We try to include these workarounds in the issue, when they are available.
In RC1, there are a number of scenarios where EF7 performs slower than EF6
More Readings:https://blogs.msdn.microsoft.com/dotnet/2015/11/18/entity-framework-7-rc1-available/
I have a pretty large model built in EF version 1. The client wants to upgrade the model to take advantage of the foreign keys feature of version 4.
Is there any way/tool to easily convert a ef v1 model to ef v4?
You can just change the Target Framework from .NET 3.5 to .NET 4.0, and the model will be automatically converted.
However, if you need EF v4 features like Referential Constraints, you should recreate the model from database.
after converting the project to target .net 4, If your using the ef 4.1 code fist,
use this tool to recreate the entity classes.
http://blogs.msdn.com/b/adonet/archive/2011/05/18/ef-power-tools-ctp1-released.aspx
Im sure you are already aware that having an extremely large edmx model has its disadvantages.
If its not too late, use this chance to move to ef 4.1 code first and leverage the poco classes to give you more control over your entities..
My experiences have proven getting away from the edmx and moving to code first as early as possible pays off quickly.
You just have to ask your self the question, is the time required to retest all the Data Access Layer, worth the investment for your project.
Good luck