.NET Standard 2.1 | Hacker News Reader

.NET Standard 2.1

blogs.msdn.microsoft.com

149 pointsbenaadams122 comments

I think they prepare already a while the shift to .NET Core as the primary .NET platform (also on Windows).

- .NET Core will soon run all three UI technologies of modern Windows UWP, WinForms and WPF (.NET Core 3). - The Windows Compatability Pack for .NET Core shifted some popular .NET Framework libraries to .NET Core (some only on Windows).

There are one thing, Microsoft is really bad with: Telling the world that something is deprecated. There is a set of technologies in the .NET Framework which have no future: AppDomains, WCF, Code Access Security, Workflow Foundation, Cardspace, ... (just to name a few). They are all already dead for some years, but no one tells. They are supported in the .NET Framework but no progress happens. And .NET Core will never see them.

> Microsoft is really bad with: Telling the world that something is deprecated. There is a set of technologies in the .NET Framework which have no future: AppDomains, WCF, Code Access Security, Workflow Foundation, Cardspace, ... (just to name a few).

There's no reason to deprecate a mature product if there's need for it, it has sufficient test coverage, and there's low/no maintenance. There is however a risk involved with deprecating them that users will migrate to another technology stack entirely.

WCF is one of those technologies that was deployed heavily in Enterprise and is deeply ingrained in applications and systems going on a decade old. WFC has better support for SOAP than anything I've seen in the open source world and with a minor configuration tweak it can simultaneously support JSON from the same endpoint.

Workflow Foundation is in a similar state to WCF, though I wouldn't shed a tear if it vanished off the face of the planet.

I agree. With everything. However, a not evolving platform is a dead platform. New code should not target this platform. Even for Enterprise environments it not a joy to see the world evolve while you are stuck with a toolset a decade old. It is already now painful to see the difference in tooling between Core and Framework.

I agree. Don't deprecate just to clean house. Only deprecate when you have a mature / table replacement.

We live in a world where Cobol mainframes are still around and in use. Microsoft can not depreciate ten year old technologies when the vast majority of their clientele in this sector are enterprises.

Oh it will be supported. But it will be a dead platform like Cobol where no one wants to put new code to. With a bit of luck they will continue to support the latest C# for a while.

A lack of new features does not mean something is deprecated. That would mean actively discouraging its use, something that doesn't make sense given the sheer amount of code written and the fact that support will continue for years, if not decades.

https://docs.microsoft.com/en-us/dotnet/core/porting/librari...

Code Access Security and Security Transparency aren't supported on .NET Framework either

Suggested naming standard:

- .Net API Specification - (now known as .Net Standard)

- .Net Windows - (now known as .Net Framework)

- .Net Cross Platform - (now known as .Net Core)

I don't think Microsoft is going to rename .NET Framework, that would already break too much for too little benefit. .NET Core would simply not be renamed because it is too well known.

Regarding ".NET Standard", I agree, it is an API specification but to prevent confusion you should think (for now) of it as "The .NET Standard [API set]".

You're right of course, but it's a crying shame that it's so unobvious what things are.

.NET XP sounds better for .Net Core :)

For Windows XP?

Since nobody uses Windows XP anymore that should not be so confusing.

There’s already universal windows platform, which is basically windows 10 only.

UWP is built from .NET Core

Universal windows platform also runs on Xbox One and certain mixed-reality headsets. It's not just for Windows 10.

Knowing the differences here is pretty serious for my day-to-day work. Does anyone have a guide/breakdown/etc that I can refer to that explains all of the versions of .NET? The documentation from Microsoft itself is atrocious.

Does it exist somewhere?

Not a breakdown, but here goes.

https://docs.microsoft.com/en-us/dotnet/framework/whats-new/

Only goes down to 4.5, as older versions are already EOL.

The archived MSDN docs do have the older versions in case you are interested.

Which runtimes implement which versions of .NET Standard:

https://docs.microsoft.com/en-us/dotnet/standard/net-standar...

