Guidance on mixing Extensions versions vs .Net Core version

[czb182]

Scenario. Targeting .NET core 2.1, netstandard2.0 running on .NET core 2.1. We are leveraging ASP.NET core (which would be 2.1 since part of core). We consume many packages from this repo and they are versioned the same as .NET core. I get many Nuget updates available for 2.2, 3.0, 3.1 versions of these packages and I'm not sure if can upgrade to any safely. Am I supposed to stay on 2.1.* versions of these packages? Are only the 2.1.* and 3.1.* versions of these packages considered 'LTS' or is this repo out of that scope?

I searched a while trying to find guidance on this, but was unable to, so hoping someone can point to some documentation or have some written. This seems like an obvious question, so surprised I couldn't find anything. I'm tempted to use wildcard versions (2.1.*) but not sure if necessary.

[Pilchie]

Tagging @DamianEdwards and @ChrisSfanos about published guidance.

The short answer is you should match the major/minor of the ASP.NET Core version you are running, and yes, the LTS version match up with the rest of the .NET Core versions.

[Pilchie]

Didn't mean to close without a chance to get some published guidance.

[czb182]

seems like this version consistency should be loosely enforced somehow. We are not directly referencing asp.net core, but rather target Microsoft.NET.Sdk.Web SDK which implicity references Microsoft.AspNetCore.App according to https://docs.microsoft.com/en-us/aspnet/core/fundamentals/metapackage-app?view=aspnetcore-3.1

Since no versions of asp.net core are mentioned explicitly, would need to infer from TargetFramework I think. So if targeting netcoreapp2.1 should make sure all the asp.net references falling within 2.1.*. Could use this to avoid suggesting updates for these dependencies since they are not recommended from your above comment.

[czb182]

any updates on this? specifcally how one should go about locking to a specific version of aspnetcore/core that we are targeting(in our case 2.1 LTS)

[Pilchie]

We don't really have a tooled way of doing this - people normally just manage their versions themselves. You could consider doing in MSBuild based on some property like $(TargetFrameworkVersion) though.