7 ms·

I got the idea of what .NET standar is, the confusing part is the versioning, they have version of .NET standar, version of .NET Framework, version for Mono, ve

I got the idea of what .NET standar is, the confusing part is the versioning, they have version of .NET standar, version of .NET Framework, version for Mono, version for .NET Core, version for the tooling, version for the libraries in project.json (now extint) etc, and all with different release schedules, that is the most confusing part and I stil not getting it.

mindingdata 10y ago
Well yes because .net standard is simply the specification, and .net framework, mono, core etc are the implementations. Think about it in a web sense. We have ECMAScript which is slowly being added to. ECMAScript is the specification and it has it's own version. Then we have browsers that "implement" that specification and they also have their own version numbers because they aren't ONLY building something to handle ECMAScript, they are building other features on top of that. So in terms of .Net Core vs Mono for example, while they both may implement the .net standard, they can also have their own features unique only to one. It's not a straight implementation with nothing else added. Now say you are building a website and you want to target all "modern" browsers. It doesn't matter what version of ECMAScript is up to, it matters what each browser has so far implemented. If you are building a library for .net, then you can say "OK, I implement this standard. That means Mono Version X and .net Core version Y can be used". Similar to how you would say "You need Firefox version X or Chrome verson Y to use this feature".
nathanaldensr 10y ago
It's a cluster. The way Microsoft rolled out .NET Core and all these related technologies did nothing but confuse everyone, even seasoned .NET developers and architects such as myself. The name changes, horrible Visual Studio tooling, version numbers with seemingly no rhyme or reason...it's been a nightmare. They are finally clearing things up with .NET Standard 2.0, which is like the One Standard to Rule Them All. I consider .NET Standard 2.0 and its related implementations, along with Visual Studio 2017, to be the first real production-ready set of standards, tooling, and frameworks. It's what .NET Core should've been from the very beginning.
- anton_gogolev 10y ago
  Just wait until it gets renamed to something like .NET Foundation 1.0 (comprising ASP.NET Foundation 1.0 and .NET Foundation Runtime 1.2 because reasons) aaand we're back to square one.
- pllbnk 10y ago
  I often wonder why did they decide to introduce such complexity with all independently developed runtimes with unrelated versions and all if they went fully open source. This problem that they have solved in their own unique way has been solved before countless times. Python is a great example, since you have your standard library with some rather carefully selected OS-specific APIs and then you got a bunch of runtimes all under the same version; no confusion whatsoever. Now we have so many different versions to follow that I am really worried it will be impossible to keep any level of uniformity and compatibility between them. There are .NET Standard, Canadian, .NET Core, Mono, .NET Framework with .NET Standard's compatibility shim and .NET Core tooling. I hope I didn't forget anything else. It's already crazy as it is. I am a long time .NET developer and I also was confused in the beginning of .NET Core about what was going on and I think their rush to release an unfinished product was to blame.
  - WorldMaker 10y ago
    «I often wonder why did they decide to introduce such complexity with all independently developed runtimes with unrelated versions and all if they went fully open source.» Most of the runtimes were developed evolutionarily for different system niches, well before .NET was given the option to be open source by default. .NET Core tried to reboot some of the "organic" evolutionary tech debt of several runtimes it was directly replacing/built from (the Silverlight runtime; the old Windows Phone runtime; the WinRT .NET runtime). «Python is a great example, since you have your standard library with some rather carefully selected OS-specific APIs and then you got a bunch of runtimes all under the same version; no confusion whatsoever.» Python still has multiple runtimes and some small amounts of confusion: CPython, Pypy, Stackless, IronPython, Python on Parrot... They don't/haven't all support the same version of the language and CPython has always been the "official standard" version, but Python is an example that no language is entirely immune from multiple runtimes either. «I am a long time .NET developer and I also was confused in the beginning of .NET Core about what was going on and I think their rush to release an unfinished product was to blame.» I don't think .NET Core was in a rush to release an "unfinished product", though it may seem to for a long term .NET developer. .NET Core has been the first runtime allowed to develop out in the open, as open source. It took about the same development time, I'd estimate, as the most similar projects you could imagine. But instead of showing up "out of nowhere" in VS 2017 Preview 1, mostly complete, we saw a lot of the little and big decisions along the way. Because it was .NET and promising big things I think .NET Core got a lot more early scrutiny by the .NET developers in what was closer to the equivalent of Python's "PEP development" phase, to use Python as the analogy, than .NET Developers had ever seen before.
manigandham 10y ago
Microsoft is one of the worst when it comes to naming products across the entire company, but doubly worse with the development offerings. They could/should just hire a single person who manages all the naming and it would probably pay back 1000x in productivity increases.
maxxxxx 10y ago
I have exactly zero faith that they won't abandon this in a few years and come out with something that does the same thing in a different and incompatible way. Their mode of operation seems to never stick to something but instead replace it with something similar. The only reliable entities are Win32 and the .NET framework. .NET Core, Standard, UWP and whatever are just short lived experiments.
- pjmlp 10y ago
  I can dig out examples for Apple and Google as well. All big corporations are like that.
- tracker1 10y ago
  I can see .Net core eventually covering everything in framework other than windows specific bits, and desktop UI. UWP, Xaml, and Mono could then become libraries as expansion on .Net core.
  - WorldMaker 10y ago
    IIRC, .NET on UWP apps already are using .NET Core inside, at least if they are using the .NET Native toolset which is built on/from .NET Core. That doesn't help anyone that thinks UWP itself is a "fad" (as in the GP comment) think .NET Core might not be a fad too, but UWP seems to be here to stay despite how many ancient developers seem to have "Win32 or Die" tattoos.