I think .NET Standard is quite right. It is a" standard". And standards rarely have implementations on their own.

> Given many of the API additions in .NET Standard 2.1 require runtime changes in order to be meaningful, .NET Framework 4.8 will remain on .NET Standard 2.0 rather than implement .NET Standard 2.1. .NET Core 3.0 as well as upcoming versions of Xamarin, Mono, and Unity will be updated to implement .NET Standard 2.1.

At some point, is it reasonable to expect Xamarin, Mono, Unity, and .NET Core to all really be backed by .NET Core? And if/when so, is there any difference between .NET Standard and .NET Core since, after .NET Framework has been essentially maintenance-mode'd, there will be only one .NET Standard implementation? Similar question, besides just having multiple implementations, what benefit is there to having both Mono and .NET Core separate (at least for the .NET Standard impl part)?

.net standard and .net core and two separate things. the former is an api/library specification and the latter is an implementation of that specification. mono and .net framework are also implementations.

https://docs.microsoft.com/en-us/dotnet/standard/net-standar...

https://msdn.microsoft.com/en-us/magazine/mt842506.aspx

I understand that, but I am asking if the implementation ends up becoming the only implementation of a specification, is there a meaningful difference between the two? I would expect Mono to use more of .NET Core (or if not, curious why not hence my last question), and .NET framework is no longer an implementation of current and future .NET standard specifications (hence the part I quoted).

oh, i see what you mean now. from my understanding, .net core 3.0 will start to make .net core the primary choice of development for new projects on windows since it will include the uwp, wpf, and winforms desktop packs. but if you still need cross-platform ui and graphics, mono is still the only choice. so it does seem that microsoft is converging on trying to "get rid of", so to speak, .net framework and mono, but it seems there's still a ways to go. even a newish project in the wilderness labs meadow board used mono and not .net core for their project. i am sure it's because they started a while ago and there were technical reasons. .net core lacked features mono had for a while (and maybe still does, not for sure of the current status). moving existing projects like it, unity, and xamarin from mono to .net core is probably a huge undertaking.

in terms of naming, i think it makes sense to keep the distinction between .net standard and .net core, even if .net core slowly heads towards becoming the de facto implementation. i doubt .net framework and mono ever really go away anyway, so the distinction is still needed.

Mono and .NET Core will never merge. But it is not a black and white thingy.

.NET Core has a sub project named corefx (Base Class Library), which acts as a master for most of the class library of Mono nowadays. However, the runtime below (mono or coreclr for .NET) are different animals. Mono is highly optimized on portable code (it runs in many more places than .NET Core) while .NET Core is tuned for performance.

Unity is based on Mono but also has yet another different runtime (it basically compiles the code first in C++ and then with C++ backends to the target architecture). Expect here the same as for Mono. It is specialized and will stay specialized.

That makes sense with regards to the runtimes and non-spec'd libs. But I was under the impression .NET Standard was essentially the class library spec and if .NET Core is/becomes the only impl of that class library spec it would seem strange to separate the spec from the impl when only one of each exists built by the same blessed implementer. I can definitely understand different compilers, AOT/JIT engines, GCs, etc. Even with minor .NET Standard impl differences in Mono, if they are so minor that they only augment .NET Core, it comes off as an optimization rather than a separate implementation. If the class library impl differences remain major, I would wonder why as surely, even when optimizing for portability vs performance, there is a lot of potential reuse.

Consider e.g. the cryptography support in the .NET Standard. On Linux it is based on OpenSSL (AFAIR), on Windows based on the crypto library there, on MacOS on another one, on Android another one and let us not speak of iOS. All of them follow on the surface the same API spec. But behind the scenes all .NET implementations have different strategies to deal with. And for good reasons.

In this cases you need a standard but not a shared implementation.

I don't think deferring by platform preference is enough of a reason to separate the standard from the abstracting implementation. Most languages, with or without a "standard" and multiple implementations, defer to the platforms' preferred ways of, say, obtaining cryptographically random numbers.

Everytime I start to think Microsoft is heading in the right direction they go and blow it all away again.

