This post was written by Vicky Harp, Program Manager on SqlClient and SQL Server Tools. Those of you who have been following .NET development closely have very likely seen Scott Hunter’s latest blog post, .NET Core is the Future of .NET. The change in focus of .NET Framework towards stability and new feature development moving to .NET Core means SQL Server needs to change in order to continue to provide the latest SQL features to .NET developers in the same timely manner that we have done in the past.
System.Data.SqlClient is the ADO.NET provider you use to access SQL Server or Azure SQL Databases. Historically SQL has used System.Data.SqlClient in .NET Framework as the starting point for client-side development when proving our new SQL features, and then propagating those designs to other drivers. We would still like to do this going forward but at the same time those same new features should be available in .NET Core, too.
Right now, we have two code bases and two different ways SqlClient is delivered to an application. In .NET Framework, versions are installed globally in Windows. In .NET Core, an application can pick a specific SqlClient version and ship with that. Wouldn’t it be nice if the .NET Core model of SqlClient delivery worked for .NET Framework, too?
We couldn’t just ship a new package that replaces System.Data.SqlClient. That would conflict with what lives inside .NET Framework now. Which brings us to our chosen solution…
Microsoft.Data.SqlClient
The Microsoft.Data.SqlClient package, now available in preview on NuGet, will be the flagship data access driver for SQL Server going forward.
This new package supports both .NET Core and .NET Framework. Creating a new SqlClient in a new namespace allows both the old System.Data.SqlClient and new Microsoft.Data.SqlClient to live side-by-side. While not automatic, there is a pretty straightforward path for applications to move from the old to the new. Simply add a NuGet dependency on Microsoft.Data.SqlClient and update any using references or qualified references.
In keeping with our plans to accelerate feature delivery in this new model, we are happy to offer support for two new SQL Server features on both .NET Framework and .NET Core, along with bug fixes and performance improvements:
- Data Classification – Available in Azure SQL Database and Microsoft SQL Server 2019 since CTP 2.0.
- UTF-8 support – Available in Microsoft SQL Server SQL Server 2019 since CTP 2.3.
Likewise, we have updated the .NET Core version of the provider with the long awaited support for Always Encrypted:
- Always Encrypted is available in Microsoft SQL Server 2016 and higher.
- Enclave support was introduced in Microsoft SQL Server 2019 CTP 2.0.
The binaries in the new package are based on the same code from System.Data.SqlClient in .NET Core and .NET Framework. This means there are multiple binaries in the package. In addition to the different binaries you would expect for supporting different operating systems, there are different binaries when you target .NET Framework versus when you target .NET Core. There was no magic code merge behind the scenes: we still have divergent code bases from .NET Framework and .NET Core (for now). This also means we still have divergent feature support between SqlClient targeting .NET Framework and SqlClient targeting .NET Core. If you want to migrate from .NET Framework to .NET Core but you are blocked because .NET Core does not yet support a feature (aside from Always Encrypted), the first preview release may not change that. But our top priority is bringing feature parity across those targets.
What is the roadmap for Microsoft.Data.SqlClient?
Our roadmap has more frequent releases lighting up features in Core as fast as we can implement them. The long-term goal is a single code base and it will come to that over time, but the immediate need is feature support in SqlClient on .NET Core, so that is what we are focusing on, while still being able to deliver new SQL features to .NET Framework applications, too.
| Feature Roadmap | Engineering Roadmap |
|---|---|
| – Azure Active Directory authentication providers (Core) | – Merge .NET Framework and .NET Core code bases |
| – Active Directory Password | – Open source assembly |
| – Managed Service Identity | – Move to GitHub |
| – Active Directory Integrated |
While we do not have dates for the above features, our goal is to have multiple releases throughout 2019. We anticipate Microsoft.Data.SqlClient moving from Preview to general availability sometime prior to the RTM releases of both SQL Server 2019 and .NET Core 3.0.
What does this mean for System.Data.SqlClient?
It means the development focus has changed. We have no intention of dropping support for System.Data.SqlClient any time soon. It will remain as-is and we will fix important bugs and security issues as they arise. If you have a typical application that doesn’t use any of the newest SQL features, then you will still be well served by a stable and reliable System.Data.SqlClient for many years.
However, Microsoft.Data.SqlClient will be the only place we will be implementing new features going forward. We would encourage you to evaluate your needs and options and choose the right time for you to migrate your application or library from System.Data.SqlClient to Microsoft.Data.SqlClient.
Closing
Please, try the preview bits by installing the Microsoft.Data.SqlClient package. We want to hear from you! Although we haven’t finished preparing the source code for publishing, you can already use the issue tracker at https://github.com/dotnet/SqlClient to report any issues.
Keep in mind that object-relational mappers such as EF Core, EF 6, or Dapper, and other non-Microsoft libraries, haven’t yet made the transition to the new provider, so you won’t be able to use the new features through any of these libraries. An updated versions of EF Core with support for Microsoft.Data.SqlClient are expected in an upcoming preview.
We also encourage you to visit our Frequently Asked Questions and Release Notes pages in our GitHub repository. They contain additional information about the features available, how to get started, and our plans for the release.
This post was written by Vicky Harp, Program Manager on SqlClient and SQL Server Tools.
Links in the article are already broken:
https://github.com/dotnet/SqlClient/blob/master/release-notes/1.0/1.0.0.md
Is Azure Active Directory multi-factor authentication in the feature roadmap as well?
I’m hitting Microsoft.Data.SqlClient is not supported on this platform.
Scope is : a simple project compiled for netstandard2.0 with the csproj option CopyLocalLockFileAssemblies = true.
This project is is called by an Azure worker role compiled for dotnetframework 4.7.2.
I have now idea how to tell the worker role to pickup to the correct dll for his OS.
I believe I need a kind of script that would copy the runtime to the output.
Hi,
using “Encrypt=True” I’m getting error:
“Microsoft.Data.SqlClient.SqlAuthenticationProviderManager threw an exception.”
What do I do?
Best,
Jefferson2019
It is support sqlserver 2008?
If I have a SqlConnection/SqlTransaction instance from one nuget package client, will i be able to use that instance in the new nuget package client. So i can share the current Connection/Transaction when i consume 3rd party nugets that make use of both nuget packages
You won’t be able to use connection or transaction instances from Microsoft.Data.SqlClient with libraries that bind directly to the corresponding types defined in System.Data.SqlClient. Such libraries will first have to be updated to work with Microsoft.Data.SqlClient. However, both versions of the provider implement the same base classes and common interfaces from ADO.NET, so any code that binds to those types should still be functional.
any indication whether SqlBulkCopy or SqlDbType will get support for the geo data types?… only been around for a decade now.
Sadly, this is important for our application as well and will make migration difficult.
Sadly geo data types are redheaded step childs of sql. You’re current best bet is to convert the data to binary and then send it as bulk copy.
Will anything change for the EF Core usage “Microsoft.EntityFrameworkCore.SqlServer”, or will that NUGET just get updated and we continue to package reference the same name?
Our thinking is that Microsoft.EntityFrameworkCore.SqlServer will switch to Microsoft.Data.SqlClient in an upcoming 3.0 Preview. Do you have any concerns with this plan?
No, we can easily update our Core ClassLib Data csproj/nuget references as needed. Just sounds like a possible breaking change that most people won’t know about unless they read this. As long as EF and scafolding/migrations/data access still works, we should be set. Just making sure I have a plan when this happens. Our IT people are excited about the AlwaysEncrypted options. Am I on the same page, or missing anything here?
Yes, this is consistent with our thinking. We will document this as a breaking change, but unless you are getting the DbConnection object from the DbContext and assigning it or casting to the old SqlConnection type, everything should just work.
Thanks for the prompt information!