These 9.0.4 versions were incorrect. The .NET Standard 2.0 target shares the .NET 8.0 package versions.

Not used directly, likely an old transient vulnerability fix.

It was added with PR: https://github.com/dotnet/SqlClient/pull/2967/files#diff-d6cdac7c9f92790e995dce24e966c09119385fdc076757b8f70b08bd14dde23fR47 since in .NET Framework v4.6.2 the type referenced by us from this namespace (IDbColumnSchemaGenerator) is not available directly in BCL and downloading this package with NuGet is required for applications to work. I would not recommend removing this dependency due to that reason.

Is this a case where testing using .NET Framework Runtime 4.6.2 would have produced an error? But testing with .NET Framework Runtime 4.8.1 (which is what we do) doesn't?

This package is referenced in

We only use the SignedCms class from this namespace, and Malcolm had pointed out that it is included with all of the .NET Framework runtimes that we target:

https://learn.microsoft.com/en-us/dotnet/api/system.security.cryptography.pkcs.signedcms?view=netframework-4.8.1

I'm not sure why we would need to explicitly depend on it for .NET Framework.

1. Whether we use only 1 type or more shouldn't discount the importance of package reference IMO.
2. The documentation for 'SingleCms' says the library and type is 'Package-provided' so isn't it available with the package only for those runtimes?

We need to consider runtimes that our customers would target, and not those that we target to build the driver. Otherwise our DLLs will reference type from runtime (expecting them to be available in client env), whereas in future .NET Framework runtimes if its not available and is package provided, it would throw exception failing to resolve the type.

System.Data.Common, e.g. is a MUST have reference, cannot be skipped.

I've added the System.Security.Cryptography.Pkcs package back for all MDS targets. System.Data.Common has been added for .NET Framework 4.6.2.

I don't think I fully understand this argument. Couldn't any type be moved out to a standalone package at any time? Why would we treat this type differently from any other that can be referenced via package?

The SignedCms type is available via runtime or package for .NET Framework. It's only package exclusive for .NET Standard and .NET. Presumably they added package support for .NET Framework to help people who were multitargeting. But in general, doesn't it complicate our dependency graph to include packages we don't need? Especially if we're not pruning any dependencies. I'd have less of an issue if we did enable pruning.

After some investigation, I've learned that the .NET Framework DLLs for Pkcs are metadata only and type-forward to the GAC. We take a negligible package size hit to get the metadata. With that in mind, it does feel simpler to unconditionally include the package reference.

For this reason and the reasons you mentioned above, @cheenamalhotra, I think our standard should be to always unconditionally include package references for namespaces that are available via package for .NET Framework.

Removing System.Text.Encodings.Web seems fine, however we should be including "System.IdentityModel.Tokens.Jwt" NuGet package as we have a direct usage of it here:

I have added System.IdentityModel.Tokens.Jwt for all MDS targets.

Inconsistent System.Diagnostics.DiagnosticSource version for netstandard2.0. In src/Directory.Packages.props line 40, this package is specified as version 8.0.1 for netstandard2.0, but here in the nuspec it's specified as 6.0.1. These versions should match to ensure the published package uses the same dependencies as the build.

@paulmedynski - The bot is correct.

$(TF) is the correct way to specify the target framework for add-ons and tests when using build.proj.

I moved all of the test-only dependencies here from the main Directory.Packages.props file.

I opted for clarity rather than efficiency here. The combinations of target framework conditions were too hard to reason over, so I made sections for each target framework. We now have some duplicate entries rather than an N-dimensional matrix of conditions.

Same changes here as the test Directory.Packages.props file above. We now have some duplicate entries, but each target framework has a clear section of dependencies that closely matches the .nuspec files and our release notes.

Interestingly, we were advertising dependence on System.Data.Common, but we weren't referencing it in the .NET Framework project. Now that we are referencing it, I had to add an explicit dependency on System.Text.RegularExpressions to avoid a transitive vulnerability (that downstream apps would likely have had to do previously).

@paulmedynski - The bot is correct.

We previously weren't explicitly depending on System.Diagnostics.DiagnosticSource even though we use it directly. .NET Framework and .NET Standard 2.0 were pulling in v8.0.1, and .NET 8 and 9 were pulling v6.0.1. Hence the explicit difference here.

However This is now breaking dotnet CLI project-based restores for the add-on and test projects, since they employ a bunch of properties to choose target frameworks:

C:\Users\paulmedynski\dev\SqlClient\dev\paul\release\6.1\dependencies\src\Microsoft.Data.SqlClient\tests\ManualTests\Microsoft.Data.SqlClient.ManualTesting.Tests.csproj : error NU1109:
      Detected package downgrade: System.Diagnostics.DiagnosticSource from 8.0.1 to centrally defined 6.0.1. Update the centrally managed packag
      e version to a higher version.
       ManualTests -> Microsoft.Data.SqlClient -> System.Diagnostics.DiagnosticSource (>= 8.0.1)
       ManualTests -> System.Diagnostics.DiagnosticSource (>= 6.0.1)

The above shows the failure. The restore of the MDS project is incorrectly choosing v8.0.1 when it tries to restore the ManualTests project for .NET 8 or 9. It should be choosing v6.0.1, but the <ProjectReference> gets confused and is assuming a different target framework for MDS.

Builds via build.proj are fine since we always set a bunch of properties that force either .NET Framework or .NET - never both.

I'm not sure what we want to do about this. If I upgrade to v8.0.1 for all targets, the problem goes away. I tried to modify the add-ons and test projects to fix things, but nothing was working for me.

Fixes (here and build.proj) to make dotnet CLI builds work.