Aspnetcore: The new ASP.NET Core 2.0 packages can no longer be used on .NET Desktop

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.

@daveaglick

• Correct in that there's no implicit ability to reference netcoreapp2.0 from net461 or even netstandard2.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 targeting netstandard is 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.

@khellang

Yes, we just updated the VSIX for 2017, but I simply use the command line version from here.

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

@NickCraver

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 https://github.com/aspnet/Home/issues/2022#issuecomment-299544884

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.

@davidfowl https://github.com/dotnet/wcf/issues/8

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 PlatformNotSupportedException telling 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 https://github.com/aspnet/Home/issues/2022#issuecomment-299536123? 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:

1. Request to support .NET desktop in vnext. (that's 99% of the replies in here)
2. 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?

@onovotny

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

@NickCraver

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.

@mythz

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.

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 need to have this API signature in the public contract, then you can go with NotSupportedException.

I'm not even talking about exposing public API. I'm talking about APIs we need to call that won't exist in netstandard. #ifdefs don't help here. We would just throw as the gaps increase.

@davidfowl Totally valid questions - answers:

Do you mean paid support or do you mean that we'll fix issues when they come up?

Active fixes for issues - will 1.x receive fixes for all the things we break, or will we be told to upgrade for a fix in some cases? (note: that's an upgrade we can't do until our libraries like DirectoryServices are there...and even if we can it's nowhere close to a free or even cheap, it's likely months at a minimum). We're big, we're fast, we will find breaks in the framework. We have for every major and minor release for years. Support is critical to us.

I think what you're saying is that you want to use the latest version of ASP.NET Core

Nope, I want a version that works and a path forward. With 1.x, we only have the first half. Until this issue, the second was kind of assumed.

How does ASP.NET Core revving versions affect that?

Because if you're dropping support for full framework, we're forced to make a major change to stay in support.

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?

Maybe? The point is having parity in use cases before making the dive. It's my career, I can't tell our company to jump when the other side may not support us. That'd just be irresponsible on my part. If our use cases were supported in the 2.x timeframe, then there's a clear path forward and it's far safer to make bets on ASP.NET Core.

So one more year is enough time for everyone?

The absolute length of time doesn't really matter - it needs to be use-case compatability + time (IMO). If our use cases worked today (e.g. AD auth), then 2 years is enough, yes. But currently that's not the case, so agreeing that an arbitrary point in time from now is okay is, at best, premature.

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.

Then no offense, but why not just say that and close the issue? That statement seems like there's nothing more to discuss, and our time is better spent elsewhere. If that's not the case, please clarify?

The main problem is we can't port our workloads to netstandard today, or, as currently proposed, at launch. If what we already have doesn't work, why would we care about new features? The team keeps talking about performance (and that's awesome, really), but something I can't use running fast really doesn't matter much.

As an architecture/platform lead, I have to decide what bets we make. Currently, this is a bad bet. When version 1 supports you but version 2 doesn't but hopefully will someday, that's a really bad gamble to make with other people's time and money. At least for us, we chose .NET for the features, ecosystem, and support. Currently, in the new word we've gone from all 3 of those to 1. The ecosystem isn't there yet (API surface, libs), and support is far shorter than we're used to, without any guaranteed upgrade path and an unknown amount of time to do so.

@jahmai

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?

Even the SignalR 2 isn't supported on ASP.NET Core (though people have hack it to make it work). SignalR is still under development and won't even be out with ASP.NET Core 2.0, it's coming later.

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.

Are there features you need in ASP.NET Core 2.0? Or are you just speculating that eventually you'll need to upgrade to the next ASP.NET Core and at that point things won't work on .NET Framework?

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.

As part of netstandard 2.0 lots of work was done identifying important APIs to bring back so that libraries that targeted .NET Framework were for the most part binary compatible with it. Of course there are areas that just won't work like WCF, WPF etc. but it will help as we did some research and ~60% of the libraries are API compatible with netstandard 2.0 (correct me if I'm wrong on that number @terrajobst) and may just work on .NET Core 2.0.

Right, isn't that ASP.NET Core 1.x? If support was extended on 1.x wouldn't that be enough?

I expected .NET Standard 2.0 was going to be the stable platform which bridges compatibility with .NET 4.x so it makes more sense LTS support will be around that. No-one is expecting 1.1/.NET v4.x to be EOL'ed mid-release so it would be respectful to announce LTS on the latest version when it's released, not pulling .NET 4.x support before it's released, no-one does LTS in retrospective to old versions like that.

I know we're maintaining our .NET Core packages in a separate *.Core packages so we can remain on a separate release cadence that follows the latest .NET Core version as the moment we merge into the main NuGet packages it means we're committing to a stable release that we're going to officially support, so we need to be highly confident we have a version we can support for the foreseeable future which I expected from .NET Standard 2.0, not the current .NET Standard 1.1/1.3/1.6 mix. I remember there was also a time where there was going to be a 1.7/8 stop gap release that was going to be incompatible with 2.0 breaking the .NET Standard versioning expectation which aren't signals of a stable platform.

I've been anxiously expecting .NET Standard 2.0 was destined to provide the much sought after highly compatible surface area and much needed stability.

Even the SignalR 2 isn't supported on ASP.NET Core (though people have hack it to make it work). SignalR is still under development and won't even be out with ASP.NET Core 2.0, it's coming later.

Not sure how you intended that statement, but I feel it just reinforces my concerns.

Are there features you need in ASP.NET Core 2.0? Or are you just speculating that eventually you'll need to upgrade to the next ASP.NET Core and at that point things won't work on .NET Framework?

I want to move to netstandard2 at some point for reasons. I'll need to move to move my web app to asp.net core 2 for that, right?

As part of netstandard 2.0 lots of work was done identifying important APIs to bring back so that libraries that targeted .NET Framework were for the most part binary compatible with it. <...>

Sure, and I like what's being done with netstandard, but if something was missing from netstandard you can work around because you can target full framework in applications that need it. We now have a handful of pure netstandard 1.3 libraries (our source) shared across: Xamarin.iOS, Xamarin.Android, net46, Asp.net core 1.1 - because we can suppliment missing funtionality in netstandard with specific framework targetting libraries, including net46 stuff in our asp.net core web app.

The _only_ reason we have these netstandard libraries is because we needed to port our huge web application (as I mentioned previously). I would _like_ to not have to expand our platform specific code base for other platforms, and instead keep moving up the netstandard chain. I really don't want to be stuck on netstandard 1.3 because there is no path to move to asp.net core 2.

Active fixes for issues - will 1.x receive fixes for all the things we break, or will we be told to upgrade for a fix in some cases? (note: that's an upgrade we can't do until our libraries like DirectoryServices are there...and even if we can it's nowhere close to a free or even cheap, it's likely months at a minimum). We're big, we're fast, we will find breaks in the framework. We have for every major and minor release for years. Support is critical to us.

I don't think there's an issue with support. I actually don't think this would be a huge problem and if it made people feel more confident in taking a bet then maybe it's worth extending support for 1.x to a longer timeframe.

Nope, I want a version that works and a path forward. With 1.x, we only have the first half. Until this issue, the second was kind of assumed.

It just means you need to stay on 1.x until all of your dependencies are ported no?

@NickCraver All of your complaints are talking about things missing on .NET Core rather than ASP.NET Core. In .NET Core 1.x and ASP.NET Core 1.x those 2 entities ship together but are completely decoupled. I haven't heard a single reason for wanting to use ASP.NET Core 2.0 specifically other than valid concerns about v1 supporting something and v2 not supporting it. I think we'd be having the exact same discussion in a year if there was another reason you weren't able to port to .NET Core only (maybe during the development of ASP.NET Core on full framework you took some new dependencies that will never be ported as an example).

Then no offense, but why not just say that and close the issue? That statement seems like there's nothing more to discuss, and our time is better spent elsewhere. If that's not the case, please clarify?

I'm here answering and replying because I'm trying to figure out why we need to support .NET Framework if so, for how long. I'm still getting a mixed vibe on this thread about those time frames. Also there's a general fear I can understand about being "relegated to ASP.NET Core 1.x" but nothing concrete in terms of specific features that are needed in 2.x.

One of the major things I like about coupling .NET Core and ASP.NET Core is that it solves some of the versioning and naming madness. Lots of people don't even know ASP.NET Core runs on .NET Framework (it even confuses new comers to the stack). That said, we have lots of customers with lots of different needs and we listen to their feedback.

@mythz

I've been anxiously expecting .NET Standard 2.0 was destined to provide the much sought after highly compatible surface area and much needed stability.

Sure, but like I said, ASP.NET Core, .NET Core and .NET Standard in 1.x are completely decoupled. You can use any .NET Standard library on any version of .NET Core that supports it. So if .NET Core 2.0 is a new LTS, we could still declare that ASP.NET Core 1.x is supported on it.

@jahmai

I want to move to netstandard2 at some point for reasons. I'll need to move to move my web app to asp.net core 2 for that, right?

No, that's not right. You can move to netstandard 2 whenever you want without moving your web app to ASP.NET Core 2.0.

The only reason we have these netstandard libraries is because we needed to port our huge web application (as I mentioned previously). I would like to not have to expand our platform specific code base for other platforms, and instead keep moving up the netstandard chain. I really don't want to be stuck on netstandard 1.3 because there is no path to move to asp.net core 2.

You don't need to be stuck on netstandard 1.3. The 2 things are unrelated.

When version 1 supports you but version 2 doesn't but _hopefully will someday_, that's a really bad gamble....

This I think is the crux of the issue. We've had comments that _some_ of the gaps (DirectoryService, et. al.) are known and will be addressed. We need something more concrete then that.

I'm OK with ASP.NET Core targeting .NET Core and with us missing the 2.0 boat if the roadmap is clear on when we can expect these gaps (and which gaps) will be addressed (again, assuming there's enough time to port before 1.X becomes unsupported).

As things currently stand, the issue we're blocked on for WCF has been stagnant since May 2015 and may never get addressed.. Leaving us effectively stranded.

@davidfowl

No, that's not right. You can move to netstandard 2 whenever you want without moving your web app to ASP.NET Core 2.0.

Excellent. In that case, as long as Microsoft ensures that 1.x is supported (all kinds of bug fixes and operational support) until it offers customers a proper 2.x migration path (e.g. SignalR), then I am comfortable biding my time until we need asp.net core 2.

It just means you need to stay on 1.x until all of your dependencies are ported no?

Correct, but that has to be a known timeframe. We have no dates, the only thing we've been told so far is "not in 2.0"...so that's not good. For example, System.DirectoryServices has been requested since Mid-2015, and is still missing yet is often repeated as the most wanted by users (followed by System.Drawing). Saying we're bringing .NET Standard 2.0 to ~60% API parity but missing the bits users have asked for most certainly sends mixed signals about what's important.

All of your complaints are talking about things missing on .NET Core rather than ASP.NET Core.

That is incorrect. I need the bits we need to run (e.g. AD auth) on a supported platform. The missing thing is support from the latter. Support for 1.x is certainly my main concern. We have no supported path forward or any timelines for when we can expect one.

I think we'd be having the exact same discussion in a year

I don't think that's the case. The problem is we couldn't port today. The APIs aren't there. As long as there's no single point in time we were even capable of porting, discussions about the future are a bit moot. I would expect .NET full framework support in ASP.NET Core to be deprecated once there was parity and most users could move over. And I'd expect that release to have a long support timeframe for people to move over.

If DirectoryServices, Drawing, etc. are coming in 2.x then awesome. That release should support .NET Framework, and be a LTS release. And 3.x should drop full framework support.

One of the major things I like about coupling .NET Core and ASP.NET Core is that it solves some of the versioning and naming madness. Lots of people don't even know ASP.NET Core runs on .NET Framework (it even confuses new comers to the stack). That said, we have lots of customers with lots of different needs and we listen to their feedback.

Fair enough, but all of the madness there is secondary to "does it even work?". Currently, that's a firm no. ASP.NET and .NET Core/Standard/whatever may be 2 sets of things inside Microsoft (and I totally get that), but to developers it's still 1 platform. The ASP.NET Side needs the APIs to be useful to many, and they're not there yet. This move further cuts down on the available APIs. The ASP.NET team may get the ones they want, but it's at the expense of the ones we need.

@ctolkien @NickCraver

This I think is the crux of the issue. We've had comments that some of the gaps (DirectoryService, et. al.) are known and will be addressed. We need something more concrete then that.

Correct, but that has to be a known timeframe. We have no dates, the only thing we've been told to far is "not in 2.0"...so that's not good. For example, System.DirectoryServices has been requested since Mid-2015, and is still missing yet is often repeated as the most wanted by users (followed by System.Drawing).

These gaps are related to .NET Core itself though and I can understand the anxiety not knowing when those dependencies will be available and that's why helping us prioritize these would be good. The good news is that netstandard 2.0 and netcoreapp2.0 laid the group work to make of other libraries easier to port. I expect that after once we ship 2.0, it'll be much easier to bring up other dependencies by porting swaths of code on top of our very compatible base.

Will CSOM run in netcore 2? That would be a huge blocker for us and one area that I haven't heard anything​ on.

@davidfowl I sincerely hope that's the case too, but I'm not betting our company on it. Dropping support before that happens, and not after, I strongly disagree with. I think this happening in the 3.x time frame after those critical APIs for many consumers are in place is totally valid. Doing so before they're ready just halts our adoption.

