5 ms·

This seems like FUD to me. (just skimmed the thread on mobile) First, this is about a preview version only. Second: Moving Asp.Core 2.0 target to Netstandard

This seems like FUD to me. (just skimmed the thread on mobile) First, this is about a preview version only. Second: Moving Asp.Core 2.0 target to Netstandard 2.0 is a sensible step to me. This version will be supported by desktop .Net 4.7 (win7+) when the standard is RTM. This will be the point where depending technologies will be RTMd as well. We should revisit this discussion then.

mythz 9y ago
> Moving Asp.Core 2.0 target to Netstandard 2.0 is a sensible step to me. Read the issue carefully, they've done the exact opposite and have started changing ASP.NET Core 2.0 packages from targeting .NET Standard to now only target .NET Core netcoreapp2.0 so they will no longer be able to be referenced from the full .NET Framework. They've also just announced that ASP.NET Core 1.x will be the last version that will be able to run on the Desktop CLR: [1]: https://github.com/aspnet/Home/issues/2022#issuecomment-300043783 https://github.com/aspnet/Home/issues/2022#issuecomment-3000...
- flukus 9y ago
  Doesn't that make sense? Why would you want to run a core 2 app on the desktop CLR instead of distributing a binary? Not having suitable replacements for a lot of existing libraries is the bad part.
  - mythz 9y ago
    Read the issue thread, it lists several use-cases that require usage of the full .NET framework.
    - jug 9y ago
      Yes, I agree with the guy for example needing NHibernate. It's a pretty big deal in the ASP .NET world. Anyway, here's an issue tracker for that one: https://nhibernate.jira.com/browse/NH-3807 https://nhibernate.jira.com/browse/NH-3807 I also agree with the opinion that ASP .NET Core shouldn't have run on the full framework to begin with to set the right expectations. We seem to be in yet a transitionary period by Microsoft and if the point is to decouple it from .NET Framework, it shouldn't have had legs in it.
  - mathw 9y ago
    The issues people have with the move largely revolve around applications that need .NET Framework (such as WPF applications) which embed network servers currently built on ASP.NET Core 1.x, which runs happily in that scenario, but 2.0 won't and 1.x support isn't going to be around for more than a year after 2.0 drops. WPF will probably never work on .NET Core, so after that they're going to have to have some kind of elaborate multiprocess solution if they want to stay in supported versions.
    - cm2187 9y ago
      But also all the third party libraries. Very few run on .net core.
      - WorldMaker 9y ago
        .NET Core 2.0 should run most libraries from every verson of the .NET Framework 1.0 to 4.6.1 (and potentially higher), with very few exceptions (albeit in some cases literally exceptions). (That's all the work that has gone into defining the .NET Standard 2.0 API.)
- Matthias247 9y ago
  To be fair to the original commentor: All these 2.0 names (.NET standard 2.0, .NET Core 2.0 and ASP.NET Core 2.0) make it hard to understand what sometimes is talked about. I also first understood that ASP.NET Core 2.0 is now dependent on .NET standard 2.0. This have caused no problems for desktop, because .NET FW 4.6 implements .NET standard 2.0 as far as I understand.

mythz 9y ago

> Moving Asp.Core 2.0 target to Netstandard 2.0 is a sensible step to me. Read the issue carefully, they've done the exact opposite and have started changing ASP.NET Core 2.0 packages from targeting .NET Standard to now only target .NET Core netcoreapp2.0 so they will no longer be able to be referenced from the full .NET Framework. They've also just announced that ASP.NET Core 1.x will be the last version that will be able to run on the Desktop CLR: [1]: https://github.com/aspnet/Home/issues/2022#issuecomment-300043783 https://github.com/aspnet/Home/issues/2022#issuecomment-3000...

flukus 9y ago
Doesn't that make sense? Why would you want to run a core 2 app on the desktop CLR instead of distributing a binary? Not having suitable replacements for a lot of existing libraries is the bad part.
- mythz 9y ago
  Read the issue thread, it lists several use-cases that require usage of the full .NET framework.
  - jug 9y ago
    Yes, I agree with the guy for example needing NHibernate. It's a pretty big deal in the ASP .NET world. Anyway, here's an issue tracker for that one: https://nhibernate.jira.com/browse/NH-3807 https://nhibernate.jira.com/browse/NH-3807 I also agree with the opinion that ASP .NET Core shouldn't have run on the full framework to begin with to set the right expectations. We seem to be in yet a transitionary period by Microsoft and if the point is to decouple it from .NET Framework, it shouldn't have had legs in it.
- mathw 9y ago
  The issues people have with the move largely revolve around applications that need .NET Framework (such as WPF applications) which embed network servers currently built on ASP.NET Core 1.x, which runs happily in that scenario, but 2.0 won't and 1.x support isn't going to be around for more than a year after 2.0 drops. WPF will probably never work on .NET Core, so after that they're going to have to have some kind of elaborate multiprocess solution if they want to stay in supported versions.
  - cm2187 9y ago
    But also all the third party libraries. Very few run on .net core.
    - WorldMaker 9y ago
      .NET Core 2.0 should run most libraries from every verson of the .NET Framework 1.0 to 4.6.1 (and potentially higher), with very few exceptions (albeit in some cases literally exceptions). (That's all the work that has gone into defining the .NET Standard 2.0 API.)
Matthias247 9y ago
To be fair to the original commentor: All these 2.0 names (.NET standard 2.0, .NET Core 2.0 and ASP.NET Core 2.0) make it hard to understand what sometimes is talked about. I also first understood that ASP.NET Core 2.0 is now dependent on .NET standard 2.0. This have caused no problems for desktop, because .NET FW 4.6 implements .NET standard 2.0 as far as I understand.