Ignore the ASP.NET Core meta packages

[slang25]

See here: https://www.youtube.com/watch?v=ttbLKrapCoY

In the video, this repo gets a good shoutout and a lot of love ❤️

A suggestion was to ignore these packages, as the rules around how they are updated are complex, they aren't really normal PackageReferences.

[slang25]

Ouch, line endings look off

[AnthonySteele]

We have been having a lot of issues with line endings lately :(

[skolima]

I'm not sold on this one. If you're using the actual version, not a floating/open/SDK one, my assumption is that you want to update them. It works for us...

[slang25]

Hmmm, I'm trying to understand this. I was going by the conversation in the video that starts here and lasts about a minute. If you reference it the version-less manner, then upgrading to a version would be wrong, and possibly not run (even though it would build).

However if you are specifying versions anyway for .App/.All, then you are saying that you require that exact framework version (down to the patch level), so NuKeeper is basically also asking you to update your runtime, but that's a mess of your own choosing if that makes sense.

So perhaps this change should be closed, and an enhancement made to give a warning around the case where it upgrades.

[slang25]

I think this might explain it better: https://natemcmaster.com/blog/2018/08/29/netcore-primitives-2/#confusing-project-settings

[AnthonySteele]

We are running into similar at work - we want to update the "package" Microsoft.AspNetCore.All to 2.1.4 but we must first apply a framework update to the machines that it runs on, or else it will fail to run.

[skolima]

I'd refer this also to #311 - new projects will be setup by VS to have a versionless reference, and that's preferred (you update by updating the SDK). Existing projects... My personal preference would be to keep updating the reference, with the (silent? perhaps documented? are the issues here documentation enough?) assumption that's this will fail unless your SDK has been also updated. So, to the best of my current understanding: I'm against applying this change. I'd wait and see how dotnet project decides to solve the problem with those framework packages.

[slang25]

@skolima I'm conflicted, ultimately there's merit in being intentionally ignorant about packages and treating them all consistently, but from my understanding this isn't a regular package and tools should not offer to upgrade it even if explicitly versioned.

@natemcmaster @DamianEdwards @shanselman Opinions welcome.
What would you expect tools like this (and dotnet outdated) do with Microsoft.AspNetCore.App if it's pinned to a version in csproj? This was the exact scenario during yesterdays community standup broadcast.

[DamianEdwards]

I'd first ask you all to forgive us for even putting you and the rest of the community in this situation in the first place.

Assuming we get past that, I think it would be useful if tools like this did acknowledge (i.e. special case) these two package names and provide concrete guidance that's inline with the way they're designed to be used (warts and all). We're planning to make specifying a version on these packages a suppressable warning in the 2.2 SDK, but more reinforcement of the guidance from other tools only helps I think.

[AnthonySteele]

So that's a vote for both ignoring the update and emitting some warning text about how the metapackage should not have a specified version.

[skolima]

Reference to the "epic" in aspnet repo: dotnet/aspnetcore#3307