I was on the path to adopting 1.0 assuming that 2.x (or whatever's actively developed/fixed) would support full framework until those critical APIs were ready (I'm being serious - you know how much work I've put into libraries already). But at this point, I can't do that at Stack...it was a bad assumption. I cannot in good conscience tell our teams to use .NET Core while the future of any port is so uncertain. I really wish I could, but it's not worth the risk and the pain at the moment.

@NickCraver

I would expect .NET full framework support in ASP.NET Core to be deprecated once there was parity and most users could move over. And I'd expect that release to have a long support timeframe for people to move over.

What's the measure of "most users" here? What's the list of dependencies that need to be covered until we can drop support? Your list is different from other users on this list. I also expect some people will say forever or until .NET Core reaches .NET Framework parity (which is just unrealistic). I'll still pose that ASP.NET Core 1.x is good enough for that purpose and we should look at extending support for that until said time.

That is incorrect. I need the bits we need to run (e.g. AD auth) on a supported platform. The missing thing is support from the latter. Support for 1.x is certainly my main concern. We have no supported path forward or any timelines for when we can expect one.

What ASP.NET Component is missing for this scenario? When you say 1.x vs 2.x it would be useful if you mention ASP.NET Core vs .NET Core.

If DirectoryServices, Drawing, etc. are coming in 2.x then awesome. That release should support .NET Framework, and be a LTS release. And 3.x should drop full framework support.

I mentioned this before, what ASP.NET Core features do you need that ASP.NET Core 1.x isn't sufficient for this?

ASP.NET and .NET Core/Standard/whatever may be 2 sets of things inside Microsoft (and I totally get that), but to developers it's still 1 platform

Agreed but we need to clear up the FUD on this discussion so that we can properly evaluate the impact. ASP.NET Core 1.x targets .NET Standard 1.x (1.0 - 1.6) and .NET Framework 4.5.1. This means it can run on any platform that supports those versions of netstandard and .NET Framework. It means that ASP.NET Core 1.x will run on .NET Core 2.0.

@smbecker

Will CSOM run in netcore 2? That would be a huge blocker for us and one area that I haven't heard anything​ on.

I have no idea what that is. Is it this https://msdn.microsoft.com/en-us/library/ff798388.aspx? If so there was no work done to explicitly support it. It might just work based on the .NET Framework compatibility in .NET Core 2.0 but my guess is that it will never be ported to .NET Core (just based on my 5 minutes of looking at it), but I could be wrong.

What's the measure of "most users" here? What's the list of dependencies that need to be covered until we can drop support? Your list is different from other users on this list. I also expect some people will say forever or until .NET Core reaches .NET Framework parity (which is just unrealistic). I'll still pose that ASP.NET Core 1.x is good enough for that purpose and we should look at extending support for that until said time.

Let's start with the top missing APIs - those are what cause blocks for the most people. For us, that's DiretoryServices, which is number 1. If that's not even there, it's a really bad sign to the community. I agree lists are different, but if we're not even including number 1...

What ASP.NET Component is missing for this scenario? When you say 1.x vs 2.x it would be useful if you mention ASP.NET Core vs .NET Core.

I mentioned this before, what ASP.NET Core features do you need that ASP.NET Core 1.x isn't sufficient for this?

I mean support for the latest ASP.NET Core that supports Full Framework (and therefore the libraries I need). I hope that's 2.x, as we want modules, razor pages, etc. We have uses for a lot of 2.x features. But it sounds like our only option is 1.x at this point. We can't make the jump from ASP.NET 5 to ASP.NET Core and from full framework with all our working libs to netcoreapp in 1 move. It's too much. It's too costly. It's too risky. And now we're unsure if we can do that expensive, risky move inside a support window. That's a bad situation - so bad that it's better to not move (as things stand today). I think that's really unfortunate.

What ASP.NET Component is missing for this scenario? When you say 1.x vs 2.x it would be useful if you mention ASP.NET Core vs .NET Core.

• Unless there's a way to handle AD authentication/queries through some Microsoft.Authentication.* NuGet package, then that's one big thing. I'm currently in that same boat, but since I'm running .NET Core 1.1 on top of .NET 462, I'll be able to pull that off. Outside of that, how would I be able to query any AD groups, metadata through supported means? I have seen in the corefx repo that there IS a lot of work happening on System.DirectoryServices though, so I'm happy about that at least.

• System.Data.Common.DbDataAdapter/SqlClient.SqlDataAdapter. Currently, I'm only able to access that when running on .NET Core on top of the full .NET Framework. I guess it's more of a convenience thing, since I can still use the DbDataReader/SqlDataReader.

Basically I need to know that there will be a guarantee of SOME supported way to handle AD Authentication while using ASP.NET Core 2.x, without the need of the full .NET Framework.

I've been thinking about this a lot today and I'm finding that my concerns are different than most of those here (not that those concerns aren't just as important, if not more so).

I'm still kind of stuck on the use case of consuming ASP.NET Core packages on netstandard. Up until this issue I had assumed (perhaps wrongly) that netstandard was the de-facto target for libraries. In other words, the intended behavior for library authors would be to target netstandard unless there was a necessary and compelling reason not. This ensures not just compatibility with Framework but the other platforms like Xamarin and UWP. The work on .NET Standard 2.0 seemed to support this by trying to unify the API surface area of the various runtimes into a common don't-need-to-think-about-it target.

To me, this change signals something different. Granted, at the end of the day ASP.NET Core is just a library and perhaps it does have "necessary and compelling reasons" not to support the common netstandard surface area. But it's also one of the most visible Microsoft-developed .NET libraries and by saying "we want the latest and greatest so we're going to stop supporting netstandard" it signals to all the other library developers (or at least it does to me) that maybe they should stop trying so hard to support netstandard and just start targeting the Core runtime. Why bother with all that compatibility stuff when Microsoft doesn't even care that much about it? .NET Core 4 lyfe. And maybe that's for the best - it's certainly different than where I thought we were going with multiple runtimes and a mostly unified API surface area though.

This concern gets even deeper when considering that ASP.NET Core contains many, many libraries that are useful outside the context of ASP.NET directly. Maybe it was wrong to assume that those were ever intended to be used in isolation, but it would be an awful shame to loose them. Library authors who want to use them will have to decide to switch their own targeting to .NET Core as well or stay on netstandard and loose access to them. I suspect many will choose the former, further splintering library support for alternate platforms. At least if I've understood the comments here that targeting different platforms for the supporting libraries is too difficult.

Finally, I'm somewhat (though a little less) concerned about the comments here that as soon as it's possible new APIs will be added to Core to rev in conjunction with ASP.NET. Particularly that those new APIs may not ever make it into netstandard or .NET Framework. I certainly understand that there may be some exciting stuff that can be done if the legacy and compatibility concerns are dropped or loosened. But to be frank, I've gotten the impression that the ASP.NET Core team is often out there charging ahead. That's not necessarily a bad thing, but it's also led to a number of broader descisions that have had to be walked back. I can't help but wonder if this, and the subsequent rapid evolution of the Core runtime, will have the result of greatly fracturing the set of runtimes over time (and again, it's not just Windows/Framework that will be left behind - there's also Xamarin, Mono, UWP, etc.).

This whole thread has caused me to reorient my understanding of the future of .NET around .NET Core instead of netstandard. Maybe I'm being extreme and that'll soften in the coming weeks, or maybe that's even the intended position and it's all for the best - either way, I'm currently tempted to just go out and target .NET Core for my own stuff and only focus on that going forward from everything I've read here.

@NickCraver

I mean support for the latest ASP.NET Core that supports Full Framework (and therefore the libraries I need). I hope that's 2.x, as we want modules, razor pages, etc. We have uses for a lot of 2.x features.

Right now it's 1.1.1 (there's no modules in 2.0), Razor Pages is a good one, another is SignalR. Those are the 2 things I see being the most painful as part of this.

We can't make the jump from ASP.NET 5 to ASP.NET Core and from full framework with all our working libs to netcoreapp in 1 move. It's too much. It's too costly. It's too risky. And now we're unsure if we can do that expensive, risky move inside a support window. That's a bad situation - so bad that it's better to not move (as things stand today). I think that's really unfortunate.

Is it though? The move from ASP.NET Core 1.x to 2.x or 3.x assuming your dependencies have been ported would be trivial. If you plan on moving to ASP.NET Core in general, moving to 1.1 is a good first step and you won't be saving any work avoiding it.

@snickler

Basically I need to know that there will be a guarantee of SOME supported way to handle AD Authentication while using ASP.NET Core 2.x, without the need of the full .NET Framework.

Until System.DirectoryServices is supported on .NET Core then is there a reason you can't use ASP.NET Core 1.x on .NET Framework?

Until System.DirectoryServices is supported on .NET Core then is there a reason you can't use ASP.NET Core 1.x on .NET Framework?

That's what I'm currently doing. I'm just looking forward in hopes that I can not have to worry about the .NET Framework if I don't need to. Currently, it restricts me to my Windows machine as the System.DirectoryServices.AccountManagement namespace doesn't exist in Mono. In those same regards, will there be System.DirectoryServices.AccountManagement available outside of the constraint of Windows? That one little piece forces me to jump between machines while debugging my MVC project and my Xamarin.iOS app locally.

If you plan on moving to ASP.NET Core in general, moving to 1.1 is a good first step and you won't be saving any work avoiding it.

I totally agree, if we knew support was there until we upgraded to another platform that worked. Right now, we don't know when the necessary bits will be available in the .NET Core world so setting a time cap now and not knowing when those bits will come later is me betting on a promise. That's the core issue. If we have a supported, overlapping release that allowed porting then I'd be all set and happy to invest. If support is dropped before the APIs are there, we're jumping a gap on faith, with an unknown amount of runway.

I keep referencing DirectoryServices because that's what I know doesn't work on netcoreapp2.0 today. There will of course be other things we find that fall in the same boat. We need ASP.NET Core + full framework + support for several years on some platform. With 1.x, we don't get a lot of gains, we actually get very little. Performance isn't an awesome argument since we already render pages in ~18ms and it's dwarfed by transport time. 2.0 however, offers quite a few good items. Razor pages and the prospect of plugins makes it very appealing to port to. So much so as to be justifiable.

Right now, the only version to go to with support (1.1.x with longer support, is what I expect after reading this thread) isn't worth moving to. It'd basically be a lot of time and effort to get to where we are today. 2.x at least offers some decent improvements and bits we'd want to take advantage of. They help justify the cost of moving.

Performance isn't an awesome argument since we already render pages in ~18ms

On a minor OT rant, I'd like to know how you're able to render pages in ~18ms @NickCraver . That's awesome

@daveaglick

I'm still kind of stuck on the use case of consuming ASP.NET Core packages on netstandard. Up until this issue I had assumed (perhaps wrongly) that netstandard was the de-facto target for libraries. In other words, the intended behavior for library authors would be to target netstandard unless there was a necessary and compelling reason not. This ensures not just compatibility with Framework but the other platforms like Xamarin and UWP. The work on .NET Standard 2.0 seemed to support this by trying to unify the API surface area of the various runtimes into a common don't-need-to-think-about-it target.

Nothing has changed here. In fact a bunch of our libraries that we want to run on other platforms are still netstandard. If you re-read some of the above:

• Microsoft.Extensions.* (Logging, DI, Configuration, FIleProviders etc)
• EntityFramework
• SignalR clients (they need to run on .NET Framework, Xamarin, UWP etc).

.NET Standard is the defacto way to write libraries that run everywhere. Library authors should aim to target netstandard where possible to get the broadest platform reach. Library authors have to decide if they want to have reach or not. That's why libraries like JSON.NET support netstandard1.x and .NET framework 2.0. They go the extra mile to make things "just work" as @JamesNK mentioned above.

ASP.NET Core moving away from netstandard in some places is more of a statement that these APIs aren't meant for UWP applications and we certainly don't test them there (as an example). It also tries to solidify that .NET Core and ASP.NET Core are a single product that versions together (since it has Core in the name). With ASP.NET Core 1.x supporting both .NET Core and .NET Framework that message was a little blurry and it causes confusion for lots of people (especially new developers) and we did it to ease the library gap problem.

This concern gets even deeper when considering that ASP.NET Core contains many, many libraries that are useful outside the context of ASP.NET directly. Maybe it was wrong to assume that those were ever intended to be used in isolation, but it would be an awful shame to loose them. Library authors who want to use them will have to decide to switch their own targeting to .NET Core as well or stay on netstandard and loose access to them. I suspect many will choose the former, further splintering library support for alternate platforms. At least if I've understood the comments here that targeting different platforms for the supporting libraries is too difficult.

I'm guessing those are still netstandard. Which ones aren't?

I can't help but wonder if this, and the subsequent rapid evolution of the Core runtime, will have the result of greatly fracturing the set of runtimes over time (and again, it's not just Windows/Framework that will be left behind - there's also Xamarin, Mono, UWP, etc.).

I think netstandard will evolve, but .NET Framework will always be the last to get new APIs (Xamarin and Mono are pretty fast to add things).

@snickler

That's what I'm currently doing. I'm just looking forward in hopes that I can not have to worry about the .NET Framework if I don't need to. Currently, it restricts me to my Windows machine as the System.DirectoryServices.AccountManagement namespace doesn't exist in Mono. In those same regards, will there be System.DirectoryServices.AccountManagement available outside of the constraint of Windows? That one little piece forces me to jump between machines while debugging my MVC project and my Xamarin.iOS app locally.

Make sure you file issues like that on dotnet/corefx. Assuming your dependencies will be ported (unless it's wildly popular) is the wrong thing to do.

@davidfowl Question: I want to File -> New Project with ASP.NET Core 2.0 and authenticate against AD. Will this be possible? I simply cannot imagine a Microsoft platform shipping without the ability to do this.

Agreed with everything there but I don't see how this decision affects anything you said. I want all of those same things

By dropping support for .NET v4.x it will kill a popular migration path and fragment the .NET ecosystem even further and prevent many devs and organizations from being able to adopt it which will reduce the wider community pool of knowledge and investment in ASP.NET Core since many .NET devs will need to support their existing ASP.NET v4.x code-bases indefinitely (which they get paid to work on full-time).

The smaller the market share .NET Core has, the lower priority it will be for library maintainers to support it and some likely never will if they work for an organization who'll no longer be able to consider migrating to ASP.NET Core because of this, which in turn effects anyone else depending on their packages, and so on. These are all side-effects of increasing the burden in adopting ASP.NET Core, by not having a stable platform, long term support guarantees and now killing off a popular migration path.

I believe everyone here wants the .NET ecosystem to thrive but it appears we're at odds with the MS team on how best to achieve it as I firmly believe dropping .NET v4.x this early on before a known quantity, highly compatible, stable LTS release is available is a mistake that will have detrimental effects for years to come.

@davidfowl Thanks - your comment helps a lot. I had (apparently incorrectly) gathered that most/all the supporting libraries were moving off of netstandard as part of this change. I use quite a few, and know others who do as well, so hearing that they aren't is welcome news.

@NickCraver what kind of auth are you using against AD today? OpenIdConnect, WsFed, NTLM, other?

@Tratcher AD auth, via DirectoryServices (we need to query group membership, etc. - the standard bits)

@mythz I think that's reasonable and I think extending the support lifetime of ASP.NET Core 1.x would be sufficient to cover most of the cases.

I see why you have to make this decision at some point but I too believe it's premature and would be happiest with:

• ASP.NET Core 2.x being LTS and last to support Full Framework (surely since we were already in preview you are not too far gone) with also SignalR following later in the year supporting it so that it's the target framework for making the jump from ASP.NET to ASP.NET Core
• 3.x dropping support for Full Framework and being released when top dependencies are migrated over

Simply extending support for ASP.NET Core 1.1 in my view would not be enough as that platform is not mature/adopted enough to be a target for many ASP.NET migrations (in my case SignalR being the blocker).

Just for the lulz, I tried using EntityFramework 6 - that I've seen massively used in ASP.NET Core 1.0 apps I've worked on - with the latest preview2 .NET Core nightly builds. Guess what...

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.0</TargetFramework>
    <NetStandardImplicitPackageVersion>2.0.0-*</NetStandardImplicitPackageVersion>
    <RuntimeFrameworkVersion>2.0.0-preview2-002093-00</RuntimeFrameworkVersion>
    <PackageTargetFallback>net45;net461</PackageTargetFallback>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="EntityFramework" Version="6.1.3" />
    <PackageReference Include="System.Configuration.ConfigurationManager" Version="4.4.0-*" />
  </ItemGroup>

</Project>

Stop pretending assemblies designed and compiled for the full framework will work flawlessly on .NET Core: trivial cases (read hello world apps) will probably work, but in many cases, you'll end up being blocked by missing APIs or non-functional APIs.

What's absolutely terrible is that you'll only realize it doesn't work at runtime. In some cases, it won't even be obvious at all. For instance, .NET Core's SqlClient doesn't support ambient transaction enlistment nor distributed transactions with TransactionScope: even if you find a way to make EF 6 work, your TransactionScopes won't be effective at all and your DB calls won't use the isolation level you need.

I feel it necessary to add my two cents here as far as my concerns with this move. We have a desktop application that is primarily Windows Forms with some of the newer areas developed in WPF. There is over 15 years of effort in that application and it will take years to move completely away from WinForms. I wish that weren't the case but it is. We have been working to build more modularity into the codebase so that we can consume the business and data access layers across a newer web interface and the existing WinForms application. I intended to move to ASP.NET Core for our newer web application very soon but as I just stated I will need to consume a large majority of our existing codebase that is targeting .NET v4.6.x. I know for sure we are using System.Drawing and System.Security.Cryptography. We also make heavy use of TransactionScope in ways mentioned above.

I have been greatly looking forward to gaining some of the benefits of ASP.NET Core like the ability to encapsulate areas of our web application into separate assemblies without needing to rely on MEF to bring it all together. There are many additional reasons but that one is the thing that makes it really nice. However, if I transition our application to ASP.NET Core I'll likely be stuck on 1.x for the foreseeable future because we have to maintain portability on our backend code with WinForms. I've been focused primarily on the Web product so I can't tell you where we are hooking into things like WMI, etc, and if it impacts the question of portability, but I know we are within our codebase. We are in a really interesting phase right now and the last thing I want to have to do is develop all the Web versions of our features onto ASP.NET MVC 5 and accrue a bunch of new legacy code that will need to be ported at some future endeavor.

I'm sure we're going to have a lot of usages that are going to keep us away from targeting .NET Standard even if/when we no longer use WinForms. We're a Microsoft Partner and we work directly with Microsoft for our product in several ways so I don't want to go into too much detail as to what we do here but I'd be happy to have a more private discussion with @shanselman or @davidfowl if you need more details into what we are doing. I'm also going to be at MS Build and could meet and talk to either of you there if you will be present.

I think you have not considered companies using your stack with these kinds of challenges. However, full disclaimer: I do intend to run the portability analyzer mentioned earlier to see where we are indeed stuck because of the need to maintain that portability within our codebase. I'll gladly provide you with a list of any .NET Framework APIs that fail that check.

Mouahaha. Not sure if I should laugh or cry...

Here's the report generated by the ApiPort analysis tool for my trivial 23-line EF 6 app that doesn't work:

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.

Prior to this issue being opened, was there a feedback process?

We're all talking about time frames and support for 1.1 but the fact that ASP.NET Core is going to drop full framework at all has come as a huge surprise to me.

My understanding was that the core framework was a cross platform play, a new framework that's made up of a subset of the full framework that isn't coupled to Windows. The 2.0 release was the one we've all been waiting for where we get most of the API's back.

ASP.NET Core was the dog food for this new framework, a new web framework which depended on such a small surface area of framework API's that it could run everywhere.

I was expecting that once the core framework made close parity with the full framework all new API's would be added to netstandard and eventually make it into both frameworks. We would all start targeting netstandard and everything would be rainbows an unicorns.

Now to find ASP.NET won't even dogfood netstandard and are going framework specific eh :/

@rohatsu

Simply extending support for ASP.NET Core 1.1 in my view would not be enough as that platform is not mature/adopted enough to be a target for many ASP.NET migrations (in my case SignalR being the blocker).

What if SignalR worked on ASP.NET Core 1.x? What else is immature about the platform that you need?

@millman82 Thanks for sharing that. It does sound like you would be stuck on the version before .NET Framework support was dropped for a while. So some of the suggestions here where we keep 2.x compatible and 3.x would drop it might not even work for you. Why not just stay on ASP.NET Core 1.x? What's missing from it that you need in your port? Or is it just the concern the same as @NickCraver 's (that 2.x not supporting it makes you nervous about taking a bet on it).

@jkells

I was expecting that once the core framework made close parity with the full framework all new API's would be added to netstandard and eventually make it into both frameworks. We would all start targeting netstandard and everything would be rainbows an unicorns.

That's not far fetched, it's just missing the time component. Will eventually make it into all framework that each ship on their own schedule.

Now to find ASP.NET won't even dogfood netstandard and are going framework specific eh :/

Part of it still targets netstandard as was mentioned several times in this thread.

Why not just stay on ASP.NET Core 1.x?

You can't - it's out of support 1 year from when 2.0 drops (assuming 2.0 is the next LTS).

@davidfowl It is definitely a large part of that. We also use OData and SignalR in our current web application and that needs to be in ASP.NET Core before we can move over. However, the one thing I don't want to happen is to be stuck in limbo when support for ASP.NET Core 1.x is dropped and there is no migration path with the framework parts we are using that aren't currently supported. I foresee ASP.NET Core replacing ASP.NET wholesale. It may be somewhere on down the road but it is coming. Knowing that I'd hate to rewrite our UI now in ASP.NET MVC 5 (we have a few things there now but it is easy to move because it is small) only to a few years later rewrite it again in ASP.NET Core once the end of life for ASP.NET arrives.

We could potentially be setting ourselves up to get burned badly if that migration path is nonexistent when EOL of ASP.NET Core 1.x does arrive if it is extended in the interim if we target Core 1.x now. We could probably navigate around some of it with micro services, however, that of course has its own concerns.

@ctolkien

You can't - it's out of support 1 year from when 2.0 drops (assuming 2.0 is the next LTS).

Assume for a second that it isn't out of support when 2.0 drops. Isn't that enough?

However, the one thing I don't want to happen is to be stuck in limbo when support for ASP.NET Core 1.x is dropped and there is no migration path with the framework parts we are using that aren't currently supported

Replace 1.x with 2.x in that sentence. Do you think that in a year all of your dependencies would be ported?

Replace 1.x with 2.x in that sentence. Do you think that in a year all of your dependencies would be ported?

Not at all, however, I'd expect that when no longer able to target .NET Full they would be. I understand why you would want to push that up but I don't think you can expect companies to adopt something that will fall out of support with no means of transitioning to a newer version because the missing dependencies haven't been ported.

I don't think you can expect companies to adopt something that will fall out of support with no means of transitioning to a newer version because the missing dependencies haven't been ported.

Why would it fall out of support? In my hypothetical world we'd be supporting ASP.NET Core 1.x on .NET Framework for longer.

Why would it fall out of support? In my hypothetical world we'd be supporting ASP.NET Core 1.x on .NET Framework for longer.

My question is how much longer? Also, is the team large enough to bring those necessary dependencies like SignalR and OData to ASP.NET Core 1.x and maintain support until all those missing dependencies have, in fact, been ported? Seems like it counters the arguments made earlier about why you would want to drop .NET Full support now. Honest question...

My question is how much longer? Also, is the team large enough to bring those necessary dependencies like SignalR and OData to ASP.NET Core 1.x and maintain support until all those missing dependencies have, in fact, been ported? Seems like it counters the arguments made early about why you would want to drop .NET Full support now. Honest question...

I'll throw out a random number, 3 years. The ASP.NET Team doesn't own the Odata integration, the odata team does so I cant answer for them. As for SignalR, I think it would be possible to target ASP.NET Core 1.x.

The problem I see is that each person has a different set of "missing dependencies" which makes it impossible to reason about when it's even "ok" to drop .NET Framework support for everyone. It's also likely that some of those dependencies may never be ported (like CSOM).
Of course being on the 1.x train you'll get bug fixes and minor features but the bulk of the work would still be happening in the latest major of ASP.NET Core.

Also none of this prevents you from using .NET Core 2.0 or .NET Standard 2.0 with ASP.NET Core 1.x. I just want to make sure everyone is aware of that because this threads constant conflates ASP.NET Core with .NET Core (which is one of the reasons we want to target .NET Core only).

The problem I see is that each person has a different set of "missing dependencies" which makes it impossible to reason about when it's even "ok" to drop .NET Framework support for everyone.

Engage the eco system to find out what the list is (no, this issue is not the place to do it). If it's a Microsoft owned dependency, port it. If it's not, engage with the owner to inform them of the plans and assist with a migration guide (if they don't do anything, not Microsoft's fault). In the time it takes to go through this process, support ASP.net core 1.x. I can't see any other way to achieve your goals without upsetting lots of folks. This is a big thing being proposed that needs a high level of care and attention to do right.

Personally, I think there is far more confusion around .NET Framework vs .NET Standard vs .NET Core. When I saw I could target .NET Framework I never said, "but this is ASP.NET Core so why can I use .NET Framework". The distinctions between the above are far more confusing for most of your customer base. I love everything ASP.NET Core is doing. Also love the direction with .NET regarding platform independence. I just think the domain of confusion is incorrectly stated. I'd say the majority of your user base is going to have some amount of code that isn't portable due to the nature of what it is doing and the APIs it is targeting within the Framework.

My preference would be to work toward API parity within .NET Core and .NET Standard and .NET Framework. Also, figure out which is the one people should strive to target. As I believe was stated earlier, perhaps in a slightly different way, .NET Standard feels like a bandaid. Eventually, I'd expect .NET Core to be the only "framework" option and when that happens .NET Framework and .NET Standard go by the wayside. Myself, and I think with most whom have spoken up since the announcement, would like to be able to continue to benefit from the work you are doing on the ASP.NET Core side without having the freedom of what they are executing their code on top of being removed.

I think the cases being considered as exceptional, like mine where I have a dependency on things like WMI are not as exceptional as the team may think. Again, I'll do the research and see what is missing (though the post earlier giving incorrect portability results has me a little concerned over the accuracy) and I will gladly report that to you in a more private medium.

Bottom line, we're passionate about this because we want to use it.

Personally, I think there is far more confusion around .NET Framework vs .NET Standard vs .NET Core. When I saw I could target .NET Framework I never said, "but this is ASP.NET Core so why can I use .NET Framework". The distinctions between the above are far more confusing for most of your customer base. I love everything ASP.NET Core is doing. Also love the direction with .NET regarding platform independence. I just think the domain of confusion is incorrectly stated. I'd say the majority of your user base is going to have some amount of code that isn't portable due to the nature of what it is doing and the APIs it is targeting within the Framework.

We have lots of customers and we have new developers that have never seen .NET in their life. We need to cater to everyone because that's what we try to do as Microsoft. People running on .NET Framework know, love and understand it works so sure you understand that ASP.NET Core runs on .NET Framework but as a new developer approaching the platform, I would hope to never mention that as it muddies the story compared to something like go or node (which have pretty much 0 legacy at this point).

My preference would be to work toward API parity within .NET Core and .NET Standard and .NET Framework. Also, figure out which is the one people should strive to target. As I believe was stated earlier, perhaps in a slightly different way, .NET Standard feels like a bandaid. Eventually, I'd expect .NET Core to be the only "framework" option and when that happens .NET Framework and .NET Standard go by the wayside. Myself, and I think with most whom have spoken up since the announcement, would like to be able to continue to benefit from the work you are doing on the ASP.NET Core side without having the freedom of what they are executing their code on top of being removed.

These things all happen in parallel. ASP.NET Core doesn't stop working on features until "everything" is ported over to .NET Core from .NET Framework. ASP.NET will continue to innovate and take advantage of APIs that are available on .NET Core since we ship as part of the same box.

I see a few trending ideas on this thread from:

• I want you to support .NET Framework forever.
• I want to you support .NET Framework until the dependencies I need for my application are ported.
• I just need 1 more year, that will be enough time for me to drop .NET Framework support (ASP.NET Core 3.x).

There's also the fact that we didn't write an announcement (which is our fault) but one is coming (I promise, I blame the weekend).

I also don't know what API parity looks like for most people here, my guess is it's different for different people. .NET Framework is a 15+ year old solid, reliable, enterprise technology tied to Windows.
.NET Core was made to write modern light weight cross-platform micro services and has slowly been evolving to be more compatible so that porting libraries was easier. That said, I don't know what it means to approach .NET Framework in terms of compatibility or if that's even a goal (it wasn't originally). At some point you will not be able to use ASP.NET Core on top of .NET Framework and there will be some dependency that can't be rewritten that isn't compatible with .NET Core. Applications will need to account for that when being designed with ASP.NET Core in mind (in some near future).

With respect to the projects I work on, a much-longer period of support for 1.1 would be a decent mitigation. It's unlikely we could drop netfx dependencies in 1 year but far more likely with the +3 years you suggested as a strawman. It'd be really nice to have a release where everything comes together at the 2.0 level first though - that's the point where everything was supposed to become easier to port! I'm only speaking for one organisation but "2.0 will be a LTS release; 3.0 will drop netfx" would basically be business as usual for us instead of a cause for FUD.

I'd also like to echo what @PureKrome said about appreciating this engagement, it has been a very informative discussion.

On the topic of parity - I had previously assumed that .net core would not ever approach .net framework levels of compatibility, but that this was fine because asp.net core would continue to support both.

I think that as a community we basically use .net core in order to use asp.net core, not for its own merits. Like you said, they're one product, and I'd thought of the core clr as an optional part of that product with benefits and drawbacks if chosen.

After sleeping over it for a night -

I personally think it is a good idea to leave the old .net framework behind and write the best possible web framework for the modern runtime.

But you know that it is definitely risky and you might lose some of your customers here along the way (I hope not - but I do a lot of consulting - and .NET Core is for many companies out of reach right now - let's hope 2.0 changes that).

..and yea - communication around this was (as usual) something you can improve (most polite version of this sentence for a German) ;)

+1

I personally think it is a good idea to leave the old .net framework behind and write the best possible web framework for the modern runtime.

I agree strongly. My hope was that this wold have been a gradual change, e.g. Kestrel dropping support first for perf (http.sys based hosting remaining), then mvc/* following for API and functionality improvements while porting / compatibility testing efforts for netstandard2.0 begin.

Excellent. In that case, as long as Microsoft ensures that 1.x is supported (all kinds of bug fixes and >operational support) until it offers customers a proper 2.x migration path (e.g. SignalR), then I am >comfortable biding my time until we need asp.net core 2.

+1

able to port to .NET Core only (maybe during the development of ASP.NET Core on full framework you took some new dependencies that will never be ported as an example).

Totally agree.
Right now I think that is good decision. I think in ideal scenarios we need more than 1 year support, I dont known maybe 2-3 year, and information about what will be ported, for confidence of the community.
No .net 461 support.

@dasMulli

I agree strongly. My hope was that this wold have been a gradual change, e.g. Kestrel dropping support first for perf (http.sys based hosting remaining), then mvc/* following for API and functionality improvements while porting / compatibility testing efforts for netstandard2.0 begin.

We don't even run performance tests on .NET Framework... Porting testing and improvements to .NET Core and .NET Standard will happen anyways, that IMO has no bearing on whether .NET Framework support is dropped or not. If anything, it makes us laser focus on those scenarios because it the only target.

@gulbanana

It'd be really nice to have a release where everything comes together at the 2.0 level first though - that's the point where everything was supposed to become easier to port! I'm only speaking for one organisation but "2.0 will be a LTS release; 3.0 will drop netfx" would basically be business as usual for us instead of a cause for FUD.

Why do you need ASP.NET Core 2.0 (forget .NET Standard and .NET Core 2.0)?

We don't particularly need the features in asp.net core 2.0. I would very much like to have the simpler build processes and interop that comes with the 2.0 wave.. will asp.net core 1.1, if running on netcoreapp2.0, be able to use netstandard2.0 libraries? Would that be considered a 'standard' and supported scenario rather than something which nobody tests or pays attention to?

Basically if 1.1 became LTS I worry about issues being closed eighteen months from now with 'well, you can do this using the 2.0 apis'..

We don't particularly need the features in asp.net core 2.0. I would very much like to have the simpler build processes and interop that comes with the 2.0 wave.. will asp.net core 1.1, if running on netcoreapp2.0, be able to use netstandard2.0 libraries? Would that be considered a 'standard' and supported scenario rather than something which nobody tests or pays attention to?

Of course that would work. As I've been saying all along the 3 things are completely decoupled today. Here's a sample project running ASP.NET Core 1.1 on .NET Core 2.0 using a version of System.Configuration APIs that have been ported to a .NET Standard 2.0 package:

https://github.com/davidfowl/AspNetCore1OnNetCore2

I'd be happier to accept this if there was an automatic interop layer between .NET Core and .NET Framework (not the current one that can throw exceptions at runtime, and not self-made internal WebAPI calls) - some kind of a wrapper ("WowNET"?) that would force us to keep 4.6-dependent code in separate .dlls but allow running legacy at the cost of performance (which in case of LOB apps is not the main concern). Do you think this would be technically possible?

I'm also wondering if this change means that full framework itself is approaching end of life and won't perform any other significant role than being a legacy component once most APIs are moved over to .NET Standard.

Basically if 1.1 became LTS I worry about issues being closed eighteen months from now with 'well, you can do this using the 2.0 apis'..

That's always a concern. The answer is always "it depends". Bug fixes are weighed accordingly and big features are likely to fall into that bucket more often than not.

@rohatsu

I'd be happier to accept this if there was an automatic interop layer between .NET Core and .NET Framework (not the current one that can throw exceptions at runtime, and not self-made internal WebAPI calls) - some kind of a wrapper ("WowNET"?) that would force us to keep 4.6-dependent code in separate .dlls but allow to run legacy at the cost of performance (which in case of LOB apps is not the main concern). Do you think this would be technically possible?

Kinda like this https://docs.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-root but for .NET Core and .NET Framework. We did something very similar when we ASP.NET supported Helios, a .NET Framework shim that was used to boostrap coreclr in IIS. The hacks to make it work were pretty ugly though it was a mix of COM and passing structures to the Main method via string[] args. All technically feasible though. I'm not sure what sort of fidelity you'd expect, as they aren't the same runtime and you can't pass objects back and forth. You'd also be running 2 GCs, 2 Jits tons more dlls in the same process and I'm not sure what you're gaining over doing something out of proc.

I'm also wondering if this change means that full framework itself is approaching end of life and won't perform any other significant role than being a legacy component once most APIs are moved over to .NET Standard.

Far from. .NET Framework evolves and ships at the pace of windows as it is a windows component. We just released .NET Framework 4.7 (https://blogs.msdn.microsoft.com/dotnet/2017/04/05/announcing-the-net-framework-4-7/) as well with a bunch of new features. The fact is that .NET Core can and will ship faster because it isn't tied to anything else, so APIs, runtime features, etc will appear there first. It doesn't mean things won't eventually make their way to .NET Standard and .NET Framework. It'll just take longer to get there. The fact that .NET Framework updates in-place is the reason we're so careful when porting changes. Any change can break any application when an update is auto pushed to a billion machines 😉 . With .NET Core, the framework is side by side so applications need to opt in to the newer version to get newer features or fixes. There's just a lot more freedom there.

Just to weigh in with the net4x libraries we currently today in ASP.NET Core 1.x, that wouldn't work in 2.0: EntityFramework 6. EFCore just has to many missing features we use missing (for example interception/lifecycle hooks). So we're stuck on EF6 for a while.

And according to @PinpointTownes 's post, EF6 does not work with the current (in development) version of ASP.NET Core 2.x.

@nphmuller then you'd keep using ASP.NET Core 1.x until more dependencies moved (I don't know how many things you require from EF Core and what the status is).

@davidfowl Sure, if the support window from ASP.NET Core 1.x does not pass during that time.
The main feature is interception (lifecycle hooks). Other missing features can be worked around more easily for us. Interception is in their backlog, but not tied to a release. And my gut tells me it won't be implemented for a while.

@gulbanana: I think that as a community we basically use .net core in order to use asp.net core, not for its own merits.

Speak for yourself. There are a number of us for whom the primary benefit of .NET Core is getting off of Windows on the server.

And, I suppose, all you dirty Mac-owning hippies. 😝

@bradwilson And, I suppose, all you dirty Mac-owning hippies.

Speak for yourself, some of us aren't hippies ;P

But yes, escaping Windows (or really, IIS and http.sys) is what I want .NET Core for along side xcopy deployment, perf, etc.

Isolating old code in separate services or porting to ASP.NET Core does pay off for reasons other than new and shiny.

@PinpointTownes is a reference error, what happens if you reference System.Configuration as per https://github.com/aspnet/Home/issues/2022#issuecomment-299810945? EF6 says it has no dependencies due to everything being in ye'olde GAC/Full Framework bundle

@benaadams and @PinpointTownes the reason its failing is because System.Configuration.ConfigurationManager isn't the DLL name that .NET Framework expects. I'm not sure if the port of System.Configuration is valid.

      "system.configuration.configurationmanager/4.4.0-preview2-25308-01": {
        "dependencies": {
          "System.Security.Cryptography.ProtectedData": "4.4.0-preview2-25308-01"
        },
        "runtime": {
          "lib/netstandard2.0/System.Configuration.ConfigurationManager.dll": {}
        },
        "compile": {
          "ref/netstandard2.0/System.Configuration.ConfigurationManager.dll": {}
        }

Yes, being able to run non-windows servers is great and a big draw.. but without asp.net core what would you run on them? Even Nancy for .net core relies on asp.net core via kestrel, UseOwin(), etc.

I've created several microservices that don't use ASP.NET Core. They're stuff like worker processes that poll a queue to do it's work.

This is not fair, we follow roadmaps, and you didn't say anything about that before !!
If you said that before, we will not use ASP.NET Core in our project because we need .NET 4.x Libs.
Our planning includes updating our projects to ASP.NET Core 2 because of needed new functionalities.
We need ASP.NET Core 2 to target .NET 4.x too. if not possible, what about the support of ASP.NET Core 1.x, are you planning to add all new functionalities to it too or just fixing bugs.

Our planning includes updating our projects to ASP.NET Core 2 because of needed new functionalities.

Which ones?

@PinpointTownes is a reference error, what happens if you reference System.Configuration as per #2022 (comment)?

Adding <Reference Include="System.Configuration" /> has no effect (i.e the same exception is thrown), as it seems it can't be resolved from the GAC (not sure it's really surprising, tho'):

I'm not sure if the port of System.Configuration is valid.

So the official conclusion is... you can't use a library written for .NET Framework 4.x on .NET Core if it uses System.Configuration?

@PinpointTownes I'm not even sure that version of System.Configuration is shipping (the one in the package). Maybe it is, maybe it isn't (that's a discussion to start on corefx). I'm just telling you why your sample broke the way it did.

Adding has no effect (i.e the same exception is thrown), as it seems it can't be resolved from the GAC (not sure it's really surprising, tho'):

AFAIK, there's no default support for the GAC references in SDK projects. See https://github.com/dotnet/sdk/issues/987#issuecomment-286307697 to see how to enable it.

So the official conclusion is... you can't use a library written for .NET Framework 4.x on .NET Core if it uses System.Configuration?

My conclusion is that you should open an issue on CoreFX with the sample your provided above.

@davidfowl thank you for reply
Some needed features and helpers on EF Core are planned in 2.0 especially for mapping data (Self-contained type mappings)...
Anyway, I need just to have a clear idea about the roadmap of ASP.NET Core 1.x, our team is confused and worried.

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

@davidfowl I do think signlarR is one such feature, it would have been in my previous project atleast. However I also think a lot of the concern is due to the relatively short support windows for 1.1 (2018?) if people were assured they could run on asp.net 1.1 until they are ready to switch to core, meaning potentially, years, and also be covered for patches that would calm people down a bit.

I also think asp.net core 1.1 support on .net core 2.0 is worth highliting even more, it gives people (what I think) a good migration path: asp.net 5 on 46 >asp.net core 1.x on 46 > asp.net core 1.x on .net core 2.0 > asp.net core 2 on .net core 2. That would be a path that would reduce the risk a lot of people worry about.

I've been following this since the first day and even after all of these discussion and clarifications ( thanks @davidfowl ) I feel a lot of us are being thrown under the bus.

I understand the reasoning for cutting loose from Full/desktop .NET framework. Hell, I even agree that's the way to empower ASP.NET, BUT I fail to see how this is being decided now instead of from the beginning.

Of course we customers would seriously complain in both scenarios, but I'd rather be in the "I can't use the new shiny thing" than bet on "I can use it, invest in slowly migrate and replace when possible" and just find out that's false.

I fail to see how this is being decided now instead of from the beginning.

At a guess:

On .NET Core 1.x you couldn't run Full framework libraries, so it would have been a complete break.

On .NET Core 2.x you can mostly run Full framework and can run .NET Standard 1.x - 2.0 libraries, so it isn't a major break.

Any issues with running Full framework libraries on .NET Core 2.0, should probably be filed in dotnet/corefx

It's clear that the main scenario is "modern web apps on the cloud", which often don't have many third party dependencies ( or are "just code" ones ).

Most of the discussion so far has been focused on BCL availability, but many of us depend on third party components( low level integration with complex Video, Audio subsystems for example... ) that are often lagging on the .NET landscape and almost always rely on lower level technologies that probably don't end up being supported.

With ASP.NET Core 1, we are developing our modern services, targeting .NET standard for Libs and choosing to deploy on Full .NET or .NET Core per services dependencies.

I could bet on this because in the case of finding unsupported features/components, we could easily target Full .NET. And the bet was on the long term platform, as staying on Full .NET looks like a decision to avoid in a few years.

_On .NET Core 2.x you can mostly run Full framework and can run .NET Standard 1.x - 2.0 libraries, so it isn't a major break._

@benaadams There is a big difference between being able to use most of the BCL and being able to use libraries that have been built for Full .NET ( and internally could use unsupported features in .NET Standard 2.0 / type unification).

I guess this decision has no impact on easing the migration to ASP.NET Core 2.0 from ASP.NET 4?
Quite a few applications I manage could really profit from an update to ASP.NET Core 2.0, but since there is no OWIN/Katana Support for ASP.NET Core I guess I need to migrate manually and that is atm too much work. @damianh suggested similar in https://github.com/aspnet/AspNetKatana/issues/27

We are running on the full framework because we need EF6 (for spatial) and directory services and we are waiting on SignalR proper (currently using an unsupported version but it works). I havent checked any other blockers in a while but probably there are more.

As i understand it we'll now be blocked from moving to asp.net core 2.0 and getting signalr when it comes out.

We've been along for the ride since dnx, RC1 to RC2 and project json to csproj and finally it felt like we were out of the woods... now not so much.

I can understand this change coming eventually but is this really the time to do it when asp.net core is trying to gain traction? Also, my gut tells me EF Core isnt mature enough yet (and certainly not for spatial) and anyone betting on support in core is taking on more risk with regards to porting of libs.... waiting out another version for this transition seems like it would give some stability and a chance for EF Core and other ports to catch up not to mention signal r on the full framework.

I bet most of the enterprise is running asp.net core (which is great by the way) on the full framework and could well be in a similar position to us.

Given this move to the fast train for ASP.NET Core, does that mean you'll introduce an LTS and Current version, and what will the support length be on this instances?

I guess I'm in the lucky instance where I am working on a greenfield solution that has had no requirements to run on netfx, _but_ it was always a nice to have if it could. The only thing that would be a blocker for me would be windows services which I am targeting netfx, but there is a plan for that.

I feel this change is going in the wrong direction. I understand some features are core exclusive until netstandard catches up. But going this core-only route is a slippery slope into creating a fractured ecosystem.

This change makes a statement that I'm not sure I like: It's OK to only target netcoreapp.

I also wanted to write my opinion.

I believe that it's too early to drop .net framework. I don't know what's the problem of supporting .net framework + .net core together, but I believe this decision will make to migrate to AspNet Core a little harder. Because some companies think that: "Let's start AspNet Core with .net core.. if we have serious problems (like a must-need library does not support it in the future) we can always turn back to .net framework". But now that will not be possible anymore and companies will hesitate to start with AspNet Core. Also, this decision may make lower the value of .netstandard.

@hikalkan

Because some companies think that: "Let's start AspNet Core with .net core.. if we have serious problems (like a must-need library does not support it in the future) we can always turn back to .net framework".

You can always use ASP.NET Core 1.1 though right?

Also, this decision may make lower the value of .netstandard.

I don't see why that would be the case. As I said before, our cross cutting libraries still target .NET Standard as well as APIs that need to work across all of the .NET implementations.

Sure, they can use asp.net core 1.1. But it's not nice to say: "ASP.NET Core's latest version is 2.x but you should use ASP.NET Core 1.x if you want to target .net framework". That's not much different than saying "use MVC 5.x" :)

I believe .net core is the future (not future, even it's now!), but it's eary to drop .net framework (this decision will be understood by the community like .net framework is being obsolete).

You can always use ASP.NET Core 1.1 though right?

there is not a clear benefit. First it is not mature yet, so it is a bet.
Second, developers in ASP.Net Core will not want to write in old tools and stay behind.
I am interested about few things.

1. We work already in greenfield project fully in ASP.Net Core, Dapper, etc.
   But in other projects, our business logic is in 4.6 assemblies. As I did read above, we should not have problem to reference them. I hope, I understood well about.
2. SignalR . DirectoryServices, MS Orleans, Azure.
3. maybe irrelevant with the conversation above, but I want madly to host locally an ASP.Net Core with Kestrel or other HttpListener as a UWP desktop application or as desktop bridge in UWP.

Gotta say I'm pretty disappointed on the communication on this. I think we can live with the decision but it came out of no-where.

In July my team is starting work on a greenfield 12-18 month project that's going to run on ASP.NET Core 2.0 with all the cool stuff that we've been reading about for years in .NET Core.

However in the mean-time we've got a ASP.NET MVC Core 1.0 app that is the center of our legacy product that essentially serves as a wrapper to call .NET Framework libraries.

I confirmed with the team that their plan was to upgrade the app to ASP.NET MVC Core 2.0 and have it become part of the new app as we swap out the .NET Framework components. Now we're stuck with ASP.NET MVC Core 1.0 which will be EOL'ed before we finish the project.

Just before I run my opinion, I would just like clarity on one part.
Would I be correct in making the assumption that if we want to continue using ASP.NET Core,
we will not be able to reference dll's that target .Net 4.5 or greater and have them work as they currently do?

@louislewis2 No, that's not correct. You will be able to use net45-net461 libraries, so long as they stay within the supported API space for netstandard2.0. You will not need to recompile those libraries.

@bradwilson Thanks for the clarification. That will surely make me sleep better tonight.
Many of the libraries are not in our control, so that would have been a huge issue.

Very relieved now :)

@shanselman @DamianEdwards @davidfowl For your list of items that we use which have not yet been ported, would be items in the system.management dll. We make use of the hardware identifiers specifically , this is used for automatic link generation for Azure Service Bus and our entire licensing server and client package. I imagine that with them not being the api currently, would cause us some serious issues?

https://github.com/dotnet/corefx/issues/3324
https://github.com/dotnet/corefx/issues/14762

This is our biggest holdup that keeps us running a few of our apps on the full framework.

This puts us in an awkward situation.

I'm in the middle of porting our microservices from ASP.Net 4.5 self-hosted in-process on top of Kestrel (legacy compat reasons), to full self-hosted ASP.Net Core 1.x. However, we need to run these things on full framework, for now. And there are good reasons for that.

We have a number of hard Windows dependencies that are already part of our infrastructure and aren't subject to change. That includes NTLM auth, Event Log logging, etc. If ASP.Net Core 2.x are bailing out of netstandard support, then I may as well not do it at all. The problem is, there isn't any actively developed full framework alternative. Katana is dead and slow (by comparison).

If somebody could point me to a HTTP server that's as fast as Kestrel for .Net Framework, then sure. But that doesn't exist. So I just have to accept that ASP.Net is leaving actual production customers like me behind with this change.

If the stack needs all the new goodies, like Pipelines and Span, then those should be provided as netstandard libs. What APIs is ASP.Net Core 2.x using that are in netcoreapp2.0 that aren't in netstandard2.0, and why can't those APIs be made netstandard2.0 extension libs in the meantime?

Are we seriously saying that MS spent 2 years working on a (net) standard across all of their frameworks only to turn around and release a flagship product that doesn't use this standard?

I think that GitHub Team will add Pagination feature for issues section because of this issue.

@mattnischan

I'm in the middle of porting our microservices from ASP.Net 4.5 self-hosted in-process on top of Kestrel (legacy compat reasons), to full self-hosted ASP.Net Core 1.x. However, we need to run these things on full framework, for now. And there are good reasons for that.

You can keep using ASP.NET Core 1.x right?

If the stack needs all the new goodies, like Pipelines and Span, then those should be provided as netstandard libs. What APIs is ASP.Net Core 2.x using that are in netcoreapp2.0 that aren't in netstandard2.0, and why can't those APIs be made netstandard2.0 extension libs in the meantime?

When APIs appear in .NET Standard that aren't in .NET Framework how are you going to use them?

@stefan2410

You can use ASP.NET Core 1.x for that right? Which ASP.NET Core 2.0 features do you need? Is it just SignalR?

Keep the app as is for the next two years but swap out the .NET Framework libraries with their .NET Core equivalent when done. This would keep our business logic etc shared between the two apps.
We can't do this as July 2018 is the deadline for ASP.NET MVC Core 1.0 support.

Once again, in my hypothetical world, we extend the lifetime of 1.x

Upgrade the app to ASP.NET MVC Core 2.0 and have it become part of the new app as we swap out the .NET Framework components.
We can't do this either, as Core 2.0 doesn't support the .NET Framework so it's all or nothing.

Do you actually need ASP.NET Core 2.0? Or just .NET Core 2.0?

When APIs appear in .NET Standard that aren't in .NET Framework how are you going to use them?

Our plan was: wait until they are in it. You said earlier that's just a matter of time, right? Lagging the bleeding edge by some fixed amount for the sake of stability would've been fine. Much better than falling permanently behind, at least.

@davidfowl
I will move in ASP.Net core 2.0. I don't have other solution. I can't say to the team to stay behind the evolution, we waited long time the ASP.Net Core.
As far as we don't have problems with our business logic 4.6 assemblies references.
I need SignalR, DirectoryServices, not problems with Azure/Amazon libraries, MS Orleans.
Also maybe it is irrelevant with the conversation above, but I want for a desktop app to host locally an ASP.Net Core with Kestrel / HttpListener as a UWP desktop application or as desktop bridge in UWP.
We can't rewrite the code for XAML and I would not like to use Electron.

You can keep using ASP.NET Core 1.x right?

For what timeframe? I can't see something like Event Log making it to netstandard.

When APIs appear in .NET Standard that aren't in .NET Framework how are you going to use them?

Is this a thing? netstandard20 appears to still run on net461 according to the docs. Are you saying that the API under netstandard20 is not complete enough to implement the new goodies? Or, is there some plan to move netstandard beyond framework that is not yet divulged?

Our plan was: wait until they are in it. You said earlier that's just a matter of time, right? Lagging the bleeding edge by some fixed amount for the sake of stability would've been fine. Much better than falling permanently behind, at least.

Libraries can be written on top of the standard. When things in the standard itself need to change it will take a lot longer to be adopted in all implementations of .NET and that includes .NET Framework. It can mean a couple of things:

• .NET Standard will evolve at the rate of the slowest implementation
• .NET Standard will evolve at some other pace and .NET Framework will be the last to catch up.

Of course it doesn't mean that libraries can't be written against it, it just means those caveats need to be taken into consideration when picking the version of .NET Standard you want to support.

Also maybe it is irrelevant with the conversation above, but I want for a desktop app to host locally an ASP.Net Core with Kestrel / HttpListener as a UWP desktop application or as desktop bridge in UWP.

ASP.NET Core on UWP isn't currently on any roadmap so I can't really say what's going to happen here. HttpListener is part of .NET Standard 2.0 though so maybe there's a chance that will work.

I want to take a moment to thank everybody for their comments and feedback here. We really do appreciate it as well as your patience while we figure out the path forward. Please know that we didn't intend for this change to be so hard, so late, and without warning. Hindsight is 20/20 and if we knew what we knew now we would have communicated things earlier. We'll try harder moving forward.

We have a plan based on the feedback we've received here that I want to share with you before we post it as an announcement later this week with the 2.0.0-preview1 release. When that happens, we'll open a new issue to facilitate discussion around that plan, but for now go ahead and continue to share your thoughts and feedback here:

• Support for ASP.NET Core 1.x on .NET Framework will be extended for at least another year (until July 2019). We will reassess this annually and commit to providing 12 months notice before ending support of ASP.NET Core 1.x (so by July 2018 we’d announce whether we’re extending for another 12 months to July 2020) (Side note: is anybody else freaked out by the fact we're talking about 2020 already? No? Ok, just me.)
• The new SignalR will target and be fully supported on ASP.NET Core 1.x (coming later this year)
• We’ll continue to update ASP.NET Core 1.x to support new language versions, etc. like we do for System.Web
• ASP.NET Core 1.x running on .NET Core 1.x will be supported until July 2018 (no change)
• ASP.NET Core 1.x running on .NET Core 2+ will be supported as long as ASP.NET Core 1.x on .NET Framework is supported
  
  
  
  • This is to ensure there is always an overlap of a supported ASP.NET Core on a supported .NET Core while we support running on .NET Framework, allowing customers to port over time while staying on supported bits
  
  
• .NET Core 1.x support (as a runtime) doesn’t change. Ends in July 2018. Customers running ASP.NET Core 1.x need to move to .NET Core 2.0 or be on .NET Framework at that point (or move to ASP.NET Core 2.0 on .NET Core 2.0)
• We will port System.DirectoryServices and System.Drawing to .NET Core this year (fully supported, cross-platform, preview for at least Windows in Summer)
• The list of things to port to .NET Core after that currently includes ServiceBase (to support .NET Core Windows Services). No timeline yet other than it’s next (timelines obviously get more concrete as we work down the list). We’ll build on this list as we go based on customer feedback.
• We have no plan currently to port System.ServiceModel (server-side WCF) to .NET Core. The WCF for .NET Core may continue to be enhanced and have features added based on feedback, e.g. HTTP message encryption.

@DamianEdwards @davidfowl a large part of the issue is that it can takes months of planning and dev effort whilst sacrificing a huge opportunity cost to commit to moving to ASP.NET Core where a lot of organizations wont to be able to move off from on .NET 4.x as it's the only platform they can be assured will be able to run all of their systems dependencies.

Up to this point MS has been marketing .NET Core aggressively as the future of ASP.NET where it's unclear whether development of ASP.NET 4.x has halted and if all future dev efforts are going to be invested in ASP.NET Core so there are going to be a lot of migrations underway to keep their systems current. A lot of people are going to feel like they've been thrown under a bus if that at the end result of all their efforts they've effectively migrated to an EOL'ed platform. This will hurt both organizations as well as the devs/consultants that were the biggest champions for initiating the move to .NET Core. They may not need anything from ASP.NET Core 2.0 now but they're definitely going to want have some headroom for their systems and be able to access some new features for all their efforts.

I also don't get why existing "legacy" code is considered a liability when IMO it should be considered one of .NET's greatest assets, .NET Core would be nowhere near as appealing if it wasn't able to run existing .NET libraries. Java is still so strong because of JVM's massive and stable ecosystem which is more important than the inherent weakness in the language itself.

I don't think MS has even begun to feel the backlash from dropping .NET 4.x support which wont be broadly known until it's announced, I'd expect most devs here actively following development on GitHub are more interested in seeing new features then they are in interoperability and ensuring there's a smooth migration path for existing code bases. I'd be very surprised, but if you don't get any heat from this decision after it's announced than it might be the right one as maybe there aren't going to be that many people hurt by it.

Would it be too much effort to focus on a ASP.NET Core 2.0 stable/compatible release, then announce the .NET Core-only future for subsequent versions? Just seems like it's the fair thing to do in this situation given it was completely unforeseen.

@DamianEdwards thanks for the update and a clear plan. I don't agree with it, but I still appreciate you laying it out.

There's still a huge fundamental gap here. The port to 1.x is almost entirely a lateral one, there are few features in it for us. 2.x is where some worthwhile upgrades are and we still have no guarantee we can ever make that move. There's a large chance that we spend a significant amount of time, money, and effort porting to 1.x only to be stranded there because of full framework dependencies. I will not make that gamble with our company. We may well end up with less support than we have on ASP.NET 4.x now.

Unless that changes, our apps will not be making the trip to ASP.NET Core, and all of our libraries will be far worse off for lack of dogfooding on it.

I sincerely hope you reconsider this decision. I hope one day we can make Stack Overflow take advantage of the thousands of personal hours we have devoted to help develop the .NET Core platform.

@NickCraver

There's a large chance that we spend a significant amount of time, money, and effort porting to 1.x only to be stranded there because of full framework dependencies.

Throughout this thread, you called out System.DirectoryServices as one of the core things. I assume you have some dependencies that you think will take a long time to get ported or ones that will never get ported. If 2.0 supported .NET Framework would those dependencies move in a year?

2.x is where some worthwhile upgrades are and we still have no guarantee we can ever make that move.

Which ones? It would be good to know because we were discussing back porting some high importance things back to ASP.NET Core 1.1 to ease the transition.

Unless that changes, our apps will not be making the trip to ASP.NET Core, and all of our libraries will be far worse off for lack of dogfooding on it.

I don't know anything about stackoverflow.com but is it possible to break pieces off (I don't want to say "micro services") so that ASP.NET Core could be used for some parts?

@mythz

This will hurt both organizations as well as the devs/consultants that were the biggest champions for initiating the move to .NET Core

Did you mean ASP.NET Core? Or .NET Core?

@davidfowl I meant ASP.NET Core, but it also affects devs who were planning on a staged migration from ASP.NET Core/.NET 4.x first then .NET Core later.

Speaking of which, I've noticed that there's no libraries on ASP.NET Core/.NET Core for handling SAML. I have a requirement to handle SSO via a third party IdP, but I don't know if that'll be possible.

@davidfowl I meant ASP.NET Core, but it also affects devs who plan on a staged migration from ASP.NET Core .NET 4.x first then .NET Core later.

I don't see why that would be the case.

I think that plan would probably be juuust enough for my org to avoid moving off the platform. The main thing is having a longer period with support (=security patches) during which remaining netfx deps can be rewritten or otherwise eliminated. It's all still kind of dicey and conceptually weird, though. What happens if three years from now we want to build a website which can ingest Excel documents or to embed a webserver in an app? What happens to other frameworks like Orleans building on top of the standard instead of netcoreapp?

I seriously do not understand why so much work was done on netstandard2.0 if it wasn't ever going to be good enough for ASP.NET Core to actually use it.

What happens if three years from now we want to build a website which can ingest Excel documents

Hard to say. I can't speak for the teams that own that but maybe it'll get ported to .NET Core and will work cross platform.

or to embed a webserver in an app?

HttpListener is part of netstandard 2.0.

What happens to other frameworks like Orleans building on top of the standard instead of netcoreapp?

It's up to frameworks to decide if they want to run on .NET Framework, UWP, .NET Core, mono etc. It's a choice. Orleans doesn't ship with .NET Core. ASP.NET Core does. Those products are one and the same.

What'll be a tough decision for us (and our clients) isn't about the libraries I have today, but the libraries I don't know if I'll need 6 months from now. There's a long tail of libraries and frameworks that don't support netstandard yet. For example, a month in to a project we realized that we needed a few features in NHibernate that weren't even close to there in EF6, let alone EF Core. So what would be my option there - target ASP.NET Core 1.x on full .NET?

Looks like I have some ApiPort in my future.

So what would be my option there - target ASP.NET Core 1.x on full .NET?

Yes.

Hard to say. I can't speak for the teams that own that but maybe it'll get ported to .NET Core and will work cross platform.

Right, but surely it's within the purview of the asp.net team to decide whether it's worth providing access to that ecosystem of maybe-not-ported libraries.

Right, but surely it's within the purview of the asp.net team to decide whether it's worth providing access to that ecosystem of maybe-not-ported libraries.

.NET is big and old, there's no way you can't expect the ASP.NET team to speak to the breath of libraries that exist in the .NET ecosystem. It's unrealistic. I just learnt what CSOM (https://msdn.microsoft.com/en-us/library/office/jj163123.aspx) was as part of this thread and I doubt it'll be ported but I couldn't say that for sure.

Extending support for ASP.NET 1.1 on .NET Framework helps mitigate this a bit but I think it also helps because some dependencies will need to be isolated to properly move to ASP.NET Core on .NET Core (which is the intended future).

I will leave aside the libraries as that point has been discussed at length already. In our case (amilia.com, e-commerce SaaS) the third party tooling is already a showstopper, we can't even run ASP.NET Core on the full framework at the time being. I acknowledge this doesn't sound like a legitimate reason, but its a constraint we have to deal with.

We could, in theory, replace those tools (i.e. profilers, monitoring, build servers, etc) with alternatives supporting .NET Core but that's a couple months of work I'd rather spend on solving more pressing issues. We'll make the migration eventually to ASP.NET Core/.NET Core, but right now it's quite a moving target.

Up until this point the expectation was created that ASP.NET Core would be able to keep running on desktop framework, and thus speak to the breadth of etc etc. I don't know what kind of tea leaves we were supposed to read to know that that was unrealistic :/

Like, to be clear: the idea that ASP.NET Core might only run on .NET Core is not crazy itself, but we never heard a peep of it before. All public information was that it ran fine on .NET Framework and there was no indication that this might have to change.

.NET is big and old, there's no way you can expect the ASP.NET team to speak to the breath of libraries that exist in the .NET ecosystem. It's unrealistic

Isn't that a good reason to keep supporting .NET 4.x? The burden of compatibility/interoperability can be contained to .NET 4.x platform which can be a working solution that could relieve .NET Core from needing to interoperate with older libs and relieve pressure to port existing popular .NET libraries to .NET Core (for MS and external authors).

@mythz

Isn't that a good reason to keep supporting .NET 4.x? The burden of compatibility/interoperability can be contained to .NET 4.x platform which can be a working solution that could relieve .NET Core from needing to interoperate with older libs and relieve pressure to port existing popular .NET libraries to .NET Core (for MS and external authors).

That's why ASP.NET Core on 1.1 's lifetime has been extended (though not permanently). We're going to make sure that SignalR works because that was stated as one major reason for using ASP.NET Core 2.0. At the same time, it's not where ASP.NET Core wants to be in the long run. The intent was always to ship as part of a unified .NET Core platform.

@gulbanana

Up until this point the expectation was created that ASP.NET Core would be able to keep running on desktop framework, and thus speak to the breadth of etc etc. I don't know what kind of tea leaves we were supposed to read to know that that was unrealistic :/

ASP.NET Core on .NET Framework was unfortunately never communicated as a stop gap solution to ease porting (that's something we messaged very poorly). It was never intended to as a supported platform forever which is the logical conclusion if you were to assume that some dependencies will just never be ported.

That's why ASP.NET Core on 1.1 's lifetime has been extended (though not permanently).

The issue is whether or not that's enough, the current version has basically been EOL'ed before a compatible/stable release has even been delivered.

I don't believe the value of existing investments is being considered, who is going to want to go through all the effort to migrate to an EOL platform? Devs will be working on their existing brownfield systems indefinitely, they're basically being told their current ASP.NET v4.x skills are going to become obsolete and they're not able to migrate to the new ASP.NET Core development model because .NET 4.x support is being dropped and it would be irresponsible for them to consider or recommend migrating to a dead-end platform.

@davidfowl

ASP.NET Core on .NET Framework was unfortunately never communicated as a stop gap solution to ease porting (that's something we messaged very poorly). It was never intended to as a supported platform forever which is the logical conclusion if you were to assume that some dependencies will just never be ported.

Mistakes happen, that's fine. The problem now is that many people made this assumption and so are only using ASP.NET Core because of their logical but erroneous conclusion. We'll see just how many, I guess :/

I waiting asp.net core 2/ .net core 2 so long, but the result is so depressed.

@mythz

I don't believe the value of existing investments is being considered, who is going to want to go through all the effort to migrate to an EOL platform?

Can't the same argument be made about ASP.NET Core 2.0 being EOL on .NET Framework next year when 3.0 comes out? If you're saying a year isn't enough on ASP.NET Core 1.1 why would you suggest a year is ok on ASP.NET Core 2.0?

Devs will be working on their existing brownfield systems indefinitely, they're basically being told their current ASP.NET v4.x skills are going to become obsolete and they're not able to migrate to the new ASP.NET Core development model because .NET 4.x support is being dropped and it would be irresponsible for them to consider or recommend migrating to a dead-end platform.

Who got told that ASP.NET 4.x skills are going to become obsolete? If anything we're hoping they aren't. MVC in particular touts concept compatibility with a few new features. ASP.NET Core looks a lot like Katana (and that's not by mistake). If you're talking about Web Forms then what about MVC ?

I don't have any experience consulting but I would agree that if the dependencies aren't available then I would agree. Either that or the application needs to be re-designed to take this into account.

@xyting can you clarify?

@davidfowl

Can't the same argument be made about ASP.NET Core 2.0 being EOL on .NET Framework next year when 3.0 comes out? If you're saying a year isn't enough on ASP.NET Core 1.1 why would you suggest a year is ok on ASP.NET Core 2.0?

I was under the long-time assumption that ASP.NET Core 1.1 was just a stop-gap solution to ASP.NET Core 2.0 and .NET Standard 2.0 which would be the compatibility focused and stable LTS release that will bridge the gap with most of the core functionality missing from .NET 4.x - up until this thread basically destroyed that assumption. Keeping .NET 4.x compatibility up to ASP.NET Core 2.0 isn't ideal, but it's a lot better than terminating it at the current release which no-one expected.

Who got told that ASP.NET 4.x skills are going to become obsolete? If anything we're hoping they aren't.

MS does with all their aggressive marketing on .NET Core with all new announcements and features seemingly being ASP.NET Core focused. Is old ASP.NET WebForms/MVC even being developed in the open? What proportion of dev effort is being invested on old ASP.NET WebForms/MVC vs .NET Core? I've no idea, everything I've seen recently, all weekly standups, video tutorials seems solely focused on ASP.NET Core. I know I definitely wouldn't feel comfortable starting new greenfield projects using old ASP.NET WebForms or MVC technology.

If you're hoping they aren't MS should definitely communicate that better with clear roadmaps. Given how volatile ASP.NET has been in the last few years (this issue being a perfect example), it's impossible to know what the future is without an official commitment and announcement.

Does anyone else feel that it would have been better if version 1 never ran on full framework? I didn't expect it to because of the naming. Now that it does and I've had a taste I'm disappointed to lose it.

I do get where you're coming from on this, you want to iterate the whole stack as fast as possible. You're competing with a whole bunch of green fields web frameworks that control the whole stack and have no baggage to drag along. Hell dropping the baggage of System.Web is one of the main reasons ASP.NET Core is so exciting.

Having slept on it I can say our usage will be fine, the dependencies we need should all work on 2.0.

At the same time, it's not where ASP.NET Core wants to be in the long run. The intent was always to ship as part of a unified .NET Core platform.

While it doesn't take a psychic to figure out that .NET Core is the platform of .NET's future... if the intent from the beginning (or as you put it "always") was to couple ASP.NET Core with .NET core, that was definitely not communicated in any medium I've ever seen.

I've literally seen every single minute of every single ASP.NET standup (including Hanselman and Glenn troubleshooting Docker for 3 hours... because I have no life), I read the blogs, I'm always on Twitter, I go to 2+ conferences a year, attend user groups, etc. and I've never once heard that communicated as the intent of ASP.NET Core. Instead, I've heard over and over and over "it runs on both platforms" and, rightfully, people feel like someone pulled the chair out from under them. I've even given talks about ASP.NET Core and said "it runs on both platforms" myself, and now I feel guilty for anyone I've led down this path. I would say the people ITT are likely to be on the bleeding edge and would be the most accepting of this kind of news, and there's a lot of backlash here. This seems like it's only going to get worse as this news trickles down to the developers and their managers who aren't as plugged in, and are likely more conservative than those ITT.

Besides the lack of communication and the lack of support for some scenarios, I think a lot of the backlash is just due to the timing of this announcement. .NET Core 2 isn't even RTM'd yet and it's already been deemed the only long term path forward, and there's essentially been a ticking time bomb put on Full Framework for ASP.NET Core. I think a lot of our fears could be cleared up once we have something tangible to play with besides nightlies.

I really do think there needs to be a better tooling experience than "run it and see if it works" when referencing net461+ libs from .NET Core 2+ in VS, because I can already see that message of "we can likely run most of your 461+ assemblies too!" will be marketed to death. Something that could analyze missing API's of what we referenced, providing compile-time errors, ideally even suggesting compat nupkgs if they exist (like System.Configuration in the EF6 example above... and have it work :smile:). Obviously, not everything can be analyzed at compile time (the distributed transaction scenario mentioned above comes to mind as something tough to anlayze ahead of time), but the more that can the better. Something kind of like what Immo did here for PlatformNotSupportedException and the missing net461 APIs for netstandard2 would be nice.

Just my 2 cents. I hope I'm just overreacting. Ultimately, a lot of us are just disappointed, because we love ASP.NET Core, and we don't want anything standing in our way of using it. ❤️

Joining my voice to the concerns already listed, we are starting a new ASP.NET MVC project next month and it will be plain .NET Framework with ASP.NET MVC, because the customer doesn't trust Microsoft doing the right thing in regards to long term planning.

The customer organization is still using Windows 7 deployments and this project is an exception, because the majority of their web projects is actually done on UNIX with Java, with .NET being mostly used on desktop applications.

This type of uncertainty just piles up to the broken history that Windows 8 .NET stack and UWP were, increasing the interest of the organization CTO to look for more stable alternatives to .NET future.

If you are forcing these type of organizations to write modules from scratch to work on ASP.NET Core, I can as well advise our customers to adopt something with more stable roadmaps,instead of losing face about issues I cannot control.

@davidfowl It might be that this change will work fine for 99% of the projects. But it was sold as "it runs on both platforms" and "you can use it with full framework if you have to". Everyone knew that the full framework version of asp.net core was for the projects that could't migrate, and that was fine. And people planned with that in mind.

This change might not be the worst in terms of code, but it will most likely create a huge shit storm when the more regular developers see the news. And it will not be about the code, it will about what was promised. And the promise was "run net or core, and netstandard to combine them all".

@DamianEdwards @davidfowl Thanks for sharing the plan.

SignalR on 1.x is a big relief to replace our unsupported version and also the news that ServiceBase is next on the list next as we are currently using that also!

We are heavily reliant on EF6 and spatial though so we'll be stuck on 1.x until that has the feature set we need....

On a semi-amusing side note however, this may finally force a more microservice deployment for this. I wont be looking forward to explaining why our LOB customers need to have several more api's installed on IIS to just to get our products working though....

I really wish this could be held back as just seems to be too soon and as several people have mentioned this will generate a significant backlash when the blog post drops.

Also i must say i feel a bit sold-down-the-river when from the start the sentiment has been this will run on the full framework and have been preaching the same thing to colleagues. Explains the confusing naming choice of asp.net core though.

@shanselman @davidfowl My biggest pain point is NHibernate. Even after the EF Core release, it's still the only most advanced full featured O/R mapper.

@shanselman @DamianEdwards I am in the process starting to think about upgrading a site from ASP.NET MVC 4 to whatever the latest version is (I'm confused whether it's 5 or one). I still need to run the full .net framework because I am referencing both SyncFusion and Telerik libraries. SyncFusion to display PDF files and Telerik to generate word .docx files. As others have pointed out it's simply not reasonable for Microsoft's strategy for dealing with this to be "try it and see if it works". I can't guarantee that and production everything is going to work because it is such a large code base of third-party code.

While SyncFusion support is generally very good Telerik's support is not and I'd be surprised if they can make it work with .net core. I have no idea what Apis they might be using that are not supported in .net core - and as an end user that's the whole point of the third-party product, I just plug it in and it does what it needs to do.

Frankly for a customer who doesn't deal in the stuff very frequently (I mostly do WPF) this is all extraordinarily confusing. There are too many different versions, with various incompatibilities. As someone has pointed out it's a bit like UWP XAML - simliar but completely incompatible with WPF XAML.

Not good for developers and just another thing that causes developers to lose trust in Microsoft (one of many over the last few years). It would seem to me that ASP.NET should definitely run on the full .net framework, because there is such a big library of tools that people may need to use on their server. In my case I can easily update to a later version of the .net framework if I need to in order to use latest ASP.net stuff if an update was required for the new ASP.net functionality.

Whatever messaging goes to developers needs to be much clearer, before people just jump ship completely.

...Stefan

ASP.NET Core on .NET Framework was unfortunately never communicated as a stop gap solution to ease porting (that's something we messaged very poorly). It was never intended to as a supported platform forever which is the logical conclusion if you were to assume that some dependencies will just never be ported.

I personally don't have a problem with the changes listed in this issue, I understand the reasoning and they make sense, now that I've read through a lot of responses here. However, what you've just said highlights what's ultimately the crux of the issue - poor communication from Microsoft as a whole (Which I appreciate is not your, or any _specific_ individual's fault).

Maybe I'm missing something, but there's more to "developing in the open" than just having the code on github for everyone to poke through and play with. This very issue was created because a change appeared in the code one day that took people by surprise, but obviously yourself and everyone on the .net team knew about it and understood it - so it was a long time coming. The problem is that the rest of us mere mortals were completely blind-sided by it.

Worse still, I suspect the majority of developers don't pay too much attention to github to get their knowledge and information - so this change is going to surprise a lot more people than are already commenting here. I only discovered this issue myself because it appeared on my RSS feed of hackernews - which is not what I'd call my top source for news and information.

Anyone following along from the blog posts on MSDN will know that 2.0 is coming and they'll see it as the holy grail of bridging the gap between asp.net core and everything it was "missing" previously, but they're completely unaware of what is essentially a breaking change for certain workflows. There's been very little details on what's really happening with the design of asp.net core 2.0. I suspect more details will come later this week at Build? One can only hope.

The .net slack is another resource for information, but it's a little bit noisy to be kept up to date with what's really going on. It's great for developer involvement and asking questions, but it's hardly a news source.

Twitter and social media is another source of information, but again a bit like this github issue by the time it appears there, it's usually because someone has raised concerns with a decision that's already been made and caught people by surprise.

This isn't the first time we've had this exact problem, either. Remember the fiasco caused by changing back to csproj? I don't want to get into the debates over that change, but it's another example of a change that happened to people's surprise, that was so poorly communicated that to this day, many people simply don't realise that it's not the same csproj from the "bad old days".

I'm not completely sure what I'm trying to suggest here, but there is definitely something "missing" from the open development of .net. Microsoft does a great job of providing resources and documentation for developers, but only for finished products and things that have shipped. The roadmap, the planning meetings, everything that gets to decide the design and direction of the frameworks seems to be done behind closed doors, with the occasional mention of "select partners" and the like. I'm not saying that every meeting should be streamed and broadcast worldwide, but there could definitely be a better middle-ground whereby decisions that are made and the rationales behind them are communicated as early as possible to the community, in a way that's easy for those of us who really _want_ to follow along to digest and keep on top of. Perhaps a dedicated blog on MSDN (or elsewhere) that's updated regularly when those decisions are made.

One of my biggest issues with this is that on almost every conference the last year that ASP.NET Core has been presented, you have presented it with a slide that shows asp.net core running on both .net framework and .net core, just have a look at this: Explore web development with Microsoft ASP.NET Core 1.0 from Ignite last year. At about 7.50, you will see the slide.

The biggest showstoppers for me are System.DirectoryServices, ServiceBase, EF6 (EF Core is not ready), ClosedXML (for creating excel sheets).

Support for ASP.NET Core 1.x on .NET Framework will be extended for at least another year (until July 2019). We will reassess this annually and commit to providing 12 months notice before ending support of ASP.NET Core 1.x (so by July 2018 we’d announce whether we’re extending for another 12 months to July 2020) (Side note: is anybody else freaked out by the fact we're talking about 2020 already? No? Ok, just me.)

@DamianEdwards Thank you for the announcement.

At the moment our company is developing enterprise applications for several clients using ASP.NET Core 1.1 on .NET Framework 4.6.2. Hearing that the support for that framework combo is supported until at least 2019, and possibly extended 2020 is a huge relief.

We will port System.DirectoryServices and System.Drawing to .NET Core this year (fully supported, cross-platform, preview for at least Windows in Summer)

These are the two only reasons we're targeting .NET Framework right now. If these are fully ported to the .NET Core 2, I'm sure that we can port our applications to ASP.NET Core 2 safely next year.

Seems like alot of ppl have broken the cardinal rule of being a MS developer - dont commit to any product/fork until atleast the V2.

but yeh, talk about alienating your enterprise clients! the whole reason they use MS is for backwards compatibility.

The majority of ppl who run ASP.NET do NOT CARE if it runs on linux. And if they saw a blog post, with a speed comparision with ASPNET Core, they wouldnt even both reading past cross-platform if they saw it didnt support legacy .NET.

lolcats.

I think there is value in having ASP.NET Core 2.0 fully run on net46x for the sake of giving lots of folks a smooth migration path to the new world. I think many people were waiting for ASP.NET Core 2.0 and .NET Core 2.0 with the hope that it will close many of today's gaps and allow a migration. If ASP.NET Core 2.0 will require everything to be ported to netcoreapp2.0, then it will be a massive slowdown for teams and perhaps even jeopardise feasibility.

However, that doesn't mean that there cannot be an ASP.NET Core 3.0 shortly after which will only target netcoreapp2.0 for all the people who work on all the new shiny greenfield stuff and want to be on the fast track.

Having two versions of ASP.NET Core (2.0 and 3.0) side by side could really be a good thing (for at least a while). That could allow MSFT to quicker phase out the current MVC 5 stack, because the new version of MVC would essentailly be ASP.NET Core MVC 2.0, which would run on full .NET as well.

I think there is value in having ASP.NET Core 2.0 fully run on net46x for the sake of giving lots of folks a smooth migration path to the new world

What would make it smoother than porting from ASP.NET Core 1.x?

I think many people were waiting for ASP.NET Core 2.0 and .NET Core 2.0 with the hope that it will close many of today's gaps and allow a migration.

The bulk of the work done to make things compatible was done in .NET Core 2.0 and .NET Standard 2.0. ASP.NET Core 2.0 honestly doesn't have that many new features. We're said we're going to backport SignalR to ASP.NET Core 1.x (which is post 2.0 anyways). Is it just a perception thing?

Having two versions of ASP.NET Core (2.0 and 3.0) side by side could really be a good thing.

This is what we're doing with 1.1 and 2.0 (just flip the numbers).

That could allow MSFT to quicker phase out the current MVC 5 stack, because the new version of MVC would essentailly be ASP.NET Core MVC 2.0, which would run on full .NET as well.

MVC 5 will never go away, we don't deprecate anything. It'll be supported as long as .NET Framework exists. You still can't run ASP.NET Core projects inside of the IIS integrated pipeline (on System.Web) and it doesn't do all of the same things as MVC 5 on System.Web so it's really not a replacement for certain scenarios.

@davidfowl Will I be able to create an ASP.NET Core 1.x app, which targets full .NET and netcoreapp2.0 so that I can migrate a current legacy app to ASP.NET Core first with all dependencies being net46x and slowly migrate one dependency after another to target netstandard2.0 until everything is on netstandard2.0 which then would allow me to upgrade the ASP.NET Core 1.x app to 2.x (and drop the target for net46x as part of that)?

If yes, then I think I misunderstood the thread. I think this is really what most people are after here.

@dustinmoris yes you can do that. The main concern people are having is what happens if they don't get migrated to ASP.NET Core 2.x before support ends on ASP.NET Core 1.x, if it is possible for them to migrate at all.

@alexwiese ah ok well that is great, then really what are we discussing here now? Rather than discussing what framework to target we should be discussing the support period of ASP.NET Core 1.x, which is something that MSFT could easily change if they wanted :)

EDIT:
@DamianEdwards wrote this a bit further up in the thread:

Support for ASP.NET Core 1.x on .NET Framework will be extended for at least another year (until July 2019). We will reassess this annually and commit to providing 12 months notice before ending support of ASP.NET Core 1.x (so by July 2018 we’d announce whether we’re extending for another 12 months to July 2020) (Side note: is anybody else freaked out by the fact we're talking about 2020 already? No? Ok, just me.)

Sounds good to me. Commit to one more year of support and then periodically re-asses. Makes total sense to me.

I've read every post in this thread. Still one question is unanswered: why is this decision made? I can only conclude it was needed due to a technical issue. If 'confusion' of the naming is the issue, Microsoft should hire a better PR person and stop stirring the shit like the team is doing in this thread.

So what is the technical issue that blocked ASP.NET core 2.0 on netstandard2.0? Nothing is impossible in software land, so it can't be you couldn't come up with a solution that isn't doable on .NET full (and thus can't be included in netstandard20). Yes that takes time and effort, but I have the feeling you all didn't really realize the side effects of this decision for your users, what the amount of time / effort they have to invest because of this.

This decision has another downside: ASP.NET Core isn't a consumer of netstandard and therefore isn't a driver of it. It makes the netstandard a follower and as ASP.NET core doesn't depend on it, a follower with little meaning: .net core 2.0+'s API is the surface to target, as ASP.NET core is targeting that surface, not netstandard2.0.

And, sorry @davidfowl, I know you mean well, but suggesting ASP.NET core 1.x to people over and over shows you really have no clue what the situation is for the people you suggest that to: the people can't migrate to ASP.NET core 1.x because they don't know if there is a smooth path off of it without a firm deadline: it might be they need to stay on that platform for longer than they currently think (dependencies needed to be ported etc.). That alone makes the decision to move to ASP.NET core 1.x a decision based on nothing else than a 'promise' from Microsoft. It's an API meant for internet facing code. They need to know whether they can run an app built today also within 3 years time because Microsoft will fix security flaws in it (to give an example).

Frankly, I don't get the urge to start yet another chaos cluster within the .NET ecosystem: we need stability, dependability, reliability: "my code written today will run in 5 years time as-is". yes, I know that sounds silly to some people, but that's reality: there are already more software packages on this planet than there are developers to maintain them and the gap is only widening. You can't simply assume that an organization will decide to use ASP.NET Core as their webstack and hope code written using it will run within 5 years time, organizations don't do that anymore: they know there are stacks out there which are reliable and give them that: they know they might not be able to rewrite the entire app within that timeframe so they need that assurance.

Microsoft has shown with this thread and, sorry, their terrible PR around this issue, they can't give that assurance. And no matter how much spin you try to give that in the coming days at \build, we on the other side of the fence have learned that Microsoft Marketing != assurance things will work tomorrow.

@FransBouma I don't think it was that there was a technical issue, it sounds like the motivation to only target netcoreapp2.0 is because this is the only track that MSFT can move as quickly as they like, which is good for us after all, because it means that ASP.NET Core 2.x can move much faster than any other web stacks in the .NET world before. If you cannot commit to this fast train, then you can stay on ASP.NET Core 1.x for longer (currently supported till 2019)

@FransBouma as @davidfowl and @shanselman mentioned there are new APIs being added at a fast rate in .NET Core, and ASP.NET Core 2.x will use some of them, therefore the desire to target netcoreapp20. If they were to add these APIs to netstandard2x then .NET Framework and other platforms would have to play catch up, and they are notoriously slow moving.

I'm going to add my voice on the This is a Good Thing side of the debate. Here's why:

• The team are not just doing this for the hell of it. There's a whole slew of new features and optimizations ready (or nearly ready) to roll in .NET Core that are incredibly useful to people building modern web applications, APIs and microservices, and waiting for those features to land in the full Windows .NET Framework would delay release by many months.
• Many of the complaints I see in this thread are some variation of "I can't do X in .NET Core 2.0" when what the writer actually means is _"I have to change the way I do X in .NET Core 2.0"_. Yes, you have to change. No, that's not a bad thing. If you have a small piece of discrete functionality in your ASP.NET MVC application that does something with PDFs or DOCX files, and you _really_ can't find a better way to do whatever that is (have you tried?), then break that functionality out into a microservice running on full .NET on Windows Server and call it as an HTTP API from your .NET Core application. Decomposing applications and moving specific functionality into small, self-contained services isn't even a workaround, _it's a general-purpose best practice._
  
  
  
  • NB As far as I can tell, the OpenXML packages are now supporting .NET Standard, so working with Word/Excel/whatever shouldn't be impossible.
  
  
• .NET Core 2.0 isn't even in proper public preview yet, so complaining that it hasn't got support for LDAP or whatever seems premature. If RTM comes around in Q3 and there's still no way of interacting with AD or Kerberos or whatever then complain away (although also think about migrating to modern token-based authentication systems because it's not 2008 anymore).
• There _is_ a smooth migration from ASP.NET MVC 4.5 to ASP.NET Core 2.0. It's called ASP.NET Core 1.0 (and I agree that there should be some promise of long-term support for 1.0 under the circumstances). You can build apps using 1.0 and run them on Full .NET in an Integrated Pipeline under IIS 8.5 on Windows Server 2012 R2 until
  
  
  
  • Full .NET catches up and you can run ASP.NET Core 2.x on it, or
  
  
  • Whatever third-party tech you depend on supports .NET Core (or can be replaced by equivalent tech that supports .NET Core).
  
  
• Remember that—while your team might be hamstrung by external dependencies or internal company policies or politics or just plain inertia—there are hundreds of thousands, if not millions, of developers in the world who are looking to build applications, services and APIs using modern architectural patterns and new technology platforms (cloud/edge/IoT/etc), for whom ASP.NET Core 2.0 is a great fit. They want it to be fast, scalable and cross-platform; those things are important to a lot of people. Asking Microsoft to ignore that rapidly-expanding market, just because your 3rd-party control supplier or an open-source project haven't ported their code yet, is silly.

@dustinmoris that suggests netstandard lacks the APIs to create a fast webstack. If so, we all have bigger problems.

@alexwiese like I said, I read the complete thread and thus also the posts you refer to. I know what they say and can see their point, but the decision made shows they have no idea what their users are doing with their stuff. I build a product myself, for many years now, and know that after a while you arrive at a point where you want to cut things out and move faster, without the old cruft that is outdated. But doing that has consequences, and one thing I've learned in the past 14 years is that backwards compatibility is one of the biggest features a software product can have: being able to use it and 'it just works' is a key point for many many people to decide for your platform. You might not think it's that important, and that's fine, but there are many many people out there who can't see it that way as their reality is different.

It's not that the asp.net core team shouldn't move fast, it's that they do it in a way that breaks with many people's assumptions when they moved to asp.net core 1.x.

@FransBouma Why do you think you have a better idea of what Microsoft's users are doing with Microsoft's stuff than Microsoft do?

@markrendle

The team are not just doing this for the hell of it. There's a whole slew of new features and optimizations ready (or nearly ready) to roll in .NET Core that are incredibly useful to people building modern web applications, APIs and microservices, and waiting for those features to land in the full Windows .NET Framework would delay release by many months.

So, tell me, why not create these super duper APIs as .net standard 2.0 packages and post them on nuget?

Why do you think you have a better idea of what Microsoft's users are doing with Microsoft's stuff than Microsoft do?

Oh I don't know, by reading the posts in this thread?

@FransBouma

that suggests netstandard lacks the APIs to create a fast webstack. If so, we all have bigger problems.

I don't think that netstandard lacks anything, because netstandard is nothing more than a list of features that need to be implemented by a platform that wants to support that standard. In theory we can move netstandard as fast as we like, just add more to the spec, but realistically it is not feasible for all platforms to catch up with those new specs.

So the question is, does ASP.NET Core 2.x want to commit to netstandard2.0 (the currently highest) and then know that it is stuck with everything that has been defined there, or does ASP.NET Core 2.x only commit to netcoreapp2.x, which can be much more than just netstandard2.0. After a while I am sure there will be a newer netstandard again (3.x?) which will catch up with new shiny things from netcoreapp, but that will take much more time and why should ALL asp.net frameworks be crippled to slow progression. It's kind of nice to have one really fast moving ASP.NET Core stack as long as there is also a second that gives people a more long term support which adheres with netstandard.

@FransBouma Oh, sorry, I didn't realise your sample size was so big. 257 comments with a strong bias towards people who don't like the decision? Hard to argue with that.

DISCLAIMER: I am not an expert on Big Data.

@davidfowl:

Throughout this thread, you called out System.DirectoryServices as one of the core things. I assume you have some dependencies that you think will take a long time to get ported or ones that will never get ported. If 2.0 supported .NET Framework would those dependencies move in a year?

Yes, we have other things. System.Directory services is what I point out because even the top requested namespace isn't ready. All others are worse off. The API portability analyzer isn't even updated for VS 2017 where we can run it. The analyzer to see if you can even port hasn't been invested in and we're dropping support already.

Which ones?

Razor pages is a huge one, I've mentioned it several times.

I don't know anything about stackoverflow.com but is it possible to break pieces off (I don't want to say "micro services") so that ASP.NET Core could be used for some parts?

No, this isn't really possible. We don't render in 18ms by making API calls and adding overhead between things. I'm happy to go over architecture anytime, you'd see that isn't really a reasonable route.

I thought I explained this earlier but here it is again:

Any API that is part of netstandard that needs to evolve will evolve slowly. Things can be built on top of netstandard and can run anywhere, and that's fine. The moment you need a new API on say, http client, or SSL Stream, or Int, or String, or Array, or LINQ or any of the primitives that exists in NET Standard a new .NET Standard version must be created and implementations need to agree that they will implement it. Now that's not the end of the world because we own most of them now, mono, .NET Core, .NET Framework, UWP but there are others though like Unity (and probably others). Each .NET vertical has their own time frame and ship cycle, they are each their own separate products and that can't be ignored.

But now you get the idea, a new netstandard version is created when new APIs come online. If libraries want to use these new APIs then you immediately lose the breath of support for all the platforms. You can cross compile and try to polyfill but that doesn't scale for all changes.

Hopefully that gives you an idea of what the process might look like bringing APIs to netstandard. @terrajobst would have a better idea of what the plan is.

@DamianEdwards and @shanselman What about Service Fabric and Unit Tests?

In our case we have a big micro service project with lots of SF applications which are Core projects but use .Net Framework 4.5 up to 4.6.(something). SF currently doesn't not support netcoreapp therefore we had to use .Net Framework but since we didn't want to fall behind we used the .Net Core project.

(another issue is) Because our services are .Net Framework and MS Fakes are not available for netcoreapp all our unit tests are normal (or should I say legacy) .Net Framework projects. Almost all our libraries are on netstandard 1.0 to 1.6.

Again our client apps are using Xamarin Forms + UWP and we managed to use netstandard so our libs are compatible.

Does this mean we are stuck and won't be able to upgrade to .Net Core 2.0 and netcoreapp2.0 and netstandard 2.0?

@NickCraver

Razor pages is a huge one, I've mentioned it several times.

I understand this one but I can't believe that you're going to convert all of stack overflow to razor pages only. If you're already using MVC today why not just port to regular views and when more dependencies come online, port to razor pages. The way razor pages is designed makes it trivial to go from a controller action to a razor page.

Yes, we have other things. System.Directory services is what I point out because even the top requested namespace isn't ready. All others are worse off. The API portability analyzer isn't even updated for VS 2017 where we can run it. The analyzer to see if you can even port hasn't been invested in and we're dropping support already.

Just make sure to escalate that list of dependencies so we know what's important.

@aboo

Does this mean we are stuck and won't be able to upgrade to .Net Core 2.0 and netcoreapp2.0 and netstandard 2.0?

You meant ASP.NET Core 2.0 and? .NET Core 2.0 and .NET Standard 2.0 don't really apply here.

Yes, you'll have to stay on ASP.NET Core 1.x.

The bulk of the work done to make things compatible was done in .NET Core 2.0 and .NET Standard 2.0. ASP.NET Core 2.0 honestly doesn't have that many new features. We're said we're going to backport SignalR to ASP.NET Core 1.x (which is post 2.0 anyways). Is it just a perception thing?

@davidfowl I think you're massively underestimating the fear that strikes the heart of a windows developer when you're told you're going to have to migrate things. _Especially_ when the new stack hasn't hit feature parity with the old stack, and it's unknown if and when that will happen. This is basically announcing the EOL-ing of ASP.NET Core on the full .NET Framework. And, while that probably wasn't the long-term plan, it was announced as a feature, and people thought it might stick around for a while. Roadmaps are shifting as we speak. Meetings will be had.

We've got some disgustingly old stuff that we have to support because of nominally maintained database connectors and SDKs. Some of these vendors are far more likely to release a new, butchered API with 30% existing functionality, an HTML5 interface and a fresh train of bugs than they are to maintain their existing products. Or they might just acquihire a competitor, release the product and quickly EOL it. Some of these vendors are big enough to be recognizable. We've got a lot of nice code, but some of that code also lives in the windows slums despite our best efforts because it's not always under our control. Old tech doesn't just gracefully retire. It lurks under your bed, in our closet, and beneath your keyboard.

I'm more concerned about this move signalling the possible sidelining of .NET Standard than I am about the rest of it. .NET Standard initially seemed like something that would bring the different implementations closer and closer to feature parity while allowing consumers to migrate to the evolving, growing platform. Now it's sounding like nothing more than a milestone of .NET Core features. You won't be able to (or want to) target executables towards .NET Standard - only libraries. And it sounds like there will be significantly less planning involved in .NET Standard, and instead it'll just get rubber-stamped with whatever got used in ASP.NET because it's already too late to change. It'll already be in production, after all.

Other developers have to sprinkle the code with compiler directives, split code into platform-specific libraries and compile with multiple targets. The rude part of me wants the ASP.NET Core team to dogfood that so you'll be interested in better runtime and tooling support for multi-targeting and multi-platform scenarios. And if your team wants it, then we might get it. The practical part of me says that at a minimum, you should have periodic releases of ASP.NET Core that target the .NET Standard. You need to make actual _stable_ releases anyway. No one's just going to compile the master branch from git and deploy to production. Why not do smaller iterations of the .NET Standard and match them with a tagged ASP.NET release?

Also, is there going to be a new ASP.NET for the desktop? All the fanfare made it sound like ASP.NET Core was the only ASP.NET. Now it's sounding like you won't get anything new on ASP.NET unless you're on .NET Core. And that's going to change a lot of business strategies. There is a whole lot of confusion going on with roadmaps.

MVC 5 will never go away, we don't deprecate anything. It'll be supported as long as .NET Framework exists.

Yes, we're quite aware that the old stuff will stay there. It usually does, and we appreciate that. But whether new things will get on the "full" framework matters a whole lot. We need to know where things are going. We don't want to ride the train to the end and only then think about how to move forward. We've also got our passengers to worry about. And the disparity between .NET Core and .NET Framework leaves a lot of people uncertain about the future. I asked a question a year and a half ago about when a particular portion of functionality was going to be supported in .NET Core. I even asked if it would be accepted if I were to work on it personally. Communication has been sparse. I still have no idea what's going to happen to it. That type of uncertainty about supported scenarios and timelines makes a huge difference in the code that we write. Even knowing what sections of the desktop framework are low-priority could give people ample time to migrate instead of waiting for status updates.

In short, I support what you're doing and the goals behind it. And I know it's hard when we get on here and complain about decisions that you've made for a very good reason. But a lot of people aren't going to jump on the pioneer train because they can't, and others won't because they don't know where it's going.

@davidfowl I guess. What do you call a core project (new) with .Net Framework? Whatever that is, my understanding from the post is that the netstandard vNext will not support that.

@markrendle We are real customers. We're telling people things won't work. I know my architecture better than you do, so the arrogant comments aren't helping. To your points:

The team are not just doing this for the hell of it. There's a whole slew of new features and optimizations ready (or nearly ready) to roll in .NET Core that are incredibly useful to people building modern web applications, APIs and microservices, and waiting for those features to land in the full Windows .NET Framework would delay release by many months.

No one is against them also supporting these things. Our complaints are universally about dropping support, not conditionally adding new features.

Many of the complaints I see in this thread are some variation of "I can't do X in .NET Core 2.0" when what the writer actually means is "I have to change the way I do X in .NET Core 2.0". Yes, you have to change. No, that's not a bad thing. If you have a small piece of discrete functionality in your ASP.NET MVC application that does something with PDFs or DOCX files, and you really can't find a better way to do whatever that is (have you tried?), then break that functionality out into a microservice running on full .NET on Windows Server and call it as an HTTP API from your .NET Core application. Decomposing applications and moving specific functionality into small, self-contained services isn't even a workaround, it's a general-purpose best practice.

This is just so far off base I don't know where to start. Our pages would be far slower and more expensive in "micro-services". We'd eat significantly more time in GC than we do in page renders with such a setup. This also makes the assumption that the full framework dependency is not a critical part of every page render. Bad assumption.

.NET Core 2.0 isn't even in proper public preview yet, so complaining that it hasn't got support for LDAP or whatever seems premature. If RTM comes around in Q3 and there's still no way of interacting with AD or Kerberos or whatever then complain away (although also think about migrating to modern token-based authentication systems because it's not 2008 anymore).

We've been told they won't be there. Watch the stand up. Or look at GitHub where it's labelled "Future". We're complaining now because this bad decision will have shipped in Q3.

There is a smooth migration from ASP.NET MVC 4.5 to ASP.NET Core 2.0. It's called ASP.NET Core 1.0 (and I agree that there should be some promise of long-term support for 1.0 under the circumstances).

Long-term support doesn't mean it's not a dead end. We can still easily be stranded on 1.x when it goes end of life. In that case, we'd have had longer support on full framework.

Full .NET catches up and you can run ASP.NET Core 2.x on it

It's targeting netcoreapp, that won't happen.

...or Whatever third-party tech you depend on supports .NET Core (or can be replaced by equivalent tech that supports .NET Core).

Those libraries are often outside of people's control and time budgets. Even libraries from Microsoft aren't being upgraded. I'm fighting the SQL team right now to upgrade their packages to work on the new project system because install.ps1 works. If we can't even get those simple fixes in, we're screwed with netstandard ports.

Remember that—while your team might be hamstrung by external dependencies or internal company policies or politics or just plain inertia—there are hundreds of thousands, if not millions, of developers in the world who are looking to build applications, services and APIs using modern architectural patterns and new technology platforms (cloud/edge/IoT/etc), for whom ASP.NET Core 2.0 is a great fit. They want it to be fast, scalable and cross-platform; those things are important to a lot of people. Asking Microsoft to ignore that rapidly-expanding market, just because your 3rd-party control supplier or an open-source project haven't ported their code yet, is silly.

Calling it silly is belittling, rude, and uncalled for. This is our lives. These are our apps. These are the things we have spent years or decades creating and suddenly before release we find out that the outlook is time capped for us, hard. A lot of uncertainty is introduced to say the least. That's not really something you want in your career.

every point make sense, but remember that in this universe everything will go in the state that requires less energy, then make sure that that state is where you want to go, because we will go there in a way or another.
So if you want to achieve a certain state, make sure that it requires less energy than the one required to stay where we are now.

I've just read through this entire thread after someone mentioned this as an aside in IRC - I haven't seen any official announcement of this yet - and I'm thoroughly disappointed.

I've been watching .NET Core, getting involved and converting small projects over from .NET Framework to .NET Standard / .NET Core in order to get some experience with the new SDK and runtime, and to run these projects on macOS and Linux.

My big target is a large enterprise web service that uses a heap of components which are not available [yet] in .NET Core 1.0 or 1.1. This includes, just off the top of my head:

• Active Directory (System.DirectoryServices), used for authentication and user management
• Entity Framework 6 (EntityFramework), since EF Core doesn't support a lot of the functions yet that we use.
• OData (Microsoft.Data.Services/System.Data.Services) v1-3, the client Javascript library we use doesn't support v4 (yet) and WebAPI OData is a lot more complex to set up.
• IIS Management (System.Web.Management) and .NET Remoting (System.Runtime.Remoting) for the web service's ability to upgrade itself - though this could be extracted out to a standalone application.
• SignalR
• Custom IHttpHandlers and IHttpModules, which would have to be adapted to whatever ASP.NET Core's equivalent is, probably some kind of middleware
• A whole bunch of custom stuff using ASP.NET WebAPI's extensibility.
• I think we might even use Microsoft.TeamFoundationServer.ExtendedClient on the server, which only supports net46, has some native assemblies, and has about a 0% chance of working on .NET Core 2.0.
• etc.

Due to the size and complexity of this service, any migration to .NET Core would have to be gradual, and in all likelihood we might have to use some new-in-ASP.NET-Core-2.0 APIs, I don't know yet, we haven't gotten that far.

Removing the ability to run ASP.NET Core on the .NET Framework means that migrations must be done big-bang style if ASP.NET Core 1.x is not a viable stepping stone. We instantly lose the stage of "run new framework on old runtime" before "run new framework on new runtime". This is a horrific change-management strategy for any large system.

I wouldn't mind so much if .NET Framework support was dropped once .NET Core was at or near parity, but it's still quite far behind for any sufficiently advanced application, and I don't think 2.0 is the right place to make such a breaking change.

@davidfowl

I understand this one but I can't believe that you're going to convert all of stack overflow to razor pages only. If you're already using MVC today why not just port to regular views and when more dependencies come online, port to razor pages. The way razor pages is designed makes it trivial to go from a controller action to a razor page.

Many libraries, etc. shared across apps are in play here. Stack Overflow is many applications (the main website is almost entirely a single app, but as a company: we have many related, communicating things.

Just make sure to escalate that list of dependencies so we know what's important.

Yep, I'm doing that. But that won't be the last dependency, just the biggest blocker since we can't even login to some apps without it. It's a first-screen breaker. I'll try and do the full portability analyzer across our apps this week (after a launch this morning), but I fear it'll just be more depressing. It would help if the analyzer was even updated for current tooling before moves like this were even considered.

Data helps, I'll try and get your more data - unless there's zero chance of this decision changing. If that's the case, please tell us so I don't invest any more of my time in it.

Just for the record: OData is another library that doesn't support netcoreapp yet.

Actually it's even still based on System.Web (you have to use it via OWIN middleware in ASP.NET Core) and they promised support (see https://github.com/OData/WebApi/issues/939).

Still worth mentioning. Especially since it's from Microsoft.

EDIT: @yaakov-h was 2 min faster, so +1 for his mentioning of OData

I'm still here replying for a couple of reasons

• I care
• Sleep is for the weak 😆
• I need to call out the FUD because somebody on the internet is wrong

@NickCraver

Many libraries, etc. shared across apps are in play here. Stack Overflow is many applications (the main website is almost entirely a single app, but as a company: we have many related, communicating things.

It just means you can't use Razor pages tbh, ASP.NET Core 2.0 has lots of small things but there's not big features or fixes that aren't also being back ported to 1.x. The EOL thing is very real and I personally don't think ASP.NET Core 2.0 supporting .NET Framework for another year would help. We're really discussing a direction change here, either we support .NET Framework forever, or not, there's really no inbetween.

@dustinmoris is not just that. is also a expectations problem. Your use case may be not the same of everyone else.

I am developing aspnetcore 1.* apps and using the .NET desktop as runtime (LOB for enterprise).

And i understand what's the difference between .net core runtime, netstandard, etc (just to be sure this is not a comment about a misunderstanding about that)

My migration was to aspnet core first (targeting .net desktop) because the flow/vision/etc, consolidate it, and AFTER move it to .net core (if possibile), was the decisive scenario in the aspnetcore choice.

This issue is just a bit unexpected, because aspnetcore 1.* was always marketed as "run on both framework", with zero warnings afaik about a dropping it next (version or year).
I was expecting an obsolete -> deprecated cycle at least, or just unsupported features (that's ok).

The good part about .net (and aspnet as choice for web stack) is i can leverage existing codebase and libraries.
Some are internal, no real roi to migrate these, when the target (.net core/netstandard) is too fluid.
Some are external, and are difficult to change, if these doesnt work in the netcoreapp2 closure, i cannot use these.

Plus my idea was consolitate to netstandard2 not netcoreapp2.
How can i start to just evaluate the migration of libs to netstandard2, if is not there yet? Is difficult to evaluate migration based on preview bits and promises (and latest years lowered my trust on stability of promises)

I understand is a different scenario than fully greenfield, but also if greenfield i'd like to reuse some libs, because i need to interact with existing system (excel/pdf/etc), not rewrite everything from scracth.
Or add microservices as rpc just because is latest trend, because make things more complicated (that is a conciuous chooice i want to evaluate and do, not be forced to to wrap existing libs). I need to deliver value (aspnetcore dev flow is nice and productive), not just change architecture.

In my personal evaluation of ecosystem, for my use case, the avaiability of .net core and/or netstandard lib is atm too low (not everyone use just free nuget.org oss pkgs). So if i need to migrate hard to a new stack, i need to evaluate also others stacks (cost/benefit/future/trust/etc)

I am not only writing a TODO web app, i use .NET because i got man years of stuff ready, so i can change one thing (in this case aspnetcore, and leave the rest as is for this iteration).
Just change everything is a recipe for disaster in my scenario, and when i need to do that, i need to really start evaluate if make more sense to migrate to another stack (as java/node) where lib exists.

A smooth migration take time, i like the vision for future aspnet core. but if i dont have a clear path (or doubt about it), is difficult to sell internally.

That said, leave behind .net desktop, can be a good gamble of aspnet team to move faster and pick more new users (or dont lose currents to node/java).
But for sure, is going to make harder the life for dev on slower ring, and this is aspnet team call (their product).
My feedback is to not do that, and work hard to support for fw, because as a dev, i need trust and stability, and last years where a bit too fluid in .net ecosystem (not just netcore/project.json, but before also, and marketing/evangelist didnt help lowering the trust)

@yaakov-h

If you decide to port to ASP.NET Core (either 1.x or 2.x) you'll need another process. ASP.NET Core does not run on System.Web so you can't do a gradual port in the same project.

I wouldn't mind so much if .NET Framework support was dropped once .NET Core was at or near parity, but it's still quite far behind for any sufficiently advanced application, and I don't think 2.0 is the right place to make such a breaking change.

There is no right time to drop it. It was never meant to reach parity with .NET Framework and it's quite possible that there are dependencies you have that will never ported. Given that, my question would be, do you redesign the application or do you realistically need to stay on .NET Framework forever?

@davidfowl that depends entirely on our upstream dependencies. At this point in time, we would be staying on .NET Framework forever.

Interestingly enough most of the 3rd-party ones have netstandard releases available already. It's largely the Microsoft dependencies that are keeping us on .NET Framework, and some of those seem to be semi-abandoned (e.g. OData)

@NickCraver I don't mean to be belittling or insulting. I appreciate that this is a late-in-the-day change, and that's frustrating for whatever section of the community are affected by it, and if I were affected by it, I would probably be kicking up a fuss too. I'm not (where I work we're still on ASP.NET WebAPI 5.2.3), so my take on the situation is less emotional.

Look at it this way: if you were to start from scratch building the next Stack Exchange (whatever that might be) today, wouldn't the stuff that's in netcoreapp20 that the ASP.NET Core team want to use (like UTF8Strings and Pipelines and low-allocation, asynchronous, _fast_ primitives (I'm guessing a bit there)) make it more attractive to you than full .NET? Wouldn't .NET Core 2.0 generally make more sense than full .NET 4.7.1? If you were picking between web stacks that can evolve and adapt to change quickly, vs web stacks that are irrevocably tied to a slow-moving underlying technology with nearly two decades of legacy code to worry about supporting, which would you choose?

@ZigMeowNyan

I'm more concerned about this move signalling the possible sidelining of .NET Standard than I am about the rest of it. .NET Standard initially seemed like something that would bring the different implementations closer and closer to feature parity while allowing consumers to migrate to the evolving, growing platform. Now it's sounding like nothing more than a milestone of .NET Core features. You won't be able to (or want to) target executables towards .NET Standard - only libraries. And it sounds like there will be significantly less planning involved in .NET Standard, and instead it'll just get rubber-stamped with whatever got used in ASP.NET because it's already too late to change. It'll already be in production, after all.

Those are actually really good points and something worth considering. You have to understand that it has nothing to do with .NET Standard being sidelined, it's just physics. If each .NET platform moves at it's own pace then using the latest .NET Standard means the slower moving frameworks get things less often. That's something that should be internalized by everyone. That doesn't make it less useful, it's just the nature of the beast. The only way to remove this burden is to have a single implementation and a single ship schedule which greatly narrows the places .NET would be able to run.

Other developers have to sprinkle the code with compiler directives, split code into platform-specific libraries and compile with multiple targets. The rude part of me wants the ASP.NET Core team to dogfood that so you'll be interested in better runtime and tooling support for multi-targeting and multi-platform scenarios. And if your team wants it, then we might get it. The practical part of me says that at a minimum, you should have periodic releases of ASP.NET Core that target the .NET Standard. You need to make actual stable releases anyway. No one's just going to compile the master branch from git and deploy to production. Why not do smaller iterations of the .NET Standard and match them with a tagged ASP.NET release?

We do the same thing, remember, we still target netstandard for a bunch of our libraries and those do contain ifdefs. Others however, target netstandard in order to set us up for taking advantage of new APIs in the 2.x timeframe.

In short, I support what you're doing and the goals behind it. And I know it's hard when we get on here and complain about decisions that you've made for a very good reason. But a lot of people aren't going to jump on the pioneer train because they can't, and others won't because they don't know where it's going.

Honest question (this is me asking not Microsoft), do you favor compatibility over new features? If yes, why choose ASP.NET Core?

Just another quick thought: for every thread like this one, there exists an equivalent-but-opposite thread where a different—but just as big—group of people got just as upset because a concession to supporting "old" .NET was made.

Interestingly enough most of the 3rd-party ones have netstandard releases available already. It's largely the Microsoft dependencies that are keeping us on .NET Framework, and some of those seem to be semi-abandoned (e.g. OData)

😞

@markrendle

• Many of the complaints I see in this thread are some variation of "I can't do X in .NET Core 2.0" when what the writer actually means is "I have to change the way I do X in .NET Core 2.0". Yes, you have to change. No, that's not a bad thing. If you have a small piece of discrete functionality in your ASP.NET MVC application that does something with PDFs or DOCX files, and you really can't find a better way to do whatever that is (have you tried?), then break that functionality out into a microservice running on full .NET on Windows Server and call it as an HTTP API from your .NET Core application. Decomposing applications and moving specific functionality into small, self-contained services isn't even a workaround, it's a general-purpose best practice.
NB As far as I can tell, the OpenXML packages are now supporting .NET Standard, so working with Word/Excel/whatever shouldn't be impossible.<<

As others have already stated, changing the architecture of our nice design is not good plan. In our case we share code between our WPF test of application and the server. The more differences we create between those more complicated it is to maintain.

I can assure you I have spent a lot of time investigating the best tools for us to use for PDF, DocX generation and it's nowhere near as simple as doing with open XML. We use a third-party library because there are tens of thousands of lines of code that they have developed and we don't have to develop/maintain/test. That's the whole point.

.net versioning has become very complicated. I'm not clear if at any point in the future ASP.net will be able to be used on the full .net framework? Because I need to share code between the server and my desktop applications does that mean I can never have the latest version of ASP.Net? This is not an issue in the short term but in the longer term with security improvements et cetera I don't want to be too far away from the latest version. I'm sure there are many others in my boat where you need some form of compatibility with the full framework.

To clarify what I do is that I have three of my own libraries that are shared between various WPF apps and my server. I would have absolutely no idea at this point which Apis I'm using may or may not be available in.net core. And then in those libraries I use full desktop versions of both Telerik and SyncFusion's WPF tools for generating docx and pdf. Some or all of the functionality that those tools use may or may not be available in .net core. Trying to develop applications based on may or may not is extremely difficult. Microsoft has a brilliant base framework in .net, and whilst I understand the reasoning behind .net core. Microsoft seems to have forgotten the importance of backward compatibility.

Stefan

@markrendle

Oh, sorry, I didn't realise your sample size was so big. 257 comments with a strong bias towards people who don't like the decision? Hard to argue with that. DISCLAIMER: I am not an expert on Big Data.

No idea what I did to you, but there's no need for snark or lowlevel whining like this. You know full well this thread is just an example.

@stefanolson

.net versioning has become very complicated

I think this is one of the few things we can all agree on.

We are looking to port to .Net Core x.
Our biggest issues are around:
NewRelic (no .Net Core plan, so we need to find an alt)
NH (where EF Core doesn't have the features).
ServiceBase (sounds like it's coming to .Net Core 2 in summer)

It certainly sounds like we'd have to target Core 1.0 in the interim and wait for NH, EF upgrades or get creative.

It just means you can't use Razor pages tbh, ASP.NET Core 2.0 has lots of small things but there's not big features or fixes that aren't also being back ported to 1.x. The EOL thing is very real and I personally don't think ASP.NET Core 2.0 supporting .NET Framework for another year would help. We're really discussing a direction change here, either we support .NET Framework forever, or not, there's really no inbetween.

It's a little bigger than Razor pages, it means there's no reason to move. There just exists no (current) scenario in which both of these exist:

1. We'll be supported the whole time
2. There's an actual upgrade on the other side

The fact is that ASP.NET Core isn't really all that useful without the ecosystem. Having a controller that renders text back is great, but not useful for that many scenarios. We need the APIs. We need the libraries. We need the ecosystem, that's why we chose .NET in the first place.

This change comes goes from a framework that fully supports our use cases today to one that's clearly not ready. It's not even close to ready. And a preview to test if it is ready isn't even generally available. A migration to figure out the promises of what will be ready is not available. We're banking on a whole bunch of promises and many will be burned. That's the worst possible way to market these things: over-promising and over-delivering (the overall experience).

I think ASP.NET Core is great. You guys are doing awesome stuff. I was lucky enough to help with some of it. But this switch at this point in time is bad. If all of the things we think will be ported are actually ported in the 2.x time frame, then great. Make the change in 3.x then. Porting before an alternative is ready and setting a deadline for when to kill the EOL life line is bad. Telling people to port to a maintenance -> EOL version is bad.

Please, don't make this change now. .NET is better than this. Show you care about your users as much as everyone here cares about you. We wouldn't be here if we didn't want to help.

@FransBouma You (should) know full well that Microsoft have vast databases of telemetry, feedback and other data on what people are doing with their tech that give a much clearer picture than any number of GitHub Issues threads, and I don't think my pointing that out was any snarkier than

Oh I don't know, by reading the posts in this thread?

.net versioning has become very complicated. I'm not clear if at any point in the future ASP.net will be able to be used on the full .net framework? Because I need to share code between the server and my desktop applications does that mean I can never have the latest version of ASP.Net? This is not an issue in the short term but in the longer term with security improvements et cetera I don't want to be too far away from the latest version. I'm sure there are many others in my boat where you need some form of compatibility with the full framework.

The code sharing story across different .NET runtimes is .NET Standard. Your libraries should try to target that to code shared across .NET Core and .NET Framework.

Microsoft seems to have forgotten the importance of backward compatibility.

The problem is, ASP.NET Core was never meant to be backwards compatible... That why there was such a big paradigm shift from ASP.NET 4.x. Seems like if backwards compatibility is the high order bit for you'd be better of using ASP.NET 4.x on .NET Framework. That is supported for the forseeable future and will be security patched for as long as Windows is alive.

Even if it wasn't meant to be, though, 1.0 was very backwards compatible! It supported the whole vast legacy of the ecosystem, and we appreciated it. It seemed at the time like nobody had to give away their cake or refrain from eating it.

@NickCraver

It's a little bigger than Razor pages, it means there's no reason to move. There just exists no (current) scenario in which both of these exist:

Can you elaborate?

The fact is that ASP.NET Core isn't really all that useful without the ecosystem. Having a controller that renders text back is great, but not useful for that many scenarios.

It can do it really fast too 😉

I think ASP.NET Core is great. You guys are doing awesome stuff. I was lucky enough to help with some of it. But this switch at this point in time is bad. If all of the things we think will be ported are actually ported in the 2.x time frame, then great. Make the change in 3.x then. Porting before an alternative is ready and setting a deadline for when to kill the EOL life line is bad. Telling people to port to a maintenance -> EOL version is bad.

I don't understand why 2.x (support) and 3.x (drop) is better than 1.x (support) and 2.x (drop). Can you please explain that to me? How does that make any difference?

A couple of //BUILD 2017 session recommendations for those concerned about long-term support of ASP.NET variations:

• T6009 ASP.NET Web Forms updates
  
  
  
  • i.e. they're still developing full .NET web platforms
  
  
• T6072 Support for ASP.NET Core: What is an LTS?
  
  
  
  • Which I'd guess is being frantically updated right now :grimacing:
  
  

@davidfowl:

How does that make any difference?

Because you've promised some of the most significant missing APIs to ship after 2.0 does?

@yaakov-h

Because you've promised some of the most significant missing APIs to ship after 2.0 does?

Tell me which ones in ASP.NET Core?

@davidfowl System.DirectoryServices, System.Drawing were mentioned above.

Honest question (this is me asking not Microsoft), do you favor stability and compatibility over new features? If yes, why choose ASP.NET Core?

I think this is a very good question. If the full .NET framework gives one everything they need today, why so keen on migrating to a complete different stack? If .NET Core and ASP.NET Core would have been named differently, without .NET int the name, then I think much less people would argue about migration issues. Nobody complains that they can't migrate to a faster moving Go or Node.js web stack.

@davidfowl being backward compatible to ASP.NET MVC 5.x is one thing, being backward compatible to .net framework is another thing. Dropping .net framework is a big thing...

I don't understand why 2.x (support) and 3.x (drop) is better than 1.x (support) and 2.x (drop).

Because 2.x is coming very soon as we understand.

@davidfowl System.DirectoryServices, System.Drawing were mentioned above.

Those have nothing to do with ASP.NET Core 1.x or 2.x and will run on both when they come online.

Like I said, I'm just here to call out the FUD and thats part of it. This thread has gotten so big that nobody can see the facts in some of the replies.

@FransBouma You (should) know full well that Microsoft have vast databases of telemetry, feedback and other data on what people are doing with their tech that give a much clearer picture than any number of GitHub Issues threads, and I don't think my pointing that out was any snarkier than

@markrendle telemetry is not magic. You cannot measure why ppl/dev are not switching, or why they switched over other stack, or the importance of their project and how much they like the stack (and help others, with consulting or oss), or what they are doing.

This thread is exactly that, a feedback.

I don't understand why 2.x (support) and 3.x (drop) is better than 1.x (support) and 2.x (drop). Can you please explain that to me? How does that make any difference?

@davidfowl time.
time to settle a bit. time to evaluate things. time to change one thing a time. time to use netstandard2 packages with an rtm thing. time to move our libs to netstandard2 (easier) instead of netstandard1 (harder). Time to change one stuff a time, for me, mostly.
You do aspnet, but my product is not only aspnet, is a combination of lots of libs and tradeoffs and the ecosystem.

Because 2.x is coming very soon as we understand.

What does that have to do with it? What if 2.0 was coming at the end of year or in January? Would it make a difference? What is it in 2.0 that makes 1.x not worthy?

@yaakov-h They were mentioned here where @shanselman said (emphasis mine)

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

@davidfowl it's not about version, it's about date and maturity of .net core and it's ecosystem.

@hikalkan

I'm sorry, I understand that from a very high level POV but not from a technical one. Maybe this isn't a technical discussion?

@enricosada

time to settle a bit. time to evaluate things. time to change one thing a time. time to use netstandard2 packages with an rtm thing. time to move our libs to netstandard2 (easier) instead of netstandard1 (harder). Time to change one stuff a time, for me, mostly.
You do aspnet, but my product is not only aspnet, is a combination of lots of libs and tradeoffs and the ecosystem.

Why difference does that make to ASP.NET Core 2.0 specifically? You'll get that benefit from the platform regardless of what ASP.NET Core chooses to do.

@markrendle someone get me a calendar, because seasons span an entire quarter (could be 3 months out from something else in the same quarter) and are especially confusing to us southern-hemisphere people.

@enricosada You can get an awful lot of useful information from telemetry and other data sources (web analytics, search data, direct customer feedback). Far more than you can get from angry mobs on GitHub (however justified each individual's anger might be).

@yaakov-h Well, the current projected RTM for .NET Core 2.0 (and so ASP.NET Core 2.0) is calendar Q3, which is July/August/September), and Summer in the northern hemisphere is mostly July/August/September, so it's basically the same thing.

You can get an awful lot of useful information from telemetry and other data sources (web analytics, search data, direct customer feedback).

I wonder how reliable this telemetry - at least the automated part - is for enterprise deployments, though. (Since that's where the majority of the backlash seems to be coming from.)

I don't understand why 2.x (support) and 3.x (drop) is better than 1.x (support) and 2.x (drop). Can you please explain that to me? How does that make any difference?

@davidfowl Time. And a proper announcement. If the messaging was clearer, people would't be as surprised.

@davidfowl Time. And a proper announcement. If the messaging was clearer, people would't be as surprised.

I understand but I don't think it would make a difference in your ability to port anything really. The same EOL policy still exists.

Ok, after having a hard time to understand this issue, i wanted to bring some insights for those that struggles like me and also have some questions.

so if understand correctly, we will eventually have netstandard replacing net framework.

So lets asume netcore doesn't exist and aspnet core is based on netstandard. that means that features will come slower.

Example:
2017 asp.net wants Feature A.
2018 netstandard implement Feature A. we get Feature A on ns.

What the team is saying is to have netcore not based on netstandard so:
2017 asp.net wants Feature A
2017 aspnet team implements Feature A. Asp.Net Core get Feature A on netcore.
2018 netstandard implements Feature A. we get Feature A on ns.

So, this decision actually brings more "flexibility and speed" to the equation. Faster release for who can use them, feedback, etc. I think it's a great addition to the slow peace of net framework. Feature will be really mature when it reachs NS.

If having netcore based on netstandard 2 means that features are released 1 year (or any time-frame) later, people will still argue that they want this? This is the scenario we are used to with NET Framework.

This is a heaven for aspnet team, be able to ship stuff without being dependent on someone else, and it's also great news for customers who can get those fast stuff. If you can't go with the fast stuff, sticking to the previous version is a reasonable trade-off (and motivation for you/dependencies to upgrade.)

Library authors should still AIM to target netstandard, and if you can then no worries at all.
If you need something not on netstandard (maybe razor pages(?)) then you must target netcore, on scenario 1, razor pages may well not even exist. I don't see how this can be bad, i would say it's fair.

So the question is, which dependency you have right now that limit yourself from going NET Framework to Net Core ?
I may be the only one here but I never expected aspnet core to work on NET Framework forever, it was obvious to me that this was a "transition" step. All my development that currently need NET Framework is splited. (and no, this isn't microservices, it's much simpler than that).

the 2.x support and 3.x drop is not different than 1.x support and 2.x drop. I'll take a guess here and say that people is not understanding the scenario clearly, so I hope this clarify at least some.

@NickCraver you said you want microsoft to revert this decision. What would be your suggestion, to do not have an isolated netcore and have slower feature releases? (honest question)

@davidfowl I think there may be a subtle hidden issue with the current proposal that worries developers.
If you have feature A for asp.net (with netcore) then you can market and ship (and tick a management/pm checkbox) and be "lazy" to implement on netstandard, if I'm not mistaken this is what "betting" on uncertain is refereed here.
So in my previous example, netstandard implements Feature A may be in 2019, or 2020, or never instead of 2018. <-- this looks like a possible problem (?) am I right ? Can Microsoft commit to something here?

Whilst we can all differ on whether we like the announcement thanks indeed to @davidfowl @DamianEdwards and @shanselman for spending the time to discuss. It's further proof of increased engagement and openness.

I'm sure some will argue on timing etc, but it's progress.

Example:
2017 asp.net wants Feature A.
2018 netstandard implement Feature A. we get Feature A on ns.

What the team is saying is to have netcore not based on netstandard so:
2017 asp.net wants Feature A
2017 aspnet team implements Feature A. Asp.Net Core get Feature A on netcore.
2018 netstandard implements Feature A. we get Feature A on ns.

what they should have done is:
2017 aspnet team builds feature needed in lib X, which supports netstandard2.0. This way aspnet works on everything .netstandard runs on, and users can then run it on .net full as lib X is usable on .NET full too (it's just a nuget install away).

Instead, they don't do this, they force lib X to be .NET core only (otherwise, why this thread/decision in the first place). If lib X is so superadvanced that it needs CoreCLR features, Microsoft has to ask themselves why these advanced features aren't ported to the .NET full CLR.

All in all it feels like politics where MS needs a fast moving .NET core/aspnet core to provide Azure customers a stack which can be used in containers on azure so it competes with JVM/NodeJS based containers on AWS or Google cloud. From their business perspective I can even understand that. But what it shows is that MS has no priority concerning .NET full to move forward faster, as it doesn't put enough resources on .NET full to keep up with .NET core. Look at the amount of APIs added to .NET full in the past 2 years. Does that tell you a large team is working on that?

No.

Microsoft sells a large database system, SQL Server Enterprise. It comes with fancy encryption features. Not supported on .NET core. Have fun selling .NET core 2.0 to the enterprises who are the potential customers of that expensive database system.

You may want to move 'fast', but unless you fully understand the destination you're moving towards, it helps taking a minute or two to decide that first.

The more I think about it the more I think the issue most people have is that they feel we are cutting the cord between .net and asp.net.
Currently we have asp.net, asp.net core (.net), and asp.net core (core). So you could choose if you wanted to go no, little or full core.

Since the versioning is poorly communicated people feel that it's only the last part that is innovating and moving on, while asp.net and asp.net core (.net) is stuck.
Since we have no way to validate if a lib will work in netstandard2.0 without trying, it gets very risky to go with full core on a new project. So they end up with either asp.net (old) or asp.net core (also old).
And since both are old, it makes sense to just go with system.web and old asp.net. Since they know that and since asp.net core is EOL anyway, why bother.

So we end up with only the brave choosing core, and the rest go with old but stable system.web. And we will forever be stuck with a even more fractured ecosystem.

PS: I'm wording this as with the current feeling. That asp.net core 1.x is "old and outdated" vs 2.x. Not that it's a fact, but that's what people are thinking.

@davidfowl

If each .NET platform moves at it's own pace then using the latest .NET Standard means the slower moving frameworks get things less often.

This already happens, and we're okay with it. The Versions document is commonly filled with _vNext_. And that's fine. Rather than waiting until all platforms are at parity before incrementing the standard, I'd rather see the standard defined a few versions ahead and watch the platforms catch up. People can even pitch in for the definition and implementation. And if ASP.NET Core targeted the standard for its releases, the moment a platform and architecture implemented that new standard, the package would be available. New Standard versions could come in through VS updates or packages.

The way it's being presented, though .NET Standard doesn't sound like it's a community planned effort. It's more like a snapshot of the implemented contracts that passed review. And if major projects aren't targeting it, there won't be nearly as much planning towards its releases.

We do the same thing

Oh good. Shared misery is best misery. Csproj and sln files with the platform/config stuff are really annoying, btw, because the build combinations aren't always declared - they're inferred. So VS might think I have more build combinations than actually exist because it assumes that every possible combination is important. And I have to have extra sections in the file that wouldn't be needed if i could just declare the platform/config combinations. Like how you can use functions like Substring in the csproj PropertyGroup elements to simplify custom properties, but those conditions are used in determine build configurations, so you have to have the full string values in there. This kind of stuff shouldn't be as much of a hassle as it is.

Honest question (this is me asking not Microsoft), do you favor compatibility over new features? If yes, why choose ASP.NET Core?

Personally, no. As long as there's a way to do what I need to do, I don't mind rewriting the code as long as it's not a huge endeavor with little benefit or a PITA to test. So I'd pick whatever's got the most momentum and potential. But I have to work with projects across multiple technologies - Win32, COM, CORBA, ADO.NET, several reporting engines, various web APIs, embedded browsers like CEF/Firefox/IE (no edge, of course, since it's not supported) and multiple vendor-specific things I'll avoid shaming. I implement what I can as a plugin, but I'm married to the least common denominator on the host executable, for the most part. Dealing with that many technologies is annoying, but they're static. That's how a lot of desktop/server stuff is. As long as I'm given the tools to interop, I can make do. But the less deprecated frameworks I remember, the better.

ASP.NET, though, is part of the web stack, and the web stack is something that I feel needs to stay up to date. It has a different use case, and there's an unfortunate expectation to use the newer platform for web work unless there's a good reason not to, or a significant incompatible code base. I try to keep that updated because web standards change quickly and significantly. Most of the people keeping pace with the web are sticking with newer technology, and implementing the new stuff on older stacks can be rather painful. Especially in the situation where ASP.NET competes with PHP and Node, I've got to keep a more modern stack to draw talent and interest. I'd love to do less web work, but unfortunately it's the new UI expectation. I was hoping that sticking to the standard would let me have the best of both worlds, but that seems like a limited time offer.

so if understand correctly, we will eventually have netstandard replacing net framework.

Not thats not correct. I'm not sure how you drew that conclusion. .NET Standard will always be a subset of each of the runtimes that support it.

I want to throw some crazy stuff out here because it's been mentioned a few times. What I'm about to say has no bearing on what will happen, it's all speculation at this point. Several people asked why we want to target .NET Core instead of .NET Standard.

• We've identified strings as one of the major things we'd like to try tackling in .NET Core, there's tons of ideas but one of them is to have string be utf8 by default (tons of compat problems but follow me here).
• Another thing we'd like to fix is the ability to take cheap slices of arrays/strings, any piece of contiguous memory. We've added Span<T> and are looking at Buffer<T> to represent this. It might mean that String and Array implement new interfaces that make it possible to take a slice that requires 0 allocation.
• This leads to new methods on String that allow splitting that doesn't allocate an array every time.
• This leads to overloads to Int, UInt etc (TryParse) that take Span<char> and Span<byte>.
• This leads to new encoding routines that take Span<byte>.
• Buffer<T> and Span<T> let you represent memory in a uniform way and we want to upgrade the networking stack to allow passing pre-pinned buffers that take Span<T> or Buffer<T>.
• Kestrel will implement HTTP2 in the 2.x timeframe (currently aiming at 2.1) and that requires new APIs on SSL stream to do ALPN (https://en.wikipedia.org/wiki/Application-Layer_Protocol_Negotiation).
• Http Client on .NET Core supports duplex streaming, it'll make it possible to implement streaming end points over http in signalr over a single, non websocket http request.
• We forked the header parser implementations from HttpClient and System.Net.Http and renamed them (https://github.com/aspnet/HttpAbstractions/tree/d1d9bceff56cb44a194ae36923ce687e5e353006/src/Microsoft.Net.Http.Headers) so that we could improve them and have them support both .NET Framework and .NET Core. .NET Core has a copy of these improvements haven't made it back because there no need to improve them (we couldn't consume them).
• There are a bunch new threading primitives that require new API that will light up new scenarios if we're able to consume them (https://github.com/dotnet/corefx/issues?q=is%3Aopen+is%3Aissue+author%3Adavidfowl+label%3Aarea-System.Threading), those are just some of the things I've personally filed.

Without the ability to rev the core primitives, we're encouraged to fork them and make things that look like them but aren't them. It's the reason we have our own little BCL within ASP.NET Core https://github.com/aspnet/Common/tree/dev/src/Microsoft.Extensions.Primitives.

That was just a random dump of things I can see us doing in the near term that affects very fundamental pieces of .NET.

@FransBouma

NET full to move forward faster, as it doesn't put enough resources on .NET full to keep up with .NET core. Look at the amount of APIs added to .NET full in the past 2 years. Does that tell you a large team is working on that?

That's just not true. Things are continually ported to .NET Framework but as we all know the risk is considerably higher than making those same changes in .NET Core. Don't you all hate it when an update to .NET Framework breaks your application? We do too so we invent all kinds of processes to mitigate it, you wouldn't believe the strangle hold it puts on engineering to maintain it. We still manage to do features in-spite of all of it. That said, it will just never move as fast as .NET Core, it's a windows component that ships on the windows schedule.

I understand but I don't think it would make a difference in your ability to port anything really. The same EOL policy still exists.

@davidfowl Correct. But how you frame it means something. Not to mention when it's communicated, if ever. It won't necessarily give people more time to do the actual work, but it would give them more time to think and make the correct decision (for them).

Currently, if you've started porting to/using ASP.NET Core on .NET Framework, it seems you have three choices:

1. Port all your code and dependencies to .NET Core and move to ASP.NET Core 2.x.
   
   
   
   • This would be the optimal solution, but it could require tons of work, and for some, it might even be out of their control because of 3rd party libs.
   
   
2. Stay on ASP.NET Core 1.x and .NET Framework and hope you'll be able to do 1. before it's unsupported.
   
   
   
   • This is pretty risky. Within a year (or two, or three? who knows?), you could risk running on an unsupported platform.
   
   
3. Move back to ASP.NET 4.x
   
   
   
   • While this alternative leaves you supported, you'll be "going back" and undoing work you've already started. And also, let's face it; this platform won't be getting much love going forward.
   
   

If you'd known in advance and could plan for it, I think both 1. and 2. are decent alternatives. The issue is that both alternatives have quite a few unknowns. What about library A? What about library B? Will library A ever be ported?

Right now, I think a lot of people feel they're being forced into making a choice, without a clear picture of what the choices actually entail.

@khellang (in your hypotheical solution)

1. Move to ASP.NET Core 2.0 on .NET Framework
   
   
   
   • This is pretty risky. Within a year, you could risk running on an unsupported platform.
   
   

@davidfowl

Honest question (this is me asking not Microsoft), do you favor stability and compatibility over new features? If yes, why choose ASP.NET Core?

Honest answer:
Favor: Stability and compatibility is paramount. New features are nice, but when they land, they simply must not break the existing ecosystem.
Why ASP.NET Core: Simply because it runs on OS X and Linux.

An ecosystem like .NET (old and/or core) or also Java is chosen by businesses. And when they make their decision, they put a lot of effort in developing code for that platform / ecosystem.

Now, one of our customers, for example, already invested a lot in ASP.NET Core. Based on the previous announcements and sold ideas of .NET Core, code was written. This new (ASP.)NET Core code we (painfully) wrote with a team over the course of the initial development of (ASP).NET Core, starting with its inception, is a set of servers and client libraries, with quite a bunch of business logic.
And this code, besides running on Linux server, providing services, is currently also being used in a set of very old applications that talk to these services, and these are a hell of a mix of WPF / Windows Forms / C++/CLI and normal C++ (including DirectX stuff).

And now you're just simply cutting off our clients investment in quite a few man-years of effort into .NET Core code for the existing applications, as it will be impossible to re-use the new .NET Core code in the actual applications (the new servers and business logic libraries were build for).

To get back to the question: A business would chose .NET Core as ".NET, now also for XPlat", while expecting the very same compatibility and stability as .NET gave us in the last 17 years. And, to be frank, this is the single reason for .NET Core. If you wouldn't wanted that, you would use Node.js or even Java. Both are much more mature and XPlat than .NET Core now.

And, just to elaborate a litte bit more: .NET Core was cool and fast-paced at the early stages with project.json and all. And then, out of reasons of "compatibilty with .NET" project.json was taken from us in favour of Msbuild and .csproj again. And now the benefits of exactly this "compatibility with .NET" is also taken away, in favour of.. what exactly?

@gingters

First of all, great reply!

Why ASP.NET Core: Simply because it runs on OS X and Linux.

Based on that, it seems like MVC 5 on mono is what you really wanted right?

To get back to the question: A business would chose .NET Core as ".NET, now also for XPlat", while expecting the very same compatibility and stability as .NET gave us in the last 17 years. And, to be frank, this is the single reason for .NET Core. If you wouldn't wanted that, you would use Node.js or even Java. Both are much more mature and XPlat than .NET Core now.

And, just to elaborate a litte bit more: .NET Core was cool and fast-paced at the early stages with project.json and all. And then, out of reasons of "compatibilty with .NET" project.json was taken from us in favour of Msbuild and .csproj again. And now the benefits of exactly this "compatibility with .NET" is also taken away, in favour of.. what exactly?

This is the basically the crux of the issue. Based on your assessment:

This new (ASP.)NET Core code we (painfully) wrote with a team over the course of the initial development of (ASP).NET Core.

You really just wanted the existing .NET Framework on linux with good old ASP.NET 4.x compatibility. Is that a fair summary?

Favor: Stability and compatibility is paramount. New features are nice, but when they land, they simply must not break the existing ecosystem.

.NET Core is actually a more stable platform than Desktop as it allows side-by-side execution where Desktop does not.

If you want to use newer features in the next version of Desktop you need to upgrade the entire machine to that new version and that effects everything on that machine, not just the app that wants to use the newer features. Which is fine if you have a dedicated server for a single purpose; but not if you have many apps running on the same server which upgrade at different rates (or never upgrade at all!)

@davidfowl wrote:

It's up to frameworks to decide if they want to run on .NET Framework, UWP, .NET Core, mono etc. It's a choice. Orleans doesn't ship with .NET Core. ASP.NET Core does. Those products are one and the same.

In Orleans' case, we support .NET Standard 1.5 in our "2.0 Technical Preview" builds, but have been waiting for .NET Standard 2.0 so that we can make a stable release. At present I don't see any blockers for us - my concern is only about future divergence. That divergence has to happen at some point, though.

👍 Huge thank you for sticking around to answer everyone's questions, @davidfowl & co! It must be seriously stressful.

NET full to move forward faster, as it doesn't put enough resources on .NET full to keep up with .NET core. Look at the amount of APIs added to .NET full in the past 2 years. Does that tell you a large team is working on that?

That's just not true. Things are continually ported to .NET Framework but as we all know the risk is considerably higher than making those same changes in .NET Core. Don't you all hate it when an update to .NET Framework breaks your application? We do too so we invent all kinds of processes to mitigate it, you wouldn't believe the strangle hold it puts on engineering to maintain it. We still manage to do features in-spite of all of it. That said, it will just never move as fast as .NET Core, it's a windows component that ships on the windows schedule.

that ignores the fact you can release the libraries _you_ depend on as netstandard2.0 packages so aspnet can run on .net full too. Additionally, making changes to .NET full isn't without risk, but please don't make it sound like it's a terribly organized pile of code where one change can make everything crumble.

We still manage to do features in-spite of all of it.

Yeah so does every other .NET developer ;) Once you release something, you're stuck with that API, we all have this. You however want to take a shortcut (like the ASPNET team has done many times before!) and move without that burden. But that's not going to fly in the end.

That said, it will just never move as fast as .NET Core, it's a windows component that ships on the windows schedule.

I think here we have the crux of the matter, right? The .NET core team can do what they want without communicating with the behemoth 'WinDiv'. Why doesn't Microsoft solve this internal politics crap in-house and make sure .NET full + .NET core are versioned / moving properly without the windows politics?

Btw, still interested in how you would sell SQL Server Enterprise's encryption API to .NET core 2.0 users.

Also, I must add; I'm pretty impressed how long this thread has been going, with so many people involved, while still remaining civil ❤️ That's not something you see every day on the internetz 👏 Maybe the .NET OSS ecosystem is growing up after all? 😉

that ignores the fact you can release the libraries you depend on as netstandard2.0 packages so aspnet can run on .net full too.

Additionally, making changes to .NET full isn't without risk, but please don't make it sound like it's a terribly organized pile of code where one change can make everything crumble.

It's big and has existed for a long time. Like any legacy system some parts are better than others. It doesn't make the code less reliable but it does make some parts practically impossible to change. There are so many fun stories veterans can tell you about how bug fixes in one areas broke obscure scenarios in applications in other parts. It's tangled, that's what happens when the dependency boundaries aren't well defined. You don't even have to believe me just go and browse referencesource.microsoft.com. In place updates are the reason we need to add a config switch for ever single potentially breaking change to .NET Framework. It's physics, it just can't move as fast.

Yeah so does every other .NET developer ;) Once you release something, you're stuck with that API, we all have this. You however want to take a shortcut (like the ASPNET team has done many times before!) and move without that burden. But that's not going to fly in the end.

We love shortcuts! Developers are lazy 😄 . We also want to genuinely improve our .NET Core without disrupting what .NET Framework represents. Maybe we should have renamed it to something else, like Sparkle 😄 .

I think here we have the crux of the matter, right? The .NET core team can do what they want without communicating with the behemoth 'WinDiv'. Why doesn't Microsoft solve this internal politics crap in-house and make sure .NET full + .NET core are versioned / moving properly without the windows politics?

Read my other answer about physics.

Btw, still interested in how you would sell SQL Server Enterprise's encryption API to .NET core 2.0 users.

That's not my area of expertise, I'll let somebody else answer that.

@khellang lol that is because GitHub issues haven't attracted MS hating trolls yet. Currently Twitter is their medium for that where there's no downvote yet :)

@davidfowl

You really just wanted the existing .NET Framework on linux with good old ASP.NET 4.x compatibility. Is that a fair summary?

No, not really. Our client required complete new / shiny (micro) services, to supplement their existing .NET 4.x (they were 3.5 when we started) Windows desktop applications.

We when you went beta with all the shiny Core stuff, we started to write the new server-code for the all-new MVC on top of ASP.NET Core together with accompanying DTO, business logic and client-libraries, which are also being used in parallel in the existing 4.6 desktop applications to talk to the all-new-servers.

Also, some of the all-new ASP.NET Core servers don't run on Linux only, but also as windows services with Topshelf (on top of full 4.6 framework).

So the thing is, a lot of investment was done, and now we're seem to be stuck with .NET Core 1, as moving on to 2 (and losing netstandard) would also mean, we can't reuse the assemblies in the existing Desktop application (the services and accompanying libs were created for) anymore.

So the most important thing for us would be to still be able to use the new (ASP).NET Core libraries we write in .NET 4.6 desktop applications (because thats what they were build for), while being able to stay on a supported .NET Core version as long as the desktop .NET Version is supported, where the code can run on.

So, as long as .NET Core 1. is supported as .NET 4.6 is, and there is a linear upgrade path to a .NET Core x when .NET 5 comes out, and .NET Core x code is capable of running on .NET 5, then we're fine.

@gingters Are you using .net features not in netstandard2.0 on the asp.net services?

If not then the libs should just work. But I'm guessing you're talking about stuff not in netstandard2.0.

@davidfowl Will c++/cli dlls work on netcoreapp 2.0? We have old 3rd party C++/CLI assemblies which will not be replaced any time sooner.

@davidfowl wrote:

ASP.NET Core 2.0 honestly doesn't have that many new features

In which case, why this highly disruptive change now?

@qrli C++/CLI does not work on CoreCLR. Here's some background on why it won't be supported: https://github.com/dotnet/coreclr/issues/659#issuecomment-91341753

Give 4 years support to 1x (porting as much possible from 2x) and go ahead and fast with 2x. A city car for slow city traffic and a Ferrari for the highways. We have a lot of competition outside of .net world.
If ASP.Net Core succeed, I am sure MS will give the resources to support the 1x for 4 years. Mostly the culture will change.

@idg10 It's really not. 2.x is pretty much 1.x with performance stuff that are only available in core. I think only major feature is Razor Pages.

So being on version 1.x doesn't mean you are on an outdated version. But this hasn't been communicated very well.

In which case, why this highly disruptive change now?

guess this pretty much summarizes it https://github.com/aspnet/Home/issues/2022#issuecomment-300141134

@hallatore
I know it works, as it does _now_. We can stay on 1 for now. The problem is going forward. When we want (or worse: need) to upgrade to (ASP).NET Core 2 libraries (i.e. when 1 goes out of service, and there's a critical security hole fixed) we face the problem that we can't upgrade, as this would make it impossible to use our libs that need the upgraded packages in the .NET desktop apps.

Edit / add: Unless there will be a new full .NET framework that is capable of running the new, fixed .NET Core libs that is on a linear upgrade-path for the existing legacy desktop app.

@gingters Not sure I understand.

If your desktop libs work with netstandard2.0 they should also run on core. (if they invoke wpf stuff etc they won't of course)
If this is the case then you should be able to use asp.net core 2.0.

If your desktop libs crash on core because they use stuff not in netstandard2.0. Then I see why you need to stay on 1.x. And I see why the short EOL is a problem.

Would 1.x be a easier/better choice if you knew 2.x only contain mostly core perf stuff (Meaning 1.x is not outdated vs 2.x). And that 1.x will get patches and be supported for * years?

@hallatore It's the other way round. Old application: Mix of Windows Forms, WPF, C++/CLI, normal C++, DirectX, millions lines of code etc. pp, running on 4.6 full framework.

On .NET Core: New business logic libraries (using also other libs, i.e. the .NET Core version of Serilog), abstractions libs + services + client libraries for these services. Services need to run on Linux and as windows services (currently Topshelf on full .NET 4.6 framework, as soon as windows service support lands in Core that could be changed, though).

Now the new business logic and abstractions as well as the service client libraries are also consumed from the .NET 4.6 applications. This means we are not capable of upgrading them, as they will need to run on the full .net framework as long as the desktop app does (which we can assume will be pretty much for as long as a desktop can live, unless full framework goes away in general).

@gingters You can still have the shared library projects in your solution targeting netstandard _min(usable)_ and consume those libraries from your ASP.NET Core 2.0 code as well as packaging them up to be used from WPF, Xamarin, UWP, whatever.

it is really sad that you MS guys still do not get the point. you still think it is only api gap issue. you still think people can just modify their code and it will work on netcoreapp... i thought you understand enterprises much better than google.

Based on that, it seems like MVC 5 on mono is what you really wanted right?

@davidfowl I mean, come on. That's a dismissive and frankly insulting answer. Can anybody at MS confirm that a single dev is even assigned to Framework ASP anymore? I'm not trying to be a jerk here, but it seems like sometimes the community is talked down to.

There's no reason under the sun that I should consider .Net Core and ASP.Net Core to be the same product. There hasn't been any messaging to support it at all. Especially when you consider that Mono came under the Microsoft wing _after_ the .Net Core announcement. It has always been messaged as the smaller, nimbler, xplat version of .Net. Not only that, but we all remember the days when ASP.Net Core was actually ASP.Net 5 and was going to work everywhere. Heck, that change is just over a year and half ago only.

Is the self-hosted HTTP story in netstandard20 effectively "use Kestrel 1.x"? I'm not sure the Nancy folks are going to care hugely for that, and neither do I. ASP.Net 2.x may be incremental feature-wise, but Kestrel 2 has a serious perf benefit that we could seriously use the day it comes out.

@davidfowl

It's big and has existed for a long time. Like any legacy system some parts are better than others. It doesn't make the code less reliable but it does make some parts practically impossible to change. There are so many fun stories veterans can tell you about how bug fixes in one areas broke obscure scenarios in applications in other parts. It's tangled, that's what happens when the dependency boundaries aren't well defined.

I think this is an interesting comment. I remember watching an older NDC conference session recording with @davidfowl and @DamianEdwards picking apart of the legacy cruft in ASP.NET 4 that you really wanted to leave behind - it was really fascinating to get peek inside that black box of code.

But I think this comment also mirrors the concerns many of the us have with our own codebases. We maintain large legacy systems, often not well designed with poor dependency boundaries. It's practically impossible to rewrite some of these systems for .NET Core. The business simply won't allow the risk of that much change.

I don't know what the right answer is. But I know that for our own applications, we'll be using the full framework and ASP.NET4/MVC5 for the foreseeable future (we still have a chunk of WebForms won't be rewritten for quite some time!). I hope to see MVC5 get some love now that it's _finally_ moved to GitHub - I'm even willing to donate my own time and effort to make it better (e.g. better async support, performance improvements, etc.).

@qrli Enterprises still have full .NET 4.5 to run on their Windows Server 2008 R2 IIS 7.5 Web Farms. Nobody's taking that away from them.

@mattnischan

Is the self-hosted HTTP story in netstandard20 effectively "use Kestrel 1.x"? I'm not sure the Nancy folks are going to care hugely for that, and neither do I.

HttpListener is part of netstandard20 therefore also netcore20 nothing is being taken away on that front by going netcore20.

HttpListener is part of netstandard20 therefore also netcore20.

And I suppose I can expect the same requests per second from HttpListener?

@markrendle True. For now.

But what would you suggest when one other libraries used by our shared stuff (i.e. serilog, newtonsoft, autofac etc.) drops support for netstandard_min(usable), (maybe just because they feel its too much of an effort to support both worlds) and there is a critical security issue detected in the latest version that still supports full framework?

@mattnischan

HttpListener is part of netstandard20 therefore also netcore20.

And I suppose I can expect the same requests per second from HttpListener?

Ok then, Nancy is .NETStandard 1.6 so you can use it on Core 2.0 and use Kestrel 2.0. Better?

@gingters I would suggest crossing that bridge when you come to it.

Never let the future disturb you. You will meet it, if you have to, with the same weapons of reason which today arm you against the present.
_~ Marcus Aurelius_

That is not as useful a mantra when delivering software which has no maintenance budget and must be used largely unchanged for years to come.

If it must be largely unchanged for years to come then why does it matter what happens to the libraries it depends on in those years to come?

@markrendle Now just assume you are required, by law (at least in some countries), to provide emergency protocols for exactly these cases, before a version of the application ships, as it might be used in environments where people's lives might be at stake.

So you want a web server that is as fast as Kestrel, and your only specific requirement is that it is not Kestrel?

Ok then, Nancy is .NETStandard 1.6 so you can use it on Core 2.0 and use Kestrel 2.0. Better?

@markrendle @benaadams No, I think you misunderstand, and again, not trying to be a jerk, just pointing out that there are other customers of pieces of ASP.Net Core that aren't the whole thing. I'd just like to host our production platform on top of Kestrel 2.0 when it comes out, and our production platform might be on Framework for a while. I can't target netcoreapp20.

Nancy may be netstandard16 but it doesn't matter because I can't use Kestrel 2.0 except on Core 2.0. I realize this is specific, and maybe the answer is truly "then write your own webserver that works on framework that's as fast as Kestrel 2. Kestrel is for ASP.Net only." But I'd hate for that to be the message.

@gingters @gulbanana I don't understand how a shipped application with a fixed set of dependencies is going to break because an open source project stops supporting an arbitrary version of the underlying framework at some putative future date.

@mattnischan Yes, I figured out what you meant and deleted that comment :)

@stefanolson

Because I need to share code between the server and my desktop applications does that mean I can never have the latest version of ASP.Net?

If you target .NET Standard with your libraries, you can use them in both Desktop and Core. For libraries target .NET Standard, then you have universal platform support: Desktop, Core, Mono, Unity, UWP, Tizen etc

An ASP.NET application is an executable; the end point, it isn't a library. The final output, the ASP.NET application/executable needs to run on a platform. Eventually any of its platform libraries will be consumed by the ASP.NET application so there is no advantage to them not being the same target as the platform.

.NET Core is a good platform as it has a broad cross-platform coverage; can be installed side-by-side with Desktop and can be upgraded independently app by app; rather than whole machine and every app.

Some items do have uses outside; so Wyam uses Razor for static site generation; Razor is currently .NET Standard 1.3 so consuming it outside Core isn't currently a problem.

There are some edge cases mentioned above:

Using libraries which don't support the .NET Standard 2.0 feature set. A lot of them are hopefully gaps that can be filled - and at the start of this issue MS were asking what those gaps were so they could prioritize them.

Running a WebApp embedded in for example a UWP app; however if Desktop was still supported but changed to version 4.7.1 you'd still be in the same situation as UWP doesn't currently support 4.7.1 and by the time it did ASP.NET would require 4.7.2, then 4.7.3 etc. It would be a Sisyphean task as the other platforms would never catch it; so it would just be busy work without much point?

Yes, I figured out what you meant and deleted that comment :)

No worries, good sir. 👍

@davidfowl

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.

Just saying (as I understand) that "sometime we needed to break with full .net why not right now" is missing an important point. I'm sure that lots of people was waiting for the release of core 2.0. Because it's publicly promised a lot of improvements in compatibility with full .net. So many libraries authors are also waiting to start migration to core. So I guess that after core 2.0 released we'll much more migrated libs on Core. And so binding asp.net core to core 3.0 would be much less frustrating for ecosystem then it's right now. Because at the moment of 3.0 these should less blocking things from migrating to core.
Right now it's a disaster.

Previously I was assessing starting migration of our framework (very similar story to what @benaadams described) onto core/asp.net core in two steps: migrate web part (which is on mvc/webapi now) onto asp.net core and keep full .net and then migrate all other stuff on core when all dependencies will have corresponding implementations for core. Currently what blocks us is Oracle ADO provider and Postgres ADO provider (there could other incompatibilities in corefx we didn't dig into it yet). Now this plan is dead. So we have to sit and wait for migration of dependencies abandoning all new stuff in Core world. And all this is only because of the fact that someone in MS decided that we need "moving fast" platform.

@markrendle The application is not going to break just because of that. The issue is a different one:
Because .NET Core 2 dropped support for the full framework (where it ran fine on in version 1, and it's from Microsoft where you don't expect such a basic, elementary feature to be dropped when updating to a new version), also your dependencies might drop support for this scenario rather sooner than later.
Someone finds a critical security issue in one of the libraries used, and no update is issued for the version you are stuck on, as newer versions don't support your runtime anymore. Now, since your application is used in a very regulated environment you need to provide an emergency plan that explains what exactly you will do when an critical security issue is detected and how to roll that fix out to prevent people from getting hurt or worse. A "well, we can't do anything" will result in revocation of your allowance to ship that application.

@gingters Look, the point is, you have to make your tech choices based on the information that is currently available and the nature of the marketplace in which your company operates. With the best will in the world, you can't account for all eventualities, however much the bureaucrats and regulators of the world would like to pretend that you can. What if Microsoft are acquired in a hostile takeover by Apple and .NET is discontinued entirely in favour of Swift? What if strong encryption is made illegal in one of the countries you sell to, and all software stacks that include SHA256 are banned? What if Nicolas or James or _insert-name-of-Autofac-maintainer-here_ decide to move to Mars and become moisture farmers? What if the magnetic poles reverse and every single bit of digitally-recorded data is wiped?

As an actual answer to the question of what you, as a company, say you will do in the event of a critical security issue being found in JSON.NET (for example), in the absence of an official update being available, the only possible answer is "we will fork-and-patch JSON.NET", which I'm guessing is already the answer to the question of what you would do if James Newton-King were to become indisposed for any reason. In my previous experience working in those kinds of markets, there were escrow arrangements for the source code to proprietary packages for that sort of eventuality; what to do about open source packages is trivial by comparison to that.

And all this is only because of the fact that someone in MS decided that we need "moving fast" platform.

"moving fast" might be overstating it; going by the previous release schedule of Full Framework it might be better stated as "without adding an extra 1 - 2 year delay" into shipping. That's a crazy amount of time in the web world.

Things are changing fast and the platform needs to stay relevant.

@davidfowl and @DamianEdwards I think that this whole confusion came from the fact that ASP.NET Core 1.x can run on .NET Framework. This created the assumption that ASP.NET Core was the evolution of ASP.NET 4/MVC5; making people migrate to it thinking that they would get all the benefits (speed and new features) while keeping the backward compatibility.

So maybe the long term / permanent answer to this issue is to re-promote ASP.NET 4/MVC5 as the answer for people seeking backward compatibility with long term support (and maybe offer to make small improvements as well).

Then, ASP.NET Core can focus on being a new platform that breaks away from the past to offer huge benefits, for those who can make the jump.

In that light, (ASP).NET (Framework) and (ASP).NET Core will be two parallel and equally valid roads that customers can choose. And I think this is the way things should have been from the start.

@markrendle Yes, this is hypthetical, but bureaucracy sadly is a real thing. And yes, you can't (and don't need to) account for all eventualities. Just for the ones you can anticipate.

And now we have the situation that a) dropping of a complete platform (.NET full framework), which was supported in .NET Core 1 just fine, wasn't something you could anticipate. However, since it happened now you can b) anticipate the drop of support for v1 in your other dependencies with a pretty sure "yes, I can totally see that happen rather sooner than later".

And yes, forking and backporting fixes is one of the possible solutions, however this is something you want to avoid as much as you can. If the .NET Core team had said something like "Hey. Look, we don't intend to run on full framework, don't rely on that", or even better never had made that possible in the first place, this whole discussion wouldn't be necessary as the customer just would not have opted to invest in new stuff on top of .NET Core in the first place.

@gingters I thought we were at the point where you were happy running your ASP.NET Core web bits on .NET Core 2.x or later, and using .NET Standard 2.x for sharing libraries between Core and Full/UWP/whatever. Because if these libraries were to drop support for .NET Standard 2.x in favour of just .NET Core 2.x, then they'd be dropping support for full .NET too, and you're hosed either way.

@markrendle Up to the point where we have a critical issue in one of the ASP.NET Core bits we need to use in the shared stuff after 1x isn't supported anymore.

@gingters luckily it's open source and you can support yourself (or pay a 3rd party) if need be!

@markrendle no. pure legacy projects are dead ones. enterprise projects are usually a big mix codebase which contains code/libs date from decades ago to fresh new. being netcoreapp only means you removed the ability to mix. so we can no longer move to your fancy new version but locked down to the old version. and the anti-ms workmates will happily say to me "i told you..." and then pushing us to migrate to google solutions.

i'm not arguing for supporting netfx forever. but i strongly feel netfx should be supported by asp.net core for at least 2 years from now. not only 1.x but also 2.x.

@qrli Those "enterprise projects ... big mix codebase which contains code/libs date from decades ago to fresh new." are everything that is wrong with enterprise projects and needs to stop. Complaining that a new technology stops you from throwing more hunks of mud into a big ball of despair held together with shims, baling wire and denial is like complaining that a new industrial laser cutting machine comes with safety features that stop you leaning in and cutting off important bits of yourself.

@benaadams

"moving fast" might be overstating it; going by the previous release schedule of Full Framework it might be better stated as "without adding an extra 1 - 2 year delay" into shipping. That's a crazy amount of time in the web world.

Things are changing fast and the platform needs to stay relevant.

This is a political/organizational limitation, not a technical one. Look at how the JVM / Java is moving. If they're moving at all. Still relevant, much more than .NET is today. So 'moving fast' isn't the reason people choose Java/JVM. On the contrary. They pick Java/JVM because it lacks all the downsides associated with 'moving fast': it's a stable, dependable platform, where your investment isn't wasted in 1-2 years.

I don't know, if MS wants to move .net full fast, it will move fast. They own it, they can decide what to do. But the powers that be don't really give much about that: .net full is 'good enough' for where it is now.

MS has slept at the wheel for many years and now all of a sudden things like performance and memory pressure are important (they are, no doubt about it), while in JVM land investments in those particular aspects of a runtime have been done for many years and that pays off.

I don't know what the solution is, short term, but in the long term, leaving .NET split across two major departments (.net full with windows, .net core with devdiv) with no common ground/goals other than the same employer doesn't bode well for us outsiders.

While there are many points being made here, and everyone is trying to make sure they understand others viewpoints, solutions like "big enterprises shouldn't be like that" aren't going to help. Even if you could convince them of that, it would take them 20 years to stop being like that, because they're big enterprises.

@kolectiv That's true, but accepting that enterprises aren't suddenly going to stop being enterprises doesn't mean you have to actively encourage/enable that sort of behaviour.

It also shouldn't mean that _my_ applications have to run more slowly and cost more to host.

Running a portability analysis on our heavily used libraries that still target .NET 4.x on ASP.NET Core 1.x (EF6, NHibernate, NServiceBus) and man, these libs aren't even close to being able to target netstandard20.

Lib | Pct
---------- | ---------
EF6 | 62.74
NHibernate | 67.39
NServiceBus | 65.68

And still huge gaps in missing APIs. EF Core still has a large gap with EF6, and we still use NHibernate when there are major features there that don't exist in EF6. NServiceBus we use on any project that does messaging.

Whew.

@markrendle

Those "enterprise projects ... big mix codebase which contains code/libs date from decades ago to fresh new." are everything that is wrong with enterprise projects and needs to stop. Complaining that a new technology stops you from throwing more hunks of mud into a big ball of despair held together with shims, baling wire and denial is like complaining that a new industrial laser cutting machine comes with safety features that stop you leaning in and cutting off important bits of yourself.

Yeah man, let's tell those pesky Enterprises and large organizations to do things differently, cut the wire! stop the mud flood! That will make them wake up and listen. Oh wait, that won't help, as they already know that but have to work with a lot of things you don't care about or ignore for your own argument.

Look, no-one says 'new tech: bad!'. It's about pursuing new tech without realizing the consequences that brings with it. We all like to work with the newest bits and not have to worry about old cruft, who wants that? Reality however tells a different story. If you only have to work with the newest bits and don't have to care about old shit, good for you! Sadly we sad work drones in the trenches have to live with a different reality. It would suit you if you at least acknowledge that for a LOT of people reality is just that, they can't change it, they can't make a different future, it's what they have to work with.

@markrendle I'm not quite sure what you're suggesting? Abandoning our 15 million lines of working C# code and write it all afresh? We were looking at transitioning (slowly) to netstandard 2.0 and hopefully getting access to things like Span etc when it came along, but issues like this make me doubt that is wise.

We'd like Linux support but this feels more like a divergence. I'd assumed netstandard was going to move ahead with the most advanced implementation and then things like the framework would catch-up, but at least we'd know it would.

@FransBouma So we should all suffer because Enterprises want to do stupid things? I shouldn't get nice things because multi-million dollar public sector projects aren't ready for them yet? How does that work?

@markrendle What's stupid about wanting to keep working code?

They pick Java/JVM because it lacks all the downsides associated with 'moving fast': it's a stable, dependable platform, where your investment isn't wasted in 1-2 years.

And you can use System.Web basically forever; its baked into Windows which means its likely never going to go away. You don't get much stable and dependable than that.

ASP.NET Core 1.x -> ASP.NET Core 2.x; all the apis are pretty much the same the main change is dropping support for .NET Framework. It even changes semver for the break 😱

ASP.NET Core 1.x runs on .NET Core 2.x and .NET Framework, supports .NET Standard 2.x (via .NET Core 2.x); and has the same apis as ASP.NET Core 2.x, So that's the stepping stone release.

ASP.NET Core 2.x is the break release. It still supports .NET Standard 2.x (via .NET Core 2.x) and not much api-wise has changed between ASP.NET Core 1.x and ASP.NET Core 2.x; but drops .NET Framework.

Could an alternative be:

• ASP.NET Core go ahead and work towards something like netstandard3.0 (could be 2.x) and just version netstandard faster. Like once a quarter.
• NetFx next release could jump again to support netstandard3.x whenever the next release is. It wouldn't even have to be the newest standard.

This might be a bad idea because everything used might not need to be part of netstandard but at least ASP.NET Core 2.x would target a standard that the other frameworks will use eventually.

Just spit-balling. I'm sure this has been brought up.

@bencyoung I'm merely suggesting that it's a bit selfish to insist that the entire world should revolve around your 15 million lines of working C# code (which isn't going to stop working, btw). So you can't use ASP.NET Core 2.0. You've still got the full Windows-only framework ASP.NET which has legacy support running through it like Brighton through rock. So there's a new toy you can't play with because it's not economically viable for you to port your code and refactor/rearchitect your application. That sucks, but so do lots of things. But if Microsoft avoid everything that's not going to work for pre-existing two-decade-old legacy codebases that probably still include COM components written in VB 6.0, then in another 20 years they'll be Micro Focus.

@adamhathcock That's what I'd assumed netstandard was for - a unification approach, rather than a least common denominator. It can move as fast as it wants, but they'd be a commitment that .NET framework would eventually catch up. Eventually there'd be a netstandard that basically was the .NET framework minus the platform specific stuff and then it would be unified

NetFx next release could jump again to support netstandard3.x whenever the next release is.

A .NET Framework update is a forced update for every machine on the planet running Windows (mostly).

A .NET Core update is a update you for an individual application choose to take.

They are very different beasts.

Well, one easy thing to do would be to stop linking to this page from the very first page of the ASP.NET Core docs.

(Or simply add a line "Don't choose .NET Framework if you want to continue to use ASP.NET Core!".)

they'd be a commitment that .NET framework would eventually catch up.

There is https://github.com/aspnet/Home/issues/2022#issuecomment-299609207

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.

But by the time it catches up, ASP.NET will have moved on to the next .NET Standard version and it would never be the right version of .NET Framework for ASP.NET; it would always be behind.

@markrendle no, they are not big mud ball. big mix does not mean they are bad architected. they are modular. it is that many modules are battle-tested code written long long ago by really smart people or bought from 3rd party. some is by c, some is in fortran, some in c++/cli, etc. to migrate or rewrite, we need to understand them, read papers, gather more real test data, retest the new version. it takes effort but such tasks are never budgeted, but up to ourselves. business people do not care we use .net core or not, but they want the features done. and for 3rd party, we have to urge them or seeking for replacement.
so, it can take a few years in practice.

@benaadams

And you can use System.Web basically forever; its baked into Windows which means its likely never going to go away. You don't get much stable and dependable than that.

ASP.NET Core 1.x -> ASP.NET Core 2.x; all the apis are pretty much the same the main change is dropping support for .NET Framework. It even changes semver for the break 😱
ASP.NET Core 1.x runs on .NET Core 2.x and .NET Framework, supports .NET Standard 2.x (via .NET Core 2.x); and has the same apis as ASP.NET Core 2.x, So that's the stepping stone release.
ASP.NET Core 2.x is the break release. It still supports .NET Standard 2.x (via .NET Core 2.x) and not much api-wise has changed between ASP.NET Core 1.x and ASP.NET Core 2.x; but drops .NET Framework.

Yes, and let's see what the options really are :) ASPNET Core 1.x is a dead end: you can port to that but your code can't move to .net core if you depend on libs which are .net full today and might not be ported to .net core /standard when support ends. Choosing ASP.NET core 1.x now is only wise if your dependencies are already on netstandard2.0/.netcore, then you can move to asp.net core 2.x without problems, knowing you are not running into a dead end.

Your suggestion to choose system.web as an alternative to nginx and a JVM stack if you want to have stability is a bit weak, don't you think? :) It's about options for a large org what to pick as platform. Unless they're creating an app that's completely new and doesn't have to work with outside dependencies (rare) they'll likely take the safe bet, and why wouldn't they? If it then comes down to system.web or JVM/nginx the choice is pretty simple.

It's the little things. I hammered on it before: sql server enterprises' encryption features. You're not going to use these on .net core as they're not there. Oracle? nope. So if you want to use asp.net core and these features, you have to use .net full and asp.net core 1.x. But what happens if these features aren't ported/available when support for asp.net core 1.x ends? (and who wants to bet the farm on a platform which is in 'QFE mode' already?) Back to system.web?

It seems to me that part of the issue is that ASP.NET is directly driving the evolution of .NET Core. I guess that's an internal thing in Microsoft, but really the platform and a specific library should not be so tightly coupled.

If something new needs adding to a version of .NET then it should be made available to everyone via a netstandard bump (with vNext) and then ASP.NET updated to use it when it is released. It's the privileged position of ASP.NET that causes this issue I think. This may be unavoidable due to the groups of developers inside Microsoft being the same...

As a writer of HPC software that uses .NET heavily we've also implemented our own zero allocation parsing etc without changes to the underlying platform. Would we benefit from Span etc? Absolutely! Can we switch to .NET Core? Not for a long time. Will we see Span etc added to .NET Framework? Seems hard to say now without it being a netstandard commitment...

@markrendle Sure, but what's our transition plan? I can't see one that doesn't hit unsupported paths. If the changes were in netstandard and then ASP.NET Core used them then at least we'd know there was a path through eventually....

@markrendle i'm not sure who are the intended users of asp.net core. but what i saw are mostly .net users who have big investment in .net and big legacy (not bad) codebase. if we are not the intended users, i dont see node.js/python/go guys give .net a sh*t, no matter how good we think .net is.
if it is not for company but for my own projects, i will not use asp but use nancy instead. companies need stable guarantee and support. and they/we pay big money for it.

The easy solution to this problem would be, if Microsoft would make a Windows only distribution of CoreCLR that supports the full range of .NET Framework libraries.

The personal side in me is cool playing with .NET Core on the PI on ubuntu but the business side didn't even consider .NET Core because .NET Framework does everything we need and .NET Core is only trouble in comparison. Most of this trouble was around tooling and getting everyone setup'd so those pains are finally going away, but it still lacks so many features... EF Core isn't even close to being mellow enough to substitute EF6 or NHibernate and they won't run on .NET Core 2 either. The lack of WCF (host) for SOAP Services is quite a burden, since its what we do all day in business communication, but could probably be migitated through clever design and using .NET Core and .NET Framework in multiple apps. AppDomains are also not easily replaced although thats the least of my problems. The leap from ASP.NET MVC 5 to MVC Core was unexpectedly easy for a rewrite but going .NET Core makes VS stop cooperating, displaying all the errors.

Fun things like hosting ASP.NET Core inside WPF will also be impossible.

It wouldn't even matter if the Windows CoreCLR distribution would be closed source since its not much different from .NET Framework today.

Now excuse me while i quietly weep and delete my experimental branches that were migrated to ASP.NET Core.

Your suggestion to choose system.web as an alternative to nginx and a JVM stack if you want to have stability is a bit weak, don't you think?

Its the extreme end ;)

If it then comes down to system.web or JVM/nginx the choice is pretty simple.

Yeah, if you can go JVM, you use ASP.NET Core 2 as you don't have blockers and it has nice interop and p/invoking :)

if the apis are "pretty much the same", why don't you keep one version numbering 2x for all, but having option to select for "netstandard" or"netcore"?

Because its the internals that are changing; and making use of changes to the runtime, jit and standard libraries. To a user they appear mostly the same as that's where the compatibility is between ASP.NET 1.x and 2.x; on the exposed api surface, not the internals "here's how its done".

It seems to me that part of the issue is that ASP.NET is directly driving the evolution of .NET Core.

As are other people. You can make an api request over at dotnet/corefx as I did for example for ValueTask; which then evolved into Task-likes and is now part of C#7.

As soon as your api is included in .NET Core you can the start using it (if you go for nightlies and want to make sure the api is right); or at the next release of coreclr/corefx if you want to hang on 6 months.

and then ASP.NET updated to use it when it is released.

Now you have to wait 2 years. That's not really practical; as the apis will need refinement through use; and through use more discovery will happen. That's like adding a 2 year compile step to your development cycle.

As a writer of HPC software that uses .NET heavily we've also implemented our own zero allocation parsing etc without changes to the underlying platform. Would we benefit from Span etc? Absolutely! Can we switch to .NET Core? Not for a long time.

Is your HPC software directly hanging off web requests? At a guess it might have queues driven by webrequests, but it runs in a separate process so should be unaffected by this change?

Will we see Span etc added to .NET Framework?

Yes

@benaadams

But by the time it catches up, ASP.NET will have moved on to the next .NET Standard version and it would never be the right version of .NET Framework for ASP.NET; it would always be behind.

Which is completely fine and acceptable, if there is at least 1 version overlap (i.e. if you stay on the latest full framework there is still at least one officially supported (ASP).NET Core version around running on that).

Microsoft would make a Windows only distribution of CoreCLR that supports the full range of .NET Framework libraries.

Or a set of .NET Standard 2.0 libraries; so they can run on .NET Core, that only run on Windows that cover the api gap?

@benaadams yeah thats the idea, although that won't work for anything that throws PlatformNotSupportedException

@qrli If it's modular, then you can upgrade the modules that can be upgraded now, and leave the rest until later.

Unless by "modular" you mean "it's a massive monolithic System.Web ASP.NET IIS application comprising dozens of different libraries interoperating via PInvoke and COM" in which case, that's a big ball of mud.

Is there a final list of which assemblies are affected and which are not? It has been mentioned that Microsoft.Extensions.* is safe and Microsoft.AspNetCore.Razor.Runtime (assumed) too, thanks to which Microsoft.AspNetCore.Html.Abstractions needs to stay on netstandard also. Is there anything else in the Microsoft.AspNetCore.* that is staying on netstandard?

@bencyoung My recommended transition plan is to migrate various components over time to standalone services targeting .NET Core 2.x (or whatever works best out of the entire universe of development tools for that particular component), consuming those services from your legacy code over a standard API boundary using HTTP or a message bus, until you've got a proper distributed system architecture.

@markrendle Not everything belongs in a distributed system though. As a concrete example: a large part of why Stack Overflow renders pages so fast is that it's not distributed. Though our network latency is 0.017ms, that would add quite a bit of network, serialization, deserialization, and GC cost to our application. Sharding a system out into many services it not a universal answer. It's a complicated one, a costly one, and a net negative for a many scenarios as well. It may be a good thing, but it can also be an over-complicated bad thing.

@markrendle my issue isn't one of migrating to services, it's that some of the fundamental service infrastructure building blocks use APIs that aren't on the roadmap for netstandard20 or even netstandardbanana. .NET Core for us isn't about greenfield applications, it's about entire greenfield systems. System.DirectoryServices is one example but for others, it's WCF, and more others, it's System.Data and the SqlClient stuff, and for us, System.Messaging.

I'm all for using .NET Core when I can. So far that has included zero client projects, greenfield or not, they're all blocked on something.

@NickCraver I don't mean to be facetious or anything, and I know that the real reason that SO pages render so fast is that you and the other people who build it are amazing, but the Google search results that include links to your pages render just as fast as your pages, and you _know_ they're coming from a big, complicated distributed system. Amazon pages render pretty fast, same deal. I'm optimistic that ASP.NET Core is driving towards a future where it can be used to build systems the same way those are built, with the same performance, and I think it's got a better chance of getting there if it frees itself from the turning-a-small-island update cycle of full .NET.

@jbogard I see similar, but that'll be very different when .NET Core 2.0 is out.

Sigh.

@jbogard

netstandardbanana

quote of the thread

The main issue with this, for me and my team, is that there was no indication that this path was the intended future. I get no one knows the future but hearing that we need to break out anything that relies on full .net framework (component vendor dlls, payment services sdks, HSM sdks) into their own services and introduce that new hop STINGS. It just isn't something this site needed and now we have to either introduce more dev ops complexity or re-do the web app portion to MVC 5.

We went with asp.net core for the speed of kestrel and the fancy new API. It would have been nice to be able to more accurately weigh the options against the lack of an easy upgrade path given our dependencies.

Adding to @jabrown85
ASP.NET Core has been a rollercoaster of emotions thus far.
After csproj landed i finally went "it's ready now" and considered it a no brainer to start anything new in it and checking what can be upgraded. After this announcement, its more like: "does .NET Core definitely support the scenario or should we go safe and just stay with MVC5?"

Casualties are low so far, only one application written in ASP.NET Core that manages the administrative tasks of the primary MVC 5 app, but it will be stuck on 1.x forever because the main app uses NHibernate.

@markrendle computer says no

It'd be nice if there were some roadmap for full .NET -> netstandard. Some of the fundamental pieces just say "Not Supported" from ApiPort. I'll be running fuller analysis of the client projects on ASP.NET Core 1.x to see what's missing.

but it will be stuck on 1.x forever because the main app uses NHibernate.

Shouldn't be, NHibernate isn't dead is it?

@benaadams surprisingly no. There are a few things that it does that EF6 really doesn't have any equivalent. We default to EF6 but there are cases where we have to go the NH route.

@benaadams officially no, it has pauses where it seems almost dead but usually theres one commit every few days. ApiPort reports 72.26% coverage for .NET Standard but i'm not really convinced that it will be ported (in the near future at least).

Reading the comments, I am concerned about the general direction this project is heading. For a long time ASP.NET was a good choice for a stable and solid technology. However, I don't get the same feeling now. There are many "move fast and break things" technologies, but that's a whole different category.
I hope that Microsoft will be able to address those concerns and align everyone's expectations.

It's not about enterprise vs. non-enterprise software. There are plenty of Python 2.x applications in use today and not all of them are "enterprise". What's more - not all new projects use Python 3 (almost 9 years after the release of Python 3.0!).

Can anyone summarize the whole thread in a blog post?

I've read through all 300+ comments while on commute/lunch and ... I still seem to not "get it" completely.

What I get is:

• The full .NET Framework won't be supported on .NET Core 2
• Every dependency will depend on netcoreapp2.0 instead of netstandard2.0
• If I want something like DirectoryServices or Drawing, I need to drop Full Framework and jump to 2.0

I kind of missed the rest... busy schedule and everything.

@MaximRouiller

If I want something like DirectoryServices or Drawing, I need to drop Full Framework and jump to 2.0

No, if you want to a library that does not support .net core, you will not be able to use AspNet Core 2.0+ at all.

@MaximRouiller, what they just did is that Asp.Net core projects won't be able to reference full framework assemblies, making it useless for many if not most, they say asemblies like system.drawing and Directoryservices will be ported to the new netstandar or I dunno, still, old assemblies won't work unleast someone port them, so, it is pretty much useless for many becuase some assemblies are legacy and won't be ported, ever. In conclusion, anyone who was using .net core with the full version of the .NET framework just got screwed and need to go back to MVC 5.

@davidfowl Thanks for this list by the way. That's the very important "so what are we getting out of this?" piece needed for people to balance the cost/benefit in their minds.

If you haven't already, read the list so you're informed on both sides. I still stand by wanting 2.x to be a transition release (with justifiable benefits to the business to actually warrant the move), and 3.x being where the wins are. Even if it came out 2 days later. I really do appreciate the insight on all sides.

@davidfowl you said:

Libraries can be written on top of the standard. When things in the standard itself need to change it will take a lot longer to be adopted in all implementations of .NET and that includes .NET Framework. It can mean a couple of things:
.NET Standard will evolve at the rate of the slowest implementation
.NET Standard will evolve at some other pace and .NET Framework will be the last to catch up.

But why is that the case? Can't you release .NET Standard vNext and have .NET catch up to it some time later (a few months to a year later)? That means that people who are on the bleeding edge and want the latest ASP.NET Core can host in .NET Core, and people who need .NET for their legacy code can eventually use that version of ASP.NET Core once .NET catches up to the .NET Standard version that it uses. I don't understand why .NET Standard has to be revved as fast as the lowest implementation.
Also here we are talking about official implementations of the standard, but there will be other implementations that will not be updated in tandem with the standard.
That way you don't leave people behind. Sure, they take a little longer to benefit from the latest features if they are in .NET, but they aren't stuck forever.

@jdom because I know the rate at which .NET Framework changes and why it has to be slow. It's a different distribution and maybe there isn't enough appreciation for that. Any change gets inplace pushed to billions of machines. The layering is also completely different so it's not a trivial thing to even reason about.

I don't understand why .NET Standard has to be revved as fast as the lowest implementation.

If we keep raising the low watermark for .net standard in ASP.NET Core it defeats the purpose and leaves you in the same situation. Sure you don't feel left behind because there's a promise that someday these APIs are coming to .NET Framework but in what timeline? .NET 4.7 still doesn't complete feature parity with .NET Standard 2.0.

@davidfowl but this will bring back the same problem as with PCLs, it will become the lowest common denominator and a pain to use, the fact that ASP.NET abandons using it shows that already.

@davidfowl but this will bring back the same problem as with PCLs, it will become the lowest common denominator and a pain to use,

@Suchiman how is that an issue? The only problem with PCLs was how they were dynamically calculated and represented in NuGet which made it hard to predict what you were going to get. How else would netstandard work if it wasn't an API set that could be implemented by different implementations?

What made PCLs annoying to use were the super duper small API surface area. .NET Standard 1.3-1.4 is enough to implement most basic libraries API wise.

.NET Standard was always about breadth.

ASP.NET Core and .NET Core were about a competitive cross platform server stack for building light weight micro-services. The breath in this sense was broader platform support (running on linux, osx, tizen, pi etc).

@davidfowl

We've identified strings as one of the major things we'd like to try tackling in .NET Core, there's tons of ideas but one of them is to have string be utf8 by default (tons of compat problems but follow me here).

Another thing we'd like to fix is the ability to take cheap slices of arrays/strings, any piece of contiguous memory. We've added Span and are looking at Buffer to represent this. It might mean that String and Array implement new interfaces that make it possible to take a slice that requires 0 allocation.

It sounds like this means that if I want to use these new bits in a library, the library will also need to target netcoreapp2.0 instead of netstandard2.0. Is that correct?

It's a really bad idea not to support the old 4.x framework any more. People don't upgrade if it causes a lot of work. See the super old classic ASP, which is deprecated since 2002 - about 15 years. And we have old applications that still exist in classic ASP! Does Microsoft like to see something similar once again? Dropping old 4.x support is something that has to be done mandatory - but on the long run! Not now. This can be an option in a few years, when .NET core is the de facto standard and only old applications use the net 4.x.

The idea behind (ASP).NET Core is really great, the best thing Microsoft did since the realease of .NET. But such a chaos dulls this nice concept. Also it's very sad, that Microsoft decide such massive changes on their own, without even discussing it in the community! Seems like this company hasn't completely learned yet how to handle open source projects.

@davidfowl

.NET Standard was always about breadth.

Breadth in APIs or platforms?

Whats the issue with evolving .netstandard at the same pace as .netcoreapp?
Is any of the BCL tunings target specific to .netcoreapp because they'll never be implemented in the other frameworks?

Releasing .netstandard2.1 at the same time as .netcoreapp2.1 doesn't make a difference to releasing .netcoreapp2.1 first and a year later .netstandard2.1 at the same time as .net50, except that packages targeting .netstandard2.1 would start immediately functioning on .net50 but will be blocked if they target .netcoreapp2.1

ASP.NET Core is a high level webapp framework built on top of .NET Core and will in the future target .NET Core, _however_ it can also be a high level webapp framework built on top of .NET Standard instead, so that it targets a reference API interface rather than a specific implementation of it.

The public positioning of .NET Standard is being an easy target to build towards while leaving the implementation details aside - with 2 official frameworks directly from Microsoft to cover most use-cases.

Why change that story now? If the .NET Framework never catches up, that seems to be beside the point. At least the possibility is there that it will, or another 3rd party framework can do so. So what if there will only be a single implementation that realistically keeps pace? This is exactly why we have interfaces in our applications even if there's just a single concrete implementation, so that we have the flexibility and advantages it brings.

Perhaps bring down the scope on ASP.NET Core 2.0 inline with .NET Standard 2.0 and then use .NET Standard 2.1 for newer features? Add in some decent support timelines and wouldn't that solve this entire dilemma? Microsoft owns the .NET Standard and both frameworks so this fear in incrementing versions seems completely unfounded...

I guess it should be considered that ASP.NET to ASP.NET Core isn't the migration path for everyone.

ASP.NET on full framework will remain and get features but not like Core.

Migration will get easier over time but never be a 100% match.

People still run classic ASP. That's fine for them too.

@davidfowl I have huge respect for the whole team and the advancements you're all making. So, please don't take this as being down on what is happening. You guys are pioneers, and we all look to you as examples on how to do things right. But I don't see many of these points as immediate target changing problems, especially when it hasn't been communicated. Maybe I'm wrong.

I want to throw some crazy stuff out here because it's been mentioned a few times. What I'm about to say has no bearing on what will happen, it's all speculation at this point. Several people asked why we want to target .NET Core instead of .NET Standard.

• We've identified strings as one of the major things we'd like to try tackling in .NET Core, there's tons of ideas but one of them is to have string be utf8 by default (tons of compat problems but follow me here).

This point here would definitely be a game changer, but IMO it's the only one that absolutely requires not targeting framework, and it isn't for netcoreapp20 anyway.

• Another thing we'd like to fix is the ability to take cheap slices of arrays/strings, any piece of contiguous memory. We've added Span and are looking at Buffer to represent this. It might mean that String and Array implement new interfaces that make it possible to take a slice that requires 0 allocation.
• This leads to new methods on String that allow splitting that doesn't allocate an array every time.
• This leads to overloads to Int, UInt etc (TryParse) that take Span and Span.
• This leads to new encoding routines that take Span.
• Buffer and Span let you represent memory in a uniform way and we want to upgrade the networking stack to allow passing pre-pinned buffers that take Span or Buffer.

All of this is still implementable as packages on top of current netstandard. You don't even need netstandard20 for this. I understand not wanting to carry this baggage around, but the rest of us out in the non-MS world have to create custom BCL-esque impl's all the time when the use case or perf doesn't fit. Not to mention that the Span API isn't targeted for 2.0 either (unless that's changed again).

Kestrel will implement HTTP2 in the 2.x timeframe (currently aiming at 2.1) and that requires new APIs on SSL stream to do ALPN (https://en.wikipedia.org/wiki/Application-Layer_Protocol_Negotiation).
Http Client on .NET Core supports duplex streaming, it'll make it possible to implement streaming end points over http in signalr over a single, non websocket http request.

I feel like this one is a little trickier, but not all that different from Kestrel carrying around libuv. The CURL implementation from .Net Core can be easily pulled into a netstandard extension package until everyone catches up.

• We forked the header parser implementations from HttpClient and System.Net.Http and renamed them (https://github.com/aspnet/HttpAbstractions/tree/d1d9bceff56cb44a194ae36923ce687e5e353006/src/Microsoft.Net.Http.Headers) so that we could improve them and have them support both .NET Framework and .NET Core. .NET Core has a copy of these improvements haven't made it back because there no need to improve them (we couldn't consume them).

Right, but this is arguably the right way of doing this in this case. Frustrating to wait and hang on to the implementations, but again, I don't see how this is different than what anyone else does when they write a framework or library.

• Without the ability to rev the core primitives, we're encouraged to fork them and make things that look like them but aren't them. It's the reason we have our own little BCL within ASP.NET Core https://github.com/aspnet/Common/tree/dev/src/Microsoft.Extensions.Primitives.

Again, just like the rest of us.

ASP.NET Core and .NET Core were about a competitive cross platform server stack for building light weight micro services.

ASP.Net Core had some messaging like that. .Net Core has been messaged from day one as a wholly functional xplat server-side .Net framework subset. Never have I heard anyone say that .Net Core is just for microservices. I've heard you can use it with ASP.Net Core if you want, but also console apps, data analysis, DB services, etc. Is the direction of .Net Core effectively "whatever the ASP.Net Core team wants most"?

ASP.NET on full framework will remain and get features but not like Core.

Will it? I still haven't seen anyone from MS confirm that it is still being worked on. My gut says that it isn't. I get it. The team needs a "move it or lose it" type of moment to break free. I just don't think this is that moment yet.

Assuming that we have a business logic 4.6 assembly, which uses the Oracle.Net driver, the NHibernate and the RabbitMQ (all of them in 4.6). The interface with ASP.Net is only through our business objects, requests and responses. Can we reference this assembly in our ASP.Net Core 2 , without recompile ?

My quick summary

@stefan2410 short answer, no, you cannot reference the full framewrok, you could reference those assemblies only if they are created for the netstandar 2.0.

@mattnischan

All of this is still implementable as packages on top of current netstandard. You don't even need netstandard20 for this. I understand not wanting to carry this baggage around, but the rest of us out in the non-MS world have to create custom BCL-esque impl's all the time when the use case or perf doesn't fit.

I'm sorry but it really isn't. You can't monkey patch types. Unless you are suggesting we add new types and don't change the existing ones.

Not to mention that the Span API isn't targeted for 2.0 either (unless that's changed again).

Span exists in 2.0 as implementation but not a public API. We make breaking changes in new majors so we can do more features in minor versions. If ASP.NET Core 2.1 targeted .NET Standard 2.1 then .NET Framework support is dropped again.

I feel like this one is a little trickier, but not all that different from Kestrel carrying around libuv. The CURL implementation from .Net Core can be easily pulled into a netstandard extension package until everyone catches up.

So what you're saying is we should rename all of the classes in the BCL so we can use them on both .NET Standard.

Never have I heard anyone say that .Net Core is just for microservices. I've heard you can use it with ASP.Net Core if you want, but also console apps, data analysis, DB services, etc. Is the direction of .Net Core effectively "whatever the ASP.Net Core team wants most"?

Nope, .NET Core is a general purpose framework that originally had no verticals at its core. It's possible ASP.NET Core should have just been a vertical instead of libraries on top of .NET Core, it would have possibly avoided some of this confusion.

Will it? I still haven't seen anyone from MS confirm that it is still being worked on. My gut says that it isn't. I get it. The team needs a "move it or lose it" type of moment to break free. I just don't think this is that moment yet.

Yes, HTTP/2 support was added in the last release. There's another team that does work on ASP.NET and IIS and they do make improvements. However, they are not on the same scale as what ASP.NET Core is doing.

I don't have very strong feelings about this as I've avoided running my ASP.NET Core services on full framework like the plague. With that being said, I've had to avoid using some nice and mature libraries because they didn't support .NET Standard because they were either waiting for netstandard2.0 or simply because they didn't want to.

My fear is that removing the ability to run ASP.NET Core on full framework will dissuade users from porting their current MVC 5/Web API 2 apps to ASP.NET Core which will just provide another reason for library authors to avoid porting to .NET Standard. Why bother doing the work upgrading if none of your users will benefit? It becomes a chicken and egg problem and I'm just afraid that this will hurt the ecosystem as a whole just as it started to get some traction. First you need ASP.NET Core users and I'm not convinced there's as many of those as we all would like. Hopefully I'm wrong.

If ASP.NET Core 2.1 targeted .NET Standard 2.1 then .NET Framework support is dropped again.

No, it just means that Net Framework will automatically support ASP.NET Core 2.1 as soon as it supports .NET Standard 2.1, whenever that is, even if it takes a year or two.

The same for all other .NET Standard compliant platforms (Xamarin / Unity / ...).

Building on .NET Standard means that other platforms will light up _eventually_, building on .NET Core means they will light up __never__.

I assume that the plan is still that full-fx will catch up to netstandard, even if with a long delay?
(and if no other platform except NET Core is expected to implement .NET Standard 2.1, then why even have a .NET Standard?)

I'm sorry but it really isn't. You can't monkey patch types. Unless you are suggesting we add new types and don't change the existing ones.

The latter is what has already been done in most cases in 1.x, right? Is that suddenly no longer tenable?

Span exists in 2.0 as implementation but not a public API. We make breaking changes in new majors so we can do more features in minor versions. If ASP.NET Core 2.1 targeted .NET Standard 2.1 then .NET Framework support is dropped again.

Why would it be dropped? Are you saying Span will _never_ exist on Framework?

So what you're saying is we should rename all of the classes in the BCL so we can use them on both .NET Standard.

Woah, no. I'm saying that if I need a Dictionary with a different API, I have to create something else and also not call it System.Collections.Generic.Dictionary, same as you guys already did with Microsoft.Net.*

Yes, HTTP/2 support was added in the last release. There's another team that does work on ASP.NET and IIS and they do make improvements. However, they are not on the same scale as what ASP.NET Core is doing.

That's fair. I was not aware of that.

The latter is what has already been done in most cases in 1.x, right? Is that suddenly no longer tenable?

It creates a mess. They've tried to do that as little as possible. The API design and deployment is so more drastically complicated than most people realize, I think. And it's not the Microsoft guys making it that way, it's the reality of supporting many platforms and timelines. I didn't appreciate this until being in the middle of it several times and talking everything through. I really wish type forwarding was at the method level, though. It'd have solve quite a few cases so far :(

Why would it be dropped? Are you saying Span will never exist on Framework?

It would need to be dropped from ASP.NET Core 2.0, as the timelines wouldn't align anymore, since full framework wouldn't have it yet.

It would need to be dropped from ASP.NET Core 2.0, as the timelines wouldn't align anymore, since full framework wouldn't have it yet.

AFAIK, Spans are part of a netstandard1.x package that can be used on .NET Desktop (it's a portable implementation so it doesn't have the same perf' boost as if it was backed into the CLR, but it's likely good enough).

Edit: the System.Memory package has a netstandard1.0 TFM, so it can be used even on .NET 4.5.

The latter is what has already been done in most cases in 1.x, right? Is that suddenly no longer tenable?

We halt feature work in certain directions today because of it. It's intentional and we hold ourselves back and refuse to use new APIs by copying and re-implementing things outside of .NET Standard so that .NET Framework can work. This isn't all things but there are some fundamental pieces that we would like to touch going forward, after all, we (Microsoft) control both sides.

Why would it be dropped? Are you saying Span will never exist on Framework?

Span itself has a portable version that runs anywhere, I'm not sure the fast implementation will ever be on .NET Framework. The APIs that will be added to .NET Framework that take advantage of Span may take a lot longer than Span itself, it's extensive. When's the last time we changed string and array in .NET Framework?

Woah, no. I'm saying that if I need a Dictionary with a different API, I have to create something else and also not call it System.Collections.Generic.Dictionary, same as you guys already did with Microsoft.Net.*

That's exactly what you are suggesting. We don't want to have a Microsoft.Extensions.Collections.Generic. We try out best to avoid that and we live with the old APIs and polyfill where possible (https://github.com/aspnet/DependencyInjection/blob/139d91e57dd31fcd5c6ddaf11ad1f771b5855807/src/Microsoft.Extensions.DependencyInjection/Internal/ConcurrentDictionaryExtensions.cs). This isn't sustainable and it means .NET Core doesn't get the benefits because we actively avoid using it.

@PinpointTownes having spans isn't good enough, they need to use them in methods calls to existing types. That's when the class-level type forwarding comes into play and causes many problems.

@0x53A

That's fair. Can you tell me why popular libraries on NuGet don't drop support for older .NET Framework versions that are clearly out of support? The most popular libraries target net20, net35, net40 etc. Why would it suddenly be ok to require the highest version of .NET Framework to keep using ASP.NET Core? Do you think that would be reasonable?

This is a show-stopper. I have to consider cancelling migrations from ASP.NET MVC 5/Web Api 2 To Core. Many stable frameworks are not yet available for core. We are still using EF6.x because EF Core is not mature enough Feature Comparison.

@PinpointTownes having spans isn't good enough, they need to use them in methods calls to existing types.

"need" is probably a bit excessive. Spans are mainly used for performance, so nothing prevents them from using the existing not-super-perfy overloads on .NET Desktop using ifdefs until .NET Desktop gets native support for Spans.

@davidfowl I think the big issue is emotional. If you target netstandard, I know that I will be able to upgrade from 1.x to 2.x eventually (even if with a delay). Most of the time, updating netfx is not that big a deal for an application (different for a lib).

But some apps will never be able to make the jump netfx -> netcore, so if you target netcore, they know they are in a dead end with 1.x.

In that regard, it would have been better if Asp.net core had never run on netfx, as it stands, they expected that to continue, and now feel (rightfully, IMO) betrayed. After all, they may have already invested a lot of time into this.

I'm not personally invested in this, because I'm not a asp.net user, my big question is actually just

I assume that the plan is still that full-fx will catch up to netstandard, even if with a long delay?
(and if no other platform except NET Core is expected to implement .NET Standard 2.1, then why even have a .NET Standard?)

Regarding other libs targeting net20, net35, etc, in my experience most authors try to target the lowest version they can and only cut platforms where they have no other choice.

And __yes, I think it is reasonable to drop support for older versions of .NET Framework__, because there is still a clear migration path available. Just update your version. Most of the time you don't even need to change anything, "just" recompile and test.

I think you guys seriously underestimate the number of apps that will never be able to target netcore - just a single closed-source third-party dependency is enough to block that.

Span itself has a portable version that runs anywhere, I'm not sure the fast implementation will ever be on .NET Framework. The APIs that will be added to .NET Framework that take advantage of Span may take a lot longer than Span itself, it's extensive. When's the last time we changed string and array in .NET Framework?

@davidfowl I think this is maybe part of the problem. I've honestly been playing devil's advocate a bit here, because we're stuck in the middle as a greenfield app that started just before .Net Core was a thing, so we're straddling the line.

Our thinking has always been, use the fancy new libs (such as Kestrel) if at all possible, but wait for .Net Core to stabilize (and I'm glad we did, if only for the tooling changes), _or_ wait for the cool Core bits to make it back to Framework. I think most people's assumption has been that most, if not all, of the advancements corefx has been making would make it into Framework vNext or vNext+1. But, it looks like (from our 30k foot view) from this and other changes that Framework is not a platform of the future.

I suppose if that's how it is, that's how it is. Our project is massive, so trust me when I say that I do understand the pain of having a bunch of custom impl's of things that are close to but not quite BCL types or ifdef spaghetti. So, I'm not suggesting things out of ignorance of the complications. There are definitely tradeoffs.

Indeed a good question: what's left of the backporting of .net core features to .NET full? As I read here, .NET full is so brittle, moving code to it takes ages (it moves very slowly) and can break at any moment (could be, no idea how intertwined it is) so I then conclude that won't happen very often.

It can't be both: either backporting to .NET full is OK, they just release less often (e.g. every 6 months to a year) or it's very complicated and error prone. If it's the former, just pick up the pace and don't let your users pay the bill and stop using the latter as an excuse. If it's the latter, isn't the right conclusion then that netstandard is a fallacy, as all that matters for the future is .netcore's API anyway?

I'm seriously concerned of the future of .NET's direction. My company builds tooling for .NET full and .NET standard1.6. The last thing we want is that the driving force of the direction of .NET (the new features which are about to be backported to .NET full, as said in the .NET core announcement all those moons ago) splits things and the ecosystem effectively gets split in half, as fragmentation is killing.

Nothing in this thread has reassured me things are OK for the future of _all_ .NET and the ecosystem that's needed to make it stay alive: I only see two groups:

• People who are concerned that options are getting complicated and they have a tough problem ahead
• Microsoft who sees one road ahead: the .net core road.

These two don't match at the moment. Can someone from Microsoft please get a coherent story out so we all can see what is the real deal, how things really are, i.e. with the backporting of features to .net full, what is done about the missing myriad of stuff in .net core (sqlserver stuff, transaction scope to name a few) and how Microsoft thinks they can sell this new direction as a solid, reliable, dependable platform for the future, so corporations and large teams can choose it without worry.

While I agree that all of this is a good thing in the long run, I also think that dropping support for the full framework with 2.0 is too early.

We'd like to move to .NET Core as soon as possible, but unfortunately, our biggest blockers right now are almost exclusively Microsoft libraries (E.g. Entity Framework Core is not good enough yet, Azure Service Bus only has a very early preview).

While I hope that the Azure libraries will be ready in the next weeks/months, it doesn't seem like EF Core will have enough features anytime soon.

I don't know anything about the internals of EF6 but wouldn't it be possible with reasonable effort to have it target netstandard? This would remove a huge blocker...

"Just staying on 1.x" doesn't seem like a good alternative because there'll surely be lots of libraries that don't care (or don't have the resources/knowledge to support both) and just upgrade their dependency to 2.0

PS: I'm very frustrated with how complex the .NET ecosystem has become over the last few years. I've had to spend A LOT of time to understand all of the new stuff and I don't see how a new developer should understand any of this. There's sooo much outdated information on the internet now due to all of these quite extreme breaking changes.
Also, all the different product versions (.net core, sdk, .net standard, ...) are extremely confusing. I've yet to see someone who understands the .NET standard table without needing a 20 minute explanation. 😞

anyone who was using .net core with the full version of the .NET framework just got screwed and need to go back to MVC 5

Yep. I understand the reasoning, and I suppose I could say I should have seen this coming, but it's very frustrating to have this dropped on us with no prior warning.

We have an application ecosytem, like many others, with shared libraries dating back a decade and more, multiple MVC 3, 4, 5 apps, console apps, windows services, hundreds of thousands of lines of code. We're not even in that bad of a situation to upgrade compared to some.

We recently stood up a couple new web apps using ASP.Net Core 1.1, necessarily targeting the full 4.6.2 framework. These apps use large swaths of our existing shared libraries. We've burned an embarrassing amount of dev time dealing with project.json, then the new .csproj, trying to mix old and new .csproj's in the same solution, dropping back to VS15 to get things done with old .csproj types, broken System. dependencies, and a litany of assembly binding problems, build & publishing issues.. the list goes on and on.

And now we've been left hanging high and dry in a dead end. Do we throw away a few man-months of development or spend many times that trying to first just ascertain what might and might not work and then figuring out any way to upgrade, and then if that's even possible doing it.

I can't say I disagree with the direction and necessity of it, but earlier communication would've been appreciated.

Oh, and of course, the Azure Service Fabric libraries don't run on .NET core either - which is another blocker for us.

I'd say you should support the full .NET framework until you can deliver a proper .NET core story within Microsoft (and especially Azure).

@cwe1ss This change will reduce some of the complexity of the .NET ecosystem though. Since you will not have two different formats (ASP.NET Core + .NET Full and ASP.NET + .NET Core). I totally agree about the outdated information but I think that can't be avoided when you develop in the open like Microsoft does now.

@davidfowl

The code sharing story across different .NET runtimes is .NET Standard. Your libraries should try to target that to code shared across .NET Core and .NET Framework.<

But the full framework as I understand it doesn't even support.net standard so it's really not a useful standard.

Microsoft seems to have forgotten the importance of backward compatibility.<<

The problem is, ASP.NET Core was never meant to be backwards compatible... That why there was such a big paradigm shift from ASP.NET 4.x. Seems like if backwards compatibility is the high order bit for you'd be better of using ASP.NET 4.x on .NET Framework. That is supported for the forseeable future and will be security patched for as long as Windows is alive.<

Security patching is only part of the issue. The web standards change so quickly that we need to have something that we can use the latest standards with. So for example I saw somewhere above something about HTTPS v2. I have no idea what that means in practice but the point being is that I want my framework to be able to support these things. If I am forced stay with an older version of the framework whether it is v4 or v1 it's not going to support the things that are required.

ASP .net Core was always marketed as running on both .net core and on the framework. As others have said, it doesn't bother me if we have to wait six months or a year until the framework catches up. I'm normally about six months or more behind anyway. But what seems to be happening is that our existing investment is being completely abandoned, like so many other Microsoft technologies that many of us have invested time in.

Stefan

@Rutix for "developing in the open" this major breaking change was done suprisingly silent without any announcement nor survey (after all, this issue was created by a community member watching pull requests).

Doing things silently has bitten microsoft in the past and they don't seem to learn. And don't even try to tell me that they couldn't see that dropping full framework support would perturb the community and hurts the faith and investment in the platform.

Last incident was https://github.com/dotnet/roslyn/issues/17054 but they quickly corrected it, i'm wondering how this will go over.

But the full framework as I understand it doesn't even support.net standard so it's really not a useful standard.

@stefanolson That is not correct. Libraries targeting .Net Standard 1.x can run on various full framework versions today. Libraries targeting .Net Standard 2.0 are slated to be able to run on 4.6.1 last I looked.

@Suchiman I am totally agreeing with you there. I am a bit disappointed that they don't seem to learn how to communicate and stuff dropping bombs on the community. They could have handled this way better if they announced it first and had a community discussion.

But the full framework as I understand it doesn't even support.net standard so it's really not a useful standard.

@stefanolson It does. Different (existing) versions of .NET Framework implement different versions of the .NET standard. See https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/

I know I'm a bit late to this thread but here are two of our use cases for using ASP.NET Core on NetFX on Windows:

Using ASP.NET to host a REST API for your application

Our application is a ".NET API-turned into-REST API" kind of application. It first shipped as a .NET API, and has dependencies into all kinds of Windows stuff.

When we added a REST API, we choose ASP.NET Web API to host it. When it became clear the Web API was unifying in ASP.NET vNext/5/Core, __and__ we figured out that __ASP.NET Core would run on NetFX__ it made sense to use ASP.NET vNext/5/Core.

While we take advantage of .NET Core to port (part of) our application to Linux and macOS, there still are Windows-dependencies that don't run on .NET Core (to get a list of dependencies that we did port, check the CoreCompat.* NuGet packages).

So long story short, we now find ourselves locked on ASP.NET Core 1.x which will remain support for about a limited period of time. And then what? Back to ASP.NET 4?

I understand all the perf work you're doing and pushing boundaries in other areas of .NET Core, but in my use case, I'm not hosting a high-volume internet-exposed website, I'm hosting a REST API which will get like what, 10-20 RPS max?

Visual Studio support

Really, my Visual Studio 2017 experience on NET 4.x is still much better than .NET Core - a good example there is the amount of time it takes to re-compile a test project and have the new tests show up in the test window. It's a lot faster on NetFX.

We end up with a situation where today we have a NetFX and .NET Core project side-by-side compiling essentially the same codebase. The only reason we keep up with this dual maintenance is because of Visual Studio's performance with .NET Core projects (_especially_ unit tests and the debugger).

As an afterthought, what really strikes me is that this change is made now, a couple of days before the preview release. It just seems to indicate that there is no technical reason to do it yet - so why not make the change in ASP.NET Core v3?

@mattnischan

@stefanolson That is not correct. Libraries targeting .Net Standard 1.x can run on various full framework versions today. Libraries targeting .Net Standard 2.0 are slated to be able to run on 4.6.1 last I looked.<

It appears to me as though asp.net core is going to run .net core not .net standard? So I'm still not sure of what the point of the .net standard is - if it gets abandoned virtually as soon as it gets created.

It would totally make sense if asp.net core required .net standard 2.1 because there are things that they need that are not in the framework at the moment. So we had to wait till the full .net framework supported those additional functionalities before we could use the latest version of Asp.net core. That would work and make sense.

But instead they are just abandoning the standard making the standard useless (if I'm understanding this confusing situation correctly)

So... its Build 2017 starting tomorrow; I imagine the team are very busy preparing for it. Maybe some announcements, maybe not. Perhaps, give them a bit of breathing room and reconvene in a week?

Maybe catch the show https://build.microsoft.com/ (Wed 8:00 PST, 15:00 GMT and Thurs similar?)

We may know more; may not. Things may be clearer, may not. However, the ASP.NET team will likely be able to respond a bit better and focus on everyone's concerns more. Though @davidfowl has been doing valiantly!

@stefanolson But instead they are just abandoning the standard making the standard useless (if I'm understanding this confusing situation correctly)

I think the point of .NET Standard is compatibility. Library authors can target .NET Standard and then anyone can use it, whether they're on .NET Framework, .NET Core, or something else that supports .NET Standard.

I think the point of .NET Core is a re-imagining of .NET Framework. .NET Core is cross-platform, high performance, open source, and rapidly evolving.

Changing the implementation of string to utf8 by default is massive and not something you would ever expect to see on .NET Framework.

After reading this thread, I feel:
.NET Core -> .NET Framework is like ASP.NET MVC -> WebForms.

I'd like to second the tooling aspect as well. The current restore/build/test etc. performance is very bad and a royal pain. If we had to "stay on 1.0" would we still be able to use newer SDKs with (hopefully) better perf or would we be stuck with a 1.x SDK?

The .NET Core story is a wonderful tour full of ups and downs. We just recently started working on ASP.NET Core because of all the previous "fuck ups" (versioning, naming, project.json - .csproj transition) and I was (and I am) looking forward to .netstandard 2.0, because I think this will be the first "real" release.

I get it that ASP.NET Core 1.1 is still supported and will run the next 10 years, but you guys are super brave to move __that__ fast and cutting one of the earlier selling points of ASP.NET Core.

If you want to know what is a blocker (besides directory services) from our side: We are still using EF6 and still wait for an official Open XML SDK NuGet package that targets netstandardwhatever.
Migrating code might take a very long time...

Would it be possible to formalize some sort of process for pushing forwards netstandardXX based on changes that happen in Core which involves targeting it as part of a maintenance phase of Asp.Net Core library release?

As it stands, I have a WebForms/MVC app that we were about to pull a trigger on exposing a ANC web api to and call from a SPA (and ultimately from the WebForms legacy app), but we cannot dev on the CoreCLR because of a dependency on Sybase (now SAP) Ase ADO.NET driver (if someone reading this could push on a button somewhere at SAP ... I sadly cannot seem to get heard at all on this or on bugs that I have known about for over 9 years now).

Reading this issue, I'm not so sure anymore what my path should be. The only thing I am confident I can plan on is a buggy driver will continue to exist for the desktop framework. Was I supposed to ignore the changes to ASP.NET over the past several years because they were going to be a waste of my time and I should just target WebApi2? Am I supposed to say go ahead with ANC 1.x under the knowledge that I'll likely never migrate and see benefits of 2.x in an application I believe will be supported here for the next 10-15 years (the WebForms app has been migrated and maintained since the 1.1 framework was released)?

@davidfowl

Span itself has a portable version that runs anywhere, I'm not sure the fast implementation will ever be
on .NET Framework. The APIs that will be added to .NET Framework that take advantage of Span may take a lot longer than Span itself, it's extensive. When's the last time we changed string and array in .NET
Framework?

Wait, what?

Not all of us are web developers. We've been eagerly awaiting better string handling support for years and now all of a sudden you are telling us that we're SOL? That the .NET Framework and the countless non-web applications built on it will never get access to string handling libraries based on Span?

This is no longer just a ASP.NET issue. It goes to the heart of Microsoft's long-term commitment to .NET Framework and its base class library.

You know, I really have to give it to people like @davidfowl for continuing to respond to everyone and to everyone for contributing to this discussion. I have a lot to catch up on from earlier today, but I feel as if I'm learning a lot through each comment in terms of what everyone is using/hoping to use .NET for.

I think we'll eventually get some path(s) straightened out with everyone's help and I hope that all sides are taken into consideration.

I'm eagerly awaiting the official announcement

If I understood it right, netcoreapp2.0 will provide a compatibility shim that will allow our ASP.NET Core 2.0 projects to depend on our legacy NetFx class libraries (e.g., net461).
Where can I find more information about the currently planned capabilities/limitations of such compat shim?

@dgaspar That's not really accurate, here's how it works: netcoreapp2.0 supports most of the APIs in net461. If your library is built for net461 and only calls the APIs that exist within the subset that netcoreapp2.0 supports, then you can import the library anyway (think of it as overriding, that you know better) and make it run, since all the classes and methods it calls should be there.

Now there's also a downside: if the methods aren't there or aren't fully supported in some way, you get runtime errors for missing methods, etc. So compile-time checks aren't a good assurance there. It's a bit of a double-edge sword to be aware of, but there for some libraries that will never be updated yet are just fine with the set of APIs they call.

@NickCraver anyone remember...

"imports": [ "dnxcore50", "portable-net45+win8" ]

A related comment I made in December. 11 thumbs up carried forward:

Something is off the rails here. I've been shipping C# apps for 15 years. Ironically as higher level abstractions are being shipped by Microsoft I'm spending more and more time digging deep into internals I never previously had to worry about. YOU'RE DOING IT WRONG.

If I wanted to be surprised at runtime by random library and package-management induced errors that the compiler didn't catch, I'd write my apps in Ruby.

even node.js allow us to easily call all netfx libraries.

the mvc code is really the easy part. it may take a few weeks to rewrite in node.js or nancy, but it will take much longer to port business and algorithm code, and prove it works as solid as the old one. not to mention the case when we do not have the source.

take the RyuJit example, even after release to production, blocking major bugs were found and it took another year to fully resolve. same for our software, which are not pet shops but industrial tools which help making million dollars a day.

the UI framework changes fast, from winform to web. but core business logic/algorithm are much more stable and long lived. so, to use the new shiny UI framework, we need to rewrite/retest or abandon our business/algorithm code? no, we known the new shiny one will be replaced by something more trendy in 5 years, but our business/algorithm code will continue being used.

@qmfrederik

As an afterthought, what really strikes me is that this change is made now, a couple of days before the preview release. It just seems to indicate that there is no technical reason to do it yet - so why not make the change in ASP.NET Core v3?

We're doing HTTP2 support next and it requires new APIs.

I'd like to second the tooling aspect as well. The current restore/build/test etc. performance is very bad and a royal pain. If we had to "stay on 1.0" would we still be able to use newer SDKs with (hopefully) better perf or would we be stuck with a 1.x SDK?

Yep, that will work.

@davidfowl

We're doing HTTP2 support next and it requires new APIs.<

So the kind of HTTP2 support that will be available in asp.net core 2.0 won't be available in 1.x? This is really the kind of problem that I worry about where we won't have access to the latest technology because we are bound to the full .net framework for whatever reason. As I've said above doesn't matter if it takes six months to a year for that filter through to whatever I'm using but ultimately don't want to be too far behind. Due to codesharing and third-party library usage at this stage I need the full .net framework.

at last, i clarify a few things:

• when i say legacy modules, they are dlls depending on netfx or c++/cli dlls, which in turn may pinvoke some native dlls. they are for business/algorithm, no COM, no asp.net. they are not bad. they become legacy mainly because .net core does not run them.
• it is possible to migrate to net core in the long run, and we really want it. but it is really hard to push that to happen.it will take a few years for us and 3rd parties to be all there.
• the domain specific libraries is much slower than mainstream libraries for tech stack changes. we all know the python 3 example. those domain specific libraries are real business.

@danielcrabtree

I think the point of .NET Core is a re-imagining of .NET Framework. .NET Core is cross-platform, high performance, open source, and rapidly evolving.<

Which is fantastic. The challenge is how deal with the existing code bases and how do we get those usable with .net core. If WPF was available built on .net core then I could use .net core everywhere. But as it isn't and my code is shared between WPF and ASP.net I need a way to share them. But I don't want to be too far behind with the latest web technology and security techniques most (all?) of which sounds like will only be in 2.x and later

A few times in this thread and in documentation elsewhere .NET Core is described as cross-platform. This was advertised as one of the major selling points for moving to the platform.

This does not seem to be the case however as clarified in this conversation on Twitter

https://twitter.com/James_M_South/status/861595907782987776

And the comment above; emphasis mine.

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.

I've been working very hard with .NET Core since very early on trying to fill the gap left behind by System.Drawing with ImageSharp and I am now left both very confused and more than a little disgruntled and asking:

What even is .NET Core now?

Here's the description from the MS Docs.

.NET Core is a general purpose development platform maintained by Microsoft and the .NET community on GitHub. It is cross-platform, supporting Windows, macOS and Linux, and can be used in device, cloud, and embedded/IoT scenarios.

There's that cross-platform statement again. Is it or isn't it? I think trying to pin this down leads to much confusion across the development community.

Every description I read seems to be different.

Can we:

1. Please get a decent, consistent, message written down somewhere so that we can actually have a target to aim for and a better overall understanding.
2. Get some clarity delivered on the actual roadmap for System.DirectoryServices, and System.Drawing

System.Drawing in particular is both confusing and concerning. I cannot fathom why you would ever want to port that API to .NET Core on any platform. It's difficult to work with, unsupported on the server, and lacks many critical features required for modern development (Multi threading, Pixel Formats, ICC, EXIF, Quantization, Indexed Png and so on).

There are a lot of recognizable names and faces here, and I know I'm just adding some noise here, but:

• DirectoryServices
• Drawing (not that I need it)
• EF

These seem like the three most critical things to have up to speed before making such a large break. Personally, most everything I work on is on net4x solely because of EF6, since EFCore... well... :trollface:

@stefanolson
I think you're expected to separate out the shared code into a .NET Standard library. Then it will be usable from WPF and ASP.NET on .NET Framework and from ASP.NET on .NET Core and other .NET Core applications.

@JimBobSquarePants
I don't think Windows compat pack is part of .NET Core. It's a Windows specific library that sits on top of .NET Core. You could imagine there being a Linux specific library that exposed Linux-only features.

I think the Windows compat pack is about making it simpler to migrate existing .NET Framework code bases. Obviously, once someone has switched to .NET Core, they should then look at migrating to better solutions like ImageSharp.

@stefanolson
It's possible they could even create a Windows-only WPF pack that let you create WPF applications in .NET Core, but which would only run on Windows.

This GitHub issue has been mentioned on a German IT news site:
https://www.golem.de/news/asp-net-core-2-0-microsoft-veraergert-net-entwickler-mit-support-entscheidung-1705-127712.html

Thanks @danielcrabtree that's the first I've heard of any compatibility packs.

Translation for @MJomaa's link: https://translate.google.com/translate?u=https%3A%2F%2Fwww.golem.de%2Fnews%2Fasp-net-core-2-0-microsoft-veraergert-net-entwickler-mit-support-entscheidung-1705-127712.htm

I'm waiting on System.Xaml to be ported over.

@alexwiese don't hold your breath.

I'm waiting on System.Xaml to be ported over.

Go on; I'll bite. How are you using Xaml on your website?

Go on; I'll bite. How are you using Xmal on your website?

Cross platform UI (screen templates shared between a "green screen" console application, Xamarin app, and an Angular SPA), also used for a business rules engine.

Wow, ok so you are transforming the XAML's XML in some way to HTML and Javascript? Fair enough 😄

Wasn't sure if you were just trolling.

I'm doing the same, but realistically I don't see them porting XAML over, considering that at this point it cannot be parsed without also being executed.

Wow, ok so you are transforming the XAML's XML in some way to HTML and Javascript? Fair enough 😄

Of course not; I'm converting to JSON first 😉

Another news article about this topic with many of us being quoted: https://www.infoq.com/news/2017/05/ASPNET-Core-2

@cwe1ss The author is @Grauenwolf

@alexwiese @yaakov-h I'd love to read a blog post about that; sounds pretty interesting and must come with a different set of challenges than I'm used to.

This is really bad. ASP.NET Core was a reasonable sell when you could leverage legacy libraries when needed. In the case where it can be done with the new stuff, tweak a few things and target .NET Core. Otherwise, just target the full framework.

With this change, it's an all or nothing jump. And given that you don't always understand all the dependencies up front, it magnifies the risk.

I understand the desire to move fast, and evolve where things are bound to go anyway, but you're going to leave your users behind. People tend to migrate, not jump. A large number just won't move off the current. And then when they do, they might well move to a different platform entirely. Seriously, you're underestimating that risk.

This is a move that should eventually be made, but more like late 2019, or 2020 at the earliest. Even then, you still want a long term model for supporting those who have chosen to mix things.

And no, ASP.NET Core 1.x is just not an answer there. It's immaturity is fine as a transitional phase with an easy migration path forward, but it's not suitable for living with for the long term. There's a big difference between the mindset of those who develop a platform like this, and those who use it. Please reconsider this direction.

@davidfowl What about something like edge.js for netcore? It makes the API consumer responsible for platform checks and a strongly typed interface between netfx and netcore is sufficient for most scenarios.

Will this template be removed then?

It's baked into VS2017 at the moment.

what a totally unacceptable bulshit, again this proves it is a toy technology not ready for prime time and wide adoption.

I really appreciate guys you have a nice ride and coding experience, you can shine in your blog entries and twitter (hoorrray!), improve your linkedin profiles and cvs (hooray^2), all release parties ahead of you, girls, drinks and stuff looks promising, but .. who is going to use it? do you target enterprises and want large adoption and solid user base? or some startup hippies only?!?

That comment about "full Span" potentially never making it into .NET Framework is seriously concerning to me. If full Span is not in .NET Framework then I assume APIs using it can never make it into a future netstandard, which makes it impossible to write cross-platform libraries that use or expose high performance parsing? Which means we're stuck with our unsafe custom implementations permanently effectively...

You mention that if you want you're library to be cross-platform then you should target netstandard, but what is ASP.NET Core if not a library that is widely used? Would you recommend other libraries start dropping support for netstandard and switch to .NET Core? Should the next major version of JSON.NET or whatever drop netstandard? It could certainly do with fast parsing!

Note Java managed to add fast IO with zero copying etc in a backwards compatible way with Netty (https://netty.io/)

Finally I do want to say thank you to the people who are willing to hang around and answer these. We do appreciate the answers...

@shanselman Moving fast is a noble goal, especially for for teams that put paramount amounts of effort into compatibility and designing things in a compatible fashion, like the ASP.Net Team. I know how much they would like to simplify their problem domain, and I support that, but ...

Moving fast and at the same time "also away" from your customers is not a good thing either. You know, your customers (me included) have a serious set of legacy software and time investment into existing apps and libraries. You can't just leave us behind and go to a place where we won't/can't follow.

You should consider your customers who can't go to .Net core and must use Full Framework for at least some more time from now. If you move away from Full Framework, you leave allot of people stranded on older versions and create big split in the .Net world.

@JimBobSquarePants I second you on the System.Drawing part. There are some discussions in the other repos about brining System.Drawing back. Based on some of the comments in this thread, I understand there will be a "compat pack" on Windows first and then on all OS-es for System.Drawing.

I wonder what that will look like, and whether it will be based on Mono's libgdiplus or not (which would remove some of the concerns you have with System.Drawing, but that's another story)

Okay, the way I see it, there are a couple of issues at stake:

1. This was communicated rather poorly.
2. People weren't involved in the decision. Note that Microsoft is of course free to choose the direction they like, but not discussing this type of large change with the community is not in the spirit of open-source development.
3. There is no "grand scheme" that the community can use to examine these types of decisions. At first, .NET Core was a trimmed, cross-platform version of the full framework. Then, with .NET Standard 2.0, it appeared to many that .NET Core 2 would be like a drop-in replacement of the full framework, within reasonable limits of course (no UWP, WinForms, etc.).
4. .NET Core 2 will miss out on several important pieces of functionality that are in the full framework, like System.DirectoryServices. As far as I can tell, this has been acknowledged, but perhaps the road to getting these features added to .NET Core could be made more explicit.
5. ASP.NET Core 2 will not run on the full framework due to the full framework missing newer features. I'm actually totally okay with this. If adding the missing features to the full framework is excessively hard, then don't. Having ASP.NET Core 2 only run on .NET Core 2 actually makes quite a bit of sense, although mentioning them as being one product was probably not the best way to describe their relation.

What I think people would really like to see is a description of the vision of the .NET platform. Which direction will things go in? Will the full framework just receive bugfixes and such but no new features? What is being done to add missing features to .NET Core and when can we expect them? Having this explained would hopefully go a long way in easing the anxiety people are feeling now.

@davidfowl I guess it's not just about HTTP 2.0; if it's really about HTTP 2.0, couldn't you have ASP.NET Core 2.0 target NetFX with the exception of HTTP 2.0 support? Perhaps even a pluggable model so that the community could do HTTP 2.0 on NetFX if they really wanted?

@cokkiy @popcatalin81 @xprzemekw If you have nothing constructive to say, please refrain from commenting, these kinds of comments are not helping anyone.

There are legitimate reasons why make the move described by @davidfowl https://github.com/aspnet/Home/issues/2022#issuecomment-300141134

Reasons why postpone it include (say asp.net core 3.0):

• EF Core is not yet ready to replace EF 6.0 due to many features missing
• no production ready System.Drawing replacement
• no System.DirectoryServices
• there was mention of office xml sdk, but that seem to be already available on netstandard as of 2017-05-01 https://www.nuget.org/packages/DocumentFormat.OpenXml/
• other packages outside of MS scope unavailable on .net core (nhibernate, various db providers, ikvm)

Reasons why not do it ever include:

• People ported apps to asp.net core with legacy dependencies with no intention to move to .net core.
• Worry about leaving netstandard behind and not caring much about it.
• Some 3rd party packages are unlikely to be ever ported to .net core (which arguably makes them obsolete, but that might be just my opinion)

Example of constructive comment would be adding your reason why you'd like to see one of these three scenarios or suggesting alternative solution. If you just want to express agreement/disagreement use the "Reaction" buttons.

@Kukkimonsuta

People ported apps to asp.net core with legacy dependencies with no intention to move to .net core.

Completely agree. Because Microsoft had announced that ASP.NET Core will work on both .net core and .net frameworks. And now leaving them in AspNet Core 1.x is not fair.

The last summary is quite good. I'd just like to add a thing or two:

1.) It should be possible to write Windows Services with .NET Core (I know that daemons on *NIX platforms work differently). So the ServiceBase would still be needed, and this is high priority together with EF.

2.) It should further still be possible to write standalone services with .NET Core, and additonally host them within your existing, full-framework based .NET application (i.e. complimentary service from your Windows Forms / WPF app) to extend them.

The latter really is required for slow migration scenarios, where its not possible to make a hard cut and start greenfield.

Completely agree. Because Microsoft had announced that ASP.NET Core will work on both .net core and .net frameworks. And now leaving them in AspNet Core 1.x is not fair.

I also like to stress again that the huge change back to .csproj and msbuild was mainly excused with the fact that it would not be possible to reference (ASP).NET Core projects from your existing (full framework) .NET projects.

This change makes the latter impossible (at least for the biggest ASP.NET part). So why was compatibility paramount back then (and caused a lot of pain), but isn't now (and again causes a lot of pain)?

sorry i have to stress, too. But almost 500 comments, i belive if i am involved as a microsoft guy for this issue i had two options:
1: mute the issue
2: rethink about my decision

@gingters The csproj change was primarily for _.net_ core though, in order for xamarin, asp.net, uwp and all the other to share code and also reference other project types like native code.

Also, it enables asp.net core 2 projects to reference full framework projects, again, via the compat shim

@qmfrederik

Perhaps even a pluggable model so that the community could do HTTP 2.0 on NetFX if they really wanted?

They technically could. But it seems they don't want to. To me it feels they just don't want to think about the real needs of enterprises / large businesses, or about backwards-compatibility or the need to cope around with something else than greenfield stuff.

And to be frank, the expectation management in the past completely targeted businessed that want to slowly extend / migrate their stuff to cross-platform, while also being able to slowly extend / migrate their existing apps over. So this move is completely unaligned with the previous expectation management.

@aL3891

in order for xamarin, asp.net, uwp and all the other to share code

Yes. Exactly. And that also includes WPF/Windows Forms app to consume .NET Core libraries, which is now impossible when you want to go on to .NET Core 2.

Could someone explain exactly why the hell these libraries can not target netstandard2.0?

Until now, I have considered netcoreapp as a moniker for a cross platform executable (only used in a csproj executable project), but I never considered it as a platform, now, it should be considered as a real platform? Why why why, and how did we come to this absurd option?