Support SDK Version Management

[dansiegel]

NuGet Product(s) Involved

NuGet.exe, Visual Studio Package Management UI

The Elevator Pitch

Project SDK's sometimes ship in the form of a NuGet. Some common examples:

• Microsoft.Build.NoTargets
• MSBuild.Sdk.Extras

The problem with this is that it isn't very well integrated into the NuGet dependency toolchain. For example if I am using the Microsoft.Build.NoTargets Sdk I might use:

<Project Sdk="Microsoft.Build.NoTargets/3.7.0">

Or I might version this through a global.json like:

{
  "msbuild-sdks": {
    "Microsoft.Build.NoTargets": "3.7.0"
  }
}

However since there is no tooling support when updates like version 3.7.56 become available I have no way of knowing that there is an update.

Additional Context and Details

No response

[baronfel]

Having an official mechanism for this could also help the build of DotNet itself - currently when doing a full product build we build some SDKs and then have to change these files' content to use the newly built versions.

[JonDouglas]

There are many moving / tooling pieces here beyond NuGet. I believe this is a great suggestion, but I also believe it extends past just NuGet including potential components in dotnet SDK, project system, VS, VS Code, etc.

I wonder if someone from the community would be willing to write up some further thinking on this topic here:

https://github.com/dotnet/designs

I won't be able to get around to this anytime soon outside of contributing potential NuGet items and helping sponsor the work internally to the right group of people.

Some core questions I have are the following:

What is the core experience desired? CLI, VS, VS Code, etc? What experience would you like to see and prior art of experiences that do it well or are conceptually similar?

Where does it belong first and where should it eventually make its way to throughout the tooling experiences?

How does it look and function? Is it like any current .NET/VS experiences such as extensions, packages, workloads, tools, etc? Is it a dropdown in a property page? Is it automatically managed for you based on proj/sol requirements? Where is the ideal place to centrally manage them? How should NuGet/SDKs warn you that an update is available and where?

Any answers, prior art, or a larger write up with some concepts would be super appreciated by anyone reading this!

[dansiegel]

@JonDouglas happy to take this offline and discuss helping to drive this forward. The keys though for the various pieces of tooling are:

1. Be able to detect when a project has an available SDK Update
2. For tooling like the Package Manager in Visual Studio for the Solution specifically it should be able to detect and display when you have multiple versions of the SDK installed across various projects.
3. You should be able to update an SDK whether using the CLI, VS or VS Code tooling to keep a consistent experience with what developers are already used to.

4. When updating it should update either the inline Sdk version or the version in the global.json. Of course this also means that the tooling whether Visual Studio, Visual Studio Code / Dev Kit would need to trigger a proper reload of the affected projects.

[hakenr]

This is a major issue that has made us reconsider using MSTest.Sdk. The behavior of NuGet Package Manager in Visual Studio makes it unusable, both for versioning within individual project files and for versioning within global.json (along with Central Package Management in Directory.Packages.props).