Move CLI tools to netcoreapp3.1

[sywhang]

From #1635 (comment):

2.1 goes out of support in August. We may want to move dotnet diagnostic tools to 3.1 before then.
I'd be half tempted to move to 3.1 as soon as we finish the 5.0 release.

We should start thinking about migration plans to .NET Core 3.1 since .NET Core 2.1 is going out of support Aug 2021. Filing this issue to keep track of this work. This work involves:

• Updating the APIs tools to make use of new APIs in .NET Core 3.1
• Updating documentation on installation

[sdmaclea]

I wonder if we should just adopt a policy the global tools will always have a dependency on the latest LTS release.

This is where we prefer the majority of our customers to be...

/cc @dotnet/dotnet-diag

[sywhang]

I wonder if we should just adopt a policy the global tools will always have a dependency on the latest LTS release.

Actually, I was thinking the other way around and have the tools have a dependency on the oldest LTS release that hasn't gone out of support, simply because that would cover the biggest group of users to use our tools.

[sdmaclea]

I don't think the tools running under 3.1 would prohibit use with 2.1 processes. Am I missing something?

[shirhatti]

The concern is not the target process.
3.1 tools will work with 2.1 processes.

The concern is not having a new enough runtime available to run the tool. A tool targeting 3.1 can't run if you only have 2.1 installed locally.

[sywhang]

It wouldn't prohibit users that use 2.1 processes but they'd have to install 3.1 SDK on top of 2.1 (which is what they're using).

Another potential caveat with the policy that we have dependency on latest LTS release is when we actually do a new LTS release - for example 6.0 is a LTS release so if we made that policy a thing we would need to migrate the tools to run on 6.0 when majority of users are still on 3.1. I suppose it will give them a "push" to move to the newest LTS release, but at the same time it could be a potential pain point for adopting these tools.

[sdmaclea]

I am OK with an oldest LTS policy. As long as we are:

• not discouraging customers to moving to the latest LTS.
• forcing/encouraging them to install the older LTS

I worry a bit about EOL. I guess/hope the global tools will run with the newer LTS version. So our customers can prepare for EOL....

We may want a caveat something like oldest LTS version with 90days of support left....

[sdmaclea]

Maybe the self-contained tools might change our story too...

[shirhatti]

forcing/encouraging them to install the older LTS

Our tools roll forward and work on newer runtimes. We're not encouraging anyone to install an older LTS
See https://github.com/dotnet/diagnostics/blob/master/src/Tools/dotnet-dump/runtimeconfig.template.json

[noahfalk]

I'd propose as our versioning/support story...

For installation SDK and the runtime that is executing our tools:

• Our tools must support at least all runtime/SDK versions that are currently supported by Microsoft (nobody is forced to get an old runtime/SDK, nor are they forced to upgrade if their current runtime/SDK is supported)
• We should only remove support for an old runtime that is outside its official support window if we get a substantial engineering benefit from doing so.

For the runtime that our tools are diagnosing:

• If we release a feature that works for runtimes >= X, at minimum we need to retain that support until X is no longer officially supported by Microsoft
• Once the runtime X is no longer officially supported by Microsoft we are no longer obliged to fix newly discovered bugs or add new functionality, but we should still avoid regressing what functionality was already working unless maintaining it would incur significant engineering costs for us.

My understanding is that our current story of supporting everything >= 2.1 meets these criteria. Once 2.1 is out of Microsoft support is there any substantial engineering benefit we expect to gain by removing support for it in the tools?

[josalem]

is there any substantial engineering benefit we expect to gain by removing support for it in the tools?

One thing (perhaps the only thing) I can think of is we would not have to dual target our tools for doing single-file publishing if we bumped to 3.1. It wouldn't drastically simplify engineering, but it would remove one forced difference between our shipping vehicles.

From a technical standpoint, we haven't hit any issues because we are on 2.1 that I am aware of. There are some syntactical sugar niceties we can't use since they're only in C# 8+, but those are just that... sugar.

[sdmaclea]

I think we should also be thinking from a security perspective. Once the runtime/SDKs are out of support, there are no more security patches.

I would prefer tool releases after a runtime is out of support not depend on the out of support runtime. Seems like asking for trouble.

I suspect the better way to handle this might be a better versioning story. If a customer really needs diagnostic tools to run on an out of support runtime, they can grab an out of support version of the diagnostic tools.

Edited

[noahfalk]

I would prefer releases after a runtime is out of support not target a out of support runtime. Seems like asking to trouble

Good point. By 'target' I assume you mean the runtime that is executing the tool (as opposed to the runtime being diagnosed by the tool)? Its a fair concern at minimum for our more security-sensitive tools like dotnet-monitor. And if we were doing it for monitor its probably clearer to be consistent than to enforce different policies per tool. Consider my opinion revised for the 'runtime that is executing our tools' portion : )

If a customer really needs diagnostic tools for an out of support runtime

• In the case of executing the tool on an old runtime they could either install a new runtime SxS or use dotnet-tool install with the explicit version option to get an old version of the tool from NuGet.
• In the case of diagnosing an out-of-support runtime I'd still suggest that we continue to support doing that with our latest tools unless there is a substantial engineering cost. I want to get users in the habit of updating readily and not worrying that they are losing functionality when they do so (such as the ability to diagnose an app on an older runtime). There should be no security issue here because a secure design for our tools needs to assume any app being diagnosed might be malicious.

Does that seem OK or we still have concerns?