Hacker News Reader

Comment by lol768 | Hacker News Reader

I'll be honest, as much as I love the improvements with .NET Core/.NET Standard, Microsoft's branding strategy leaves a lot to be desired.

vNext has already been historically used in the context of ASP.NET to refer to ASP.NET (not to be confused with ASP.NET MVC) v6. We restarted the versioning back with ASP.NET Core, now on version 2. Entity Framework used to be a .NET framework component but is now standalone, and has a Core version? Does Blazor (or is it Razor Components now) share the .NET branding?

Separate to the web stuff, we have the .NET platform - .NET framework is the non-cross platform version for which we're on version 4, but it implements .NET Standard v2 along with .NET Core, which has a Linux runtime. Mono also implements .NET Standard v2 and has a Linux runtime.

I remember many years ago when we also had Microsoft .NET Passport.. which was completely unrelated to everything else that I've mentioned related to the .NET brand.

And now we have .NET 5 which is neither Framework nor Core - so will ASP.NET drop this Core branding too? Is it just me, or is this all incredibly convoluted?

View on HN

> And now we have .NET 5 which is neither Framework nor Core

Just to note, the blog post explicitly says that .NET 5 is the next version of .NET Core. It's where .NET Core is going, and given that so much more of the .NET "picture" is being realized with it, the name is changing to be more reflective of the fact that it's not really a "core" (small) thing anymore.

Yes, indeed. But will that change also apply to the other projects that target .NET Core (now ".NET")? Will Entity Framework Core become Entity Framework and clash with the 'full-fat' Entity Framework? The blog post suggests this won't happen by referencing ASP.NET Core 3.

And where does this leave the legacy .NET Framework? It reads as a sub-project of '.NET' (previously .NET Core) but it very much isn't because it provides a set of older APIs. We seemingly have two meanings for .NET now, referring to .NET Core (which I guess only applies when suffixed with v5+) and the wider array of .NET projects, whatever they are.

Legacy net framework Will stop with 4.8, as said some months ago

EDIT: more on this here https://devblogs.microsoft.com/dotnet/update-on-net-core-3-0...

Fair enough - but the wealth of documentation for it will continue to exist, as will older applications targetting it. This seems problematic if you want to search for ".NET" (meaning .NET Core).

I missed that, and that would be a pretty big deal. I thought the message was of a side by side evolution, with full framework getting features possibly with a delay.

There's no point since .NET Core 3.0 can run desktop applications now.

All the desktop stuff is only on Windows though, right? If I'm not mistaken this is the first major .NET Core component that is not cross-platform, which is confusing in itself.

Yes, since it's using Windows components like WPF. I dont think they ever had a plan for a cross-platform desktop UI kit.

They explicitly won't support cross-platform efforts for the GUI stuff, as stated on GitHub (though maybe, one day ...).

I suppose their rationale is damage control ("Okay, they get the server, but the desktop is still firmly ours"), but it would certainly keep me from starting a personal project with a Microsoft Framework.

> but the desktop is still firmly ours

At this point I'm guessing that it's because there isn't a strong future for desktop apps written in native code. Even VSCode is written on top of Electron. Good, bad, or indifferent I think that there isn't a lot of point in developing a native GUI framework at this point.

