Target .NETFramework 4.7.2 in addition to the existing targets.

[JJoe2]

Given that:

• The Microsoft.Data.SqlClient package ... will be the flagship data access driver for SQL Server going forward.

• .NET Framework 4.6.1 will reach End of Support on April 26, 2022

• 4.6.1 through 4.7.1 are all partially compliant with the shipped Runtime, but work by adding additional dependencies to your project when a .NET Standard 2.0 component is added ... This is pretty messy and clutters up your output folder and app.config

Would it be possible to target .NETFramework 4.7.2 in addition to existing targets for the upcoming 4.0.0 release?

[cheenamalhotra]

Hi @JJoe2

We're aware of end of support for .NET Framework 4.6.1, is there a use case you're looking forward to solve with net472 DLL?

[JJoe2]

In the short term, mainly to avoid the clutter of the additional dependencies added to the output folder and app.config when I reference Microsoft.Data.SqlClient from a .NET 4.7.2 application.

I may be mistaken, but I would have thought that adding an additional target would be straightforward.

[ErikEJ]

There should not be any difference between the current 461 target and 472 - what additional dependencies are you referring to?

[JJoe2]

What I'm talking about is illustrated in the attached VS2017 solution, which contains:

• A trivial .NET 4.7.2 console application SystemDataSqlClientTest that references System.Data.SqlClient
• A trivial .NET 4.7.2 console application MicrosoftDataSqlClientTest that references the Microsoft.Data.SqlClient NuGet package.

As can be seen in the bin\Debug folder, MicrosoftDataSqlClientTest includes a whole host of additional "System" assemblies, e.g. System.Configuration.ConfigurationManager. I may be wrong, but my understanding from the article I linked above is that these assemblies won't be added if all NuGet packages I reference target .NETFramework 4.7.2,

SqlClientTest.zip

[ErikEJ]

I see, so we are talking about the 15 additional files, amounting to 1 MB

[JJoe2]

Yes, that's right. Together with a bunch of assembly redirects cluttering the app.config file (which you don't see in the trivial sample I posted, but which are added in real applications).

`

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
  <dependentAssembly>
    <assemblyIdentity name="System.Memory" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.0.1.1" newVersion="4.0.1.1" />
  </dependentAssembly>
</assemblyBinding>

... etc ... `

[cheenamalhotra]

@JJoe2

As can be seen in the bin\Debug folder, MicrosoftDataSqlClientTest includes a whole host of additional "System" assemblies, e.g. System.Configuration.ConfigurationManager.

This is because Microsoft.Data.SqlClient is an Out of the box NuGet package and is not shipped with .NET Framework. Even if we build for .NET Framework 4.7.2, it's going to be the same. Any .NET Framework targeting NuGet package will show same behavior because it's not tied with dependencies from .NET Framework directly. Also we have explicit dependencies on .NET Standard packages that play a role here. Have you come across a NuGet package that you reference explicitly and it does not load dependencies?

[weltkante]

Even if we build for .NET Framework 4.7.2, it's going to be the same.

Newer .NET Framework versions have better support for .NET standard and need less redirection assemblies. There was active development for .NET standard support in the 4.6-4.7.x era so it is expected that the situation improves when targeting a higher version.

(Just correcting above statement because it was wrong, I don't have any immediate need.)

[MichelZ]

If this is not going to be implemented, maybe it's time to close this issue out.