Explain our guidance on managing .NET Core SDK Installers

[BillWagner]

Over time, users can have a large variety of .NET Core SDKs installed on a single machine.

We need to explain which to keep installed, and which can be safely removed.

In summary, the .NET Core SDK is backwards compatible and the newest one on the box is used unless there is a global.json file that indicates another version of the SDK.

So, the short answer is:

• You need the one you want to run (latest suggested and previews should be fine)
• And, any that are specified in global.json

If a SDK version is in a global.json on your machine, and you do not have that version, you will roll forward across patch, but not feature versions of the SDK. Except that the roll forward behavior is overly aggressive in the the 2.1.x -> 2.1.300 range. For that range, we recommend you not do roll forward but have the specified version available.

/cc @richlander @KathleenDollard

[KathleenDollard]

Adding the dev team as they wanted to look at the language.

…

________________________________ From: Bill Wagner <notifications@github.com> Sent: Monday, January 29, 2018 8:10 AM To: dotnet/docs Cc: Kathleen Dollard; Mention Subject: [dotnet/docs] Explain our guidance on managing .NET Core SDK Installers (#4241) Over time, users can have a large variety of .NET Core SDKs installed on a single machine. We need to explain which to keep installed, and which can be safely removed. In summary, the .NET Core SDK is backwards compatible and the newest one on the box is used unless there is a global.json file that indicates another version of the SDK. So, the short answer is: * You need the one you want to run (latest suggested and previews should be fine) * And, any that are specified in global.json If a SDK version is in a global.json on your machine, and you do not have that version, you will roll forward across patch, but not feature versions of the SDK. Except that the roll forward behavior is overly aggressive in the the 2.1.x -> 2.1.300 range. For that range, we recommend you not do roll forward but have the specified version available. /cc @richlander<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Frichlander&data=02%7C01%7Ckathleen.dollard%40microsoft.com%7Cf6b140445aec42170b3808d56732e1ac%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636528390592234490&sdata=jdrzOK1mUxkGSDyKRTusOCywAwm8MdOjy29f83JjipU%3D&reserved=0> @KathleenDollard<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fkathleendollard&data=02%7C01%7Ckathleen.dollard%40microsoft.com%7Cf6b140445aec42170b3808d56732e1ac%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636528390592234490&sdata=FSiQMHCx8dhBOH1LurgDfx6k4eZSBZnh6KlqIIGylWM%3D&reserved=0> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdotnet%2Fdocs%2Fissues%2F4241&data=02%7C01%7Ckathleen.dollard%40microsoft.com%7Cf6b140445aec42170b3808d56732e1ac%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636528390592234490&sdata=k3gSl%2F0qDdvIJLRBgmrBP6qoHppRW59g%2BYa3M4EAHGI%3D&reserved=0>, or mute the thread<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAFktXqyowO44AacHiAY53KEwhzHBk9Npks5tPe2PgaJpZM4Rw7fn&data=02%7C01%7Ckathleen.dollard%40microsoft.com%7Cf6b140445aec42170b3808d56732e1ac%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636528390592234490&sdata=jXHIHXNP%2BzbNdtn9wTQxjzXf8bEGm9zHgxgu4MZt%2BwY%3D&reserved=0>.

[mairaw]

A good place to add this would be this topic: https://docs.microsoft.com/en-us/dotnet/core/versions/ where we talk about versioning

[KathleenDollard]

One correction. By the time 2.1.300 ships, we will not rollforward from 2.1.x to 2.1.300. We will keep within the boundaries of the release. So: 2.1.x => 2.1.1, 2.1.9, 2.1.10… 2.1.100 => 2.1.100, 2.1.101, 2.110… 2.2.200 > 2.1.200, 2.1.201,… Edited by @mairaw: removed email template

[mairaw]

That's good to know @KathleenDollard. We need to create an issue for updating that topic too for the versioning rules.

[bergmeister]

If I have a .Net Core 2.0 app, is there any benefit (not just features but also fixes, especially if there will be future security fixes as there were already in the past) to use the newer .Net Core 2.1 SDKs like e.g. 2.1.300 SDK or should I stick to the old 2.1.200 SDK for .Net Core 2.0? I have heard that apps compiled for .Net Core 2.1 should work out of the box for 2.0 runtimes (is that correct for apps that are not self-contained?), is it therefore recommended to just compile against 2.1?

[dasMulli]

@bergmeister There is a difference between "upgrading your application from 2.0 to 2.1" and "using newer tooling to build a 2.0 application".

Both are possible, you can use the 2.1.300 SDK to build applications for 1.0, 1.1, 2.0 and 2.1.
Using the new SDK will likely give you incremental performance boosts when used locally for development purposes.

If you only install the 2.1.300 SDK on a machine, you will also need to install the 2.0 Runtime (+ ASP.NET Core Runtime Store, depending on the platform) because otherwise you won't be able to run the application (e.g. dotnet run will fail but dotnet build should work). This is only because the new SDK installer bundles a 2.1 runtime but no 2.0 runtime.

In fact, if you only use VS and install the 2.1.300 SDK then VS will use components of this SDK by default (unless you created a global.json file in the project's directory hierarchy to pin a different version).

If you want to migrate your Application to 2.1, follow the migration guide. This will also require you to install .NET / ASP.NET Core Runtimes on the servers you deploy to (no-op in case of Azure App Service)

[mairaw]

This item should focus only on:

• which versions I need to keep on my machine
• how do I uninstall SDKs I don't need anymore per OS