I'm trying to rewrite old library to use EntityFramework Core and I can't figure out how to begin transaction with specific isolation level.
Previously I was able to do something like this:
DbContext.Database.BeginTransaction(IsolationLevel.Snapshot);
What is alternative implementation in the EntityFramework Core?
The EF Core code is exactly the same.
DbContext.Database.BeginTransaction(IsolationLevel.Snapshot);
The only difference is that in EF Core the method with isolation level (as many others) is an extension method, defined in RelationalDatabaseFacadeExtensions class, and importantly, located in Microsoft.EntityFrameworkCore.Relational assembly.
So if you have using Microsoft.EntityFrameworkCore; and don't see it, add reference to the Microsoft.EntityFrameworkCore.Relational.dll assembly / package.
In addition to Ivan Stoev's answer, it is also important to use System.Data.IsolationLevel and not System.Transactions.IsolationLevel when calling BeginTransaction method.
Related
"The ambiguity, is in the box" - Monty Python.
Autofac is having a problem resolving an interface. See attached solution.
The Interface, IAmbiguous, is defined in project ACommon. It is implemented in project AInjectable. The AInjectable project does not / cannot reference ACommon. The AInjectable project defines IAmbiguous as an existing item brought in with a file link.
The UI project calls ACommon Inject and attempts to register the AInjectable assembly. IAmbiguous is not ambiguous initially but after a builder.RegisterAssemblyTypes command it becomes "ambiguous in the namespace." There is no error thrown when the container is built but the registration is not there.
Registration can be done "AsImplementedInterfaces" if Named and Keyed is not used. But then there is no way to Resolve the registration because the service IAmbiguous is "ambiguous in the namespace."
This question was double-posted as an issue on Autofac. It is not an Autofac problem. I will copy/paste the answer from the issue in here; for future readers, if you want to see the repro solution, go check out the full issue
What you're doing by including the same interface in two different assemblies isn't something you should be doing. Note that by doing that, your AInjectable class is not implementing the interface from the ACommon project. It's implementing a different but identically named interface.
This sort of thing is a problem - having the same type (interface, class, whatever) name in two different assemblies. We even had a problem (#782) where we had a System.SerializableAttribute in Autofac as a shim for .NET Core. You really just can't do that.
You'll also see the same thing if you try to make a static extension method class that has the same namespace and name as some other static extension method class. Ambiguous references.
Without doing Reflection.Emit style code generation, you won't be able to declare an interface in one assembly ("Assembly A") and implement that interface in a different assembly ("Assembly B") without having Assembly B reference Assembly A. That's just how .NET works. What you're seeing is a manifestation of that when you use Autofac, but it's not caused by Autofac. It's caused by you doing something you shouldn't be doing in .NET.
The fix is to define your interfaces in a separate assembly that everyone implementing the interfaces can reference. (Or you can try to dynamically generate code using Reflection.Emit or Roslyn or something, but that's waaaay harder.)
I just upgraded to EF6 from EF5 and I encounter this error in a custom T4 that connects to the DB using a DbContext from a different assembly.
File: EF6.Utility.CS.ttinclude
Compiling transformation: The name 'ArgumentNotNull' does not exist in the current context
What I've done is replacing EF.Utility.CS.ttinclude with EF6.Utility.CS.ttinclude, which solved another error about DbSet and DbContext not being found.
The T4 is very simple, like this one:
using(var context = new EntityContext)
return context.Entities.Where(x => 1==1);
Except for the EF include I only reference my own assemblies. The freshly-added Context is generating just fine (in another project).
What on earth could be wrong?
EF6.Utility.CS.ttinclude reference some static functions that are defined in the main template.tt so you need to have them in your template too.
Example:
Entity.tt defines ArgumentNotNull(T arg, string name) which is used in the EF6.Utility.CS.ttinclude (it's not the way we are used to have)
See the bottom of generated template from EF6 designer to see this missing functions
One way to solve this is moving almost all the code to a .cs file and then use that file in the T4 template. Then remove the EF ttinclude from the T4 template.
Works and is easy better praxis to follow.
I have using entity framework 6 in a project that is net 4.0, and when I instaled the nuget package, the project adds the reference to EntityFramework.dll and EntityFrameWork.SqlServer.dll.
However, I want to capture the exception EntityCommandExecutionException, but there is not avaliable in neither of the both dlls.
I know that I can add a reference to System.Data.Entity, but I don't konw if this a good solution, because when I try to use the enum EntityState there are a conflict because the are one in the System.Data.Entity and other in EntityFramework.dll.
So the quiestion is if it is a good idea to use the System.Data.Entity library with EF 6. And if it is a bad idea, which is the equivalent exception of EntityCommandExecutionException in EF 6?
Thanks.
EF6 does not use System.Data.Entity.dll so adding a reference to this assembly won't help since EF6 will throw its own EntityCommandExecutionException. Actually adding a reference to an EF6 project will create even more confusion since the two are not designed to work together even though the type names tend to be called the same (EF6 was build by merging System.Data.Entity.dll and EntityFramework.dll code bases but is not binary compatible with EF5). In your app you need add
using System.Data.Entity.Core;
since this is where the EntityCommandExecutionException type lives in EF6.
i have big Trouble using the EntityFramework 5.0. After updating EF in our Project from EF4.2 to EF5.0. The Framework throws InvalidOperationExceptions in the TypeInitializer of InsertHistoryOperation during initializing of the database. (In the InnerException it says: "The List does not contain any element").
I tried using DropCreateAlwaysInitializer as well as DropWhenModelChanges. We don't need the Migration Feature (Sure, would be nice to have, but not recommend). Is there a way to disable the Migration Feature so the exception is not thrown. Or can somebody give me a hint what i did wrong?
The Model is very complex, so i think its not very useful to post it here.
best regards,
Chris
I tried with .Net4.0 and .Net4.5
Ok, i got it.
The Problem is that the EntityFramework since V5.0 is not able to work correctly if you merge it into (e.g. a Datalayer Assembly) or use it from a merged assembly. (ILMerge).
I have a Prism project with several modules. Using EF code first for generating the database.
I am trying to build the context using partial class. For each module will have its partial class context (one context whole solution).
I am using the same namespace for each module to create the context. However, when initializing the database, only the tables defined in the main module is created, but not the others.
Is there anything I could look for or is there a better way? Tks.
All parts of partial class must be in the same assembly (in your case probably in the same module) because it is just syntactic sugar to divide single file (class) into multiple parts but these parts are concatenated during build. Partial classes will not help you to achieve modularity (if you expect to add or remove modules to deployed application).