This week we've already had a new asp.net core which drops support for .net standard and only supports .net core.

And now, a new version of .net standard that .net fx isn't going to support.

We are right back at the mess of portable class libraries with all their different supported profiles.

It means app devs are constantly dealing with problems like "is this library I want to use, supported by all the targets my app needs to run on", and library devs have a mess of different frameworks and combinations to support, so inevitability drop a few of them unless they are a big project with lots of manpower.

I need to highlight, that ASP.NET Core never run on .NET Standard. Some parts always have been dual-compiled for netcoreapp2.0 and net46(?).

Ah, my mistake, I didn't know that. Kind of actually enforces my point of the ecosystem being a mess though and the only realistic thing to do is compile for multiple targets.

I believe that ASP.NET Core should be able to move to .NET Standard 2.1 (Span<T> is the big reason they decided they needed to drop .NET Framework support). They dropped .NET Framework, but there's still a case that they can support .NET Standard here, for what that is worth.

Regards Portable Profile: I think the case is different. .NET Framework will just no longer evolve. It will always stay on .NET Standard 2.0.

.NET Standard is not a intersection. It is a small bubble being in a bigger bubble. And the biggest bubble is the latest. The reason Miguel and the Unity folks are so important in this process, is the fact that they have to agree to participate in the latest and biggest version of the Standard.

Exactly. The fact that the .net framework will not implement .net standard mean the latter lost immediately most of its raison d'être.

Let me just check if I finally understand this:

- .Net Framework: The Windows Specific (and nearly deprecated) branch

- .Net Core: The replacement for Framework and cross platform branch (but with Windows specific libraries)

- .Net Standard: A way to write something that runs on both .Net Framework and Core?

To clarify: My understanding is that .NET Standard is a specification for a set of .NET APIs that all implementations support, rather than a concrete library or something like that. So if you target .NET Standard with your application, it should be able to run on any .NET implementation. Otherwise, yes, that sounds correct.

It is just an API set you target. You should see it as NodeJS vs Web Browser. They both support a common API set defined in ECMAScript 6 (for instance) which contains Date, Intl.DateFormat, Symbol.iterator, etc.

Note that executables cannot be compiled to .NET Standard, because they are self-bootstrapping so they must target one or the other (or both).

that was the primary purpose before, but since .NET Framework will no longer be implementing new .NET Standard versions, it's now more like a way to write something that runs on both .NET Core and on Xamarin platforms

> that was the primary purpose before, but since .NET Framework will no longer be implementing new .NET Standard versions

.NET Framework 4.8 won't implement .NET Standard 2.1 doesn't mean .NET Framework won't implement new .NET Standard versions.

.NET Framework has been announced previously to be slower-movinh and lower-risk than Core, so it's not surprising that it will take longer for it to support new versions of .NET Standard. That the next Framework release won't incorporate the newest Standard doesn't mean Framework won't advance it's Standard support going forward.

> This means that .NET Core will get new APIs and language features over time that .NET Framework cannot. At Build we showed a demo how the file APIs are faster on .NET Core. If we put those same changes into .NET Framework we could break existing applications, and we don’t want to do that.

The "slower" explanation doesn't really fit with that sentence to me... if Standard 2.1 already has things that Framework "cannot" have, then it seems like "stopped" is more accurate than "slower." I guess technically they only are saying that Core gets things Framework can't, not necessarily the standard, but I'm not sure that's much of a distinction in practice.

Of course it doesn't have to mean that Framework is just frozen but it would seem to make the Standard a bit of a dead letter (I'm not really familiar with how useful it is in terms of Xamarin/Mono/Unity).