mindingdata 10y ago

Well yes because .net standard is simply the specification, and .net framework, mono, core etc are the implementations. Think about it in a web sense. We have ECMAScript which is slowly being added to. ECMAScript is the specification and it has it's own version. Then we have browsers that "implement" that specification and they also have their own version numbers because they aren't ONLY building something to handle ECMAScript, they are building other features on top of that. So in terms of .Net Core vs Mono for example, while they both may implement the .net standard, they can also have their own features unique only to one. It's not a straight implementation with nothing else added. Now say you are building a website and you want to target all "modern" browsers. It doesn't matter what version of ECMAScript is up to, it matters what each browser has so far implemented. If you are building a library for .net, then you can say "OK, I implement this standard. That means Mono Version X and .net Core version Y can be used". Similar to how you would say "You need Firefox version X or Chrome verson Y to use this feature".

nathanaldensr 10y ago

It's a cluster. The way Microsoft rolled out .NET Core and all these related technologies did nothing but confuse everyone, even seasoned .NET developers and architects such as myself. The name changes, horrible Visual Studio tooling, version numbers with seemingly no rhyme or reason...it's been a nightmare. They are finally clearing things up with .NET Standard 2.0, which is like the One Standard to Rule Them All. I consider .NET Standard 2.0 and its related implementations, along with Visual Studio 2017, to be the first real production-ready set of standards, tooling, and frameworks. It's what .NET Core should've been from the very beginning.

anton_gogolev 10y ago
Just wait until it gets renamed to something like .NET Foundation 1.0 (comprising ASP.NET Foundation 1.0 and .NET Foundation Runtime 1.2 because reasons) aaand we're back to square one.
pllbnk 10y ago
I often wonder why did they decide to introduce such complexity with all independently developed runtimes with unrelated versions and all if they went fully open source. This problem that they have solved in their own unique way has been solved before countless times. Python is a great example, since you have your standard library with some rather carefully selected OS-specific APIs and then you got a bunch of runtimes all under the same version; no confusion whatsoever. Now we have so many different versions to follow that I am really worried it will be impossible to keep any level of uniformity and compatibility between them. There are .NET Standard, Canadian, .NET Core, Mono, .NET Framework with .NET Standard's compatibility shim and .NET Core tooling. I hope I didn't forget anything else. It's already crazy as it is. I am a long time .NET developer and I also was confused in the beginning of .NET Core about what was going on and I think their rush to release an unfinished product was to blame.
- WorldMaker 10y ago
  «I often wonder why did they decide to introduce such complexity with all independently developed runtimes with unrelated versions and all if they went fully open source.» Most of the runtimes were developed evolutionarily for different system niches, well before .NET was given the option to be open source by default. .NET Core tried to reboot some of the "organic" evolutionary tech debt of several runtimes it was directly replacing/built from (the Silverlight runtime; the old Windows Phone runtime; the WinRT .NET runtime). «Python is a great example, since you have your standard library with some rather carefully selected OS-specific APIs and then you got a bunch of runtimes all under the same version; no confusion whatsoever.» Python still has multiple runtimes and some small amounts of confusion: CPython, Pypy, Stackless, IronPython, Python on Parrot... They don't/haven't all support the same version of the language and CPython has always been the "official standard" version, but Python is an example that no language is entirely immune from multiple runtimes either. «I am a long time .NET developer and I also was confused in the beginning of .NET Core about what was going on and I think their rush to release an unfinished product was to blame.» I don't think .NET Core was in a rush to release an "unfinished product", though it may seem to for a long term .NET developer. .NET Core has been the first runtime allowed to develop out in the open, as open source. It took about the same development time, I'd estimate, as the most similar projects you could imagine. But instead of showing up "out of nowhere" in VS 2017 Preview 1, mostly complete, we saw a lot of the little and big decisions along the way. Because it was .NET and promising big things I think .NET Core got a lot more early scrutiny by the .NET developers in what was closer to the equivalent of Python's "PEP development" phase, to use Python as the analogy, than .NET Developers had ever seen before.

manigandham 10y ago

Microsoft is one of the worst when it comes to naming products across the entire company, but doubly worse with the development offerings. They could/should just hire a single person who manages all the naming and it would probably pay back 1000x in productivity increases.

maxxxxx 10y ago

I have exactly zero faith that they won't abandon this in a few years and come out with something that does the same thing in a different and incompatible way. Their mode of operation seems to never stick to something but instead replace it with something similar. The only reliable entities are Win32 and the .NET framework. .NET Core, Standard, UWP and whatever are just short lived experiments.

pjmlp 10y ago
I can dig out examples for Apple and Google as well. All big corporations are like that.
tracker1 10y ago
I can see .Net core eventually covering everything in framework other than windows specific bits, and desktop UI. UWP, Xaml, and Mono could then become libraries as expansion on .Net core.
- WorldMaker 10y ago
  IIRC, .NET on UWP apps already are using .NET Core inside, at least if they are using the .NET Native toolset which is built on/from .NET Core. That doesn't help anyone that thinks UWP itself is a "fad" (as in the GP comment) think .NET Core might not be a fad too, but UWP seems to be here to stay despite how many ancient developers seem to have "Win32 or Die" tattoos.