You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Adopt Microsoft.Data.SqlClient instead of System.Data.SqlClient #16156
We can not remove System.Data.SqlClient, it will be a huge breaking change. Nevertheless we could add Microsoft.Data.SqlClient.
System.Data.SqlClient.dll is ~1Mb. I guess Microsoft.Data.SqlClient too. We need to see important scenarios to add so large dll in distribution.
I believe we now have a compelling reason. Bugs are no longer being fixed in System.Data.SqlClient, only in Microsoft.Data.SqlClient.
Case in point: #16567 was fixed (dotnet/SqlClient#1411) in Microsoft.Data.SqlClient, but this doesn't help PowerShell 7.2 users since it contains System.Data.SqlClient which will not be fixed.
Adding Microsoft.Data.SqlClient and its dependencies to PowerShell will still require people to update their affected scripts, but that is much easier than trying to use it as a standalone package (because #6724).
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.
We would absolutely love to have Microsoft.Data.SqlClient available in Powershell - I'm part of a platform team and want to get rid of SQL Auth. completely in our infrastructure. Not having Microsoft.Data.SqlClient available to us in Powershell is currently blocking us from doing that as we need to authenticate a Powershell process using IAM in our CD pipelines and execute SQL scripts prior to doing database migrations.
Right now, we're forced to stick with SQL Auth which is less than satisfying for us for various reasons - i.e. company compliance policies, just to name one of them
I would love to have Microsoft.Data.SqlClient in Powershell but I don't think that adding this .dll to code is the way to go. It would not fit with the open-source philosophy since this addition would only bring benefit to SQL Server, a Microsoft product. Since PowerShell was open sourced, we can see a lot of effort to make it more compatible with other non-Microsoft platforms. Like Python, or any other open-source programming language, we have to use libraries for this job and PowerShell has the modules. The preview v22 version of SqlServer module switches from System.Data.SqlClient to Microsoft.Data.SqlClient and we should use this module for new script developments for SQL Server.
I would love to have Microsoft.Data.SqlClient in PowerShell but I don't think that adding this .dll to code is the way to go. It would not fit with the open-source philosophy since this addition would only bring benefit to SQL Server, a Microsoft product. Since PowerShell was open sourced, we can see a lot of effort to make it more compatible with other non-Microsoft platforms. Like Python, or any other open-source programming language, we have to use libraries for this job and PowerShell has the modules. The preview v22 version of SqlServer module switches from System.Data.SqlClient to Microsoft.Data.SqlClient and we should use this module for new script developments for SQL Server.
I agree with this sentiment. The new Assembly is about 1.5MiB on Windows. These were included to not break existing scenarios. If the the scenario is new, we should move to a module based solution, and it looks like one already exists.
From a security point of view, eventually, I believe we will eventually have to drop System.Data.SqlClient because of certain issues which cannot be fixe (I'm not predicting what they will be.)
Can you clarify this comment about how it is a huge breaking change? Other than maybe modules relying on the assembly in-built? I didn't see any direct references to the library in PowerShell itself. #16156 (comment)
Such problems should be easier to deal with if C# / .NET NuGet packages were natively supported in PowerShell - #6724
Perhaps it's an opportunity to reopen both issues?
marcinsmialek in this case it wouldn't, because it is natively bundled in PS you'd still have the assembly conflict until it is removed from being bundled in PS.
I have done some investigation packaging the new Microsoft.Data.SqlClient in its own AssemblyLoadContext. It appears to work well as it's own PSGallery module.
elthombre even though it is a "Microsoft" assembly, it is still considered a third party assembly, so it won't even be supported by the team in terms of directly fixing issues with it.
In terms of "working" however, it should be loadable in PowerShell7 as per #16156 (comment), as he is doing the proper work of isolating common dependencies in an Assembly Load Context.
So you can try his gallery module, but again, this would be community supported, not PowerShell team supported.
It is my understanding that in order to support MFA, Azure-based SQL databases, etc., that this assembly is recommended/required.
So, if it's not actually supported by Microsoft, what is? And what is recommended best practice/choice by Microsoft?
It would be supported by the Microsoft team that provides the assembly, you would have to ask them, in the same way the Azure PowerShell module is owned by that Azure team and not the Powershell team itself.
It is my understanding that in order to support MFA, Azure-based SQL databases, etc., that this assembly is recommended/required.
Hi, my PSGallery module is using the true Microsoft assembly. Does this not work? As mentioned it loads the assembly in its own ALC, this is the recommended approach in PowerShell to avoid conflicts.
Activity
iSazonov commentedon Sep 26, 2021
We can not remove System.Data.SqlClient, it will be a huge breaking change. Nevertheless we could add Microsoft.Data.SqlClient.
System.Data.SqlClient.dll is ~1Mb. I guess Microsoft.Data.SqlClient too. We need to see important scenarios to add so large dll in distribution.
ajansveld commentedon Feb 10, 2022
I believe we now have a compelling reason. Bugs are no longer being fixed in System.Data.SqlClient, only in Microsoft.Data.SqlClient.
Case in point: #16567 was fixed (dotnet/SqlClient#1411) in Microsoft.Data.SqlClient, but this doesn't help PowerShell 7.2 users since it contains System.Data.SqlClient which will not be fixed.
Adding Microsoft.Data.SqlClient and its dependencies to PowerShell will still require people to update their affected scripts, but that is much easier than trying to use it as a standalone package (because #6724).
daxian-dbw commentedon Feb 10, 2022
Quoted from Introducing the new Microsoft.Data.SqlClient
That means the
System.Data.SqlClientwill still be patched with security fixes, though not all bug fixes. So I guess it's fine to keep it in PowerShell, and add the newMicrosoft.Data.SqlClient. Thoughts? Travis Plunk (@TravisEz13) Aditya Patwardhan (@adityapatwardhan) Paul Higinbotham (@PaulHigin)iSazonov commentedon Feb 11, 2022
Maybe move System.Data.SqlClient to WinCompat and now start migration to Microsoft.Data.SqlClient since we are on new dev cycle (vNext is not LTS).
kerbou commentedon Nov 24, 2022
We would absolutely love to have Microsoft.Data.SqlClient available in Powershell - I'm part of a platform team and want to get rid of SQL Auth. completely in our infrastructure. Not having Microsoft.Data.SqlClient available to us in Powershell is currently blocking us from doing that as we need to authenticate a Powershell process using IAM in our CD pipelines and execute SQL scripts prior to doing database migrations.
Right now, we're forced to stick with SQL Auth which is less than satisfying for us for various reasons - i.e. company compliance policies, just to name one of them
ronascentes commentedon Dec 7, 2022
I would love to have Microsoft.Data.SqlClient in Powershell but I don't think that adding this
.dllto code is the way to go. It would not fit with the open-source philosophy since this addition would only bring benefit to SQL Server, a Microsoft product. Since PowerShell was open sourced, we can see a lot of effort to make it more compatible with other non-Microsoft platforms. Like Python, or any other open-source programming language, we have to use libraries for this job and PowerShell has the modules. The preview v22 version of SqlServer module switches from System.Data.SqlClient to Microsoft.Data.SqlClient and we should use this module for new script developments for SQL Server.TravisEz13 commentedon Feb 13, 2023
I agree with this sentiment. The new Assembly is about 1.5MiB on Windows. These were included to not break existing scenarios. If the the scenario is new, we should move to a module based solution, and it looks like one already exists.
From a security point of view, eventually, I believe we will eventually have to drop System.Data.SqlClient because of certain issues which cannot be fixe (I'm not predicting what they will be.)
iSazonov commentedon Mar 3, 2023
It is a time to consider the breaking change for 7.4. We have a time to get feedback before release.
/cc Steve Lee (@SteveL-MSFT) Dongbo Wang (@daxian-dbw)
JustinGrote commentedon Dec 7, 2023
Steve Lee (@SteveL-MSFT) Ilya (@iSazonov) this came up in the PS discord today and already has a 7.4/NET8 breaking issue if someone tries to load SqlGuidCaster
Can you clarify this comment about how it is a huge breaking change? Other than maybe modules relying on the assembly in-built? I didn't see any direct references to the library in PowerShell itself.
#16156 (comment)
EDIT: Also Please reopen as active.
marcinsmialek commentedon Jan 4, 2024
Such problems should be easier to deal with if C# / .NET NuGet packages were natively supported in PowerShell - #6724
Perhaps it's an opportunity to reopen both issues?
JustinGrote commentedon Jan 4, 2024
marcinsmialek in this case it wouldn't, because it is natively bundled in PS you'd still have the assembly conflict until it is removed from being bundled in PS.
rhubarb-geek-nz commentedon May 21, 2024
I have done some investigation packaging the new Microsoft.Data.SqlClient in its own AssemblyLoadContext. It appears to work well as it's own PSGallery module.
I have a proof of concept on github and PSGallery
elthombre commentedon Feb 25, 2025
I need Microsoft.Data.SqlClient for a current automation against an Azure SQL database. I am having issues getting the package installed.
What is the status of this? Is the Microsoft.Data.SqlClient fully supported in PowerShell and, if so, how to install it?
JustinGrote commentedon Feb 25, 2025
elthombre even though it is a "Microsoft" assembly, it is still considered a third party assembly, so it won't even be supported by the team in terms of directly fixing issues with it.
In terms of "working" however, it should be loadable in PowerShell7 as per #16156 (comment), as he is doing the proper work of isolating common dependencies in an Assembly Load Context.
So you can try his gallery module, but again, this would be community supported, not PowerShell team supported.
elthombre commentedon Feb 25, 2025
Justin Grote (@JustinGrote) , OK, interesting...
It is my understanding that in order to support MFA, Azure-based SQL databases, etc., that this assembly is recommended/required.
So, if it's not actually supported by Microsoft, what is? And what is recommended best practice/choice by Microsoft?
JustinGrote commentedon Feb 25, 2025
It would be supported by the Microsoft team that provides the assembly, you would have to ask them, in the same way the Azure PowerShell module is owned by that Azure team and not the Powershell team itself.
rhubarb-geek-nz commentedon Feb 25, 2025
Hi, my PSGallery module is using the true Microsoft assembly. Does this not work? As mentioned it loads the assembly in its own ALC, this is the recommended approach in PowerShell to avoid conflicts.
elthombre commentedon Feb 26, 2025
OK, thanks.