Microsoft here sounds extremely hesitant to ever do the ".NET Framework 5.0" release that would break the .NET Framework world necessary to push a new CLR Runtime out. .NET Framework 3.x and .NET 4.x have all still been using the CLR 2.0 (for the most part), and the risk at upgrading the CLR is far greater than the .NET Framework 1.0 to .NET Framework 2.0 era. (Certainly the "reward" of the new mostly performance-oriented features in .NET Standard 2.1 doesn't seem worth it at first glance, not compared to the CLR 2.0 upgrade for generics.)

> Microsoft here sounds extremely hesitant to ever do the ".NET Framework 5.0" release that would break the .NET Framework world necessary to push a new CLR Runtime out.

Yeah, I think the question is "will Framework be the slow moving, but 'living' component you target for long-term, but perhaps not eternal, stability on Windows platforms or will it be a legacy component that Windows is burdened with only for backward compatibility with older apps".

I think Microsoft has sent signals out which point in each of those directions, but not yet converged clearly on one or the other.

Yeah, I think Microsoft has changed its mind a couple times too many. With .NET Core's original announcement it sounded like .NET Framework was legacy and in mostly maintenance mode. With .NET Standard < 2.0 it seemed clear that .NET Core might move way too fast for .NET Framework to catch up, but maybe it was possible for it to catch up eventually, though there was some question there because there were some APIs it wasn't clear if .NET Framework would adopt at all for a bit there. I think .NET Standard 2.0 gave some at Microsoft a calm sense of ".NET Framework can keep up surely" as .NET Core paused to catch up with Mono/Xamarin's API footprints, but .NET Standard 2.1 here seems to make it clear that Microsoft realized again it can't keep up with .NET Framework. Definitely not in the short term, and probably not ever.

It would be great if they better articulated that "probably not ever", but I can't blame them for not doing that when we all know that a bunch of enterprise devs and HN/Reddit/Slashdot randoms would be out in force with pitchforks and torches if they did.

they have done it; it’s called “.NET Core”.

I feel that way, too, but I understand some of the reasons people still want to see a ".NET Framework 5.x".

.NET Framework is not anywhere close to deprecated, AFAIK...

I guess it is a matter of perspective and your definition of the word "deprecated". This is the definition I use (from Wikipedia):

> In several fields, deprecation is the discouragement of use of some [..] feature

Microsoft are currently telling people for new projects only use .Net Framework if you have a specific requirement, otherwise use .Net Core. .Net Core is therefore the default choice.

That to me is discouragement which starts to put .Net Framework into the realm of depreciated. Is it deprecated yet? It is not, but it is definitely going in that general direction and you can see it on the distant horizon.

There is still just a lot of stuff you can't do on Core alone. It's fine, I guess, if you are doing fairly vanilla web server development, although the last time I tried it was not the easiest to run .NET Core on Azure. Probably the story is better there now than it was.

Microsoft also has the entire silent iceberg of enterprise development that is going to be slogging along with .Net framework applications for years and years. Billions of lines of code that work as is, and just are not going to be invested in to update them.

The .NET Standard 2.0 push moved a vast amount of code to being compatible on .NET Core alone. The "desktop app packs" for .NET Core 3.0 to run WinForms and WPF closes the gap a lot further.

(.NET Core on Azure seems pretty easy to me. Even from early beta days of .NET Core, but there are certainly even more Azure tools for it today than then, including some really good .NET Core on Docker support from what I hear.)

Yes, enterprises will always be slogging along with ancient solutions so long as "if it isn't broke, don't fix it" aligns with the bottom line. Arguably that seems exactly why .NET Framework might not support .NET Standard 2.1+, because Microsoft doesn't want to accidentally break ancient enterprises if they can avoid it.

.NET Framework isn't depreciated in the same sense that Mozilla Suite wasn't depreciated while Phoenix/Firebird/Firefox was being developed. .NET Framework is, at best, on the equivalent of an LTS branch. You'll get bug fixes, but few, if any, new features. Microsoft is clearly making .NET Core the premier framework going forward and .NET Framework is expected to die.

If you ask Microsoft, they'll currently tell you otherwise, but that's because that's a bad idea from a marketing perspective. You don't let your customers know you're going to end of life your product that they used for 15 years until you have absolutely no other choice.

I would not call .NET Core having "Windows specific libraries". It is more like they have feature packages on-top, which are Windows specific.

Feature packages that contain Windows specific libraries? I guess I don't see the distinction you're trying to make.

Yes that's about right.

Standard = an API set. If you know OO in C# or Java this is effectively analogous to an interface.

It's the smallest common denominator of various implementations.

.NET Core = the new implementation

.NET Framework = the old implementation

It's a pity 2.1 will not be implemented by netfx 4.8. I wonder if there will ever be E netfx with netstandard 2.1.

Sadly things are not looking good for standardization - on one hand we have new netstandard without netfx and on the other aspnet.core without netstandard (https://github.com/aspnet/AspNetCore/issues/3753).

I think it's more a pity that .net core 3.x still can't run ALL the things.

i.e. if .net core would run anything that could've run on .net framework/mono whatever by just retargeting to .net core 3.x and even dlls from .net 4.7 could be run on core 3.x than nobody would complain and people would love it since, it would reduce the pain of that many runtimes.

This is basically where they're headed. .NET Core can now be used for UWP stuff, for instance. It seems to me that they're trying to prevent a situation where people write a bunch of Windows-specific Core code though.

well the problem is that they only add some stuff. currently a lot of problems are because of "legacy" web apps, that need to integrate with new ones. i.e. webforms, mvc4, etc...

The interesting thing to note is that the core runtime in netfx hasn't changed in a long while (.NET Framework 3.x and .NET Framework 4.x are still essentially CLR 2), and it sounds like after what Microsoft learned from the CLR 1 -> CLR 2 (.NET 1.0 -> .NET 2.0) update they never want to do that again if they can avoid it. CLR 1 to CLR 2 had a very good reason to do that (generics); .NET Standard 2.1 has a lot of little reasons, but no good, big reason to break the .NET Framework world with a runtime upgrade.

(Also, it looks like ASP.NET Core still should be considered .NET Standard 2.1 compatible, but yes the "upgrade" to .NET Standard 2.1 is fascinating because it loses compatibility with netfx.)

ASP.NET Core is not .NET Standard based. Most of its libraries are, but the core runtime is bound to a platform like .NET Core (and earlier the .NET Framework). It was never running on a pure .NET Standard interface.

One of the biggest reasons for that seems to be Span<T>, so it seems possible that ASP.NET Core can move toward .NET Standard 2.1, since it includes Span<T>. Certainly it isn't guaranteed, but it seems plausible. (Not that it would help much in the case that .NET Framework doesn't seem to be capable of .NET Standard 2.1.)

> (.NET Framework 3.x and .NET Framework 4.x are still essentially CLR 2)

Not quite. There is a grand total of three different major versions of the VM on Windows:

CLR 1.0 - used by .NET Framework 1.0 and 1.1 CLR 2.0 - used by .NET Framework 2.0, 3.0 and 3.5 CLR 4.0 - used by .NET Framework 4+

These can all be installed side-by-side, and any particular .NET application is bound to a particular CLR version.

The differences between 4.0 and 2.0 are far more minor than the ones between 2.0 and 1.0. 2.0 added a bunch of changes visible on IL level - most notably, generics, and all the new IL opcodes and metadata to support them. 4.0 was mostly internal improvements - better JIT, GC etc. But there were also some new features, like NoPIA and "uncatchable" exception types (StackOverflowException etc), and a new CLR hosting API that allowed it to be hosted side-by-side with old frameworks in a native app.

I think it is fair to say, that we need to realize, that .NET Core runs on all of the platforms which in Microsoft view have future (.NET Core, Xamarin, Unity and UWP). The only platform no one is really interested (from Microsoft perspective) is the .NET Framework.

The .NET Framework is, from Microsoft .NET and WIndows Team perspective, a legacy burden which is unable to innovate, change or improve due to the deployment methodology. It is a dead end.

I know, it sucks. I am an enterprise developer and understand the consequences. I hate it as well, but I can completely follow their rationale. They make it possible for us to develop WPF and WinForms on .NET Core which is their strategy to compensate the blow they give us.

The problem is see is not being able to go to .NET Core because of third party dependencies.

And we still have lots of them that until now haven't cared much about .NET Core.

They will start caring now, or will be replaced by ones that do.

I wish, some of them are the only animal that matters on their domain.

Unlikely. [0]

> > Are there plans to support .NET Standard 2.1 in a future version of .NET Framework, or will 2.1 and beyond be .NET Core only?

> Never say never, but given that .NET Standard is accumulative, I don't think it's very likely as the risk argument that applies to .NET Standard 2.1 will always apply to future versions too. And a side-by-side release of .NET Framework is extremely unlikley.

[0]: https://twitter.com/terrajobst/status/1059517534049726464

So they added Span<T> as a big thing ...

> (Span<T> is) at the heart of most performance-related improvements in .NET Core 2.1. Since it allows managing buffers in a more efficient way, it can help in reducing allocations and copying. We consider Span to be a very fundamental type as it requires runtime and compiler support in order to be fully leveraged.

Small struct that is declared as

    public readonly ref struct Span<T> 
    { 
      private readonly ref T _pointer; 
      private readonly int _length; 
      ... 
    }

which is exactly what I am using in Sciter (https://sciter.com) for 10+ years:

    template <typename T> 
      struct slice { 
        const T* start; 
        unsigned int length; 
        ... 
      }

https://github.com/c-smile/sciter-sdk/blob/master/include/au...

Such small thing definitely speed ups many areas and surprisingly quite a lot, parsing in particular.

Nothing new under the Sun, eh?

Does your template work with memory managed by a GC and provide all the memory safety guarantees that .NET does? If so, does it work seamlessly across the stack & the heap for both managed memory and unmanaged memory at the same time?

I get it, similar concepts - but let's not dismiss the value in this addition.

No, this is pure C++ (non-managed) thing.

It is used strictly in read-only places. It makes absolutely no sense to use things like std::string (and allocate it each time) when you need to pass string or fragment of string or array to consumers.

For write-only access I also have target<T> that safely wraps all memcpy, memmove, strcpy[_s] cases.

I didn’t read the poster as dismissing it (or claiming to have outright invented the concept) - rather pointing out that good implementations naturally keep re-arising.

Yeah, this concept is quite old.

It reincarnated quite many times: in D language by Walter Bright where arrays are just such slices. Or by Andrei Alexandrescu in its range<T> thing: http://www.informit.com/articles/article.aspx?p=1407357&seqN...

Any special reason why they put the length after the pointer? Or is it just a coincidence?

Question is not clear.

The Slice is just an address of memory chunk combined with the length of that chunk. That's somehow better than "C strings" - that are just pointers and so you need to do some computation if you need to get length of the string. Such C strings have too many drawbacks - in particular strtok function that modifies input string (that shall be read only all times).

Well, both implementations do have a strict which has the length as last member. Is there any special reason for it? Something like struct-layout optimization?

You can re-interpret the struct to a pointer (length would simply be truncated). Apart from that there wouldn't be any benefit: the pointer and length would be aligned no matter which position they take (on x86 and amd64 at the very least).

"re-interpret the struct to a pointer (length would simply be truncated)."

Wrong. It will be pointer-to-pointer.

Reinterpretation (to treat struct as a pointer to C string) is only possible if you have something like this:

    struct BSTR {
      size_t length;
      WCHAR  chars[N]; // N is length + 1     
    };

and you return pointer to chars[0]. This is so called Basic string - BSTR is a WCHAR* pointer to memory location prepended by string length field.

That's not what I was going after. You can treat the memory location (where the structure resides) as a pointer, plan and simple, nothing more fancy than what I said.

I don't think so. My guess would be that it is because a pointer to the struct can be cast to a pointer to T. I /think/ that is defined behaviour.

It is: https://port70.net/~nsz/c/c99/n1256.html#6.7.2.1p13

Well, to be fair Modula-3 and Eiffel did it first.

And I bet Sciter is younger than any of them.

Would you mind to provide some link that illustrates what you mean exactly?

Basic examples, a big late to go diving into old documentation.

Modula-3 version:

    GENERIC MODULE Slices(T)

    TYPE
      Slice = RECORD
         start : REF T;  (* If you want the GC out of the way, replace with UNTRACED REF T*)
         length: CARDINAL;
         ...
      END;

    END Slices;

Or one could simply use open arrays:

    TYPE
        Slice = ARRAY OF T

Eiffel version:

    expanded class Slice[T]
       start: detachable T;
       length: INTEGER_32;
       ...
    end

Naturally, one would use Array[T].slice() instead.

http://smarteiffel.loria.fr/libraries/api/lib.d/storage.d/lo...

Yeah, thanks a lot. That is really it. Same as in D lang. In fact D's array is just a slice. At least it used to be so 10 years ago. GC there does the rest - as in Modula-3.

Small struct that is declared as

        public readonly ref struct Span<T> 
        { 
          private readonly ref T _pointer; 
          private readonly int _length; 
          ... 
        }

But the important parts are not _pointer or _length. Most of the implementation effort went into the `ref struct` part, which was released at the same time as Span<T> and is precisely what makes Span<T> powerful. It is a big thing.

I thought the Java framework nomenclature was bad, but .Net is way more confusing.

I was thinking about this... but I'm not so sure :)

JRE, JDK, Java EE, Java SE, Beans, Enterprise Beans, Managed Beans, JEE APIs vs Implementations etc, containers, app containers, app servers.

'Enterprise' has to be the worst prefix/name ever for an API or technology.

It is a tough contest.

Anybody got any updates on the state of Mono/.NET Core convergence?

I actually don't care very much if they're actually the same code base, but I'd like to be able to use the dotnet CLI for everything. Xamarin project templates in the new SDK format are also on my wishlist.

Are .NET Core and Mono converging? I would have thought that they'd remain separate while both implementing .NET Standard, and becoming interchangeable as .NET Standard implementations.

At least some convergence is happening: https://www.mono-project.com/news/2016/11/29/mono-code-shari...

And here's a more recent update: https://www.mono-project.com/docs/about-mono/releases/5.0.0/...

Also, this article on .NET Standard 2.1 mentions that for new features to be considered for future .NET Standard APIs they expect them to be MIT-compatibly licensed in at least one .NET Standard implementation with option for the other implementations to just use it outright, which indicates convergence as a policy goal.

I think Microsoft is missing a trick by at least making some of MVC5 target .NET standard. It would make it a lot easier to port apps over. Moving from asp.net to asp.net core is a big pain in the arse.

It seems like the kind of thing that should be possible - after all, Mono has had System.Web for a long time, and can run both MVC and Web Forms apps. I don't know anyone who has actually done so in production, though.

But although it's possible, I imagine there are lots of reasons why MS, or certain teams at MS, don't want it to happen. We'll see, though. I didn't expect them to make the decision to add WPF and WinForms support to .NET Core, but they did.

I do mainly desktop dev but reading that Core is now the platform with rapid improvements I wonder if it's possible to write WPF or UWP apps with .NET Core or Standard.

Does anyone know?

This is coming in .NET Core 3. Slated for Q1 2019 AFAIK. https://blogs.msdn.microsoft.com/dotnet/2018/05/07/net-core-...

Very good. For a moment I was worried that desktop development would stay on Framework which from the article seems to slowly being pushed into maintenance mode.

If WPF is coming in .NET Core, does this mean we are going to be able to run WPF apps on Linux and Mac?

I highly doubt it. As far as I know WPF is way too entangled with Windows.

But isn't .Net Core meant to be cross-platform?

It is. The WPF library is just a separate package that includes a lot of Windows API calls to allow .NET Core to talk to WPF.

In general, yes, but a lot of its cross-platform capabilities are community-contributed/community-led, there are still some APIs that don't have cross-platform implementations (because it hasn't been a community priority), but also there are APIs that simply can't work on any platform but Windows (obvious things like Registry access, for instance) and will either no-op or throw clear exceptions on other platforms.

The "desktop app packs" for WPF and WinForms Microsoft has made very clear that they will not support anything other than Windows. (They also won't directly be a part of .NET Core according to diagrams, but packages installed on top of it.) It's also unclear if they can be open sourced (they probably cannot be), and if they can't be open sourced it is unlikely a community-led effort could easily work on making them cross-platform.

> The "desktop app packs" for WPF and WinForms

WinForms work quite nice on Linux with Mono. Won't they cooperate?

I think Mono Winforms is a total rewrite of the Windows Winforms. There is no shared code.

Sure it is but why not use that code to let .Net Core support WinForms on Linux the way it is going to support it on Windows?

I think you have that a little backwards. This is not up to the Core developers but to the Mono developers. There is nothing preventing the Mono developers from supporting .Net Core.

Aren't these the .Net Core developers who sort of import (or re-implement?) WinForms support from the classic .Net Framework on Windows?

It's shared with WINE I believe. (The native parts)

Wine uses its own Mono instance and I usually run WinForms apps directly with the system Mono set-up without using Wine (although I have both installed).

They might not port Mono's WinForms to .NET Core? Given how strictly tied to Windows WinForms is, they may not want to give enterprises they are encouraging to use .NET Core any confusion on the subject. Taking that extra step of trying to run the application on Mono shows at least some awareness of possible compatibility issues in the software.

That said, this may still be a great opportunity for .NET Core to encourage trying Mono in its documentation for enterprises looking for cross-platform support. (Hopefully they already knew about Mono by this point, but an extra push won't hurt.

Nope, it will be a windows only capability.

-Edit-

I should add that the purpose of them adding this capability isn't to set up a new cross-platform UI suite. It is just to lure enterprise shops to .NET core by supporting more of their .NET Framework workloads

I'm still wondering whether it would be smart for them to port WPF or UWP to all platforms. They are already decoupling their services from Windows and a UI library would be quite a flagship for them.

Then again they'd also lose the Windows vendor lock-in, which might still be more valuable to them.

Then again they could sell their development toolchain and gain developer sympathy.

Well, I think it is an engineering problem. WPF is basically cemented to DirectX which only exists on Windows.

There will be a desktop pack that extends Core with windows desktop application technologies. Bear in mind these are really .NET API wrappers round the underlying Windows systems, so since those underlying libraries and such don’t exist on Mac or Linux .NET APIs won’t have anything to provide access to.

Think if it this way. Someone could write a .NET Core wrapper round the MacOS GUI libraries and platform APIs, but you couldn’t run that on Windows.

Not WPF per se, but if you're looking for something similar check out https://github.com/AvaloniaUI/Avalonia

Xamarin Forms also has WPF, OSX, and GTK renderers, so it might be an option. Based on GitHub activity it looks like they're being worked on fairly actively, too.

You can also use QML with .NET Core.

https://github.com/qmlnet/qmlnet

It is stable, I'm currently using it in production (https://medxchange.com/4klear-all-in-one-camera-recorder/)

PS: I'm the author.

I thought we already have .NET 4. I don't understand.

.Net framework is upto 4.7 .net standard is now 2.1 .net core is 2.1

Thank for clarifying all the "synonyms" associated with .NET. I did not know there were three different things: framework, core and standard.

Are there others I am missing?

Mono (5.0) and Xamarin (4.5) implement .NET Standard 2.0.

".NET Standard" is the specification that defines the available features. .NET Framework 4.7 (windows) and .NET Core 2.1 (cross-platform) both implement .NET Standard 2.0, meaning they have a shared feature set.

i really wish they would say "the .net standard" rather than just ".net standard". missing that prefixed article is confusing for someone not in the ecosystem (or me at least).

even better would be "specification" rather than "standard", the later being a word frequently used to indicate a particular version of some thing.

Totally fair. The original name was ".NET Standard Library" but we were too lazy so we shortened it to just ".NET Standard", which then ended up becoming the product name.

Reply on news.ycombinator.com