dotnet
Next Release for Microsoft.Data.SqlClient
Question
What are the plans for the next release of EF6? I wonder when https://github.com/dotnet/ef6/issues/823 is going to be available? I see documentation says:
In addition, we plan to make it clear on the legacy EF6 GitHub repo that we are not planning any future work on EF6. The exception to this is that we plan to add support for using EF6 with Microsoft.Data.SqlClient. This will be limited to runtime support. Use of the EF6 designer in Visual Studio will still require System.Data.SqlClient.
The reason I ask: migrating a large application with multiple EF context from EF6 to EF Core, is challenging in itself. One approach is to migrate DbContext by DbContext through multiple releases of a project. However, this approach is limited by SQL transactions, which would naturally span across EFCore and EF6 requests, using Microsoft.Data.SqlClient and System.Data.SqlClient respectively. I found 2 ways to 'mitigate' the problem:
- using Azure SQL which has elastic transactions, so things work seamlessly with EF6 and EFCore. But even when a team uses Azure SQL, it is not practical and available in all environments.
- using distributed transactions, which inherently gets complicated in cross-platform scenarios, ie. someone would run a DB using the Linux version of SqlServer on docker. Msdtc does not seem to support cross-platform cases well.
That leaves a question in the migration path of EF6 to EFCore: what is the best way to manage these transactions?
My understanding is that using Microsoft.Data.SqlClient for both frameworks would solve the challenge. I see the corresponding code is merged in this repo, and there is a willingness to release it.
When would you estimate this release becomes publicly available? What is the suggested approach in the meantime, should everyone build their own version of EF6?
(Please note, the described scenario would only require limited runtime support, no designer, no tooling, etc. would be really needed.)
@ladeak just use my well tested and supported runtime package, you could be in for a long wait. https://www.nuget.org/packages/ErikEJ.EntityFramework.SqlServer
I have tried both using https://www.nuget.org/packages/ErikEJ.EntityFramework.SqlServer from @ErikEJ and building this repository.
When I built the main branch of this repository, I noticed a few "breaking" changes that were captured by unit tests, but they were mostly on some arguments being validated against null values or some types now require Database.SetConfiguration(...) call. Nothing that could not be worked around.
DbFunctionCommandTreerequires a non-nullMetadataWorkspaceargumentDbContext.ChangeTracker.DetectChanges()requiresDatabase.SetConfiguration()to be invoked upfront.
Note, that the same changes are not required when using ErikEJ.EntityFramework.SqlServer package, but only when I try to build EF6 from the main branch.
DbFunctionCommandTree is straightforward, it throws in the base ctor (DbCommandTree).
ChangeTracker.DetectChanges() goes as
- InternalContext.DetectChanges
- LazyInternalContext.DetectChanges
- InternalContext.Initialize
- LazyInternalContext.InitializeContext
- RetryLazy...GetValue
- LazyInternalContext.CreateModel
- DbModelBuilder.Build
- Provider Connection.GetProviderInfo
@ladeak Sorry, I do not follow - is this when you build the Microsoft.EntityFramework.SqlServer project locally?
When I build the main branch of EF6 locally with Microsoft Entityframework.SqlClient enabled and use it as a package, then some of my unit tests are breaking at test execution time with exceptions that were previously not present. I had workaround for all of them in my tests, but I thought it might worth bringing this up.
@ladeak Are you abe to share the failing tests? Maybe it is something that need to be fixed in the new EF Provider?
@ladeak Indirectly? (Just a sample of an isolated test that now fails, and did not before)
The first case is relatively simple in a unit test:
new DbFunctionCommandTree(null, ... );
the second case is a bit trickier to describe: we create custom DbContext and invoke one of its methods which eventually calls ChangeTracker.DetectChanges() in the unit test.
@ladeak a 6.5 preview package is available now
@ajcvickers @SamMonoRT feel free to close this, no repro code provided and it relates to my project, not this
@ErikEJ
Just to follow up on this, I'm looking at the NuGet package for the preview version, and I see that the NetStandard code is still very much dependent on System.Data.SqlClient, not Microsoft.Data.SqlClient. Why is that?
Oh I see, upon further inspection, it seems that the Microsoft.EntityFramework.SqlServer is an inheriting build of EntityFramework that modifies the Pragma definitions to enable Microsoft.Data.SqlClient.
Leaving this comment here in case someone else has the same question.
Also, you have to make some changes. https://github.com/dotnet/ef6/issues/2250
@EdLichtman
Also, you have to make some changes.
Could you clarify what you mean by this? You are referring to a closed issue??
My mistake -- I was having trouble because it was still using System.Data.SqlClient, so I asked for help. I eventually realized that I need to download a different package, Microsoft.EntityFramework.SqlServer. I thought that solved the issue, but I searched through other issues because it didn't solve the issue, and I finally found a reference to realize that we have to add the DbConfigurationAttribute. So I was just remarking to anyone who comes here after and sees the very obvious "I want Microsoft.Data.SqlClient to be released for EntityFramework" issue, that "you have to use this other library, and also make some code changes, in accordance with the issue I referred to.
I was trying to be helpful by leaving my comment and my addition to it, but I suppose I wasn't specific enough in my language, and I apologize.
@EdLichtman no problem at all. Just wanted to make sure there was no outstanding or undocumented issues, as RTW release in coming very soon.