Clean of package references due to framework references

[thompson-tomo]

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

I am wanting to decrease the number of transient packages in my projects and instead focus on using framework references where appropriate.

Describe the solution you'd like

I would like projects which have a framework reference to only have packages references for those packages not available as part of the framework.

Initial list for 4.0:

• Steeltoe.Security.Authentication.Mtls.csproj
• Steeltoe.Configuration.CloudFoundry.csproj
• Steeltoe.Configuration.ConfigServer.csproj
• Steeltoe.Configuration.Encryption.csproj
• Steeltoe.Configuration.Kubernetes.csproj
• Steeltoe.Configuration.SpringBoot.csproj
• Steeltoe.Management.Endpoint.csproj
• Steeltoe.Logging.DynamicSerilog.csproj
• Steeltoe.Logging.DynamicLogger.csproj
• Steeltoe.Discovery.Client.csproj
• Steeltoe.Management.Task.csproj

I would like a similar spring clean done on the 3.x branch.

Describe alternatives you've considered

N/a

Additional context

Full list of packages bundled into framework: https://github.com/dotnet/core/blob/main/release-notes/net-package-deprecation.md

Should framework references be added for any other projects? Can target frameworks be reduced due to addressing package versioning & possibly restore previous frameworks?

[thompson-tomo]

@TimHess would a pr for 3.2 have a chance to be reviewed/approved given change would be focused on cleaning up references?

[bart-vmware]

@thompson-tomo Is there an official recommendation for changing this that we're not aware of? Can you provide some background on the consequences of such a change? What are the risks and what problem does it solve?

[thompson-tomo]

@bart-vmware here is some background from Microsoft talking about it https://learn.microsoft.com/en-us/aspnet/core/fundamentals/metapackage-app?view=aspnetcore-8.0 & Andrew lock https://andrewlock.net/exploring-the-microsoft-aspnetcore-app-shared-framework-in-asp-net-core-2-1-preview-1/

The issue I ran into was 2 of my dependencies had CVE's in them and because the library with CVE had been deprecated due to the cleanup issue I need those developers to approve my PR with the switch to address the CVE. In fact moving those 2 libraries to framework references meant 70 transitive dependencies got trimmed out of my dependency graph some of which were v2 libraries as the dependencies weren't being maintained.

For me by using the framework reference (already there) we can be sure the best supported combination of libraries is being used especially with the removal of the direct references.

[thompson-tomo]

Also see https://github.com/dotnet/aspnetcore/issues/3612

Further benefit to moving to this approach would be that the conditional package version is not needed as shown in version.props as it would come out of box due to getting it from the framework it is being compiled for ie net 6 automatically gets the latest net 6 packages.

[TimHess]

Generally speaking, we would also prefer a framework reference to package reference, though I don't think we've revisited this topic in several years so I could see there being more to do now. If you want to see how things look in main I think that would be helpful (maybe take it one project at a time at least at first so it isn't a huge pile of work).

As for v3.2 however, for changes in that area we'd probably want to drop .NET Core 3.1 and probably add .NET 8 at the same time, and I'm not sure it is worth the effort to test all the necessary scenarios for that compared with maintaining focus on getting 4.0 ready to ship. FWIW, I'm hoping we can have a 4.0 milestone release in the next month or so.

[thompson-tomo]

So I did an initial investigation when I created this issue hence the list of projects above which was based on the main branch. Let me in the next couple of days clean those projects to reduce those dependencies & submit a pull request.

But agree it should be revisited what projects should have a framework reference & which one's should have the packages. For those with a framework package, it could be looked at targetting a single older target framework as the framework reference ensures the latest supported libraries are included.

Based on that timeline I won't touch the 3.x branch

[thompson-tomo]

PR has been submitted which removes references to packages if projects either directly or indirectly has a framework reference which will bring the package in.

What are your thoughts about

• only targeting multiple frameworks for projects which actually need it ie Abstractions