4 ms·

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 standa

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 https://github.com/aspnet/AspNetCore/issues/3753).

merb 8y ago
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.
- daeken 8y ago
  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.
  - merb 8y ago
    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...
WorldMaker 8y ago
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.)
- oaiey 8y ago
  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.
  - WorldMaker 8y ago
    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.)
- int_19h 8y ago
  > (.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.
oaiey 8y ago
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.
- pjmlp 8y ago
  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.
  - manigandham 8y ago
    They will start caring now, or will be replaced by ones that do.
    - pjmlp 8y ago
      I wish, some of them are the only animal that matters on their domain.
sebazzz 8y ago
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 https://twitter.com/terrajobst/status/1059517534049726464

merb 8y ago

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.

daeken 8y ago
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.
- merb 8y ago
  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...

WorldMaker 8y ago

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.)

oaiey 8y ago
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.
- WorldMaker 8y ago
  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.)
int_19h 8y ago
> (.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.

oaiey 8y ago

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.

pjmlp 8y ago
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.
- manigandham 8y ago
  They will start caring now, or will be replaced by ones that do.
  - pjmlp 8y ago
    I wish, some of them are the only animal that matters on their domain.

sebazzz 8y ago

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 https://twitter.com/terrajobst/status/1059517534049726464