The new ASP.NET Core 2.0 packages can no longer be used on .NET Desktop
kevinchalet opened this issue · comments
Edit: the "no .NET Framework support for ASP.NET Core 2.0" plan has been officially cancelled and running ASP.NET Core 2.0 on .NET Desktop will be supported in the next previews. For more information, read Announcing ASP.NET Core 2.0.0-Preview1 and Updates for .NET Web Developers or watch .NET Standard 2.0 and .NET Core 2.0.
I'd like to thank everyone for taking the time to participate to this thread ; no doubt it helped make the Microsoft heads realize that they couldn't silently adopt such a major breaking change at the last minute without consulting their community or measuring the actual impact of their unilateral decisions on the entire ecosystem.
Even though we all had different opinions, the most important thing was to have a real discussion about this change. It's clearly a huge - and unprecedented - success (>150 participants and more than 700 messages, woot!)
It's amazing to see such a great community in action, I'm so proud of being part of it 🤙
Original message: earlier today, most of the ASP.NET Core 2.0 packages were updated to target netcoreapp2.0 instead of netstandard1.* and net4* (e.g aspnet/Security#1203 and aspnet/Mvc#6234), making them totally incompatible with .NET Desktop and Mono.
Although this major breaking change is likely to have a huge impact on the entire ASP.NET ecosystem, it was neither discussed nor announced publicly (demonstrating once again that the ASP.NET team is not very good at communicating and is not really willing to discuss such important changes with its community, but that's another story).
In this thread, @Eilon partially mentioned the reasoning behind this decision, but didn't say whether less extreme options have been considered or not (e.g cross-compilation, introduction of a netstandard2.1 TFM, etc.):
Yes, for ASP.NET Core 2, most of the libraries will target .NET Core 2 in order to use new APIs that are not yet available in a .NET Standard TFM. Code that needs to target multiple platforms, such as Microsoft.Extensions.*, Entity Framework Core, and a few other libraries, will continue to use .NET Standard.
My question is simple: are you going to amend/revert these changes at some point before RTM, so people can use the ASP.NET Core 2.0 packages on .NET Desktop, or is ASP.NET Core 2.0 on .NET Desktop definitely dead? (which would be a major blocker for many people, including me).
Thanks.
This would be an extremely weird and bad change to make. I have written a lot of netfx-only asp.net core code and do not want to see that investment wasted. More generally, .NET customers are going to need to be able to interoperable between ASP.NET Core and Desktop code for the foreseeable future - imagine webapps which use Active Directory, or Office COM automation, or which do thumbnailing using some System.Drawing based library, or share code with a WPF app. It's trivial to think of a lot of scenarios like this and I hope we've simply misunderstood what's going on.
We're currently on AspNetCore 1.1.1 - i.e, the "current" support branch. If we cannot move to 2.0 due to dependencies on Net4XX, does that mean we'll be unsupported when 2.0+3months drops?
We use a combination of WPF and ASP.NET Core and target in both cases the full framework.
So I guess no 2.0 in the foreseeable future?
But full framework 4.6.1 will support netstandard 2? am I missing something? (https://docs.microsoft.com/en-us/dotnet/articles/standard/library)
isn't this that the current tooling isn't updated?
it would be totally fine and expected to see asp.net core running on netstandard 2. the alarming thing is this prospect of moving to netcoreapp2.0, which would imply no longer being able to use legacy code inside of asp.net core websites
oh, that's an issue.. I suppose though that its mitigated a little by the compat shims in netcore2 that allows you to reference old assemblies, but still, it means porting all projects to the new project system and a lot of other work..
Would be nice to hear the teams reasoning on this
oh, so you think that netcoreapp2.0 projects will simply be able to reference netfx libs thanks to type unification? that would explain a lot. my question, if so, is how much code will actually work when run on windows but on the core CLR..
Wow. This would be totally blocking for us and basically make sure we could never update these packages for the far foreseeable future. We even might need to migrate our MvcCore project back to Mvc, because we currently cannot get around targetting net462+.
I'm extremely curious about this as well. I'm really hoping this in an intermediate (and short lived) step or a big miscommunication. It would certainly be a blocker to adoption for most of our applications as well.
Moving everything to Core is just too much for a large existing codebase (without stopping dev to do it), moving to the new ASP.NET Classes (HttpRequest, controllers, etc.) as an intermediate step has to happen for our main projects.
Perhaps @DamianEdwards or @davidfowl can comment on plans here? I'm also having trouble finding any additional reasoning.
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.
I thought .NET Standard 2.0 was all about compatibility and interoperability which bridges the gap between .NET Core and .NET fx that everyone is waiting for - this seems to kill that.
For whatever reason there's going to be lots of customers who will have dependencies that require .NET 4.x whether it be custom external dependencies, commercial components, legacy lib dependencies, etc.
Is it the intention that Customers wont be able to create ASP.NET Core 2.0 apps running on Desktop CLR so they can reference their existing .NET 4.x deps?
@shanselman Thanks for the reply - lots of good examples in there.
A follow-up about libraries:
Will all of the abstraction libs remain as cross-compiled? For example if I'm using HttpRequest, maintaining a 1.x and 2.x builds on which version of ASP.NET Core you're using (which now cleanly map to a TFM at least) would be something I'd prefer to avoid...so I'm hoping the abstractions will remain on netstandard. Is that the general plan?
We're already maintaining multiple variants for things that depend on ASP.NET/MVC because System.Web's HttpRequest is totally different, so that's another library entirely (e.g. MiniProfiler vs. MiniProfiler.AspNetCore). I just want to make sure we're keeping in mind the number of variants we're loading up on maintaining for any lib authors if their dependencies move off netstandard...and hopefully just avoid that headache all together.
I'm very happy this doesn't seem like as big a deal as it appears, thank you for the detailed clarification.
I do have two questions/concerns:
-
It sounds like consuming .NET Framework libraries from ASP.NET Core should have minimal friction. That's great! What about the other way around? There are probably .NET Framework or netstandard libraries and applications out there that are embedding parts or components from Mvc and other supporting ASP.NET Core libraries (I know because I have a couple). Those will break, correct? Are there any tips for how to work around that scenario? If netstandard libraries can no longer consume ASP.NET Core libraries, that seems like a big deal for embedded ASP.NET Core scenarios.
-
From a non-technical perspective it seems like this will cause a lot of confusion. Outside of the folks who are active on GitHub, follow along on Twitter, etc. there's already a great deal of confusion surrounding the different platforms, etc. I can see developers who've only been partly following along or who are just now getting up to speed getting very frustrated when they go to use ASP.NET Core (perhaps following an outdated tutorial) and can't get it to work on their .NET Framework platforms. Not sure what, if anything, can be done about that.
We can even reference many net461+ assemblies from ASP.NET Core 2.0 because of typeforwarding and netstandard20
Unfortunately, this doesn't mean that a library compiled and designed for the full framework will work on .NET Core (the risk is high things will blow up at runtime!).
Many of the "old" APIs re-introduced in .NET Core 2.0 are stubs that will never (functionally) work. Not to mention that there are still many missing APIs, and even entire areas that were deliberately excluded from .NET Core (IdentityModel, WCF server, remoting, complete AppDomain support, etc.)
Trying to convince people that they can "safely" migrate their ASP.NET Core 1.0 w/ .NET Desktop apps to ASP.NET Core 2.0 w/ .NET Core is - IMHO - a lie.
.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.
I don't believe that's what (most) people are looking for. Many people don't need fast-moving libraries, they need stable stuff that can gracefully integrate into their older stuff without taking the risk of breaking everything.
- Correct in that there's no implicit ability to reference
netcoreapp2.0fromnet461or evennetstandard2.0. The bridge goes one way. You can always work around it by specifying TFMs for package fallback, but that's obviously an escape hatch, not a supported scenario (although it will be enough to unblock many people). It's a non-trivial amount of work for us to support sub-systems of ASP.NET Core outside of the larger stack (which is what targetingnetstandardis implying). - The potential for confusion goes both ways. E.g. we've had lots of feedback that the fact that "ASP.NET Core" can run on .NET Framework (which isn't .NET Core) is confusing. This change effectively makes ASP.NET Core part of the .NET Core stack meaning if you're using ASP.NET Core, you're using .NET Core.
@shanselman BTW, you didn't say why cross compilation was not an option. ASP.NET Core components that could benefit from netcoreapp2.0-only APIs could have both net46/netstandard1.x/netstandard2.0 and netcoreapp2.0 TFMs and make the new cool/fast stuff .NET Core-only.
@NickCraver currently the plan does not include leaving the *.Abstractions packages targeting netstandard. The separation simply isn't as clean as that across the board. For the purposes of someone attempting a migration like what you're suggesting however, using package target fallback should get you there anyway (but I might be misunderstanding you).
Also you're point about the clean TFM split is correct, and is an advantage of this plan, in that a single package can now target ASP.NET Core 1.x and 2.0+ simultaneously using the TFM as a pivot.
I've toying around with the idea of "mixed applications". E.g. a WPF application exposing a Web API or a Server offering both a REST API and WCF endpoints (this might be for compatibility with earlier clients). These scenarios are made impossible with this change and makes ASP.NET Core only suitable for new applications rather than being "just a library".
@PinpointTownes as @shanselman stated, we're very interested in the specific requirements and blockers that customers have with regards to needing to continue to target .NET Framework directly. Our work with customers in this boat so far has indicated that System.DirectoryServices and System.Drawing and the No.1 and 2 blocker and we have a plan to address that. Beyond that, we're looking at the feedback and we'll assess.
Cross-compiling is an overhead that must be balanced with customer and product needs. This is why we want to get this feedback so we can more concretely define what the landscape looks like for both our customers and us as we continue to evolve ASP.NET Core moving forward.
@DamianEdwards Thanks for the further clarification. The netstandard -> ASP.NET Core libraries are kind of a big deal for me. I embed Kestrel (which also looks to be moving to netcoreapp) in several netstandard libraries. I also embed Razor in several places, and I know you're working on the new more modular version, but if that only targets netcoreapp too it'll hurt. There's also tons of libraries that are "part" of ASP.NET Core but that have lots of utility outside of it.
In other words, I'm much more concerned about removing the ability for netstandard libraries to consume ASP.NET Core packages than I am about the reverse. It seems like this is removing an entire class of use cases from consideration.
@daveaglick Razor itself (the engine) will continue to target netstandard. Again, there's a cost involved in supporting particular sub-systems of a large complex graph (like ASP.NET Core 2.0) on different platforms. For things like embedding there are other options (source embedding, copying, etc.) but of course they come with their own trade-offs.
Definitely hear you on the different classes of use cases front, we indeed have different customer groups to consider when designing and shipping a stack like ours.
I share @daveaglick's concerns here: ASP.NET Core wanting to use the latest APIs is totally understandable, but for everything else downstream to require the same gets a little messier. You don't get any choice after 1.0 of stable or upgrading, you're on the fastest train available with netcoreapp2.0 and that's the only choice. If all of the bits (even the basic abstractions) can't be consumed without making users consume netcoreapp2.0, that means there is effectively no netstandard2.0 for that entire line of libraries...and everyone that depends on them.
I get the core application stack moving, but I don't necessarily agree with the abstractions in particular moving. One of the major points of the abstractions was to avoid the tight coupling like this, at least from my view as a consumer. I'd be very curious to see some examples where netstandard2.0 doesn't have the APIs needed for them but netcoreapp2.0 does - are there some examples out there? Is this mainly around new types in method parameters? I don't doubt there's ample reasoning, I'm just very curious - seeing examples would help show the maintenance cost which we don't have nearly as much daily insight to.
The Kestrel case is more complicated, but I certainly see the arguments for having it on the latest API set. I'd imagine new APIs will continually be created for Kestrel given the work it's driving.
@PinpointTownes as @shanselman stated, we're very interested in the specific requirements and blockers that customers have with regards to needing to continue to target .NET Framework directly.
As a consultant, I helped a bunch of clients move their apps to ASP.NET Core and I often had to target .NET Desktop to be able to use third-party (closed-source) libraries depending on IdentityModel/WCF or relying on AppDomain support.
Not having these things in ASP.NET Core 2.0 would be a major blocker for them.
There are also libraries that wouldn't work on .NET Core even if the APIs were there, because they'd be functionally different. Here's a concrete case I've seen many times:
On .NET Core, RSA.Create() returns a RSACng instance on Windows, but on .NET Desktop, a RSACryptoServiceProvider instance is returned. Yet, many libraries - including the BLC itself - try to cast RSA to RSACryptoServiceProvider, which will always fail on .NET Core, as RSACng can't be cast to RSACryptoServiceProvider.
@NickCraver which abstractions in particular? The problem with moving just the abstractions is that next you'll end up wanting everything that builds upon those abstractions as well (unless you're literally saying that you only need Microsoft.AspNetCore.Http.Abstractions and nothing else)
@davidfowl Yep, only the abstractions: e.g. HTTP, Hosting, HTML, and Logging. It looks like Microsoft.Extensions.* are covered by earlier comments, which is most of these. Those are the ones I'm interfacing with today.
For a concrete example: the MiniProfiler Middleware doesn't reply on anything but abstractions (link)
If you're using MVC and such on top, well then you're on netcoreapp2.0 anyway, and that is what it is (and IMO, that's just fine). But currently I have freedom to split up APIs logically where shared and do so easily because they're abstractions. I'm very much a fan of the current split, please don't lock that down unnecessarily.
Heh. As a consultant, I've definitely heard the "What? ASP.NET Core runs on desktop .NET Framework!?" question quite a few times. The fact that "ASP.NET Core" literally has ".NET Core" in the name is really unfortunate.
Anyway... Just as I was a fan of dropping obsolete/legacy/broken APIs when .NET Core started out (a "fresh" start), I'm also a fan of this change in order to get a faster, leaner framework with more features and a higher rate of innovation.
With that said, I'm also sympathetic to all the devs out there that can't, for some reason, migrate all their code to .NET Core before June next year.
This includes my current client, which has an insanely big legacy library/framework, targeting .NET Framework, consumed by multiple ASP.NET Core projects currently being developed in parallel. By the time these systems goes into production, there will be little to no time to either a) port everything to .NET Core, or b) move everything to full framework ASP.NET, before ASP.NET Core 1.x is unsupported.
Is one year of support really enough here? I can imagine there are other similar cases out there...
@khellang as previously stated, they'll be able to continue referencing libraries/frameworks targeting .NET Framework, and that will work just fine assuming the APIs they call are part of the closure of netstandard2.0. Do you know if they rely on things outside of that space? That's what we'd really love to get feedback on so we can assess the priority of porting those APIs (like System.DirectoryServices and System.Drawing).
So hosting a web api (say communication layer) or even upcoming asp.net core sockets is going to become impossible for a current windows service or WPF desktop app? (with supported versions).
I imagine there will be a list forthcoming of things that used to be netstandard1.x that are now netcoreapp2.0
I've browsed the repos and it seems MVC specific things are netcoreapp2.0 but HttpAbstractions, Logging, Configuration, etc are still netstandard Or is there more change to come?
@NickCraver I see you're using Extensions but are still using System.Web. Do you have plans to shim Microsoft.AspNetCore.Http.HttpContext with System.Web.HttpContext? Do you have an idea how much of the API you need?
If you're using MVC and such on top, well then you're on netcoreapp2.0 anyway, and that is what it is (and IMO, that's just fine). But currently I have freedom to split up APIs logically where shared and do so easily because they're abstractions. I'm very much a fan of the current split, please don't lock that down unnecessarily.
I'm not talking about MVC though, I'm just talking about other helpers that expose more functionality on top of the underlying abstractions. The big value of the "abstractions" pattern we chose is that other things can build on top of them, not so much the abstractions itself. My gut tells me that if we make the ASP.NET abstractions netstandard then we'll end up having to make all of the middleware netstandard as well.
@dasMulli windows services will work once we have the API ported over (there are also open source libraries that support windows services on .NET Core).
WPF desktop app? (with supported versions).
Yes. This won't be the default anymore. We won't support it out of the box anymore with .NET Core 2.0.
@davidfowl I'm not sure you looked at the right pieces there:
but are still using System.Web
...not in the same libraries, because of this split. To achieve minimal overhead and not a truckload of dependencies for consumers, there's MiniProfiler for ASP.NET MVC < 6 (System.Web) and MiniProfiler.AspNetCore/MiniProfiler.AspNetCore.Mvc (lots of NuGet).
I think you're talking about System.Web vestige that was that was on MiniProfiler.Shared - I was waiting to clean those up until the NuGet issue fixed just last night on framework assemblies. I just removed it to clear things up.
@DamianEdwards I'm not 100% on the closure of netstandard2.0, but I would be happy to (with their permission) do a portability analyzer run and share the results. Is portability analyzer still a thing and up to date?
ASP.Net Core is quickly becoming the new Python 3*; only worse. This seems like a move in the wrong direction to me. This just means a ton of scenarios will force developers to maintain (and write new) code on the "old platforms" for many years to come instead of moving. "Faster development" doesn't seem like a very good argument if all it means is you get to a worse/unsuitable place "Faster".
*I like Python 3, but it's been out almost a decade and the Python community is still fractured
Just to be clear - is there any technical blocker (fancy perf stuff) or is this just to save the cost of maintaining compatibility in the future?
I think most of us knew this move would come but no one expected it so soon.. given the transition time is still going on (like libs being ported, .net standard 2.0 around the corner but no libs are yet bing built for it) - it would be great to keep net* support for at least one release (e.g. 2.0, not 2.1).
@shanselman I see your points and i personally even agree, but alot of people are not going to see it that way.
The primary issue is not calling net46 assemblies from core, the compat shims deals with that in most cases. The problem is existing net46 code and asp.net core 1.* code running on 46. As someone mentioned, the whole point of netstandard was to allow code, including asp.net, to run everywhere, this is going to feel like a step away from that and perhaps even a failure of that vision to some people.
I don't think the problem is that people don't want to move to net core. The problem is that organizations, managers, CTOs and the like has to be convinced that the cost/benefit of doing so is worth it. Not only is porting time consuming enough to eat into deliveries, it also introduces risks of regressions etc.
in other words, its not always technical reasons that prevent people from moving. I'd even say its rare, technically almost any project can make the jump. But motivating that cost/delivery slip, that's the problem. It can be a very hard sell, one that i've had to make a fair few times. In those cases being able to say, "but you can run on full framework" has been a way to drive that move though
If you want to hurt yourself
This is exactly it. Net46 devs and management will not see it like that, they'll see it as you, microsoft, want to hurt them in order to keep up with the latest release. "Well don't move then" one might say but with the support of asp.net core 1.x as short as it is, they kind of have to, at least from the perspective of managers who has to be held responsible if a bug causes downtime or information loss. (even if the framework is not responsible)
A lot of devs that really pushed for asp.net core 1.1 are also going to feel betrayed that they now wont be able to move to 2.0 without core. That may or may not be justified but i'm just telling you, alot of people are going to feel that way, they'll be the ones who have to answer to their more conservative colleagues
Does any of that matter? Will asp.net core2/dotnet core2 "die" because of this? No, but it will slow adoption and fracture the ecosystem and that's really sad imo. I want people to be able to use all this great stuff coming in 2.0 and cutting cross compilation to net standard will impact that. Certainly, most people who hang out in these repos wont have a problem, its Joe and Jane dev and even more so, their manager that's the problem.
@DamianEdwards
I agree that this has been a source of confusion, I've had to explain it many times, but the result of that has always been turning a disappointed dev into an excited one because they thought they were not able to use the new cool stuff but it turned out they could.
To summerize, I'm sure this decision was not made lightly but if you have to do this i think you have to be really really careful about the messaging.. You have to show that migrating to asp.net core, especially from 1.x on net46 is super simple and super polished. The story for referencing other netstandard libraries from net46 both as project references and otherwise has to be rock solid. I think you need to show/adress this explicitly to avoid people freaking out
@khellang paging @terrajobst for the Portability Analyzer question.
@NickCraver Sure, you can write a piece of middleware that targets netstandard, what good does that do for you as a library author if ASP.NET Core supports netcoreapp2.0.
@aL3891 great summary! One big issue we do have going forward is how we take advantage of new APIs for things that are also in netstandard. .NET Core will get new APIs that we need to implement new features (one that comes to mind is SSLStream ALPN support for HTTP2 support in Kestrel). So you could argue we stay on stay on netstandard and constantly use the highest version (which .NET Framework doesn't support yet) but then we'd be in the same boat.
One big issue we do have going forward is how we take advantage of new APIs for things that are also in netstandard. .NET Core will get new APIs that we need to implement new features (one that comes to mind is SSLStream ALPN support for HTTP2 support in Kestrel).
According to https://github.com/dotnet/corefx/issues/4721, ALPN support for SslStream won't be ready for .NET Core 2.0. Assuming this is eventually implemented a few months later, does that mean that one will be able to use it when targeting the netcoreapp2.0 TFM? In this case, what will happen if I decide to release a netcoreapp2.0-based library that uses new APIs that were not part of the initial netcoreapp2.0 shape if my users use an older .NET Core runtime? Will it crash? Or will netcoreapp2.x be aligned with netstandard1.x, whose contract can't be changed without incrementing the TFM version?
@davidfowl for other implementations of any piece of the stack and testing. And because with the way abstractions are (not requiring MVC) as a decent split between 2 libraries instead of "assume everyone has MVC and wants all dependencies".
If the abstractions aren't actually abstractions and are so tightly coupled to ASP.NET Core itself, why don't we just remove those packages? It's an honest question, as that'd make life easier and clearer if that's the overall relation goal. I'm trying to understand the point of having abstractions as separate packages are if they're effectively tied to a simple implementation/use. I'd posit that no one outside of Microsoft wants to or has the resources to dedicate to a competing netcoreapp2.x web server (happy to be corrected there!).
Can you clarify what the point of the abstractions would be in a netcoreapp2.x world? Or if there are plans to simply deprecate them in 2.0?
According to dotnet/corefx#4721, ALPN support for SslStream won't be ready for .NET Core 2.0. Assuming this is eventually implemented a few months later, does that mean that one will be able to use it when targeting the netcoreapp2.0 TFM? In this case, what will happen if I decide to release a netcoreapp2.0-based library that uses new APIs that were not part of the initial netcoreapp2.0 shape if my users use an older .NET Core runtime? Will it crash? Or will netcoreapp2.x be aligned with netstandard1.x, whose contract can't be changed without incrementing the TFM version?
ASP.NET version x will just align to .NET Core version x. The TFM will be updated to align with every release of .NET Core. It's a single product that can finally be treated as such. That's one of the major simplifications we're doing as @DamianEdwards mentions above. We won't break people building libraries by adding new APIs in the core without changing the TFM.
for other implementations of any piece of the stack and testing.
What other implementations? Are there other pieces of the stack that implement ASP.NET Core.
If the abstractions aren't actually abstractions and are so tightly coupled to ASP.NET Core itself, why don't we just remove those packages? It's an honest question, as that'd make life easier and clearer if that's the overall relation goal. I'm trying to understand the point of having abstractions as separate packages are if they're effectively tied to a simple implementation/use. I'd posit that no one outside of Microsoft wants to or has the resources to dedicate to a competing netcoreapp2.x web server (happy to be corrected there!).
Can you clarify what the point of the abstractions would be in a netcoreapp2.x world? Or if there are plans to simply deprecate them in 2.0?
We could put everything into a single assembly but the refactoring allows us future flexibility that we wouldn't otherwise have if we did this. It even opens up the possibility to have other implementations and doesn't really preclude it in the long term.
Simply put, abstractions are about lowering the number of dependencies, not about platform portability.
We won't break people building libraries by adding new APIs in the core without changing the TFM.
You guys said that you wanted to opt for netcoreapp2.0-only as it was moving faster - compared to .NET Desktop and by extension, .NET Standard - but what's the point of targeting netcoreapp2.0 instead of netstandard2.0 if you can't benefit from new .NET Core APIs without changing the TFM? (e.g netcoreapp2.1)
You guys said that you wanted to opt for netcoreapp2.0-only as it was moving faster - compared to .NET Desktop and by extension, .NET Standard - but what's the point of targeting netcoreapp2.0 instead of netstandard2.0 if you can't benefit from new .NET Core APIs without changing the TFM? (e.g netcoreapp2.1)
Sorry, I misspoke, I mean netcoreapp2.x not netcoreapp2.0.
Okay, I'm totally confused, now.
Sorry, I misspoke, I mean netcoreapp2.x not netcoreapp2.0.
I'm not sure I understand. Do you mean there'll be an equivalence between the ASP.NET Core 2.1 packages and the netcoreapp2.1 TFM?
Do you mean there'll be an equivalence between the ASP.NET Core 2.1 packages and the netcoreapp2.1 TFM?
Yep. Think of the 2 as one in the same. See #2022 (comment)
So what prevents you from adopting a similar pattern, but with netstandard? It would be the best approach, IMHO: new APIs could be adopted via new TFMs and people who need to support .NET Desktop could still run their ASP.NET Core apps on the full framework.
ASP.NET Core 2.1/.NET Core 2.1/.NET Desktop 4.7.1 -> netstandard2.1
ASP.NET Core 2.2/.NET Core 2.2/.NET Desktop 4.8 -> netstandard2.2.
@PinpointTownes because .NET Framework on desktop can't ship fast enough, that's the crux of most versioning issues with Core. It's a hard problem in an immense chain.
.NET Standard will not move at the same speed as .NET Core. Nowhere near it in actuality. A move in .NET Standard essentially leaves all platforms behind, until they catch up, and .NET Framework is both the slowest moving and the largest.
Point token, tho' I'm not sure how fast .NET Framework is supposed to ship (e.g the new ECDSA APIs were ported from CoreFX to NetFX in less than a year, which seems to be a reasonable time frame for such sensitive crypto components).
Cross-compiling is an overhead that must be balanced with customer and product needs.
When you have a minute, I'd love to know more about the exact nature of the overhead caused by cross-compilation. Thanks.
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.
At the moment, we need the fullframework version of WCF client libraries - as the netstandard / netcore versions (https://github.com/dotnet/wcf) are not close to complete.
When you have a minute, I'd love to know more about the exact nature of the overhead caused by cross-compilation. Thanks.
There will be a time in the very near future where we literally can't polyfill features like ALPN support for SSLStream. Also we haven't even begun to stretch our legs and add APIs into .NET Core, so far we've been bogged down with porting things back to .NET Standard and .NET Core 2.0 (the entire purpose of .NET Standard 2.0). We're going to be adding new APIs and finally consuming them in ASP.NET Core on day 1.
At the moment, we need the fullframework version of WCF client libraries - as the netstandard / netcore versions (https://github.com/dotnet/wcf) are not close to complete.
@ctolkien That is a problem and it's the reason we ported the WCF client in the first place. Do you know what's blocking you? This is a good chance to help us prioritize.
There may be more, this was just the first hurdle we hit before transitioning to full framework wcf.
There will be a time in the very near future where we literally can't polyfill features like ALPN support for SSLStream.
How is that a problem? AFAICT, no here has ever said that the .NET Desktop and .NET Core flavors of ASP.NET Core had to support the same exact feature set. If a feature is not available on .NET Desktop due to missing APIs (e.g HTTP 2/0), why not making it .NET Core-only and throwing a PlatformNotSupportedException telling the developer that the feature he's looking for is not available?
It would be far better than making all the ASP.NET Core packages .NET Core-only, even though most of them will be unlikely to use new BCL APIs.
@davidfowl I guess one major fear is that things don't get fixed in say netcoreapp2.3, it gets fixed in netcoreapp2.4. If ASP.NET Core is focused on the fastest train, how long with each minor version get love? If we have to constantly upgrade, then every consumer has to constantly upgrade.
That's great for getting the latest and greatest, but it's not the best for most companies. So we either have to maintain many versions (each minor version) with our libraries for each consumer of ASP.NET Core (to not depend on the latest and keep up), or drag users to the latest version to keep up. This isn't friendly to things like validated environment.
Unless the abstractions need to rev as fast (examples?), having them disconnected would be preferred. That way you're not dragging the entire ecosystem along with every upgrade. I guess I'm more concerned not that they'll be on netcoreapp, but that they'll be continually updated and everything is tightly coupled.
If the abstractions will maintain each minor version and shift the pain (to be frank) to your side, I'm a lot less worried. Can you guys elaborate on intentions with revisions here?
@PinpointTownes:
why not making it .NET Core-only and throwing a PlatformNotSupportedException telling the developer that the feature he's looking for is not available?
It would be far better than making all the ASP.NET Core packages .NET Core-only, even though most of them will be unlikely to use new BCL APIs.
Noooooooo, please no. That's a runtime failure and very much not desirable behavior. We want to have as many compile-time assurances that our libraries will work as possible. There have been many debates on this, that simply isn't a good path. PlatformNotSupported should be avoided as much as humanly possible.
That's a runtime failure and very much not desirable behavior.
This is exactly what will happen with the "bring your .NET Desktop assemblies on .NET Core" approach if your assemblies try to use an unsupported API, except you'll get a MissingMemberException instead of a PlatformNotSupportedException.
With my approach, you could at least define a better tooling story with things like Roslyn analyzers that could determine at compile-time whether the APIs you're using are supported or not.
And BTW, throwing a PlatformNotSupported would be really a corner case. With cross compilation, the best option would be to simply exclude the unsupported APIs from the public contract.
@PinpointTownes I thought this way as well, but the reality is new platforms ship and it's just not that simple. After discussing this many times my mind has changed greatly on how to do compat here. Going with the netcoreapp direction allows fixes to be shipped in minor versions. Going the other way means you have to wait on .NET Desktop to ship fixes, which...good luck. That's a very slow vehicle for resolutions.
AFAICT, no here has ever said that the .NET Desktop and .NET Core flavors of ASP.NET Core had to support the same exact feature set. If a feature is not available on .NET Desktop due to missing APIs (e.g HTTP 2/0), why not making it .NET Core-only
The first half of that is what netstandard is. Differentiating to netcoreapp is exactly what they're doing here. Without the intentional exceptions. It's a proper contract this route.
You want to go the direction of the thing that can be fixed and improved faster when gaps are involved, not the other way around. "PlatformNotSupported" exceptions can be fixed in the library tomorrow, instead of waiting for the platform to rev 3 months from now. .NET Core can support them faster because the actual code ships with it, not separately as forwarders most of the time.
[@PinpointTownes] If a feature is not available on .NET Desktop due to missing APIs (e.g HTTP 2/0), why not making it .NET Core-only and throwing a
PlatformNotSupportedExceptiontelling the developer that the feature he's looking for is not available?
We need to balance simplicity in API surface & reach with developer productivity. So far, we've primarily used PlatformNotSupportedException in order to deliver an API surface that is compatible with the past. We don't intend to use PlatformNotSupportedException as a way to deliver disjoint feature sets moving forward. Instead, we'll either drop support for versions of the .NET platforms that don't have the features or deliver the feature as an independent NuGet package that itself isn't supported everywhere.
Going with the netcoreapp direction allows fixes to be shipped in minor versions.
How is that different to the 1.0 approach? @davidfowl said new APIs would require new TFMs, which means you'll have to opt out of LTS to get fixes relying on new .NET Core APIs. Not really an ideal situation.
Differentiating to netcoreapp is exactly what they're doing here.
Differentiating is totally fine and I definitely agree .NET Core should be the preferred target for ASP.NET Core. But that doesn't imply ditching .NET Desktop completely, specially when alternatives like cross compilation exist.
We need to balance simplicity in API surface & reach with developer productivity.
Sure. But you also need to balance that with the fact legacy libs - developed for .NET Desktop and using features not available on .NET Core - should work fine in the ASP.NET Core 2.0, just like they did in 1.0.
Instead, we'll either drop support for versions of the .NET platforms that don't have the features or deliver the feature as an independent NuGet package that itself isn't supported everywhere.
That's totally fine in theory. But thing is the platform that's currently lacking important features is .NET Core, not .NET Desktop. This will probably change in a few years, but what's sure is that people will still find missing features in .NET Core 2.0.
Might be worth having a forward-port repo in dotnet where people can make api requests for specific items they consider missing from .NET Core from .NET Framework?
Then feedback, reviews and guidance can be done outside of the day to day noise of the code repos? Or a general api review/spec repo (Sort of like csharplang vs roslyn)
Also will be a good go to for: "I have conversion issue and need to search for issue related to X api" Whereas corefx is very noisy for that.
[@benaadams] Might be worth having a forward-port repo in dotnet where people can make api requests for specific items they consider missing from .NET Core from .NET Framework?
I'd say these are simply issues in CoreFx. Also, our promise generally is: if the type is shared between .NET Framework and .NET Core, we intend to port newly added members to .NET Framework. In very rare cases this might not be possible, but the stake in the ground is that they are automatically considered.
[@benaadams] Or a general api review/spec repo
Not sure it's worth it. API reviews are already somewhat heavy handed; extracting them to another repo seems to amplify that. I'd rather we keep streamlining CoreFx so that adding new APIs is as simple as doing it in, say, ASP.NET.
as previously stated, they'll be able to continue referencing libraries/frameworks targeting .NET Framework, and that will work just fine assuming the APIs they call are part of the closure of netstandard2.0
@DamianEdwards What about the APIs not in the closure of netstandard2.0? Most 3rd party libraries are closed source. How am I able to tell that every edge case is in the closure of netstandard2.0?
As @PinpointTownes hinted, this is a kinda like playing Russian Roulette.
@MJomaa tooling will help here but obviously the only way to know for certain is the actually run it. That's actually no different from a .NET Standard library running on a .NET Standard supported framework. API's existing don't replace the need to test these libraries. That's not to say that netstandard implementations don't aim to be compatible, but they are edges, e.g. https://github.com/dotnet/standard/blob/cc9f646354fc68a13707a82323d4032b8dbfda52/netstandard/src/ApiCompatBaseline.net461.txt
Those are APIs that exist in NS 2.0 but not in .NET Framework 4.6.1.
I got really nervous about this change, but after reading the thread it seems fine in theory. We have 5 ASP.NET Core apps with 4 of them on full framework, but that was mostly just us being defensive than anything else and taking the path of least resistance.
I think some sort of tooling baked into VS like the .NET Core Portability Analyzer could help the devs who aren't up to date on Twitter/GitHub and aren't aware that this extension even exists. The "suggest an extension" pop up comes to mind, but I'm not sure what action a person would be taking to trigger that. Trying to add a net46x lib to an ASP.NET Core 2+ app maybe?
Stuff Microsoft can't control like 3rd party support with Telerik, Syncfusion, etc. will be a potential blocker too depending on what they're doing.
The messaging in this GitHub thread needs to get out into a blog post ASAP with an FAQ or something. I feel like I've been staying on top of everything, and I still wasn't 100% sure if this meant we could reference net46x libs or not. I clearly wasn't the only one confused by that either.
To echo what others have been saying. I have talked with at least 10 devs who didn't know ASP.NET Core could run on full framework. I had the same experience as @aL3891 though where devs were really happy they could run ASP.NET Core on full framework and their internal libs would just work. Again - the messaging about .NET Core 2.0 having a vast majority of use cases will be very, very important. The piece about having at least a Windows-only solution for like System.DirectoryServices in the works will also be important too. A lot of NET devs I talk to give a shrug when they hear that .NET Core is cross-plat and care more about their existing code working than x-plat/perf.
Guys, this is kind of garbage :(
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. Let me move on to the concrete use cases..
I work in a tooling group which builds line of business libraries and applications for use internal to a company and for sale to 'enterprise' clients. Mostly government organisations in our case but I'm sure you'll be hearing the same thing from the private sector. We have internal frameworks which encode business patterns into common abstractions - think "IDatabaseConnection", "IEntityProvider", "IWizardFlow", "ICodeGenerator" - and build RAD frontends on top of these pluggable backends.
In our stack, ASP.NET Core is a 'plugin' - it's an HTTP destination, used as a datastore abstraction and for hosting services and so on. It's also a 'frontend' - obviously a bunch of the LOB apps out there are websites, and it's a great new framework for webapps. So we have bidirectional interoperability requirements - A.N-C code which references random other components, and random other code which references A.N-C.
We're totally fans of Core CLR and portability, and we've ported a bunch of our components to target or multitarget netstandard. We've got one app that's hosted on Linux so far and hope to have more to come. However, there's no way that everything is going to be ported any time soon! We have still-live, actively-developed code which relies on
- NTLM authentication (including advanced scenarios around tokens and SPNs)
- System.Drawing as above (interesting wrinkle here: we need old image formats like TIFF, which new OSS libraries don't support)
- Connecting to WCF/SOAP apis - still tons and tons of these out there
- Windows crypto apis (including RSACng, ECDSA, and CSP for PKI tokens)
- WPF guis - our clients are not switching to windows 10 any time soon and even when they do they won't want Store apps
- Microsoft Office interop (particularly access and excel) for data import and export
- Visual Studio extensibility
- Third party plugins like the Oracle ADO.NET provider
Some of these technologies are never going to be supported by Core CLR. But they are real technologies, which are the basis of new app development - we need a version of .NET which has access to this stuff. Right now our position is manageable: we isolate "legacy" (really: platform-specific) dependencies into their own components which are net461 specific. Specific business apps then take a dependency on netfx if they need these features, and not otherwise. I envisage a future where this is rare for new apps.. but it's hard to imagine it ever being 0%.
You did all this work on csproj and the SDK because interop is important. ASP.NET Core is the carrot, the reason to want interop. I do not think it makes sense to take it away. And no, "you can load your references in one direction, but they will likely fail at runtime" is not interoperability.
@gulbanana Can you describe the parts of the system that use ASP.NET Core why they need to be in the same process as .NET Framework. I appreciate the list (Visual Studio plugings, office interop etc) but are you embedded ASP.NET Core in all of those places today (I don't have a good picture from the above description)?
Also what were you using before ASP.NET Core existed? Or is this just a new endeavor that never used ASP.NET but took a 5-10 year bet on ASP.NET Core on .NET Framework being a thing? Did you look at Katana?
OK, here are some specific case studies. I'll say up front that I'm sure a lot of these could be handled by running the desktop-specific work in a separate process, though it seems like a huge hassle to basically turn a bunch of interface implementations into RPC. It's not like we can just use remoting or binary serialization between core and desktop CLRs, either..
NTLM/AD
For Single Sign On purposes we have apps which rely on the browser passing Windows login credentials through to IIS, which passes them on to an ASP.NET Core website. Part of the authentication process is then looking up information like whether the user is in a particular AD group. I'd really like to hear more about the "windows support pack" and whether it's intended to cover things like this.
System.Drawing
This is used in a webapp which creates thumbnails and basic image edits (rotation, watermark overlay). Many of the images being used date back to the time of dinosaurs, so there are things like TIFF in there. They're data maintained by a government department relating to particular property listings and land management. In this case the application was initially ASP.NET MVC, and got upgraded/rewritten through MVC 2, 4, 5 and now Core.
VSIX
This is a case of embedding A.N-C in netfx instead of the other way around. We have Visual Studio extensions for code generation which run 'templates' for various RAD scenarios. Some of these templates were created for web development and refer to A.N-C types at design time (they're created using preprocessor/runtime T4).
Crypto
This one really does have to be in-proc I think - we have licensing scenarios where the code is very security-sensitive. Broadly speaking, it's decrypting and verifying license files with respect to the environment the code is running in - this is a common library used in the backend of webapps as well as desktop apps. Eventually .NET Core seems likely to get enough crypto support that this one can be ported, but it hasn't today. For example, we one option we have today is Fortinet/ePass2003 PKI token support, where their middleware definitely does not support Core (and there's no timeframe for doing so).
Oracle ADO.NET
Using Entity Framework 6 with an Oracle backend doesn't have to be in-proc but it sure would be inconvenient for our websites to add an extra tier just to get to a database!
WPF Interop
We use Microsoft.Extensions.Logging in all our desktop applications these days- the logging abstractions themselves will need to be in-proc, even if implementations aren't.
As for what we used before ASP.NET Core - ASP.NET MVC! We could go back but it would be a great shame to give up all the benefits.
As an architect it's my screwup to have not looked into whether "ASP.NET Core runs on full framework" would persist beyond the first version. It honestly never occurred to me that it wouldn't. I just didn't imagine the possibility that as early as 2018 there might e.g. be no supported version which could load Office documents...
One thing I'm not clear about is where ASP.NET Core is used in each of those scenarios you mention.
NTLM/AD
This one makes sense and I'd like to understand what APIs that ends up mapping to. Is this just System.DirectoryServices? That one is actively being worked on (you can see it in corefx).
System.Drawing
This is a known gap that we're looking at addressing. I don't have any answers here yet and I won't suggest rewriting using ImageSharp (though that is an option). This will need to be addressed.
VSIX
Where's the ASP.NET Core here? Is it running inside of a visual studio extension?
Crypto
Is there a corefx issue for this one? Why wouldn't it just be ported? Unlike .NET Framework, .NET Core releases are decoupled from the OS so it's possible that this could happen sooner rather than later if deemed important. (Disclaimer: I don't know enough about crypto to understand the implications of doing this cross platform).
Oracle ADO.NET
Where does ASP.NET Core come in here? Are you just saying the Oracle provider hasn't been ported to .NET Core yet?
We use Microsoft.Extensions.Logging in all our desktop applications these days- the logging abstractions themselves will need to be in-proc, even if implementations aren't.
Microsoft.Extensions.* will remain netstandard so you're covered there.
Why no announcement/discussion?
I love what aspnet/.net core team do, but I have the same fears as @jhurdlow.
Glad to hear about M.E.L. On the other points-
NTLM
Here's one class which is used in most of our applications. It makes pretty trivial use of the API, stuff which hopefully could be ported in theory (but hasn't been).
https://gist.github.com/gulbanana/70fe791735ee884169e2eee354a32ad2
VSIX
The codegen templates specific to asp.net core use the action/routing system (IFileProvider etc) to discover controllers and views etc and fill in our scaffolding. We're not hosting an ASP.NET webhost inside of visual studio, just introspecting over ASP.NET applications.
Crypto
I suspect the algorithms we use will be ported, but they haven't been yet. This would all look a lot different if the premise was, like, an announcement of a long-term plan to drop support for asp.net-core-on-netfx and discussion of when that might be possible!
Oracle
Yep, this would be resolved if an Oracle port happens (assuming it's full-featured and so on).
One more use case:
One of our applications imports legacy data from an Access application. Right now that import process runs on a server in an asp.net core website. It uses COM interop to load acedao.dll from the accdb/jet engine redistributable, reads tables into our entity abstractions, then saves them into a more modern SQL database.
This is another case of 'could be out of proc, but why should it have to be'. We'd essentially be using A.N-C as a frontend to a WebAPI 2 website or something, in which case we've gone back to that dependency on the past :(
Overall our goal is to move the vast majority of what we do to .NET Core. We would like as much interop as possible for as long as possible while we move things over...
WTF !!! 😨
Are you saying that ASP.NET Core 2 will not target Full .NET framework 4.x anymore !!!
We just starting a project 1 month ago with ASP.NET Core 1.1 and we targeted .NET 4.6 because we reference some Full .NET Lib. And we were going to upgrade to ASP.NET Core 2. But what I'm hearing from this post... 😞
Look, we chose ASP.NET Core because of its benefits (DI, merged API and MVC, ... powerful), so, please give as a change dude.
We just starting a project 1 month ago with ASP.NET Core 1.1 and we targeted .NET 4.6 because we reference some Full .NET Lib
What do those libraries do? Did you read @shanselman 's initial reply #2022 (comment)? It's possible to reference some .NET Framework libraries in .NET Core 2.0 (assuming they stay within the subset of APIs).
What do those libraries do? Did you read @shanselman 's initial reply #2022 (comment)? It's possible to reference some .NET Framework libraries in .NET Core 2.0 (assuming they stay within the subset of APIs).
@davidfowl yes I read @shanselman 's comment, we use some Libs made by company some of those lib uses WCF, all those Libs are stable, they target .NET 3.5, and we cant touch them.
This is going to be a very common situation. I'd love to know whether any information has been gathered (telemetry?) on just how many users of ASP.NET Core are on .NET Core vs .NET Framework so far.
I am personally not emotional about this, but some observations:
- most customers I have today use the asp.net core 1.x/full framework combination because they are scared to go all-in on the new stuff
- telling from the nuget package download numbers, adoption of asp.net core is not great. With that move it will be even a bit harder to sell something that doesn't sell well right now.
- it is great that you have identified the LDAP stuff to be a gap (I think I never seen anyone in the last 10 years using those libraries but maybe that's just me). The bigger issue will be 3rd party libs. These will be the real reasons why people will not move to .net core
This whole situation is again another good example of MS just making a decision without any heads up. Only because some people follow the check-ins, this thread here exists.
I might be wrong, but I thought .NET Core is now under governance of the DNF - so these decisions are not purely MS internal anymore.
The LDAP/AD stuff is definitely a reason why I need to stay on top of net462 right now. I'd love to completely go, BAM -> NetCore completely, but this is a drawback.
I'm also using XML-RPC.net in one of my projects. It uses some serious Reflection.Emit in it, and I'm not sure whether NetCore 2 will support it completely. I'll have to try the Portability Analyzer to see for sure, though.
I find this whole situation a bit disheartening with just how quickly and easily an important decision like this which affects the future of .NET can happen without any transparency, at the last minute, yet again. Lots of energy has been invested in selling the existing .NET ecosystem on migrating to ASP.NET Core with the messaging (from my understanding) being that .NET Standard 2.0 will focus on compatibility and will be the release that bridges the gap with .NET v4.x to finally produce a solid, stable .NET platform the ecosystem can finally depend upon. I personally don't believe .NET Core will really take off until after .NET Standard 2.0 is released as I anticipated it to be the "promised stable land" we're all waiting for - now I have no idea what ".NET Standard 2.0" means, what exactly it's going to cover and which libraries are planned to be .NET Core only.
As there has been no prior official announcement, request for feedback, polling or rationale given, this decision "appears" to be have been done with zero community involvement or impact analysis to the existing .NET ecosystem and will likely fragment the entire ecosystem for many years to come. Removing .NET v4.x support removes a smooth migration path for many enterprises to be able to migrate their existing code-bases to ASP.NET's new development model. This won't encourage them to jump to .NET Core faster, it effectively prevents them from even attempting to, causing a massive fragmentation that will fracture the .NET ecosystem in two. I don't see how this will end up being any different than Python 2/3 which has been irreparably harmed by the fragmentation which it still hasn't been able to recover from in nearly a decade.
Most existing .NET code-bases are brownfield being developed behind-the-scenes by "dark matter" .NET developers, most of which won't have any idea that this decision was made given .NET Core 1.1 supports .NET v4.x and the messaging for .NET Standard 2.0 was the promise of improved compatibility. I'm expecting a massive backlash once the news and impact of this decision finally hits home. Many devs who have been selling adoption of .NET Core internally within their organization are going to feel betrayed given they've effectively have been migrating to a dead-end platform (if they're unable to fully migrate to .NET Core for whatever reason) a harsh reality they'll need to face just after they've succeeded in the monumental decision of convincing stakeholders in their organization to approve the resources required for their current migration.
Most organizations need to migrate their existing code-bases "in-flight" where they need to continuously deploy their existing systems whilst migrating their code-base "in parallel" which are going to want to deploy to .NET v4.x first, then after everything has stabilized and all issues have been ironed out they can then plan on a full migration to .NET Core from there.
This decision is also being made in the context of years of breaking changes to ASP.NET which IMO have eroded the trust that .NET is a stable platform that organizations can depend on. I love .NET Core's new development model, but IMO what we need most is a stable platform we can depend upon that the rest of the ecosystem can catch up to. .NET Core is still in uncanny valley, with immature tooling, incompatible dependencies, runtime issues, out of date documentation, etc - I haven't seen .NET this unstable since the early days when it was first released.
Why not run a poll on what .NET devs want more? i.e. a a solid, stable polished platform or a "fast moving" platform that delivers new features faster? I understand it would require a lot less effort to not have to worry about back-porting features to .NET v4.x but it would be invaluable to have a version of ASP.NET Core that focused primarily on delivering a stable compatible platform with long term support that can run on either .NET v4.x or .NET Core.
Has this ship sailed or is there an option to keep ASP.NET Core 2.0 as it is? i.e. with most libraries and abstractions covered by .NET Standard 2.0 and then in the next ASP.NET Core 3.0 release announce that the next platform will be .NET Core only? This will allow organizations to continue to move forward and adopt ASP.NET Core 2.0 and allow the rest of the ecosystem to catch up to, with stable and well supported tooling and libraries, whilst having a clean split from where .NET Core only platform/features start.
It's possible to reference some .NET Framework libraries in .NET Core 2.0 (assuming they stay within the subset of APIs).
This breathes uncertainty, very few people are going to want to risk their reputation and the health and stability of their systems and attempt a full migration to .NET Core when uncertainty exists on exactly which of their dependencies will and will not be able to run on .NET Core, which means more people staying on .NET v4.x for the foreseeable future.
I don't really know how this will ultimately play out and what the true impact of this decision will have on the entire .NET ecosystem, but the fact that important decisions like this with broad impact can happen without any external community involvement is concerning.
I wish you guys were a little less hell bent on bifurcating your user base.
My point of view when creating a library is to make it easy to use as possible, for as many people as possible, in as many places as possible. It is a pain in the neck (search for #if compiler directives in Newtonsoft.Json and you get 1300+ results) but "It just works" is a powerful selling point.
Why not run a poll on what .NET devs want more? i.e. a a solid, stable polished platform or a "fast moving" platform that delivers new features faster? I understand it would require a lot less effort to not have to worry about back-porting features to .NET v4.x but it would be invaluable to have a version of ASP.NET Core that focused primarily on delivering a stable compatible platform with long term support that can run on either .NET v4.x or .NET Core.
Genuine question, ASP.NET Core 1.x currently supports .NET Framework and .NET Core. Lets say it was the stable platform you mention above, that we bug fix and support on both runtimes but didn't get more features. Would that be enough?
ASP.NET Core and .NET Core are the fast moving feature rich platforms for .NET at this point. It's a version of .NET that isn't tied to any operating system and that gives us the agility needed to innovate rapidly and release faster.
Has this ship sailed or is there an option to keep ASP.NET Core 2.0 as it is? i.e. with most libraries and abstractions covered by .NET Standard 2.0 and then in the next ASP.NET Core 3.0 release announce that the next platform will be .NET Core only? This will allow organizations to continue to move forward and adopt ASP.NET Core 2.0 and allow the rest of the ecosystem to catch up to, with stable and well supported tooling and libraries, whilst having a clean split from where .NET Core only platform/features start.
We're always open to feedback and ASP.NET Core 2.0 hasn't shipped yet. If ASP.NET Core 3.0 was the release that dropped .NET Framework would that make things better? If you look at some of the feedback from @gulbanana and @ikourfaln, there are technologies that are likely never to get ported and thus will never work on .NET Core, doesn't that mean supporting .NET Framework pretty much forever? Wouldn't we just have this same discussion a year from now? Maybe by then the ecosystem or libraries that support .NET Core would be bigger so it has less of an impact? What about those enterprise libraries that will never be updated (or where the source code was lost)? Will those change in a year?
My point of view when creating a library is to make it easy to use as possible, for as many people as possible, in as many places as possible. It is a pain in the neck (search for #if compiler directives in Newtonsoft.Json and you get 1300+ results) but "It just works" is a powerful selling point.
No offense @JamesNK but JSON.NET is a JSON parser and for the most part a single package (I know there are a few more). ASP.NET Core has > 200 packages.
No offense but I'm one guy working part time. Your problem is harder but you have exponentially more resources.
After reading through this and looking through the dependencies we have, I'm far less convinced this is a good idea.
As plans stand, we can't port any of our apps over to netstandard/netcoreapp until System.DirectoryServices is available (CoreFX issue #2089 here). So while we can port to ASP.NET Core 1.x, we can't go to 2.0. Looking at the applications here: Opserver, Stack Overflow itself, our internal apps...nothing would be ready as 2.0 is pitched to be at this point. According to the standup this week, critical things like DirectoryServices would still follow in a 2.x later release.
So between 1.0 and 2.0 it's changed from something I was preparing to move to, into something I can't go to. So yeah, I'd say it's not ready. ASP.NET is a way to expose the bits I need over HTTP. ASP.NET Is not the thing I need in itself. I'm not using .NET just for the web bits, I'm using it for the platform...as are a great many people. The platform is not ready for the wide variety of use cases users demand, so forcing users onto that platform causes pain and blockers.
The bottom line is that if we need AD auth (a huge part of the platform), we've just been abandoned on the 1.x line. That's where I was headed with our apps...but if this is the direction then there's no point is putting in effort here until the bits I need are available at the destination.
If we can say these critical things like System.DirectoryServices, System.Drawing, and the other top items people need will be ready with ASP.NET Core 2.0, my opinion changes a lot. If they're an afterthought (as current schedules show), please continue supporting the .NET Framework until they are.
Moving fast is great. I love it. I'm running alphas in production right now. But none of that matters if it doesn't work for your use case in the first place.
One thing I'm personally struggling with is the "stable platform" vs "new features" thing. On one hand, we want the platform to be stable and reliable and compatible, on the other hand nobody wants to stay on 1.x because it's doesn't have 2.x features. Are there super compelling features in ASP.NET Core 2.x that are pulling people in that direction or is it just the fact that we have more features than we had in 1.x (because it's new and shiny)?
If it's the latter, then do those people care about stability? If the answer is yes, then why isn't ASP.NET Core 1.x sufficient?
I'm not using .NET just for the web bits, I'm using it for the platform...as are a great many people. The platform is not ready for the wide variety of use cases users demand, so forcing users onto that platform causes pain and blockers.
Agreed, but in your opinion, how does that relate to ASP.NET Core 2.x dropping .NET Framework support? When more dependencies come online, they'll work every where so in a sense, as the platform moves forward the broad set of runtimes will get the benefits. All versions of ASP.NET Core applications would suddenly be able to take advantage of of those features.
If it's the latter, then do those people care about stability? If the answer is yes, then why isn't ASP.NET Core 1.x sufficient?
Everyone always wants new features, the possibility of new features, or at least knowing that they'll have the option to get more goodies sometime later. When you close off a platform and put it in "stable"/"maintenance mode, people see that as no longer being paid attention to.
Are there super compelling features in ASP.NET Core 2.x that are pulling people in that direction or is it just the fact that we have more features than we had in 1.x (because it's new and shiny)?
Support - that's what we're paying for.
If the answer is yes, then why isn't ASP.NET Core 1.x sufficient?
Because support ends just about a year after release (according to Scott above). And I may barely be done porting Stack Overflow by then.
how does that relate to ASP.NET Core 2.x dropping .NET Framework support?
Because libraries I have to have aren't there. And I don't know when they will be. So I'd be stuck on 1.x and I have a time bomb until support ends. Will I have enough time to port from 1.0 to 2.x (or 3.x) before support ends? Probably not.
Large codebases can't just stop and port, they need time, it needs to happen in stages. Doing a .NET 4.6.x port onto ASP.NET Core was feasible as an intermediary step. Going to core at once is much harder, takes much longer, and requires longer-lived branches and more pain. If we can't do this in stages, I honestly just can't see us ever making the move off the the now-abandoned ASP.NET 5 line. There's no way I can justify the time, cost, and development impact it'll have.
I think many OSS authors are like myself as well - it's an extension of our day jobs. If we aren't using the platform or dogfooding it, the libraries are far worse off or don't get created. And we can't justify the time to maintain them with company hours that we spend today. And every library we make comes from a need we hit in production. The ecosystem dropping use cases has a lot of downstream impact that's not sudden, but still adds up.
Currently my view is this: there's a new platform that works until about July 2018. After that: I know nothing, I just hope what I need is available on netstandard/netcoreapp by then. And hope I have enough time to port before support ends. I'm not paid to hope though, I'm paid to make platform decisions for our company, and ASP.NET Core is a bad bet (for us) with this change and no date for a version that will work.
Let me offer a one-line summary: without .NET Full Framework support, ASP.NET Core does not offer a supported platform for our use cases for the next 2 years.
As a short version, it's this:
Priority 1: This has to work on net461, no matter what ifdefs, perf there is.
Priority 2. If you can make it 10x faster on .NET Core 2.0, then that's awesome. It's a great reason for people to choose the platform and/or migrate when they can.
The key thing here is that for long term support, it still has to work on the full framework, even if it's slower there.
Priority 1: This has to work on net461
And if .NET Core was fully compat with net461 (within reason); so anything written for net461 worked on Core; would that then be ok?
Basically, at that point you have a more stable platform than net4x as you can do side-by-side and self contained (touch of x-plat too). Whereas net461 has whole machine changes to 4.6.1, 4.6.2, 4.7 etc
Obviously somethings will never work; like partial trust - but that never worked anyway.
Genuine question, ASP.NET Core 1.x currently supports .NET Framework and .NET Core. Lets say it was the stable platform you mention above, that we bug fix and support on both runtimes but didn't get more features. Would that be enough?
I would love a to see a LTS release of ASP.NET Core 2.0 like Ubuntu / Redhat does with their LTS releases which they support for 5+ years. It would provide a solid compatible target that the rest of the ecosystem can have the confidence to commit to adopting.
I'm personally more interested in a stable .NET Standard 2.0 more than any future .NET Core-only features as I would love to get back to .NET development where everything just works again, the tooling isn't broken, the popular .NET packages all provide support for, the surrounding deployment and hosting solutions are polished and there's plentiful docs, posts, videos and knowledge-base available for a stable ASP.NET Core we can start building solutions on.
Wouldn't we just have this same discussion a year from now? Maybe by then the ecosystem or libraries that support .NET Core would be bigger so it has less of an impact? What about those enterprise libraries that will never be updated (or where the source code was lost)? Will those change in a year?
In an ideal world .NET v4.x and .NET Core would both support ASP.NET Core in the foreseeable future and it's only new .NET Core-only features which will only be available in .NET Core-only packages. But if MS is destined on leaving .NET 4.x behind then a ASP.NET 2.0 LTS release before you officially part ways would be the next best thing. By definition no-one is depending on new features that don't exist yet so no-one is going to be forced to upgrade to a .NET Core-only v3.0.
With the freedom of only having to support 1 platform you could potentially deliver new features that would entice developers to adopt the next latest and greatest version with continual new stream of features, personally I'm happy with the functionality ASP.NET has now and so I'm more interested in a stable version where everything's polished so I can go back to being productive again and focus on developing solutions on it instead of chasing an always moving platform.
Firstly, thanks @davidfowl for jumping into the thread and standing up/asking questions, etc. When there's a heated community asking heaps of Q's, it's easy to not step in and avoid being 'a target'. So thanks for getting involved, constructively. /me salutes you.
I see two main points/threads coming out of this conversation:
- Request to support .NET desktop in vnext. (that's 99% of the replies in here)
- Lack of community consultation over such an important decision. (the 2 or 3 replies in here).
TL;DR;
- Can we please be more open with big important vnext changes.
- Allocate some time for some RFC from the community about these vnext changes.
@mythz stated it nicely in his opening sentence to his (at this point), most recent 2nd most recent comment:
I find this whole situation a bit disheartening with just how quickly and easily an important decision like this which affects the future of .NET can happen without any transparency, at the last minute, yet again.
This is what really hit me personally and I would love some official replies/comments from the appropriate folks at MS who make these calls plz. "We" have been around this community for a hella long time - familiar faces, familiar names and it's pretty fair to say - all following the same positive goals. I'd even go on to say "we" are a pretty large, extended family, warts-and-all.
So I feel that with the new direction MS has taken (OSS-all-the-things, etc) and with some recent mega-uber-.NET-threads in the last 12/18 months (read: learning from those community discussion experiences) ... that "we" are all in this together and that some of these Really-Big-Things ™️ would be discussed in the open, way ahead of time.
So - can we please have some of these big decisions talked about in the open, before hand? Get some positive community consultation and discussion?
Note: I do accept that this project(s) are not a democracy and that the decisions are made by MS. No probs. I'm not criticizing that. I'm talking about the steps way prior to that. Also, I'm not asking for everything to be put up for RFC, etc. Just the odd major ticket item - like what this thread has started.
But if MS is destined on leaving .NET 4.x behind then a ASP.NET 2.0 LTS release before you officially part ways would be the next best thing. By definition no-one is depending on new features that don't exist yet so no-one is going to be forced to upgrade to a .NET Core-only v3.0.
I don't understand. No one is depending on features in ASP.NET 2.0 yet either as they don't exist in a release. So isn't ASP.NET Core 1.x that version? It runs on full framework, core 1.0 and core 2.0 and can act as the stepping stone to ASP.NET Core 2.x?
Everyone always wants new features, the possibility of new features, or at least knowing that they'll have the option to get more goodies sometime later. When you close off a platform and put it in "stable"/"maintenance mode, people see that as no longer being paid attention to.
Yes but it's really hard to guarantee the same level of quality when .NET Framework is the big stable supported tied to the OS component. As @terrajobst said, some things will definitely be ported at some point but others will need to be figured out. The fact is, ASP.NET Core runs best on .NET Core because we have the ability to rev the entire stack all at once. So far, there are big performance differences between the 2 runtimes and we've yet to take dependencies on new APIs because of .NET Framework support. As we move forward, we will be adding new APIs that may or may not appear on .NET Framework at some point and we don't want to rev at the pace of the most stable and slowest moving runtime (.NET Framework).
Because support ends just about a year after release (according to Scott above). And I may barely be done porting Stack Overflow by then.
I'm not sure that's entirely accurate. When 2.0 is available 1.1 will still be supported. So what is this "support" you're talking about? Do you mean paid support or do you mean that we'll fix issues when they come up?
Because libraries I have to have aren't there. And I don't know when they will be. So I'd be stuck on 1.x and I have a time bomb until support ends. Will I have enough time to port from 1.0 to 2.x (or 3.x) before support ends? Probably not.
Like I said though, those libraries will light up irregardless of the .NET Core version. I think what you're saying is that you want to use the latest version of ASP.NET Core (whatever that is) and you want it to be supported on .NET Framework until there are enough libraries on .NET Core so that the port is easy for you specific scenario.
Large codebases can't just stop and port, they need time, it needs to happen in stages. Doing a .NET 4.6.x port onto ASP.NET Core was feasible as an intermediary step. Going to core at once is much harder, takes much longer, and requires longer-lived branches and more pain. If we can't do this in stages, I honestly just can't see us ever making the move off the the now-abandoned ASP.NET 5 line. There's no way I can justify the time, cost, and development impact it'll have.
How does ASP.NET Core revving versions affect that? If we dropped .NET Framework support in 3.0 (as people seem to be eluding to in this thread), wouldn't you be in that same dead end regardless? You'd have your ASP.NET Core 2.0 application ported running on framework for a year and when 3.0 comes out, you'd be unable to upgrade. You would be able to do this anyway with ASP.NET Core 1.1.x which runs on .NET Framework and is supported even when ASP.NET Core 2.0 is out.
Currently my view is this: there's a new platform that works until about July 2018. After that: I know nothing, I just hope what I need is available on netstandard/netcoreapp by then. And hope I have enough time to port before support ends. I'm not paid to hope though, I'm paid to make platform decisions for our company, and ASP.NET Core is a bad bet (for us) with this change and no date for a version that will work.
So one more year is enough time for everyone? That's not the feeling I'm getting from this thread.
Priority 1: This has to work on net461, no matter what ifdefs, perf there is.
Priority 2. If you can make it 10x faster on .NET Core 2.0, then that's awesome. It's a great reason for people to choose the platform and/or migrate when they can.
The key thing here is that for long term support, it still has to work on the full framework, even if it's slower there.
The only reason .NET Framework works as well as it does today is because we were intentional about supporting it. It didn't come for free, it's not "just faster on core", we had to intentionally design the system so that it was possible to make it work on .NET Framework. Even though you don't see it yet, the feature gap will grow between the 2 once we decide (and we've decided) to take dependencies on APIs that don't exist in .NET Framework as yet. We can do what @PinpointTownes says and start throwing NotSupportedException when those feature gaps appear but IMO that's a pretty bad experience.
We spent a large development budget on porting our ASP.net MVC5 app to ASP.net core full framework to make it work nice with Azure Service Fabric. The whole project was multi-month in which there were several weeks dedicated to porting our web application (and frankly, wrestling with the awkward VS2015 tooling).
The only reason that worked was because full framework was supported, since we're currently running SignalR on ASP.net core (to @davidfowl discouragement). As far as I can tell, SignalR still isn't supported on Asp.net Core?
Then we spent a week or so migrating to the new VS2017 tooling. Fine.
Note that up to this point there are no improvements to the product at all, it's just adjusting code shape to fit into Microsofts platform and tooling requirements.
Now you're telling me that within 12 months I'll have to perform more featureless development effort with no guarantee that I'll even be able to do it, depending on a bunch of hand waving and should be able to's? No thanks.
First, get everything Microsoft branded that people are using in ASP.net core full framework today working on ASP.net core only. Second, find out what else (if anything) would be blocking the ecosystem from adopting ASP.net core as desired. Then, and only then, drop support for Netfx as is being discussed.
We can do what @PinpointTownes says and start throwing NotSupportedException when those feature gaps appear but IMO that's a pretty bad experience.
That's not exactly what I said: when going with cross-compilation, ifdefs should definitely be the preferred option to exclude APIs unavailable on a specific platform, but if for whatever reason you absolutely MUST have this API signature in the public contract, then you can go with NotSupportedException.
I don't understand. No one is depending on features in ASP.NET 2.0 yet either
I'm expecting most devs are waiting for a stable and highly compatible .NET Standard 2.0 that their dependencies are supporting before they commit to migrating to ASP.NET Core. They're not going to want to adopt .NET Core 1.1 now knowing it's been EOL'ed and MS doesn't have a good history of providing long term support for any old DNX/.NET Core version. If there was a highly compatible stable LTS release that the rest of the ecosystem can safely adopt, enterprises should have everything they need to run their systems on it and they wont feel obliged to upgrade to .NET Core vNext as they'll have everything they need on v2.0 and when the time comes it will be a lot easier to plan their migration from ASP.NET Core 2.0/.NET v4.6 to a future .NET Core only version.
I'm personally more interested in a stable .NET Standard 2.0 more than any future .NET Core-only features as I would love to get back to .NET development where everything just works again, the tooling isn't broken, the popular .NET packages all provide support for, the surrounding deployment and hosting solutions are polished and there's plentiful docs, posts, videos and knowledge-base available for a stable ASP.NET Core we can start building solutions on.
Agreed with everything there but I don't see how this decision affects anything you said. I want all of those same things 👍 .
With the freedom of only having to support 1 platform you could potentially deliver new features that would entice developers to adopt the next latest and greatest version with continual new stream of features, personally I'm happy with the functionality ASP.NET has now and so I'm more interested in a stable version where everything's polished so I can go back to being productive again and focus on developing solutions on it instead of chasing an always moving platform.
Right, isn't that ASP.NET Core 1.x? If support was extended on 1.x wouldn't that be enough? We could just make sure that ASP.NET Core 1. which is netstandard 1.x runs on .NET Core 2.0 (which it already does) and support that for say another year or so.