.NET 5.0, Names and the Future of .NET

[svengeance]

With the recent announcement of .NET 5.0, I feel a bit sour with the direction the framework naming scheme has taken.

Currently you can bisect the .NET world at large into either those running on .NET Core, or those running on the .NET Framework. There are clear naming semantics between the two - at a glance, anyone can tell you that .NET Core sounds like it's new, hip, and fast. It is absolutely the place to be if you want to ride the wave of the future. It gets new features daily, it's open source, and it's what turned the heads of many folks I've spoken with, with regards to Microsoft's willingness to open up and work with the dev community at large.

And now we're doing away with all of that? .NET Core, 3 major versions in, will be rebranded instead to .NET 5.0. 5+ years worth of work on building a rich ecosystem focused on a fast-moving product will be condensed down to one major version change of an old product.

I get it's just a name, but perception is reality. .NET 4.8 and .NET 5.0 don't seem that far apart, but guys, we all know there is a world of difference. And not only that, whereas it took 10 and a half years to go from 4.0->5.0, we're now content with hopping on that same naming scheme to make yearly major version releases?

---

I don't know what I can accomplish here, but I'd love to hear some insight on the change of direction. Remember, .NET Core is the Future of dotnet. Thanks for y'all's time.

[karelz]

Thank you for your feedback @svengeance! As you can imagine there is no way to please everyone. I have talked with dozens of customers at Build .NET booth and at customer visits -- this is the first time I hear such a strong dislike to the new name & versioning plan. Typically it requires a bit of explanation what it means, but vast majority of customers and developers are fine with it -- and it helps people who are not yet familiar with .NET Core to understand where the future of .NET is and where they should move next to keep up with latest and greatest. Of course, my opinions and perceptions do not make your feedback less important, but I want to make sure it is put in perspective of wider feedback-range. Especially from the perspective of customers/developers who are confused now by the duality of .NET Framework and .NET Core trains and versioning and who are confused about .NET future and where it is focused on.

To be honest, I share a bit of your dislike to the rapid yearly version increase after .NET 5. On the other hand, I also understand that there is not much better versioning scheme which would "clearly" make more sense. It is also easier to explain which version is LTS and how it relates to the next version to customers. If we used point versions, it would be IMO more confusing.

I will pass your feedback to @coolcsh (you may want to reply also on the blog post itself - maybe with a link to this issue). cc @richlander @terrajobst

Given that this is not actionable bug report, we will leave it open for a few days (for a chance to have back-and-forth discussion) and then close it as resolved. Let me know if you have any concern about such approach. cc @carlossanlop Thanks!

[terrajobst]

@svengeance

We hear you -- and truth to be told -- many on our team are also ambivalent about the naming, for the reasons you presented. Let me try to make an argument in favor of the ".NET 5" branding.

.NET, as most technologies that are about 20 years old, have a lot of heritage. Both in product design decisions as well as in product naming and editions. I like to believe that we did reasonable well with the concept count in the product itself: we were always striving towards simple APIs rather than Byzantine castles. Same is true with C#, VB, and F#. We haven't always succeeded, but nobody is perfect. However, on the product naming & edition site we've inflated the concept count like there is no tomorrow: .NET Framework, .NET Compact Framework, Silverlight, .NET Micro Framework, .NET Portable Class Libraries, .NET for Windows Store, .NET Native, .NET Core, .NET Standard... and that doesn't even include what the Mono community did. While this evolution of .NET can be explained (and was always properly motivated) it did come with a massive tax: the concept count. If you're new to .NET, where would you start? What is the latest stack? You may say, "of course that's .NET Core" but how would anyone know that?

