3 ms·

Let me just check if I finally understand this: - .Net Framework: The Windows Specific (and nearly deprecated) branch - .Net Core: The replacement for Framewo

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?

RussianCow 8y ago
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.
- sebazzz 8y ago
  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).
gulbanana 8y ago
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
- dragonwriter 8y ago
  > 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.
  - zerocrates 8y ago
    > 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).
  - WorldMaker 8y ago
    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.)
    - dragonwriter 8y ago
      > 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.
      - WorldMaker 8y ago
taco_emoji 8y ago
.NET Framework is not anywhere close to deprecated, AFAIK...
- Someone1234 8y ago
  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.
  - thrower123 8y ago
    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.
    - WorldMaker 8y ago
      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.
oaiey 8y ago
I would not call .NET Core having "Windows specific libraries". It is more like they have feature packages on-top, which are Windows specific.
- Someone1234 8y ago
  Feature packages that contain Windows specific libraries? I guess I don't see the distinction you're trying to make.
alkonaut 8y ago
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

RussianCow 8y ago

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.

sebazzz 8y ago
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).

gulbanana 8y ago

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

dragonwriter 8y ago
> 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.
- zerocrates 8y ago
  > 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).
- WorldMaker 8y ago
  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.)
  - dragonwriter 8y ago
    > 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.
    - WorldMaker 8y ago

taco_emoji 8y ago

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

Someone1234 8y ago
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.
- thrower123 8y ago
  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.
  - WorldMaker 8y ago
    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.

oaiey 8y ago

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

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

alkonaut 8y ago

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