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

[kevinchalet]

Edit: the "no .NET Framework support for ASP.NET Core 2.0" plan has been officially cancelled and running ASP.NET Core 2.0 on .NET Desktop will be supported in the next previews. For more information, read Announcing ASP.NET Core 2.0.0-Preview1 and Updates for .NET Web Developers or watch .NET Standard 2.0 and .NET Core 2.0.

I'd like to thank everyone for taking the time to participate to this thread ; no doubt it helped make the Microsoft heads realize that they couldn't silently adopt such a major breaking change at the last minute without consulting their community or measuring the actual impact of their unilateral decisions on the entire ecosystem.

Even though we all had different opinions, the most important thing was to have a real discussion about this change. It's clearly a huge - and unprecedented - success (>150 participants and more than 700 messages, woot!)

It's amazing to see such a great community in action, I'm so proud of being part of it :call_me_hand:

---

Original message: earlier today, most of the ASP.NET Core 2.0 packages were updated to target netcoreapp2.0 instead of netstandard1.* and net4* (e.g https://github.com/aspnet/Security/pull/1203 and https://github.com/aspnet/Mvc/pull/6234), making them totally incompatible with .NET Desktop and Mono.

Although this major breaking change is likely to have a huge impact on the entire ASP.NET ecosystem, it was neither discussed nor announced publicly (demonstrating once again that the ASP.NET team is not very good at communicating and is not really willing to discuss such important changes with its community, but that's another story).

In this thread, @Eilon partially mentioned the reasoning behind this decision, but didn't say whether less extreme options have been considered or not (e.g cross-compilation, introduction of a netstandard2.1 TFM, etc.):

Yes, for ASP.NET Core 2, most of the libraries will target .NET Core 2 in order to use new APIs that are not yet available in a .NET Standard TFM. Code that needs to target multiple platforms, such as Microsoft.Extensions.*, Entity Framework Core, and a few other libraries, will continue to use .NET Standard.

My question is simple: are you going to amend/revert these changes at some point before RTM, so people can use the ASP.NET Core 2.0 packages on .NET Desktop, or is ASP.NET Core 2.0 on .NET Desktop definitely dead? (which would be a major blocker for many people, including me).

Thanks.

[gulbanana]

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.

[ctolkien]

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?

[MJomaa]

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?

[aL3891]

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?

[gulbanana]

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

[aL3891]

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

[gulbanana]

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

[nphmuller]

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

[NickCraver]

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.

[shanselman]

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.

[mythz]

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?

[NickCraver]

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

[daveaglick]

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.

[kevinchalet]

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.

[DamianEdwards]

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

[kevinchalet]

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

[DamianEdwards]

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

[ap0llo]

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

[DamianEdwards]

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

[daveaglick]

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

[DamianEdwards]

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

[NickCraver]

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.

[kevinchalet]

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

[davidfowl]

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

[NickCraver]

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

[khellang]

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

[DamianEdwards]

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

[dasMulli]

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

[adamhathcock]

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?

[davidfowl]

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

[NickCraver]

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

[khellang]

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

[jhurdlow]

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

[dasMulli]

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

[aL3891]

@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

[DamianEdwards]

@khellang paging @terrajobst for the Portability Analyzer question.

[terrajobst]

@khellang

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

[davidfowl]

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

[kevinchalet]

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?

[NickCraver]

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

[davidfowl]

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.

[kevinchalet]

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)

[davidfowl]

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.

[kevinchalet]

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?

[davidfowl]

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

[kevinchalet]

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.

[NickCraver]

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

[DamianEdwards]

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

[kevinchalet]

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.

[ctolkien]

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.