We've tried to simplify the world with .NET Standard, so that class library authors don't have to think about all the different "boxes" that represent different versions of .NET. However, in order to do that we had to add one more box (the irony wasn't lost on us). In order to make the future more sane, we have to reduce the number of boxes. We don't want to make .NET less flexible, but we want to reduce nonsensical differences that purely resulted from us not being open source early enough. For example, Mono/Xamarin/Unity are based on a different set of runtimes and frameworks than the .NET Framework/Silverlight/UWP/.NET Core lineage. With .NET 5 the goal is to converge these lineages onto a single product stack.

We strive to provide an experience where you don't have to reason about the different kinds of .NET anymore. Of course, we still don't want to abstract the underlying OS, so you'll continue to be able to call OS specific APIs, be that via P/Invokes and WinRT or the Xamarin projections for iOS and Android. But when you talk about the kind of .NET code you'll be writing, you no longer have to think about .NET Core vs. Xamarin or .NET Core vs. Mono.

Now think about developers who start on this stack and can write any application for any of the platforms .NET supports. The branding we currently have makes no sense to them. The only two things a person should need to know to get good results on the internet is (1) what development stack are you using and (2) which version are you in. This is how virtually every other developer stack has always worked.

We didn't chose the ".NET 5" by accident: any .NET platform that started with ".NET" (.NET Framework, .NET Core, .NET Standard) has a version number that is lower than 5. Thus, even when only giving things a cursory look, most people would conclude that ".NET 5" is the most recent version among them.

Yes, ".NET 5" wouldn't be perfect superset of .NET Framework. However. we believe starting with .NET Core 3 already, you can build the same kind of workloads that you could with .NET Framework. Some of the tech has changed, but that's the way it's gonna be forever. The remaining delta will never be closed. Existing apps can stay on .NET Framework and will be supported, but we already said we'll generally no longer add new features to it. Thus, new apps should start on .NET Core/".NET 5".

I'm much less concerned about existing customers being confused about ".NET 5" than I am concerned about new customers. Existing customers have enough context that .NET 5 can be explained in simple terms (".NET 5 is just .NET Core with more features"). And new customers get to see a branding that is reflective of the simplicity of the underlying stack.

That being said, the branding hasn't been decided yet. We're running more user studies to figure out where we'll go.

[svengeance]

I appreciate your guys' feedback, with all the thought and honesty that went into the responses. I hadn't fully considered what it would be like to the new end-users -- in essence, we are abstracting away the complexity of understanding the differences between Core and Framework, and condensing it down to Latest Version = Good sort of deal.

I guess the big shtick here, for me personally, is that there is a world of differences between the two runtimes and versions despite being so close in name. This affects so many little things, from day to day conversations, to searching for problems in Google, and to introducing new developers. You can witness a perfect example of it occurring with Angular - there's a plethora of content out there written for AngularJS that it makes solving Angular>=2.0 problems unnecessarily difficult. Talking with people who've had poor experiences with Angular, you have to ask them -- "We're you on Angular 1.4 or 2.0?" Just like a .NET 4.8->5.0 transition, the Angular 1.4->2.0 transition contained so much but it still impacts development negatively today.

We already experience this slightly. I was an early-ish adopter of .NET Core down around July 2016, and researching problems then was a nightmare. Nowadays things are better -- appending 'Core' to your favorite Google search tends to give you pertinent results, but still, it's not always easy to find. From the perspective of newer developers, the most reliable way to solve your problems will be to append 'Core' to your search when solving .NET 5.0 issues, and implicitly understand that solutions from .NET Core>=2.0 are probably relevant to your problem.

No matter what the outcome, I'm happy for your guys' revolutionized codebase and atmosphere, and I hope this nitpick doesn't come across too poorly. Y'all at MSFT are quite literally paving the way for my and others' careers, so thanks.

[kameko]

I think the biggest issue with the naming is the fact that "just .NET (5)" can be confused with .NET Framework. Has it ever been considered to rename Framework? Maybe .NET Classic? Or do you think that would have the opposite effect of posts from years ago using ".NET" referring to Framework and people assuming they meant .NET 5 and not .NET Classic because of no mention of the word Classic (or whatever marketing would decide to rebrand it)?

[drchilds]

I personally think @terrajobst 's post above would make an excellent blog post, just to get that message to a wider audience.

[kingboyk]

I wouldn't expect this to affect Microsoft's thinking of course, but this naming scheme will lead to chaos on Stack Overflow where we currently have .net and .net-core tags for the legacy framework and Core respectively.

[terrajobst]

I personally think @terrajobst 's post above would make an excellent blog post, just to get that message to a wider audience.

Once we decided where we land with naming, we'll probably do that. Until then, it's probably best to keep that conversation for folks that are used to consuming information from a firehose, i.e. you folks on GitHub :-)

[karelz]

I don't think there is much left to discuss here. Closing. If I misunderstood and we see value in having the issue and discussion open, please let me know and I will reopen. Thanks!

[doubleyewdee]

Longer variant of the tweet I randomly replied to: no choice is perfect and at this point I am begging you to just ride it out and stop changing the names. :) I agree with the assertion that existing ecosystem participants will be much better positioned to navigate the ambiguity between Core/Framework than a new user. .NET 5 is clear and unambiguous in what it is, the plan for .NET 6 is similarly about absorbing more into the unified new platform, and I dig that.

