This is what Scott Hanselman wrote, please read that first:
==
I can see why this is initially a scary WTF moment. Let me explain because it’s less freaky than it seems.
You said .NET customers are going to need to interoperate. Totally agree.
We can share netstandard libraries between ASP.NET Core 2.0 and EVERYWHERE.
We can even reference many net461+ assemblies from ASP.NET Core 2.0 because of typeforwarding and netstandard20
You said WebApps may need to use:
AD – Totally, this is a gap IF you want to call LDAP directly. You can certainly auth against Windows Auth NOW. We plan to have specifically the DirectoryServices namespace for Core 2.0 around summer timeframe
Drawing – Totally, this is a gap. We plan to have this for Core 2.0 around summer timeframe. Until this, these netstandard options also exist ImageSharp, ImageResizer, Mono options, etc
COM Automation – This has never been possible under Core 2.0, but you can certainly PInvoke if you want to hurt yourself. You could also local WebAPI to a net461+ process if you really want to hurt yourself.
Sharing code with WFP Apps – YES. Totally possible with netstandard2.0.
This is a weird change to make.
Feels like it but…
Think about it this way. WPF isn’t netstandard2.0, it knows it’s on net461+ and that’s OK. It’s optimized, but it can reference netstandard libs. ASP.NET Core 2.0 is optimize for Core 2.0 but it can reference shared libraries. Xamarin is the same.
.NET Core is side by side and it’s moving fast. It’s WAY faster than .NET (Full) Framework can move which is good. By building ASP.NET Core 2.0 on top of .NET Core 2.0 (which, remember, is a SUPERSET of .NET Standard) that means stuff can be built faster than NetFx or even Netstandard.
NetCore > Net Standard > NetFx when it comes to development speed and innovation.
Point is, if you are doing new work, netstandard20. If you have older net461+ libraries, MOST of those can be referenced under ASP.NET Core 2.0.
ASP.NET Core 1.1 which runs on .NET Framework will be fully supported for a year after we release 2.0. That workload is fully supported thru at least July of 2018.
The remaining large gaps missing in .NET Core 2 are System.DirectoryServices and System.Drawing. We are working to have a Windows compat pack which would enable both of those on .NET Core on Windows this summer.
What we need from you all is a clear list/understanding of WHY you think you need ASP.NET Core 2.0 to run on net461+. Be specific so we can close those gaps and let everyone be successful.
Boys! We've been caught. Quick, do Jazz hands and pretend it doesn't matter!
That does not seem like a sane response to me. We move fast and break things and that's good is not something we should be hearing as a justification at this point.
And he's making a deal out of it being supported till 2018! A whole year! What do they think people are making on their framework? Apps that disappear after a year? Once you commit to a framework you'll be supporting it for 5 or 6 years.
Am I totally misreading it, as to me that is really not a reassuring response at all, quite the opposite. It seems to me that they've completely lost touch with their customers who want a stable, fast and predictable new version of MVC 4.
We built on top of ASP.NET Core because of the option to use it with netfx, and we built things which were intended to last 5-10 years, not for 1 year of support max. This is what the ASP.NET name means in business and it's why large, slow-moving organisations choose it over flavour of the month frameworks.
They should take a look at MS history and look back at the Windows Mobile (6) -> Windows Phone transition for what can happen worst case when you crap all over your enterprise customers.
Have you tried using it in VS2017? Nowhere to be seen. The runtime is supported yes, but you try combining and debugging a Silverlight solution with a .Net Core web app.
Of course - I was actually surprised it still worked in VS2015.
I don't expect it to be forwards compatible. (Hell, we're talking about tech that only runs in IE11 :) )
But one big difference is: Official support means updates in case of critical vulnerabilities and guarantees that, at least with IE11, it won't simply stop working after an update.
ASP.Net Core 1.x won't have any such guarantees after 2018.
And that's kinda hefty when the ASP.NET Core website (https://docs.microsoft.com/en-us/aspnet/core/) still refers to this page for guidelines as to which .NET Runtime to choose for ASP.Net Core(!) projects:
This is still splitting the ecosystem. This is the exact same mistake they made with the json project format.
Also, if you started using asp.net core 1.0, and you do actually do need stuff that's .net 4+ only, you're stuck.
There are a ton of people/businesses that use old .net libraries, that now have no way forward, no way to gradually introduce asp .net core. I'm going to assume that, if this is a new policy, that all the other new core stuff (entity framework core, async enumerable) might also become core only, which would be an even bigger issue.
Also, I can't think of a good reason this happen. Are they trying to force people to .net core? Was supporting two .net versions that big of a burden?
It certainly runs on .NET Core (I'm currently using it that way for a project); it just also runs on full-fat .NET, too. ASP.NET Core seems to break with that and only run on .NET Core.
==
I can see why this is initially a scary WTF moment. Let me explain because it’s less freaky than it seems.
You said .NET customers are going to need to interoperate. Totally agree. We can share netstandard libraries between ASP.NET Core 2.0 and EVERYWHERE. We can even reference many net461+ assemblies from ASP.NET Core 2.0 because of typeforwarding and netstandard20 You said WebApps may need to use: AD – Totally, this is a gap IF you want to call LDAP directly. You can certainly auth against Windows Auth NOW. We plan to have specifically the DirectoryServices namespace for Core 2.0 around summer timeframe Drawing – Totally, this is a gap. We plan to have this for Core 2.0 around summer timeframe. Until this, these netstandard options also exist ImageSharp, ImageResizer, Mono options, etc COM Automation – This has never been possible under Core 2.0, but you can certainly PInvoke if you want to hurt yourself. You could also local WebAPI to a net461+ process if you really want to hurt yourself. Sharing code with WFP Apps – YES. Totally possible with netstandard2.0. This is a weird change to make. Feels like it but… Think about it this way. WPF isn’t netstandard2.0, it knows it’s on net461+ and that’s OK. It’s optimized, but it can reference netstandard libs. ASP.NET Core 2.0 is optimize for Core 2.0 but it can reference shared libraries. Xamarin is the same.
.NET Core is side by side and it’s moving fast. It’s WAY faster than .NET (Full) Framework can move which is good. By building ASP.NET Core 2.0 on top of .NET Core 2.0 (which, remember, is a SUPERSET of .NET Standard) that means stuff can be built faster than NetFx or even Netstandard.
NetCore > Net Standard > NetFx when it comes to development speed and innovation.
Point is, if you are doing new work, netstandard20. If you have older net461+ libraries, MOST of those can be referenced under ASP.NET Core 2.0.
ASP.NET Core 1.1 which runs on .NET Framework will be fully supported for a year after we release 2.0. That workload is fully supported thru at least July of 2018.
The remaining large gaps missing in .NET Core 2 are System.DirectoryServices and System.Drawing. We are working to have a Windows compat pack which would enable both of those on .NET Core on Windows this summer.
What we need from you all is a clear list/understanding of WHY you think you need ASP.NET Core 2.0 to run on net461+. Be specific so we can close those gaps and let everyone be successful.