Hacker News Reader

Comment by cm2187 | Hacker News Reader

So in other words Microsoft doesn't think .net standard is a practical approach to prevent the fragmentation of the .net ecosystem and won't use it themselves.

Also it probably means blazor (which runs on mono) won't be able to share libraries with asp.net core...

View on HN

The core issue is that it is too hard to update the full .NET Framework without making breaking changes in this Operating System component. As actually mentioned by David Fowler, if there are missing API that are required in .NET Core, requests for them can be made.

I cannot find the comment from @terrajobst in Github anymore but it states that it is simply not possible to port some of the breaking changes to the .NET framework (because they are breaking changes in the CLR, and maintaining a third CLR version (2.0, 4.0, vnext) is very hard because of a number of shared components used).

edit: It appears some comments have been deleted, luckily we have still mail notifications from Github.

> > Do what you promised: make .NET Framework a stable framework that evolves slower instead of a dead end for the ones who trusted you when migrating to ASP.NET Core.

> That still makes the assumption that .NET Framework will eventually get all features .NET Core has, but with a time delay. We learned that's simply not realistic. We can either decide not to innovate drastically in .NET Core or accept the engineering reality that a good chunk of the new features will never make it back to .NET Framework. We believe that we serve our customers best to preserve .NET Framework's core value prop (a mature & rich development platform) while also allowing customers to exploit new capabilities on .NET Core. Moving forward, I'd expect that we'll be more willing to innovate in areas that require runtime, library, and language changes like we did for Span<T>. While these things are costly, they also allow us to change the way people can write code. A good example of this is default implementations of interfaces, the ability to author generic code involving arithmetic, being able to use hardware intrinsics etc. And those features are likely exactly the kind we're not going to backport to .NET Framework due to risk.

And later on:

> > What prevents you from introducing a new side-by-side .NET Framework version (let's say .NET Framework 5) that includes those "risky" changes? Again, it's not a technical issue.

> What makes you think it's not a technical issue? Shipping side-by-side versions of .NET Framework isn't a workable solution. First of all, it's fairly expensive due to the fact that it's an OS component and thus needs to be serviced. You have no idea how complex our branching/servicing/patching strategy for .NET Framework 3.5 and 4.x is. Adding a 3rd one is close to impractical. Secondly, just doing that also has risks, as we need to make changes to activation in order so select the correct runtime for things like COM activated managed components. And that begs the question of whether or not we support in-proc side-by-side as well and with how many combinations. It's not a simple task and not free of risk either.

> A good example of this is default implementations of interfaces, the ability to author generic code involving arithmetic, being able to use hardware intrinsics etc. And those features are likely exactly the kind we're not going to backport to .NET Framework due to risk.

I suspected that but it's good to see it written. It means not only the target will become independent and incompatible but that also the C# syntax will diverge between Core and Full. That's a death sentence for Full.

I think that writing has been on the wall for a couple years now. .NET Core 3.0 supports WinForms and WPF, as additional death nails for those keeping score.

It's not really clear to me what the difference between .NET Core 3 and a '.NET Framework 5' would be.

For users, having to install .NET Core 3 runtime (if the app doesn't ship it internally) doesn't seem like a different thing than having to install .NET Framework 4.x when it first came out.

It wouldn't be surprising if future versions of Windows started shipping with .NET Core pre-installed.

Why is .NET Core so different from this perspective?

The full framework is part of Windows, and contains shared components such as COM activation, and is also part of IIS when applicable etc.

> It wouldn't be surprising if future versions of Windows started shipping with .NET Core pre-installed.

The UWP .NET stack seems close enough to .NET Core (esp. when using .NET Native) to posit that this is already the case. (Though there are still subtle differences between UWP .NET and .NET Core, they seem very close to converging.)

The .NET Core runtime (for a specific platform) can be bundled with the application so the user doesn't need to install it, and every application can ship with the exact version it prefers.

This wasn't possible with the .NET Framework, it needed a global install and, from 4.0, it upgraded in-place only.

Exactly, to ensure critical vulnerabilities do not get patched in your app when one patches the machine! One would have thought Microsoft would have learned from the experience of java...

In .NET Core you have the option. You can do a standalone deploy or depend on the system wide installed version of .NET Core. In the latter case it is an sysadmin issue.

Are there solid reasons why blazor cannot move to .NET Core? I know they require an ultra slimmed down runtime, but maybe there's ways to achieve that which could be upstreamed.

It is a simple matter of programming!

I suppose Blazer would eventually move to CoreRT when it is ready.

Depends on what your definition of "solid" is. Since most of the shiny new stuff is coming out on .NET Core first (think Span<'T>), it means that if a project is targeting .NET Standard (a set of APIs that can run on .NET Framework or .NET Core) it has to wait until that new stuff is ported to the other frameworks and a new version of .NET Standard is released.

> most of the shiny new stuff is coming out on .NET Core first

I hadn't fully appreciated prior to this post that .NET Core has things that aren't in .NET Framework, let alone .NET Standard. I thought it was a portable subset (a core, if you will) of the full .NET languages and APIs. I don't know whether that makes me more interested in Core, but I'm certainly less inclined to target any other flavor.

ha, Yes it often seems that MS is intentionally trying to confuse developers with their naming. I truly do not understand it.

Then again, two hard problems in CS, etc. etc.

Core is one of those Microsoft branding words that wound up used everywhere, denotes one thing, but means almost something else entirely. (Not unlike the .NET brand itself in its early years.) In the developer side Core has meant "open source rewrites that can break backward compatibility to move forward".

(Windows has also had several Core-branded things, at least as internal brands that have externally leaked over the last few years or been used to describe Windows Insider initiatives, but there they seem to more actually mean "core" as denoted as pure subset, though it sounds often in those cases they did imply nearly-from-scratch rewrites like the Developer initiatives with that branding.)

Well, .Net Core started as a subset of .Net Framework APIs. Now that they're adding a lot of them back with .Net Core 2.0 and 3.0, it's no longer accurate.

Though ASP.NET Core was never really a subset of ASP.NET.

.NET Core was never a pure subset of .NET Framework API: it broke compatibility in some places, and it had new features/capabilities in others, leaving the full .NET Framework to catch up on those. (There's an interesting overview of some of that in the histories of the .NET Standard versions < 2, when it sometimes felt unsure if the Full .NET Framework would be .NET Standard compatible, because .NET Core had the wheel on .NET Standard.)

Span<T> only requires .NET Standard 1.0, so it came out for Core and Framework at the same time [1].

.NET Framework only has the portable implementation though. The fast implementation requires support in the runtime, and Framework may never support fast Span<T> [2].

[1] https://www.nuget.org/packages/System.Memory/4.4.0-preview1-... [2] https://github.com/dotnet/coreclr/issues/18280#issuecomment-...

Did not know that, thank you!

Also, .Net Framework still doesn't have support for Span<T> on existing types like Stream. Though those APIs will be in .Net Standard 2.1, so presumably they will be in some future version of .Net Framework too.

Isn't Blazor is becoming part of ASP.NET with .NET core 3.0?

Reply on news.ycombinator.com