Will I, personally, need to think about .NET Framework vs. Core in five years? Probably, but not for any project I start today, which will be .NET 5. And while it is going to be cognitive load, it's a pebble in the ocean of tech debt for any long-lived codebase. For myself at least I'm confident in my ability to manage the complexity, and I believe in other .vets as well.

The 'win' for new users is so, so important for the long-term health of the ecosystem that I think those of us already in it need to just deal with this and move on.

[Amondale]

I know my web hosting provider, or at least the few that still regularly support the Windows/.NET platform, are completely unaware of the distinction between Core and dotnetFX (4.x and 3.x are my only choices with the Plesk interface). This is all due to "branding-speak" and gradual migration of server admins to LAMP over Windows in the hosting world. OK, also a good shot of "Microsoft wants you on Azure, not in the hosting world, and lookie here, we got your LAMP covered in Azure too!" I'm sure when my prepaid hosting expires in mid-2022 I'll be ready to move my domain to Azure, and also sure it will be cost-comparable with my current WSP/ASP (which I joined in 2009 or thereabouts, when it was cheap as dirt, ~$4/month to have that ASP.Net goodness). However, for the time being I'll have to be content with coding MVC versus the much more feature-rich Core framework, because there's very little incentive for the hosting "giants" (RackSpace, GoDaddy) to get on the Azure/Core train or spaceship or whatever.

[HppZ]

@svengeance

We hear you -- and truth to be told -- many on our team are also ambivalent about the naming, for the reasons you presented. Let me try to make an argument in favor of the ".NET 5" branding.

.NET, as most technologies that are about 20 years old, have a lot of heritage. Both in product design decisions as well as in product naming and editions. I like to believe that we did reasonable well with the concept count in the product itself: we were always striving towards simple APIs rather than Byzantine castles. Same is true with C#, VB, and F#. We haven't always succeeded, but nobody is perfect. However, on the product naming & edition site we've inflated the concept count like there is no tomorrow: .NET Framework, .NET Compact Framework, Silverlight, .NET Micro Framework, .NET Portable Class Libraries, .NET for Windows Store, .NET Native, .NET Core, .NET Standard... and that doesn't even include what the Mono community did. While this evolution of .NET can be explained (and was always properly motivated) it did come with a massive tax: the concept count. If you're new to .NET, where would you start? What is the latest stack? You may say, "of course that's .NET Core" but how would anyone know that?

We've tried to simplify the world with .NET Standard, so that class library authors don't have to think about all the different "boxes" that represent different versions of .NET. However, in order to do that we had to add one more box (the irony wasn't lost on us). In order to make the future more sane, we have to reduce the number of boxes. We don't want to make .NET less flexible, but we want to reduce nonsensical differences that purely resulted from us not being open source early enough. For example, Mono/Xamarin/Unity are based on a different set of runtimes and frameworks than the .NET Framework/Silverlight/UWP/.NET Core lineage. With .NET 5 the goal is to converge these lineages onto a single product stack.

We strive to provide an experience where you don't have to reason about the different kinds of .NET anymore. Of course, we still don't want to abstract the underlying OS, so you'll continue to be able to call OS specific APIs, be that via P/Invokes and WinRT or the Xamarin projections for iOS and Android. But when you talk about the kind of .NET code you'll be writing, you no longer have to think about .NET Core vs. Xamarin or .NET Core vs. Mono.

Now think about developers who start on this stack and can write any application for any of the platforms .NET supports. The branding we currently have makes no sense to them. The only two things a person should need to know to get good results on the internet is (1) what development stack are you using and (2) which version are you in. This is how virtually every other developer stack has always worked.

We didn't chose the ".NET 5" by accident: any .NET platform that started with ".NET" (.NET Framework, .NET Core, .NET Standard) has a version number that is lower than 5. Thus, even when only giving things a cursory look, most people would conclude that ".NET 5" is the most recent version among them.

Yes, ".NET 5" wouldn't be perfect superset of .NET Framework. However. we believe starting with .NET Core 3 already, you can build the same kind of workloads that you could with .NET Framework. Some of the tech has changed, but that's the way it's gonna be forever. The remaining delta will never be closed. Existing apps can stay on .NET Framework and will be supported, but we already said we'll generally no longer add new features to it. Thus, new apps should start on .NET Core/".NET 5".

I'm much less concerned about existing customers being confused about ".NET 5" than I am concerned about new customers. Existing customers have enough context that .NET 5 can be explained in simple terms (".NET 5 is just .NET Core with more features"). And new customers get to see a branding that is reflective of the simplicity of the underlying stack.

That being said, the branding hasn't been decided yet. We're running more user studies to figure out where we'll go.

so when will UWP be supported by .NET 5.0 or 6.0?