Adding Microsoft.Data.SqlClient Support

[bmasephol]

Added support for using the extension with the Microsoft.Data.SqlClient library. Did a little rework of the solution to separate the System support from the Microsoft support.

[birbilis]

This looks ok (not sure if it breaks anything at the "Rearranging source files" commit, probably not), but would need to split it and publish two separate NuGet packages I think since they kept support for both

That is since one wants to get rid of the now-DEPRECATED (see its description, it doesn't show yet a deprecation icon on NuGet) System.Data.SqlClient in favor of Microsoft.Data.SqlClient (which works for both .NET [the Core] and .NET Framework [the Classic])

[birbilis]

@jphellemons any plan on releasing an updated NuGet package or a separate one with Microsoft.Data.SqlClient dependency instead of System.Data.SqlClient?

[birbilis]

Btw, above pull request would need an extra step to update NuGet packages to latest versions.

As I say above, I'd split it into two separate projects (and respective NuGet packages), can't keep both System.Data.SqlClient and Microsoft.Data.SqlClient dependencies and carry them on to other projects that use the CommandAsSql package.

They still seem to release updates (probably security ones) for System.Data.SqlClient, though its description says DEPRECATED - Use Microsoft.Data.SqlClient

[jphellemons]

maybe just move away from the deprecated package to stay aligned with Microsoft. What are you people thinking about this?

[birbilis]

Main concern would be to check which .NET versions the Microsoft.Data.SqlClient supports (down to which one) and compare with System.Data.SqlClient. I'm on .NET Framework (Classic) 4.8 (final one) for the project I use it in. Not sure if other users use it with some very old .NET that Microsoft.Data.SqlClient might not support (haven't checked its decription on NuGet, supports both .NET [Core] and .NET Framework [Classic] from what I remember)

[birbilis]

...from what I understand this pull request isolates those dependencies into two different Expressions classes.

So could add a separate csProj for the older dependency for those using source code.

And then make the NuGet from the upgraded project that has the class with the new dependency and not remove the old nuget package version, just deprecate online.

Alternative is to keep the old source version in a branch and just upgrade at the main branch. Any future changes to main branch could selectively then be also applied to that branch if say they're security-related/imporant (or if you want to backport new features to that branch too). For those using the sourcecode version though, since the only way to have multiple releases for NuGet package I think is to use separate ones (so for security issue would need to remove the legacy version that had been deprecated)

[bmasephol]

Been a while since I looked at this. You guys probably know better than me what makes sense to do. I'd be happy to make some changes depending on the direction you think this should go.