Can you remove the dependency on System.Threading.Tasks.Extensions?

[shueybubbles]

Is your feature request related to a problem? Please describe.

System.Threading.Tasks.Extensions package hasn't been updated since March 2020. It depends on version 4.5.3 of package System.Runtime.CompilerServices.Unsafe
Meanwhile M.D.S also has a dependency on System.Text.Encoding.CodePages version 5, who has a dependency on System.Runtime.CompilerServices.Unsafe version 5.

On Net462 these versions conflict, leading us to having to implement binding redirects and workarounds for unit tests to run.

AutoGenerateBindingRedirects is fine for EXEs but we run our unit tests at build time and the only binding redirect we can readily do there is in code with an AssemblyResolve implementation.

Describe the solution you'd like

Either: Get rid of the dependency on the old package. The rest of the .Net world seems to have upgraded to System.Runtime.CompilerServices.Unsafe version 5 and pulling in version 4 to get Microsoft.Data.SqlClient complicates builds.

Or:
Add an explicit dependency on version 5 of System.Runtime.CompilerServices.Unsafe to trump the indirect dependency

Describe alternatives you've considered

Force M.D.S consumers to implement binding redirects even for test DLLs.

Additional context

Add any other context about the feature request here.

[ErikEJ]

M.D.S. does not have a direct dependency on the on lib, but Azure.Identity does: https://www.nuget.org/packages/Azure.Identity

[shueybubbles]

A PackageReference to M.D.S pulls in System.Text.Encoding.CodePages via this dependency in its nuspec

packages\microsoft.data.sqlclient\5.0.0\microsoft.data.sqlclient.nuspec:        <dependency id="System.Text.Encoding.CodePages" version="5.0.0" exclude="Compile" />

Another source of the CompilerServices.Unsafe 5.0 dependency is this dependency on System.Diagnostics.DiagnosticSource. Azure.Core 1.24 only references 4.6 of S.D.D.

packages\microsoft.data.sqlclient\5.0.0\microsoft.data.sqlclient.nuspec:        <dependency id="System.Diagnostics.DiagnosticSource" version="5.0.0" exclude="Compile" />

i suppose a solution could be to remove those dependencies from the M.D.S nuspec or downgrade them to match the versions used by Azure.Core.

[shueybubbles]

Well I did a poor job of looking at the nuspec, some of these dependencies are not part of the netframework4.6.2 group.

The dependency on System.Threading.Tasks.Extensions.dll isn't even listed in the nuspec though the M.D.S.dll binary has a direct dependency on it.

I'm having a difficult time dealing with the nuget warnings with package version downgrades as I am trying to move github.com/microsoft/sqlmanagementobjects to M.D.S 5.0.

[JRahnama]

@shueybubbles sorry for the hard time. @David-Engel how should we proceed here?

[shueybubbles]

FWIW turning back on AutoGenerateBindingRedirects for our unit tests appears to fix the build, after upgrading other package references for dotnet system packages from 4.7 to 5.0

[David-Engel]

@shueybubbles So is there anything MDS needs to do here (or should do)? I'm new to AutoGenerateBindingRedirects but it sounds like it defaults to true and resolves these issues.

The only issue I see might be to add the missing direct dependency on System.Threading.Tasks.Extensions to the nuspec.

[shueybubbles]

Eventually I'd like to see #1108 implemented such that M.D.S core has as few dependencies as possible. Many SMO apps in particular never run in an Azure environment so dragging those components into a build just complicates their builds needlessly.
SMO itself has no Azure-related functionality so I'd prefer that the only parts of our source tree that pull in Azure dependencies would be our tests.

Old versions of dependencies tend to get caught in security scanners, so having as few dependencies as possible, and having the latest version of them as possible, is desirable.

This particular issue can be closed, but be mindful of dependency bloat going forward.
thx

[bytefish]

I am in the process of migrating an application from .NET Framework to .NET 6 and thought a first step is to move the Data Access into a netstandard2.0 project and use Microsoft.Data.SqlClient.

The .NET 6 project works without a problem, but the .NET Framework 4.8 project crashes, because it fails to load System.Runtime.CompilerServices.Unsafe. I think it’s the same issue @shueybubbles reported.

@shueybubbles It would be cool, if you could share some more details how you fixed it, because my Binding Redirects didn’t work and enabling AutoGenerateBindingRedirects in the project didn’t work either.

Just as a data point, I think it would be good to go ahead with #1108. I was quite surprised, that Microsoft.Data.SqlClient installs Azure dependencies (such as JsonWebToken) for the SqlClient.

[shueybubbles]

What version of visual studio/msbuild are you using? As part of my upgrade to sqlclient 5 I am moving to msbuild 17 and VS 2022 as well. I think they do a better job of generating binding redirects than older msbuild/vs targets did.

That said - @David-Engel be aware that many other folks who use SMO and Microsoft.Data.SqlClient don't have good dependency management tools available to them. Powershell users always struggle to find the right way to get dependencies going, and they rarely have the luxury of configuration-based solutions like binding redirects.

[bytefish]

@shueybubbles Thanks for your help.

I am on VS2022 and I guess it’s msbuild 17. I will give AutoGenerateBindingRedirects another try tomorrow. Maybe I did something wrong, I will update this comment if it works.

Is there anything that needs to be done besides activating AutoGenerateBindingRedirects in the project file and updating the system dependencies to 5.0?

Thanks again.