(To be clear - I'm 100% sure that there are a lot of use cases that I'm blithely waving away, but I'm also sure that those use cases are currently being addressed with WinForms, Qt, GNOME, etc, etc, so why should MS invest in Yet Another GUI Framework?)

I wouldn't mind seeing WPF, or a descendent, ported to other platforms. Xamarin Forms, Eto Forms, and a lot of other wrappers already do a lot of that though, if you want cross platform gui from .Net. (god that looks sloppy)

I also tend to agree that for good, or bad, that Electron will probably grow significantly as an application base. Like I see node becoming the defacto runtime for WebAssembly, I see Electron taking that place for WebAssembly + UI. And I don't think it's all that bad.

Even with MS, Electron seems to be their unified UI target for a lot of apps. VS Code, Teams, Azure SQL Studio (or whatever the name is now), and don't see that space shrinking. I'm only surprised that Teams doesn't have an official Linux version.

WinForms is outdated, "replaced" by WPF and I think apps on the Microsoft App Store have to use WPF instead of WinForms.

So it would make sense if they're pushing .Net Core to be cross-platform, that they want to eventually push the Microsoft App Store "buy" button to be cross-platform as well, with a GUI framework to support those apps. Speculation, but .. of course they will want to.

You can't publish WinForms or WPF applications to the Microsoft Store, they've both been replaced. It's only UWP or using MS's tooling to convert Electron apps to UWP.

Xamarin Forms is that.

Isn’t that a clone of WinForms and not WPF?

That's probably a good thing. WinForms is still the nicest GUI development experience out there, sadly...

Not at all, it uses XAML and the same ideas behind WPF.

It will run desktop applications developped for .net core. I don't believe that .net core can run a full framework desktop executable.

It can using the compatibility shim depending on what framework capabilities it requires.

WCF, Remoting, Web Forms, ODP.NET, EF6 UI designers certainly not.

Yes, some of those items are legacy, but not everyone enjoys paying to rewrite stuff from scratch.

Only partially, try to run any desktop application that depends on WCF or ODP.NET with it.

wcf works under core (at least most of it), core 3.0 + wcf + windows desktop shim actually makes everything under wcf working again.

Most of it is not good enough.

I don't want to be the one stating on RFP "it kind of works".

What is not good enough?

Pick random .NET app using WCF and run it with zero changes on .NET Core.

The implication I took from this was that it's not good enough now, but they anticipate it being good enough by the point this is released.

Those customers want the existing apps to just run. Some of them, as sometimes happens, don't want to rewrite them.

Key pull quotes in this article specifically:

> There will be just one .NET going forward

> Additionally, we wanted to clearly communicate that .NET 5 is the future for the .NET platform.

Well, it is not really the case, there will be still two frameworks, just one isn't going to be developped anymore (full .net 4.8). The way I read that sentence initially was them merging the two into one.

>Well, it is not really the case, there will be still two frameworks, just one isn't going to be developped anymore (full .net 4.8).

If "one isn't going to be developed anymore" there there will be just one framework.

"Being" here means what's the official worked-on implementation. Not merely existing, obviously the code for 4.8 wont go anywhere, nor will existing deployments suddenly vanish.

When 4.8 is installed, 4.7 is going away. Here .net 5 will not replace .net 4.8, it will exist side by side (if I understand correctly). That's two frameworks to me.

>> When 4.8 is installed, 4.7 is going away.

That's not true at all. You can run any version of the framework side-by-side all the way back.

You can only have a single 4.x version on the box. They all install into the same folder.

The VB6 runtime is still installed on Windows 10, but no one (should) considers that a viable Framework to target in 2019.

Maybe a better analogy is that .NET Framework 1.x and .NET Framework 2-4.x are side-by-side installed still in Windows 10. If you wanted you could still target .NET 1.0 and it will run in an entirely different runtime (.NET 1.x and 2.x are hugely different). .NET was designed for that sort of side-by-side deployment, they just haven't done it in a while.

Yet I've not met a developer that still sees .NET 1.x as a viable Framework recently. Do you want .NET 4.8 applications to just break? What do you expect here? The "current framework" is always a combination of marketing and support and this article seems pretty clear that all marketing and support effort will be on .NET 5, and .NET 4.8 is "done".

Yes, major versions install side-by-side (except v2-v3) because they aren't perfectly backward compatible and this is necessary for legacy app support. So, you can need all of .NET Framework 1.1, 3.5, and 4.8 now, and in the future .NET 5.x is added to the list.

That's just 2 frameworks installed on a machine.

You can have .NET 2 or whatever older on the same machine too.

Doesn't change the fact that .NET 5 will be the single official .NET release onwards, where development efforts will be concentrated, etc. It's not like MS will support 2 different frameworks (except one as a legacy release).

What they are saying at MS Build is 4.8 will be supported "forever" because there is too much code depending on .NET Framework, but new feature development is going into .NET Core 3+. By the time they reach .NET 5, they will have unified .NET Core, .NET Standard and Xamarin. They are skipping version "4" to avoid confusion with the second .NET Framework 4.8.

I took "forever" to mean that they would still be issuing security patches to 4.8, for example. Given all that I don't know why you're insisting on phrasing it like that. There is only one future, sure. But you seem to be making it sound like 4.8 has a planned obsolescence date or something and Microsoft is saying the exact opposite.

But that article says:

"Both .NET Framework and .NET Core will move forward, and both will be fully supported"

???

Which is why I found this one confusing... because it essentially says the opposite.

Yep, I've semplified. What I understood from this post is that net framework is in "maintenance mode": probably MS plan a 4.8.1 with but fixes and maybe a 4.9 with some minor updates, but .net core (now simply .net) is the place where new things will be developed.

I don’t see anything in the linked article that supports your conclusion.

Nothing in the article suggests maintenance releases, but MS' history is probably enough for that. The article does definitely state that .Net 5 is the evolution of Core and will be the entire platform going forward. I'm, personally, glad to see Core/Framework/Mono etc rolled into a single version at 5. The previous split versions have been fairly confusing.

yep! this blog post is more clear about future releases: https://devblogs.microsoft.com/dotnet/net-core-is-the-future...

"We will continue to both service and support .NET Framework, which includes bug–, reliability– and security fixes."

Here is the post you are looking for, I think ... https://devblogs.microsoft.com/dotnet/net-core-is-the-future...

exactly! "We will continue to both service and support .NET Framework, which includes bug–, reliability– and security fixes."

The post is a vision-setting announcement about where .NET is headed. The finer details like you've described will be worked out in the following 1.5 years.

I look at this ".NET 5" thing as a PR move to end full framework.

"We aren't ending full framework, we have .NET 5!"

If you are developing new apps in full framework, you are doing it wrong.

Then we are doing it wrong, until the 3rd party libraries that we require, actually bother to make it right.

If you're developing an application with a Windows desktop GUI, you're still doing it on full framework (WPF, WinForms, UWP). They're folding that into .NET 5, and I haven't seen anything indicating that they see that as "doing it wrong". This is only one case of developing for full framework, but it's a big one. I imagine any other cases where the developer community really needs full framework capabilities that still aren't ported to CoreCLR, they'll fold that in just the same as with the UI frameworks, as a Windows-specific capability. Maybe they end up sunsetting more than I think, but for now this seems more like consolidating Core and Framework than ending Framework.

There are a ridiculous amount of first-party Microsoft SDKs for products they are pushing heavily that don't support Core yet.

Unless there is a newer version than last month, one of those is the Bot Framework extensions for Microsoft Teams, which they are just slamming ahead with.

Last time I tried to seriously switch from Framework to Core, I was dismayed to find that Assemblies could not be unloaded from memory in Core after they were loaded. That was something that depended on the AppDomain functionality, which existed in Framework only.

Thankfully, they finally got around to adding support in .NET 3.0 (https://www.strathweb.com/2019/01/collectible-assemblies-in-...).

Yes, the branding is terrible and has been for some time. It's good that most of it is merging but this is still years away and will create a lot of historical churn in its wake.

Even with the tremendous strides in tooling and docs, the naming and runtime complexity is the biggest hurdle in getting new developers to the ecosystem. Just about every other major stack has a far simpler setup. Even ".NET" is hard to search for.

Yeah, the dot has always been unwelcome now that you mention it. Including in my filesystem.

Not to mention the fact that the whole thing was named after an experience that to me at least has always meant "Shoot, .com isn't available!"

> And now we have .NET 5 which is neither Framework nor Core - so will ASP.NET drop this Core branding too? Is it just me, or is this all incredibly convoluted?

My understanding is .NET 5 is both. Previously .net framework and .net core were both implementations but also api surfaces. And it's my understanding that .Net 5 will basically "implement" both. So .net standard won't be necessary because if all implementations(.net core + mono) implement all the difference api surfaces then you don't need a "common" api surface.

So there will only be two implementations. Mono and .NET core which will provide all the same api surface as .net framework + .net core(and therefore .net standard).

.NET Standard will probably still be necessary due to the fact that Mono will still continue to exist separately thanks to products which embed it (such as Unity).

This vision structure paints Mono as "merging" into .NET 5 where the MonoVM will be a optional switch with CoreRT and the goal of MonoFX entirely dropped for CoreFX. It also sounds like they want to converge the hosting APIs so that products such as Unity may easily switch between MonoVM and CoreRT. At that point, if Mono is .NET 5 and Core is .NET 5 (embedders like Unity would move to embed to .NET 5), there maybe isn't really a need for .NET Standard.

The first two sentences of the article sum up the announcement and eliminates most of the confusion:

Today, we’re announcing that the next release after .NET Core 3.0 will be .NET 5. This will be the next big release in the .NET family.

There will be just one .NET going forward, and you will be able to use it to target Windows, Linux, macOS, iOS, Android, tvOS, watchOS and WebAssembly and more.

I think Microsoft has been guilty of what you say in the past but this announcement and their product offering going forward could not be more clear.

If they just said ".net framework is being discontinued; .net core will be known as .net", that would help a lot.

It is quite confusing and misleading to say "There will be just one .NET going forward" since this will not affect the .net framework at all - there will still be two incompatible platforms (4.8 and 5/core) for the foreseeable future. They just changed the name of one of them.

I think the problem with MS is they want a simple name change to look like some new unifying strategy. Developers would be much happier if they just cut out the bullshit and made it clear this is just a name change of .net core. The name change in itself is fine.

MS is just FUD'ing themselves with these confusing messages.

>It is quite confusing and misleading to say "There will be just one .NET going forward" since this will not affect the .net framework at all - there will still be two incompatible platforms (4.8 and 5/core) for the foreseeable future. They just changed the name of one of them.

Well, everything will move to 5. And the framework at 4.8 will stop being developed. And 5 ( Core, whatever you want to call it, ) is incompatible with the .Net 4.8.

How misleading is it?

> everything will move to 5

Not likely. Many libraries (like web forms) will probably never be migrated. We will have two incompatible .net's for the foreseeable future. Changing a name does not change that.

That's right; we'll have two incompatible .NETs for the foreseeable future but only one will be getting new features. .NET 5 will unify Core, Standard and Xamarin/Mono.

In what way will this unify .net Standard with Core etc.? Or are you talking about a different standard?

I'm genuinely confused because the illustration shows .net standard as a layer between .net 5 and various platforms. But if that is the case, the platforms will not be able to take advantage of newer features, since .net standard is the API shared with .net 4.8. This does not seem likely.

Yes that's a good question. The situation today with .NET Core vs .NET Standard is: Standard is the common functionality that works in both .NET Framework and .NET Core. Standard continues to overlap more with Framework as those features are added into Core.

After .NET Core 3.0, MS said new features will only be added in Core. And when they reach .NET 5, Standard and Core will be identical, with "Standard" being the library you link to regardless which specific .NET implementation you're running on: desktop, IoT, mobile, etc. I believe the diagram only means that "Standard" covers all of .NET 5, not some subset of Core. And .NET Framework is a separate, maintained legacy library off to the side.

Note, I don't work for Microsoft, this is just my understanding from reading their docs and talking with them about it online and at MS Build.

So ".net Standard" is going to mean two different (incompatible) things in the future?

I don't see how you reached that conclusion. Once .NET 5 arrives, there won't be any more concern with ensuring portability between .NET Core apps and .NET Framework apps by way of targeting .NET Standard.

.NET Standard will be only one thing, if they end up retaining the name at all. It will be the the interface to everything in .NET 5. .NET Framework will just be its own thing maintained only for legacy compatibility. After .NET Core 3.0, new development will not be added to .NET Framework.

I do agree with you that it would be clearer if they only spoke of .NET 5 and .NET 4.8 Framework versions.

> Once .NET 5 arrives, there won't be any more concern with ensuring portability between .NET Core apps and .NET Framework apps by way of targeting .NET Standard.

In the real world there are massive amounts of code in the .net framework. Because of the significant breaking changes between 4.x and core/5 it will take a long time before all this code is ported, and many application will probably never be ported, while still having to be maintained. So for the foreseeable future it is going to be very important whether libraries are 4.x compatible or not.

Consider Python had (IMHO) fewer breaking changes between 2 and 3, but still the migration took about a decade.

> In the real world there are massive amounts of code in the .net framework.

Right, I agree with everything you said here. That's exactly the reason why MS said at the Build conference that they will be supporting .NET Framework "forever". There is a lot of it out there and it will likely remain for a very long time.

When I said there won't be a concern with portability via .NET Standard, I merely meant that the current shifting landscape of Framework features vs Core features vs the intersection known as Standard, will go away. There will be .NET 4.8 in maintenance mode and .NET 5 as the future, growth mode. Maintaining .NET Framework apps hopefully won't be a problem but if you're thinking of building a new app using .NET 4.8, you're likely making a big mistake unless it's to satisfy some immediate need that doesn't work on .NET Core. MS said they're committed to supporting people stuck in that position. Just don't expect new features that will appear in future .NET versions.

> When I said there won't be a concern with portability via .NET Standard, I merely meant that the current shifting landscape of Framework features vs Core features vs the intersection known as Standard, will go away.

I'm really struggling to understand this. Can you explain how you would prepare to port a .net 4.x site to core/5, if the notion of a compatible intersection goes away? How would you even make a library which is compatible with both 4.x and 5?

If you are thinking of porting an old 4.x app but you wait until some time beyond Nov 2020 (https://i.redd.it/f8todfd66uw21.png) then it is in your interest to track the latest .NET Standard along the way. If you haven't been keeping the app up to date, say you're on 4.6.1, and then you decide you like .NET 5 and want to move to it, I think you'll just have to try it and fix whatever breaks.

This is pretty much like every other porting project where you have an old neglected project that you want to bring up to date. Maybe there is an easier way but I don't know what it is. Staying on the legacy .NET Framework isn't the end of the world, you're just committing to maintaining it as is. If you want new features as they become available, well... that's on you, don't wait.

Maybe you move some functionality out of your legacy GUI app to microservices written in .NET 5, parts that are unlikely to have any porting issues. In any case it's not like anyone is going to be surprised by what's going on. Maybe the community will back port some new things to .NET 4.8. MS will be devoting their efforts to enhancing the new platform while keeping the old one on life support. I think that's reasonable. (edit: typos)

Yeah all that is completely obvious. So why not just communicate honestly: This is a massive breaking change. It is going to be painful, but is necessary to moving forward. But don't deny the reality of it.

Saying .net 5 is unifying .net is like saying Python 3 unified Python or that Angular 2 unified Angular.

> If you haven't been keeping the app up to date, say you're on 4.6.1,

Again, why the dishonest arguing? 4.6.1 is years old, but you will have exactly the same problem if you are on 4.8 which was just released. It has nothing to do with code not being updated.

> where you have an old neglected project that you want to bring up to date

Again, this has nothing to do with projects being old and neglected. It is a breaking change, it will affect all projects on .net framework if they want to upgrade. And you know that.

I honestly fail to see what has been dishonest in the communications around this.

The plan for .NET 5 does, in fact, unify .NET Standard, Core and Xamarin. These will no longer be separate things but will go forward under one name.

I'm not sure what you're claiming as the _breaking change_. Can you be specific? It's not, in fact, going to break anything from what I can see. .NET Standard will simply continue to grow larger in .NET Core 3+ until it covers everything. This seems to me to be very different from the Python situation where you are (probably) forced to make code changes to compile with Python 3. If I have some code that compiles with .NET Standard 2.0, are you under the impression that it won't compile with .NET Core 3+ or .NET 5? If so, what leads you to think that?

OK, sorry I called it dishonest, that was out of line since it was assuming bad faith. I just don't think we can pretend .net framework doesn't exist anymore just because the successor is announced.

As I have gathered from talking to former Microsoft developers and evangelists, vNext is generally embraced to mean "the next great version", maybe primarily for developer centric stuff.

Personally, I've been hearing about MS Build vNext and TFS vNext for the last 8 years, and there's been several releases since then. Maybe that's why I kind of associate it with vaporware, even though that's probably unfair.

What would be a great naming schemes for retro fitting an open standard with a new, open implementation for a subset of the existing framework?

It sounds like they're trying to improve this situation in this build by replacing and unifying it all around 5 and give it a clear path forward.

But yeah, it got a little crazy with divergent visions there.

It’s getting silly indeed, it’s also getting unproductive. You have to spend too much time thinking about tooling instead of just building things.

To draw an analogy to Debian, vNext is somewhat similar to Sid. The name is a moving pointer. In a Microsoft context, there is not an unstable connotation like Debian's Sid is.

vNext is a term used across much of the Microsoft ecosystem to denote the current WIP version of a specific technology. SQL Server vNext has pointed variously at what became the 2017 release and currently points at the 2019 release (and will soon point to the next release after that).

Excellent recall--I had almost entirely forgotten about ".NET Passport," one of Microsoft's many premature plays at being an identity provider. This certainly added to confusion at the time about .NET's actual form... something to do with XML, or web services? And an awkward new ORM that will definitely not become well-loathed in near-record time?

I work on Mono and used to maintain a .NET cross compiler and the Core / Standard / Framework terminology still makes no sense to me.

On the bright side unifying products and libraries and stuff will mean it doesn't have to confuse me anymore (:

Given the embracing of other platgforms, and the convergance aspect of one .NET to rule them all. WHy they didn't rebrand it is a mistake they will probably end up doing if they want to pull in dev's on other platforms. Many who's exposure to .NET will be of a legacy flavour and maybe left a sour taste. A taste that will stick with them upon anything .NET.

I'd vote for .ONE, one API to rule them all.

Though convoluted does sell books, I'm sure we will see a title "When is .NET not .NET" soon.

.ONE

Yeah, that's easy to search for!

/end sarcasm

You haven't even mentioned the runtimes, and the target platforms, and the whatever elses.

Reply on news.ycombinator.com