Breaking change: Update FrameworkName to ".NET"

[richlander]

See: https://github.com/dotnet/runtime/blob/master/src/libraries/System.Runtime.InteropServices.RuntimeInformation/src/System/Runtime/InteropServices/RuntimeInformation/RuntimeInformation.cs#L11

This code produces this output today (for 5.0):

.NET Core info
Version: 5.0.0
FrameworkDescription: .NET Core 5.0.0-preview.1.20120.5
CoreCLR Build: 5.0.0-preview.1.20120.5
CoreCLR Hash: 3c523a6
CoreFX Build: 5.0.0-preview.1.20120.5
CoreFX Hash: 3c523a6

[Dotnet-GitSync-Bot]

I couldn't add an area label to this Issue.

Checkout this page to find out which area owner to ping, or please add exactly one area label to help train me in the future.

[danmoseley]

@jkotas do you plan to update markdowns in this repo also?

[jkotas]

@jkotas do you plan to update markdowns in this repo also?

I have done a pass over the repo docs in #33694

[jkotas]

I am sure there is more cleanup that can be done in the repo docs and comments, but I think we won't be able to fix all references to .NET Core. For example, if a comment talks about .NET Core 2.0, it should stay as .NET Core 2.0. Changing it to .NET 2.0 would be ambiguous (does it mean .NET Framework 2.0 or .NET Core 2.0?)

[danmoseley]

@jkotas there are still 244 hits for .NET Core in docs/**md. I take your point about ambiguity with .NET Framework. But if a year or two from now someone comes fresh to this repo, and wants to find out about .NET 5+, should we have to teach them what .NET Core means? For example how should they interpret ".NET Core host probing". Should we explain that this means ".NET Core and .NET 5+ host probing" ? Similarly eg "ECMA 372 is supported by the .NET Framework, but not .NET Core." .. should that say something else now?

@richlander this seems like a broader question, what is the best way to refer to the "new .NET architecture" that started with .NET Core 1.0?

[danmoseley]

I don't mind making the markdown edits BTW, if it's clear what we want to do.

[jkotas]

if a year or two from now someone comes fresh to this repo, and wants to find out about .NET 5+

I agree that the need to learn about .NET Core should and will be fading away over time, but .NET Core is always going to be part of the history and it won't be ever possible to erase it completely. For example, I expect that it is always going to be in the repo glossary.

all .NET Core assemblies are strong-named

I would reword this one as "all .NET Runtime assemblies are strong named".

.NET Core host probing

I think this one would be fine to change to ".NET host probing". There is very low risk of ambiguity with .NET Framework.

ECMA 372 is supported by the .NET Framework, but not .NET Core

This should say "ECMA 372 is supported by the .NET Runtime on Windows platforms only."

Other examples:

For .NET Core version 1.x and 2.0.x

This should either stay as is; or the whole paragraph should be deleted if it is no longer relevant.

select .NET Core from the selection dropdown

This should stay as is until the UX is changed.

[danmoseley]

Can you clarify what you mean by ".NET Runtime" in your examples? I assume you don't mean it to include .NET Framework. Does it mean ".NET Core and .NET 5+" ? (I do not know where we support ECMA372)

[jkotas]

I think ".NET runtime" is a good name to use for a general reference to .NET Framework or .NET Core. We have used this name in .NET Framework days too.

where we support ECMA372

.NET Framework 2.0+, .NET Core 3.0+, .NET 5+

[danmoseley]

Seems enough was done here cc @richlander

[richlander]

Sounds good. Thanks for all the work, Jan! Looks great.

[ericstj]

@ViktorHofer do we have a breaking change notice for the TFM change? If not can we add one here: https://github.com/dotnet/docs/issues/new?template=dotnet-breaking-change.md

[ViktorHofer]

We don't have one yet AFAIK. What would be the breaking change here? That we rename the short target framework moniker from netcoreapp to net? cc @terrajobst

[danmoseley]

Could break anyone testing Framework name (maybe various API) eg gfoidl/Stochastics#88

[ViktorHofer]

Sorry I was reasoning to Eric's question. I understand that renaming the FrameworkName is a breaking change. I guess even for the TargetFrameworkMoniker, which shouldn't be read/persisted anywhere as it's inferred properties should be used, a breaking change notice makes sense.

[ericstj]

We can enumerate the places the new moniker may appear. The thing @danmosemsft mentioned actually doesn't change. We left it at .NETCoreApp:

[assembly: TargetFramework(".NETCoreApp,Version=v5.0", FrameworkDisplayName = "")]

The same seems to be true for AppDomainSetup.TargetFrameworkName.

@jkotas changed what RuntimeInformation returns here:
410b992

Perhaps that's the only place? It might be worthwhile to just talk in general about the change and how it works and how it is largely non-breaking.

[ViktorHofer]

Filed the breaking change issue: dotnet/docs#20958

[ericstj]

Thanks @ViktorHofer, removed the label.