Taking a look at Microsoft.Data.SqlClient in .NET Core

If you're a .NET developer then no doubt you are very well versed in using the  System.Data.SqlClient namespace. It is essentially at the heart of ADO.NET and what allows programmers access to SQL Server databases and Azure SQL Databases through C# code.

With Microsoft's push towards an entirely .NET Core ecosystem though, things are in need of a change.

Currently, development is split into two camps when it comes to building .NET applications. You have .NET Framework (Standard) on one side and .NET 5.0 (soon to be .NET 6) on the other. Which means that Microsoft has to maintain 2 separate codebases for SqlClient. The .NET Framework implementation is the more globally recognized version that comes preinstalled with Windows.

The .NET Core version is slightly different in that an application can select which specific version of SqlClient to use. Which means that by default these classes will not be included in your .NET Core projects.

As of right now, there are two different versions, both under their own unique namespaces and with different development cycles.

If you are working with a .NET Core application, and you want to work with the SqlClient libraries, you will manually need to install these libraries via Nuget.

The biggest benefit here is that you can work with both libraries concurrently within the same project, at least while Microsoft works towards finalizing the newest version. The downside is that you will have 2 libraries to keep track of and to maintain.

This new Nuget package for Microsoft.Data.SqlClient is going to be supported in both .NET Framework and in .Net Core moving forward.

What are the differences between each of the libraries you might be asking?

Well, one of the major improvements that the new library brings with it is support for Always Encrypted, which allows sensitive data, such as credit card information and user personal identification numbers to be secured in SQL Server databases. The process essentially involves encrypting data on the client application while storing encryption keys outside of the SQL environment. In this manner, only the application itself can actually read the sensitive information.

The simplest way to begin migrating over to the new binaries is to install Microsoft.Data.SqlClient from the Nuget manager and to begin to replace your old using directives to point to the new one. The new library still uses the same class names and methods as the original, so this should not under normal circumstances affect your functionality.

But as with any major library or framework update, it is best to transition slowly module by module to ensure that any errors are kept to a minimum.

Is this the end of System.Data.SqlClient?

Not quite. Microsoft has stated that it plans to continue support for System.Data.SqlClient in terms of bug fixes and security patches for years to come. So if your entire codebase relies on it and you are hesitant to make any big changes, you still have plenty of time to think about it. And if you don't make the change, odds are you will be just fine.

Any new development and new features however, will only be coming to Microsoft.Data.SqlClient moving forward.

I myself have made begun to make the transition on my primary class libraries. And so far, so good. The thousands of lines of code that I have written so far using SqlClient classes are running as they always have without a hitch.

Because it is an entirely different codebase however, differences in performance should be expected. .NET Core has been touted as being up to 30% faster than .NET Framework, so for that reason alone, it might be worth the extra effort to make the switch.