Aspnetcore: Discussion: ASP.NET Core 3.0 will only run on .NET Core

I think this makes a lot of sense in the overall picture now. Both .NET Core and ASP.NET Core have been around for long enough by now that people already had or still have the chance to switch to it, without causing huge issues (compared to when the support was first dropped in the past with 2.0).

However, I am sad about the implications though for certain components of ASP.NET Core that can currently exist as separate dependencies. Because this will probably mean that the individual components will drop netstandard support, requiring netcoreapp3.0 instead; and especially with #3756 those components would be unusable outside of an ASP.NET Core context.

For example, projects like RazorLight will then effectively be forced to drop .NET Framework and more importantly .NET Standard support in general.

This is going to leave a lot of people who've sold moving to the new ASP.NET Core programming model in their organization to stay on a supported and actively developed platform out in the cold on an unsupported platform in less than 3 years (.NET Core 2.1 LTS).

I'm not sure what analytics you've used to justify this move but for Running ServiceStack ASP.NET Core Apps on the .NET Framework we're seeing that the most popular web-corefx template for running ASP.NET Core project on the .NET Framework is over 1/3 (33.8%) share then the same empty web template which is our most popular project template for running on .NET Core.

IMO 3 years is not enough time to abandon Customers that have started to or have made move to the new ASP.NET programming model (to escape the stagnated ASP.NET Framework platform) only to find out now that the platform that they've sold to their organization to move to has been abandoned.

For whatever reason there are Customers who cannot move to .NET Core due to relying on .NET Framework only dependencies, if MS doesn't want to maintain support for .NET Framework in ASP.NET Core 3.0 in future IMO you should extend the support for ASP.NET Core 2.1 on .NET Framework to an extended period like 7 years. Migrations of existing production systems can take years, since starting .NET Core it's clear the ASP.NET Framework has been left to stagnate with the official stance being that ASP.NET Core is the future programming model for .NET, now the same Customers will soon start finding out that the new programming model that they've move/moving to will be unsupported in a few years. The best way to accommodate these existing .NET Customers is to support .NET 2.1 for an additional LTS period, for security patches at least (ideally for resolving bugs as well).

"killing .NET Framework", episode 2: same story, same characters :rofl:

Sadly, this just highlights one thing: you completely failed to make .NET Standard the front car of the .NET ecosystem. It doesn't move as fast as it should and is nothing more than a lowest common denominator that is always updated at the very last moment, when all platforms include (or are about to include) the new APIs.

Perhaps that's just me, but I've never understood why it didn't move as fast as netcoreapp (which is the first to get the new APIs, by definition).

You're a NuGet package author and want them to use the latest stuff? Target the most recent netstandard version: sure, initially, only netcoreapp-based applications will be able to use them, but eventually other platforms - like Xamarin, Mono or .NET Framework - will catch up and folks will be able to use your packages without requiring you to change anything. That's how things should work.

Of course, it may take a while for non-.NET Core platforms like .NET Framework to catch up as the releases are rarer and the stability bar much higher, but even if it takes 6, 12 or even 18 months, I don't think it's a problem, because that's what people want when using .NET Framework: a stable framework, not a fast moving target.

IMHO, it would be a much better approach to make ASP.NET Core 3.0 target a new netstandard TFM exposing all the .NET Core APIs you need. Once you're sure the new APIs are stable enough, backport them to the .NET Framework so that it is compatible with the latest standard.

I'm sure people would prefer having to wait a few months before being able to move their .NET Framework app to the latest ASP.NET Core version rather than being blocked forever on an old version with a super short 3-year support.

Do what you promised: make .NET Framework a stable framework that evolves slower instead of a dead end for the ones who trusted you when migrating to ASP.NET Core.

I don't like this. At the beginning of .net core , Microsoft wasn't chooce mono or .net framework as a cross platform, and u said there are multiple .net runtime there so u design the .netstandard , now there'r still many nuget package that do not support .net core (mean reason) .Many developer will leave behide in the old asp.net core programming model if asp.net core only run on .net core. then .net standard will exist in name only (at least for asp.net core, people start build netcoreapp only packages ) .
Maybe oneday, .net core can replace .net framework on window, but what about mono , and other platform rely on mono (xamarin,unity3d) .
and another reason for sometime I prefer .net framework is that .net core share framework is really huge, how big is your C:/program file/dotnet folder if you upgrade your app from .net core 2.0 to latest .net core 2.1 ? There GBs file in my folder , and it grows when I update .net core runtime. but .net framework will just replace the old version.

Do what you promised: make .NET Framework a stable framework that evolves slower instead of a dead end for the ones who trusted you when migrating to ASP.NET Core.

FWIW this would be the optimal strategy, my suggestion of extending the LTS is the minimum bar to give more time to existing Customers that have been aggressively marketed to migrate to ASP.NET Core who have now been left abandoned on a future unsupported platform with this announcement.

So .net standard is a joke? Hope mono team will fork aspnetcore repos and rename to aspnetmono,otherwise I may leave .net stack.😔

I guess that this means that at my work we will never use ASP.NET Core. We will stay at ASP.NET forever never mind porting an app to Core because that would now involve even more changes.

Sure, if your goal is to have no changes then you can keep doing the same thing forever. Where I work, we began using ASP.NET Core a couple of years ago, initially running on .NET Framework. Over time, as the .NET Core platform matured and gained features, we switched our projects to netcoreapp. One or two older projects are still using ASP.NET, and we have no plans to rewrite those - it’s working code. But for the newer stuff we’re looking forward to features like Span.

Change can be put off but it isn’t something you can or should avoid forever - technology _is_ change and a developer’s job will always require learning new things. If you’re using ASP.NET Core on .NET Framework today, it’s unlikely to take three years of work to move it to .NET Core.

Come to .NET Core, the water's warm...

For whatever reason there are Customers who cannot move to .NET Core due to relying on .NET Framework only dependencies...

More seriously, you can use .NET 4.x libraries on .NET Core 2.0 since .NET Standard 2.0; though there is the possibility they may use some features that .NET Core doesn't have; although there is the Windows Compatibility Pack for .NET Core that plugs a lot of these holes and many more features are being supported in .NET Core 3.0 including COM interop and other app models like WinForms and WPF etc.

Any blockers preventing an ASP.NET Core application moving to .NET Core from .NET Framework should probably be raised in dotnet/corefx.

For Xamarin; I could be wrong, but I assume its unlikely that you'd use it to run a webserver on iOS or Android.

For Mono client apps the webserver could run out of process and run on .NET Core while the UI runs in Mono. Kestrel has never been able to run on a Big Endian platform which cuts out some of Mono's other platforms though BSD flavours are currently a .NET Core gap.

For Unity; games do all sorts of strange stuff, so maybe that's a scenario not covered; if the game was using the webserver in the client; rather than on a server or out of proc; when .NET Core could run that part.

Outside the ASP.NET Core app model; e.g. for libraries .NET Standard is more important as ASP.NET Core has all sorts of useful features, Razor being a particular example.

Not all the libraries are moving to .NET Core only (e.g. Microsoft.Extensions.* are staying as .NET Standard) and it would likely be helpful to provide specific scenarios that would be impacted as @daveaglick has done in https://github.com/aspnet/AspNetCore/issues/3757#issuecomment-434140416 so they can be taken into consideration; as to which specific libraries and/or features can be kept available on .NET Standard rather than just a nebulous "everything".

ASP.NET Core is driving a lot of changes and new apis in .NET Core and I can understand the desire to then use those features (since that's was one of their use-cases); otherwise its a bit self-defeating.

On the other hand it would be nice if they were also in a .NET Standard version so other runtimes could then support ASP.NET Core 3.0 when they get around to implementing it. Realistically that wouldn't be soon (as .NET Standard 2.1 is not finalised yet and it would need to be a version beyond that).

Perhaps the ASP.NET Core app model will return to .NET Standard at a later date when things have caught up? Though it may always be moving too fast for the .NET Standard process as it currently works?

@gulbanana what if your asp.net core on .net framework using com ? or there's a nuget package that only support .net framework ?

I believe it was never a question of if the move should be done or not, but only when.
Last time this caused a ~discussion~ shitstorm, the ecosystem wasn't ready to allow porting existing apps.
Now there are the windows compatibility packages and WinForms and WPF are coming to .NET Core.

I think that the 2.1 packages being around for .NET Framework provide a good migration path: Migrate to 2.1 on netfx and then on to .NET Core.

This is similar to AngularJS vs Angular: Migrate existing code to components (hard) in the latest 1.*, then move to the latests Angular version. It's super hard but doable.

With exciting new features being added to both CoreCLR and mono (e.g. default interface methods or just fast Spans) which would never make it to .NET Framework, it seems reasonable to leave .NET Framework behind at some point.
That doesn't necessarily mean "not supporting" .NET Framework, but rather just leaving it as is.

There are still some sites around that use classic ASP (not ASP.NET, but the really old stuff). It still works and ships in Windows, you just wouldn't create new apps with it.
I believe that in <10 years, this may be the situation with .NET Framework.

I do agree with the requested extended support for 2.1, but I'd like the team to monitor 2.1 package downloads to make a decision in 2-3 years if they'd need to support (= fix important security issues) it for a little bit longer.

@John0King COM will be supported in .NET Core 3.0.

Also: We do have legacy applications using things like .NET Remoting.
But those are legacy already.

The world basically runs on legacy code and will continue to do so. It's a business decision of whether or not to port something to a "supported" or even "new" thing, but until then, as @dylanbeattie puts it:

Yeah, it’s worth mentioning that whether something is “supported” is not all that relevant - old apps don’t actually have to be ported to a new framework just because it’s available. Web servers are a bit of a special case though due to security threats. A long period of security patch support for the LTS would help people out.

@gulbanana It is only adding a higher bar to porting applications from System.Web to ASP.NET Core, since you need to change the web framework, the underlying application framework and then upgrade or swap out any incompatible dependencies (which may involve buying new licenses).

If you would do then a cost/benefit analysis, I'm not sure it would be in the benefit of ASP.NET Core.

This is especially applicable when you develop software on a project basis, and of course each project is tight enough on budget as it is, so while regular maintenance is of course possible, it is hard to justify swapping out the entire framework without apparent tangible benefit.

If you would do then a cost/benefit analysis, I'm not sure it would be in the benefit of ASP.NET Core.

So.. well.. leave it? If you don't need to migrate to ASP.NET Core then don't do it..
Not trying to sound sarcastic or anything, but if there is no business need to keep an application on the "latest things" then don't port it. The benefit is that .NET Framework / ASP.NET classic is still supported and your application will run as is.

Porting is frequently needless, I agree - ASP.NET to ASP.NET Core is a big change, and part of that change is that Core moves more rapidly (3.0 will have api breaking changes too, as did 2.0). This discussion issue is about the netfx to corefx change, though, and for most ASP.NET Core apps that is not a big change anymore,

This seems to remove the "ASP.NET Core on .NET Framework" intermediate point that would make migrations a lot more gradual and easier. After this, migrating an ASP.NET MVC/WebAPI/etc. applicaton to ASP.NET Core will be a very big-bang change, changing both the web framework and underlying runtimes all at once.

For large enterprise apps I expect this to be quite painful. My team's been eyeing this closely for a year or two, but:

• EntityFrameworkCore does not do everything we require, and only now with .NET Core 3.0 is EntityFramework itself coming to .NET Core. How much of that and what platforms it will run on, I don't believe has been clearly communicated, and I'll probably need to actually test a preview build to see.

• The OData story seems to still be up in the air in terms of large-scale applications. There's a _substantial_ amount of (re-)work required to move from OData 3 / System.Data.Services to OData 4 / WebAPI and onwards. This is something that hasn't been resolved for several years now, and I'm honestly not sure it ever will be.

Additionally, now we'd have to trim off all of the other unsupported technologies (AppDomains, Remoting, etc.) _first_, instead of being able to do that work in parallel or at a later stage.

Additionally, now we'd have to trim off all of the other unsupported technologies (AppDomains, Remoting, etc.) first, instead of being able to do that work in parallel or at a later stage.

Why can't you migrate to 2.1 first?

@davidfowl We probably could use that as an intermediary, unless we come across some new feature in 3.0/3.1/etc. that we need in order to migrate. I haven't done a full analysis yet, we've mostly been blocked on EF and OData so far.

New feature in ASP.NET Core 2.1 that’s needed to migrate? I meant ASP.NET Core 2.1 on .NET Framework.

When this issue came up a couple of years ago, I remember complaining that it was too hard to port everything. Here’s a quote from an old github comment I made back then:

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

The cool thing is that as of .NET Core 3.0, all those scenarios are supported. A huge amount of work has been done to make it easier.

@davidfowl so did I.

Hypothetically there might be some feature we're using in ASP.NET/MVC/WebAPI that isn't implemented in 2.1 but does arrive in a later version. In that case, 2.1 wouldn't be a workable stepping stone.

I'd have to do a more thorough analysis though, to see if there's actually anything critical we need that isn't in 2.1.

@PinpointTownes

Sadly, this just highlights one thing: you completely failed to make .NET Standard the front car of the .NET ecosystem. It doesn't move as fast as it should and is nothing more than a lowest common denominator that is always updated at the very last moment, when all platforms include (or are about to include) the new APIs.

You aren't wrong, but you're somewhat ignorant of the goals of the .NET Standard. The goal of the standard has never been to drive innovation, but to to drive convergence. If you approach it from that angle, it's by design a thing that has to lag behind because we have to think about which concepts can be universal or even should be universal. If you're curious what this looks like I invite you to take a look at the 35+ PRs that I merged over the last three weeks after review by all the .NET implementation owners.

We see .NET Core as the cutting edge platform where innovation happens. We've built several capabilities that allow us to deal with the churn and risks that come with that, much better than what .NET Framework had. However, not all capabilities that matter for the .NET ecosystem are part of the .NET Core experience. For example, ahead-of-time compilation is much more prominent on Xamarin and Unity. And when we take .NET Core features and add them to the standard, we need to consider their runtime environments, operating systems, and hardware constraints.

Perhaps that's just me, but I've never understood why it didn't move as fast as netcoreapp (which is the first to get the new APIs, by definition).

The reality is that "moving fast & breaking things" isn't something that our entire audience appreciates. It's bad enough if we have to remove APIs in major versions of .NET Core but it's virtually impossible to do with the .NET Standard. So we have to move somewhat slower and only include concepts we believe are mature enough for addition.

Do what you promised: make .NET Framework a stable framework that evolves slower instead of a dead end for the ones who trusted you when migrating to ASP.NET Core.

That still makes the assumption that .NET Framework will eventually get all features .NET Core has, but with a time delay. We learned that's simply not realistic. We can either decide not to innovate drastically in .NET Core or accept the engineering reality that a good chunk of the new features will never make it back to .NET Framework. We believe that we serve our customers best to preserve .NET Framework's core value prop (a mature & rich development platform) while also allowing customers to exploit new capabilities on .NET Core. Moving forward, I'd expect that we'll be more willing to innovate in areas that require runtime, library, and language changes like we did for Span<T>. While these things are costly, they also allow us to change the way people can write code. A good example of this is default implementations of interfaces, the ability to author generic code involving arithmetic, being able to use hardware intrinsics etc. And those features are likely exactly the kind we're not going to backport to .NET Framework due to risk.

I think it makes total sense for our web stack to be able to exploit these capabilities; and the only way to do this is to remove the limitation for ASP.NET Core to run on .NET Framework too. Keep in mind that the original reason we made ASP.NET Core run on .NET Framework was because .NET Core simply didn't had enough APIs. On .NET Core 3.0 we'll have more than 120k of the existing APIs. That's more than half of the entire .NET Framework and even includes WinForms and WPF. Yes, there are still large numbers of APIs that are missing, but we've made huge inroads into the long tail. While we'll never have a 100% parity I expect us to close this gap even more moving forward, based on customer data.

@yaakov-h I’d be surprised if that was the case. When you do the analysis, let me know.

You aren't wrong, but you're somewhat ignorant of the goals of the .NET Standard. The goal of the standard has never been to drive innovation, but to to drive convergence.

And you're heading exactly toward the opposite direction: abandoning .NET Standard for ASP.NET Core because it doesn't move fast enough, forcing NuGet packages targeting ASP.NET Core to abandon it too. Don't make me think it's convergence, I'm not that ignorant :rofl:

If you approach it from that angle, it's by design a thing that has to lag behind because we have to think about which concepts can be universal or even should be universal.

It's a choice, not a technical issue: nothing prevents you from determining whether a given API should be included in a new version of .NET Standard when reviewing it for inclusion in corefx/coreclr.

If you're curious what this looks like I invite you to take a look at the 35+ PRs that I merged over the last three weeks after review by all the .NET implementation owners.

I'm not saying it's an easy task and it proves my point: you're waiting far too much to create new netstandard versions and the rare times you do that, it's a painful process because it comes with tons of new APIs at the same time.

The reality is that "moving fast & breaking things" isn't something that our entire audience appreciates.

Yet that's exactly how every ASP.NET Core iteration works: it comes with (sometimes massive) breaking changes that make packages written for a version incompatible with the next ones. Yet, you don't give us many options: updating or staying on legacy versions forever, with a support policy that has nothing do with what we used to have (it's not just ASP.NET/.NET, Windows' lifecycle is also much shorter these days).

Moving forward, I'd expect that we'll be more willing to innovate in areas that require runtime, library, and language changes like we did for Span. While these things are costly, they also allow us to change the way people can write code. A good example of this is default implementations of interfaces, the ability to author generic code involving arithmetic, being able to use hardware intrinsics etc. And those features are likely exactly the kind we're not going to backport to .NET Framework due to risk.

What prevents you from introducing a new side-by-side .NET Framework version (let's say .NET Framework 5) that includes those "risky" changes? Again, it's not a technical issue.

Any chance to promote Microsoft.AspNetCore.Razor.Language and Microsoft.AspNetCore.Razor outside of aspnet or keep it on netstandard wave? Even though razor is just for html there are several libraries that use it for mail templates and it would be great if we could keep using it as is.

This move shows lack of support for netstandard in .NET roadmap, contrary to what's been told before. If one of the main new libraries abandons netstandard it does not bode well for its adoption .

Is this a move that now .NET developers should anticipate for all other new libraries developed by Microsoft in the open? Can the community get a more official statement on the future of netstandard and its adoption?

@terrajobst I totally understand you point regarding not adding to .netstandard those APIs which don't seem to be ready to span all platforms (and likely won't ever be). However, that didn't prevent you (MS) from introducing netstandard2.0 when, for instance, UWP wasn't ready to support it. As I understand, it took noticeable effort to add that support some time later, but you did it. Was that somehow a different story?

And you're heading exactly toward the opposite direction: abandoning .NET Standard for ASP.NET Core because it doesn't move fast enough.

ASP.NET Core only makes sense on .NET Framework and .NET Core, but the .NET Standard has to be implemented by everyone. It simply doesn't make sense to, for example, make Xamarin/Unity provide APIs that are predominantly used by a sever web stack.

It's a choice, not a technical issue: nothing prevents you from determining whether a given API should be included in a new version of .NET Standard when reviewing it for inclusion in corefx/coreclr.

That's what we did in .NET Core v1 days. We've decoupled the standard from .NET Core with v2. So yes, it's a choice but it wasn't an arbitrary one. The goal was to be able to move faster with .NET Core. It simply takes more time to consider how features work in the context of N other runtimes than a single one.

it's a painful process because it comes with tons of new APIs at the same time.

No it's a painful process because you have to review the design with multiple implementers and multiple different runtimes. However, doing it after a the fact, aggregated & bundled is much cheaper than having to coordinate that as we go. The CoreFx repo is a high-volume repo. It's much easier for Xamarin and Unity to review the features bundled together than drinking from the firehose and subscribing to all API discussions on CoreFx.

Yet that's exactly how every ASP.NET Core iteration works: it comes with (sometimes massive) breaking changes that make packages written for a version incompatible with the next ones.

And because you don't like this you want to impose it on everyone by making .NET Standard match .NET Core? Sorry, but this argument makes no sense to me.

What prevents you from introducing a new side-by-side .NET Framework version (let's say .NET Framework 5) that includes those "risky" changes? Again, it's not a technical issue.

What makes you think it's not a technical issue? Shipping side-by-side versions of .NET Framework isn't a workable solution. First of all, it's fairly expensive due to the fact that it's an OS component and thus needs to be serviced. You have no idea how complex our branching/servicing/patching strategy for .NET Framework 3.5 and 4.x is. Adding a 3rd one is close to impractical. Secondly, just doing that also has risks, as we need to make changes to activation in order so select the correct runtime for things like COM activated managed components. And that begs the question of whether or not we support in-proc side-by-side as well and with how many combinations. It's not a simple task and not free of risk either.

Don't make me think it's convergence

@PinpointTownes It is convergence... on .NET Core 😉

It simply doesn't make sense to, for example, make Xamarin/Unity provide APIs that are predominantly used by a sever web stack.

There are people who'd like to use ASP.NET Core not just on .NET Core, but also on UWP, so why not also on Xamarin? https://aspnet.uservoice.com/forums/41199-general-asp-net/suggestions/32626766-support-for-asp-net-core-running-on-uwp-as-windows

There's a difference between something that makes no sense - for you - and something you don't want to support.

The CoreFx repo is a high-volume repo. It's much easier for Xamarin and Unity to review the features bundled together than drinking from the firehose and subscribing to all API discussions on CoreFx.

Did I suggest such an extreme approach? I'm sure there's a compromise you could find, like discussing new standard APIs shortly (i.e a few weeks) after they are introduced in .NET Core, once the dust has settled a bit.

And because you don't like this you want to impose it on everyone by making .NET Standard match .NET Core? Sorry, but this argument makes no sense to me.

You assume I don't like that but you're wrong: I like fast-moving things - even if as the maintainer of 60 NuGet packages it's sometimes quite painful. What I don't like is forcing everyone to move at the same speed, abandoning folks in the middle of the road because they can't keep up.

I'm not sure how making .NET Standard move as fast as .NET Core can be seen as a punishment: nothing forces you to target the latest netstandard TFM. You'll only do that if you need the latest API set. If you don't need it, target an older version so your packages can be used by a broader set of platforms.

From the average developer's perspective, it's a total win: you can write packages using the latest shiny APIs that can be used by the newest .NET Core runtime. When the other platforms catch up, your packages can be used there too: you don't need to go with multi-targeting or re-publish packages.

First of all, it's fairly expensive due to the fact that it's an OS component and thus needs to be serviced. You have no idea how complex our branching/servicing/patching strategy for .NET Framework 3.5 and 4.x is. Adding a 3rd one is close to impractical.

I can certainly imagine it's not ideal for you, just like removing .NET Framework support for ASP.NET Core 3.0 isn't going to be ideal for folks who can't move to .NET Core. But am I totally wrong thinking you - Microsoft - have much more resources to deal with that than the average company has to move to .NET Core? (I'm not even talking about external dependencies you don't own and control).

Secondly, just doing that also has risks, as we need to make changes to activation in order so select the correct runtime for things like COM activated managed components. And that begs the question of whether or not we support in-proc side-by-side as well and with how many combinations. It's not a simple task and not free of risk either.

Sure, it's not easy. And it's risky. But that's what major versions indicate: there's a risk things might break. Now, between being forced to stay forever on ASP.NET Core 2.2 and taking the risk to move to .NET Framework 5 to use ASP.NET Core 3.0, what do you think people would opt for?

But am I totally wrong thinking you - Microsoft - have much more resources to deal with that than the average company has to move to .NET Core?

In my experience people consistently overestimate how many resources we have and how much work the resources we have have to do in order to support the status quo alone.

But in this case it's not even a matter of resources. We could have just open sourced .NET Framework and then all PRs would go directly to .NET Framework. It has to do with the complexity of the machinery and the compat risks. It is a centralized framework and even side by side releases share a common set of resources, like activation. We've been proven wrong time and time again that we can just assign smart people have it come out correctly.

Now, between being forced to stay forever on ASP.NET Core 2.2 and taking the risk to move to .NET Framework 5 to use ASP.NET Core 3.0, what do you think people would opt for?

In my view, it's much more practical to push the envelope of supported APIs on .NET Core to make it possible for more people to migrate smoothly to .NET Core than trying to backport .NET Core features to .NET Framework. All we can do there is cause grief. Keep in mind that side-by-side releases come with other challenges, such as getting IT to allow you to install it, chaining it into installers, or waiting for your hoster to provide you with machines etc.

Does this apply to all parts of ASP.NET Core, or will some useful, generally-reusable parts (like Microsoft.AspNetCore.Http.Extensions) remain on .NET Standard?

@andriysavin

@terrajobst I totally understand you point regarding not adding to .netstandard those APIs which don't seem to be ready to span all platforms (and likely won't ever be). However, that didn't prevent you (MS) from introducing netstandard2.0 when, for instance, UWP wasn't ready to support it. As I understand, it took noticeable effort to add that support some time later, but you did it. Was that somehow a different story?

Yes. .NET Standard 2.0 had zero net-new APIs. It was defined as the intersection of .NET Framework and Xamarin. Whatever the delta, we simply need it in order to get to reasonable compat bar with existing code. The only work was in UWP and .NET Core. And those code bases were originally designed to be a modern reset of .NET, which we learned to be not viable. Since the to-be-added APIs/technologies were largely mature and supported in constrained environments (Xamarin iOS) the complexity was low -- just a ton of porting work.

But now we're talking about adding brand new capabilities and concepts and that's a different beast to drive.

In my experience people consistently overestimate how many resources we have and how much work the resources we have have to do in order to support the status quo alone.

In my experience, Microsofties consistently overestimate how many resources we have and how much work we have have to do in order to support the status quo alone. Your argument really works in both directions :sweat_smile:

In my view, it's much more practical to push the envelope of supported APIs on .NET Core to make it possible for more people to migrate smoothly to .NET Core than trying to backport .NET Core features to .NET Framework.

Let's be clear: I'm all for that, but it's not going to work until .NET Core catches up and implements most/all the features .NET Framework had. Until it does, you'll still see people being blocked by a missing feature or a missing API. There are so many missing things that it's not reasonable to think big-legacy-monolithic apps will be able to move to .NET Core without hitting issues.

I definitely understand your concerns. But ultimately, what makes your life easier has a chance of making ours more painful: not supporting .NET Framework is going to be a PITA for us.

I definitely understand your concerns. But ultimately, what makes your life easier has a chance of making ours more painful: not supporting .NET Framework is going to be a PITA for us.

That part I understand. But the alternative wouldn't be more features in .NET Framework but simply a less powerful ASP.NET Core.

We have tried to co-evolve .NET Framework and .NET Core over the last years. It's not like we were trying to avoid work. I've personally spent a bazillion hours talking to our runtime engineers trying to fix, for example, the binding redirect nightmare. Or the broken .NET Standard 2.0 support in 4.6.1. We tried. It's not a matter of willpower, it's matter of practicality.

it's not going to work until .NET Core catches up and implements most/all the features .NET Framework had

In my experience, the availability of some APIs isn’t even that relevant. What matters a lot in corporate environments is the support and deployment complexity. And “supported, shipped and automatically updated with the operating system” is a lot more appealing than the 3 years support we get from .NET Core LTS releases and the finicky deployment it currently still involves. And let’s be honest here: There’s still not a stable tooling for .NET Core and ASP.NET Core I can confidently say that it will still be the status quo in a year. We had changes with every release and who knows if the new framework reference with 3.0 will be the right solution. So that’s definitely a huge pain point when dealing with corporates where you can’t just update things or do it the way it should be done; usually, they want it done in the way they have been doing it for the past 5+ years. They are spoilt by the framework and anything that isn’t as comfortable to them is almost a showstopper.

But the alternative wouldn't be more features in .NET Framework but simply a less powerful ASP.NET Core.

That's pretty much what I suggested last year: ASP.NET Core packages that still work on .NET Framework (e.g by targeting netstandard20 and netcoreapp30) but offer a more limited feature set, with much less interesting performance. Sometimes what people want are things that work. Not the new shiny things. Not the super fast stuff.

We have tried to co-evolve .NET Framework and .NET Core over the last years. It's not like we were trying to avoid work. I've personally spent a bazillion hours talking to our runtime engineers trying to fix, for example, the binding redirect nightmare. Or the broken .NET Standard 2.0 support in 4.6.1. We tried. It's not a matter of willpower, it's matter of practicality.

We clearly don't agree on everything but needless to say, I'm very impressed by what you guys did (yes, even if things like the HttpClient hiccup were fairly painful to deal with).

I'm really sorry to be that guy :sweat_smile:

So far on the ASP.NET Core front, I’ve seen Razor come up as something concrete that people would like to be available outside of ASP.NET Core in general. I think that’s reasonable and we should identify more areas like that (it’ll be a more useful discussion). ASP.NET Core 2.1 and 2.2 will still support .NET framework but I don’t think it’s reasonable to support .NET Framework forever.

@terrajobst

A good example of this is default implementations of interfaces, ... And those features are likely exactly the kind we're not going to backport to .NET Framework due to risk.

And with that statement died DIM. It's entire point is evolution of legacy. If it doesn't apply to legacy, and can't even apply to libraries attempting to bridge legacy and new, then it doesn't help anyone.

So far on the ASP.NET Core front, I’ve seen Razor come up as something concrete that people would like to be available outside of ASP.NET Core in general.

You can add the Microsoft.Owin.Security.Interop backcompat' package, ASP.NET Core Data Protection and the underlying dependencies to the list.

That's pretty much what I suggested last year: ASP.NET Core packages that still work on .NET Framework (e.g by targeting netstandard20 and netcoreapp30) but offer a more limited feature set, with much less interesting performance. Sometimes what people want are things that work. Not the new shiny things. Not the super fast stuff.

We've discussed this as well. The challenge there is that we can't encapsulate that entirely as some of the underlying platform APIs and capabilities will have to bleed into the public API. That means libraries integrating into ASP.NET Core's middle-ware would also have to provide multiple implementations. But worse, it might not even be possible without creating a schism as the public exchange type might be core-only which would create two versions of ASP.NET Core which aren't compatible any longer.

@HaloFour

And with that statement died DIM. The entire point of evolution of legacy. If it doesn't apply to legacy, and can't even apply to libraries attempting to bridge legacy and new, then it doesn't help anyone.

I think you're conflating legacy code with existing installations. Even if we were to port DIM to .NET Framework, you'd still have to upgrade to a newer version in order to use the feature. While it's likely a .NET Core-only feature it sill allows us to evolve .NET Core while still being able to consume code that was compiled against .NET Framework.

@terrajobst You keep mentioning Unity. Do they have their own CLR implementation? I was under the impression they're using Mono.

Unity has multiple .NET implementations, including their own non-mono AOT version, IL2CPP. Their class library and supported APIs also differ from standard Mono.

@terrajobst

I think you're conflating legacy code with existing installations.

There isn't much difference when it comes to "legacy" applications still being actively maintained and developed. There's a massive difference between upgrading the framework vs. having to migrate to .NET Core.

While it's likely a .NET Core-only feature it sill allows us to evolve .NET Core while still being able to consume code that was compiled against .NET Framework.

To what end? None of those "evolved" APIs in .NET Core will ever be applicable to .NET Standard. And no library writer will touch it given how it will create incompatible divergence in their own APIs.

I agree with @HaloFour. The only people that will be able to make use of DIM are those library authors targeting .NET Core only... so basically just corefx and aspnetcore. I can’t imagine anybody else would go near it.

The only people that will be able to make use of DIM are those library authors targeting .NET Core only... so basically just corefx and aspnetcore.

Well, another way of phrasing would be that the only platform where you can’t use it will be .NET Framework while you can on .NET Core, Xamarin, Mono, and Unity.

I can’t imagine anybody else would go near it.

I’ll imagine features like this will have a hockey stick adoption pattern in libraries, which makes sense. In the end library authors will always consider reach vs feature set. For apps it’s easier to decide, because you know (and often control) your target environment.

@yaakov-h

Does this apply to all parts of ASP.NET Core...

The tentative list of what's happening to what package is here: https://github.com/aspnet/AspNetCore/issues/3756

@terrajobst I thought that default interface implementations was going to be a language feature of C#. Saying that .NET Framework won't support it, you are practically saying that .Net Framework will be forever stuck with C# version 7.3 or at most the next. That divergence is not something that anyone would like to happen in the ecosystem.

We run a few .NET Core workloads but also run projects that are multi-year .NET FX.

Upgrading to .NET Core (even on .NET Framework to begin with) safely is a very large task.

Are there any plans for Microsoft to release some tooling to help "upgrade" projects from at least ASP.NET on .NET FX to ASP.NET Core to .NET FX?

There are MSDN articles about creating new VS Projects and importing views and rejigging projects but there is so much legacy stuff (Global asax, routing, ....) that I wish there was a central place that documented the old vs new way to help porting everything.

What prevents you from introducing a new side-by-side .NET Framework version (let's say .NET Framework 5) that includes those "risky" changes?

At that point is there any advantage to it not being .NET Core 3.0? Its already side-by-side and has the "risky" changes. Would the next set of features for .NET Core then need a .NET Framework 6 etc.?

With the apis already in .NET Core 2.0 and the new feature set coming to .NET Core 3.0 doesn't .NET Core fulfil the ".NET Framework 5" with Framework 4.x being the extremely long LTS version?

At a guess; at this point, it would be a smaller engineering challenge to cover any specific identified gaps that .NET Core 3.0 has from .NET Framework 4.x rather than change .NET Framework to behave as .NET Core.

Practical suggestion: Is there any chance ASP.NET Core 2.2 would become LTS with an _extended_ support duration above the common 3 years?

I am sure that would satisfy those that have to stick with the full framework for now, while also giving them (1) enough time to actually migrate to .NET Core and (2) enough motivation to migrate away from ASP.NET MVC to ASP.NET Core (when they cannot move to .NET Core _yet_).

I still don’t think this is clear, does ASP.NET Core on .NET Framework follow .NET Core 2.1 LTS or does it follow the .NET Framework v4.6.1+ support cycle (i.e since it’s running on .NET FX) where it’s supported within the foreseeable future?

@mythz ASP.NET Core is covered under the .NET Core support lifecycle, regardless of what platform you run it on.

I think the best move here would be to actually keep .net standard updated for at least 3.0, 4.0 and 5.0 and actually communicate forward that at some point the .net framework will be completly migrated to .net core.
everything else is just half baked.

Do you guys have customers already paying for LTS support today? (Just a probing question). How much time is enough time?

@terrajobst It sounds the real problem is that netstandard is monolithic. It sounds like we don't need netstandard but versioned API sets instead. Those will also be the TFM, for instance base2.0+span would be two API sets.

You could then evolve the standard based on API sets and possibly only implement some API sets in the full framework. (This would also make it easier for other platforms to implement netstandard, since some API sets can be left out).

With the API sets in place a separate build of ASP.NET Core would be created for the less-supporting targets like the full framework.

@Sebazzz that’s extremely odd topic. Can we not derail this thread with attempts to re-design netstandard? You can file an issue on dotnet/standard for that but I’ll tell you this idea was already proposed and shot down.

@davidfowl I don't think that's "odd" or "derailing" at all. It sounds like exactly what we need, if a bit less fine-grained than the way he proposed it. If the problem with all this is that we'd end up having to shoehorn all this web server stuff into implementations like Xamarin and Unity that don't care about web servers, then IMO making a separate ".NET Web Server Standard" API group would be the ideal solution.

@Sebazzz @masonwheeler

@terrajobst It sounds the real problem is that netstandard is monolithic. It sounds like we don't need netstandard but versioned API sets instead. Those will also be the TFM, for instance base2.0+span would be two API sets.

We tried this in various flavors (profiles, PCLs, loose contracts, and then versioned contract sets which became .NET Standard 1.x). It's too hard to tool and understanding compatibility rules over time (when platforms versions and API sets evolve). The .NET Standard as it is today is the closest we have ever been to a workable model. While not perfect, it's at least something I can explain in minutes and not have people's head explode.

I'm happy to discuss .NET Standard in more detail, but I agree with @davidfowl that this doesn't belong here. If you want to, file an issue in https://github.com/dotnet/standard.

Edit I've marked our .NET Standard comments as off-topic.

@Shayan-To

@terrajobst I thought that default interface implementations was going to be a language feature of C#. Saying that .NET Framework won't support it, you are practically saying that .Net Framework will be forever stuck with C# version 7.3 or at most the next. That divergence is not something that anyone would like to happen in the ecosystem.

It's a feature that requires language changes as well as runtime changes. It's similar to generics as it changes the rules of the type system. Generally speaking, C# doesn't know which framework you're compiling for (it just gets passed a set of reference assemblies that describe the APIs that the framework offers). Any C# feature that doesn't require API changes (e.g. the null-coalescing operator ?. or the _ for discarding expressions) will be supported. In that it's identical to how the compiler has always worked when you used the latest compiler & language version and targeted an older version of the .NET Framework that lacks the corresponding APIs. For instance, async/await won't work if you target .NET Framework 3.5 or 4.0 -- you need to be on 4.5 or up in order to use Task.

Man I feel for you guys.. Moving full on to .net core is, imo, the right thing to do long term and I do prefer the higher pace of innovation that will provide.

However people _will_ be upset about this.. A considerable part of it is the communication. When the 2.1 3 year LTS was announced, people on fullfx expected to be able to be able o move to 3.0 and still run fullfx, they will have sold asp.net core to their employers and clients putting their own reputation on the line, and now they'll feel like the rug has been pulled out under them. What they sold as a long term solution, the future of asp.net, is now (perceptually) capped at 3 years of support

It doesn't matter that its easier to migrate now, switching platforms will always be a risk, and that will be a risk and development effort that these people didn't expect, plan or budget for.

Most developers will _want_ to move to .net core 3, but besides potentially having dependencies they can't change (or involve a risk changing) they now have to pitch a migration _again_ and promise that _this time_ it will be a long term investment.. it can be a tough sell, but they will feel compelled to do it because of the 3 year support cycle..

Again, i'm for dropping fullfx, but I really think you should consider extending the LTS for the last version that support it by a considerable amount. Also communicating very clearly, as in blogs, conference/ session and so on, what parts will still be netstandard and how people still on 2.1/ full framework can still leverage them.

Otherwise you have a large risk of the narrative becoming "Microsoft is leaving its dedicated developers behind yet again" Not saying that is fair, just trying to warn you about what might happen.

What’s a reasonable about of time for the LTS?

6 years maybe? I think messaging is going to play a huge part in the reception though.. In the end, some people will be upset no matter what :/

@davidfowl @aL3891

For reference, Java LTS "Premier Support" is 5 years with "Extended Support" (paid) of an additional three years. Java 11, which is an LTS release and was released last month, will be supported through September 2023 and September 2026 respectively

We are investigating an "extended support" LTS offering and will provide more details when we have them. This would potentially offer customers who need a supported ASP.NET Core on .NET Framework version (2.1.x) an option longer than the current LTS support period.

Also FYI, I chatted a bit about the announcements today on the ASP.NET Community Standup: https://www.youtube.com/watch?v=-b59KvkWBUo&list=PL1rZQsJPBU2StolNg0aqvQswETPcYnNKL&index=0

Target .net standard, please. asp.net core can target .netstandard2.1 or 3.0 and let mono and .netframework catchup later , but if asp.net core target netcoreapp , then any library try to access a type of those aspnetcore library must be a .netcoreapp library.

and .net core will always release faster than .net framework and mono ,
mono and .netframework will eventually consume .netcoreapp assemblies if microsoft start target more frameworks/libraries to netcoreapp (that'll cause more library on nuget target .netcoreapp too) .

if that so , the .netstandard will became .netcoreapp 😂

@John0King please give examples of types you need outside of ASP.NET Core.

1. Razor as @poke mentioned
2. MVC filter Interfaces/Attributes (I have a helper class library that contains some ActionFilters and TagHelpers and common static/extention method for string , int,long ect. I use PrivateAssert="All" to reference MVC packages so when I use use this library some where else , that project doesn't have to reference MVC assemblies, I guess I have to sepreate the library to two , one is .netstandard and another .netcoreapp )

another question is : Will it be a problem for what type of class library should I create ? (.netstandard vs .netcoreapp). Today is pretty simple in asp.net core 2.1. choose .netstandard for class library, choose .netcoreapp or net461 for web project.

mono and .netframework will eventually consume .netcoreapp assemblies if microsoft start target more frameworks/libraries to netcoreapp (that'll cause more library on nuget target .netcoreapp too)

This will happen if people do not try harder to seperate what should come to a .netstandard library and what come to .netcoreapp library

MVC filter Interfaces/Attributes (I have a helper class library that contains some ActionFilters and TagHelpers and common static/extention method for string , int,long ect. I use PrivateAssert="All" to reference MVC packages so when I use use this library some where else , that project doesn't have to reference MVC assemblies, I guess I have to sepreate the library to two , one is .netstandard and another .netcoreapp )

Can you elaborate? This isn't making sense. MVC is an ASP.NET Core framework and can't be used standalone.

@davidfowl this library is a helper class library , I can use those filters when I work in a asp.net core MVC project and only use its extension methods in a console app.

@davidfowl this library is a helper class library , I can use those filters when I work in a asp.net core MVC project and only use its extension methods in a console app.

I still don't understand. Are you talking about a library that has MVC things and other random things?

Unfortunately, that sort of thing is common in enterprise software - 'helper libraries' which have, like, the company's utilities for MVC + the company's utilities for WPF + the company's utilities for telerik...
It made more sense when '.NET' was a single unified platform.

@davidfowl yes. There are some class/method in the helper library you can use those type everywhere. and when u referece this library in a mvc project, then u can use its mvc related class/method.

Oh well this just forces your libraries to be layered better 😉

Unfortunately this means that anybody who does on premise deployments still, cannot support their software for any longer than 3 years. As soon as you release an app targeting .netcore 3.0 for example, your customers have got 3 years and then are forced to upgrade. Some industries that'll be fine in, some it certainly won't.

That's the biggest problem with this, and makes .net core a complete non-go for a lot of people, I would imagine. I actually agree that in the end this is the right direction to go, but am certain this will stop a lot of places going to .net core.

Would really like a response from the .net team on this.

The thing is, ASP.NET Core is a web framework. In what industry is it safe to run a website for >three years totally unmodified? If it isn't security vulnerabilities, it'll be browsers deprecating that thing you relied on, or TLS 1.4, or users demanding that the site function on their new watchlet.

Over that timespan you should be able to get away with just small tweaks and minor dependency updates, but planning to not update a web application at all for years on end is reckless.

I think this would be more palatable to the community if you just increase the LTS period for ASP.NET Core 2.1 to 5-7 years.

In our experience, corporate enterprise-y development moves at a glacial pace compared to "modern" web development, and yet they still want to make sure they are not making new investments on significantly older platforms. These applications often take over a year to even _launch_, let alone be able to make a major breaking upgrade within 3 years. These enterprise (usually internal-facing only) web applications often are supported for 7-10 years, although I think it's unreasonable for the LTS for ASP.NET Core 2.1 to be 10 years. 5 years feels like a better solution than 3, with 7 years being a figure that surely would make nearly everyone comfortable.

And this is only necessary because ASP.NET Core 3.0 requires a major breaking change removing .NET Framework support. Future LTS releases should not be held to this standard, assuming the breaking changes are not this big.

I'm not sure how making .NET Standard move as fast as .NET Core can be seen as a punishment: nothing forces you to target the latest netstandard TFM. You'll only do that if you need the latest API set. If you don't need it, target an older version so your packages can be used by a broader set of platforms.

What if the platform never catches up? Then you will have a Library that targets netstandard2.3 that needs feature A which is only available on .NET Core and Xamarin, but impossible for .NET Framework.

Then netstandard2.4 comes out, having a few new Apis and some of these APIs are possible to port to .NET Framework. What now?

How do you target a library which needs a feature from netstandad2.4 which runs on .NET Framework, but netstandard2.4 can't target .NET Framework, because it can't implement netstandard2.2.

Then you'd have to cross compile to three platforms:
netstandard2.2 for the old platforms and net4x for the net standard just to support the feature that was added in netstandad2.4 and which net4x can also implement but not support because of APIs that went intonetstandard2.3`.

How would that make it easier for package authors to write and ship their nugget packages?

The whole thing can only work when the lowest common denominator that all platforms are going to support flow into netstandard. Unless you desire that even more APIs throw PlatformNotSupported exceptions, otherwise it will lead to fragmentation within the netstandard.

I can certainly imagine it's not ideal for you, just like removing .NET Framework support for ASP.NET Core 3.0 isn't going to be ideal for folks who can't move to .NET Core. But am I totally wrong thinking you - Microsoft - have much more resources to deal with that than the average company has to move to .NET Core? (I'm not even talking about external dependencies you don't own and control).

What's the actual issue here? People who can't move from ASP.NET Legacy to ASP.NET Core won't be able to move whether or not ASP.NET Core targets .NET Framework or not. Most likely reason they can't or won't will be System.Web specific libraries, which won't work neither on ASP.NET Core on .NET Framework. The people who have their applications now, obviously already have the working set.

And the people who are already on ASP.NET Core 2.1 on .NET Framework, if its working why wanting to move? Obviously all thats needed is already there and everything else that comes newly to ASP.NET Core 3.0 is nice to have.

As for the others:
There are a lot of ways to migrate an application to .NET Core, i.e. breaking parts out of the old monolithic applications and reimplementing them as Microservices, they way you also lower the risk and spread it over time

What if the platform never catches up? Then you will have a Library that targets netstandard2.3 that needs feature A which is only available on .NET Core and Xamarin, but impossible for .NET Framework.

If an API can't be implemented by the majority of platforms supporting .NET Standard, then chances are high it shouldn't be part of the standard, no? (in practice, it's very likely the other way around, as platforms Xamarin runs on are generally much more constrained). I'd expect this kind of issue to be detected when reviewing the API for inclusion in .NET Standard, but I might be wrong.

And the people who are already on ASP.NET Core 2.1 on .NET Framework, if its working why wanting to move?

• Support? (a 3-year support is insanely short)
• A bug fix present in 3.0 only? (LTS versions only get fixes for critical bugs and vulnerabilities)
• You need to reference a library that is only compatible with the latest ASP.NET Core version?

There are a lot of ways to migrate an application to .NET Core, i.e. breaking parts out of the old monolithic applications and reimplementing them as Microservices, they way you also lower the risk and spread it over time

Yeah, sure, in theory that's the ideal way to deal with that. But:

• Some apps depend on external libraries you have no control over. If the library doesn't work on .NET Core and the vendor doesn't want (or can't) port it, you're out of luck.
• Migrating to .NET Core can be costly and time-consuming. If even Microsoft's best teams are struggling with that, do you really think it will be that easy for any average team? We'll have to wait for 3.0 to see Entity Framework 6 being finally compatible with .NET Standard.

Don't misinterpret what I'm saying: I'm all for using .NET Core for new apps. But the fact ASP.NET Core was compatible with .NET Framework helped a lot of companies to move to ASP.NET Core for a reasonable cost. I'm convinced it would have never been so popular without that "not too hard" migration path.

Microsoft, would it be too much to ask to extend the 2.1 support? 2021 is not long enough for us and we don't have enough resources/time to make that conversion. Maybe to 2022 at the least? An extra year would really give us the chance to make the changes, albeit painful ones.

Keep in mind that many of our 3rd party vendors have yet to migrate their libraries to .Net Core compatibility, which is the biggest reasons for our hangup.

FYI https://github.com/aspnet/AspNetCore/issues/3753#issuecomment-434521855

Whilst I view extending LTS as necessary, IMO rolling ASP.NET Core on .NET FX into .NET FX support cycle should also enter into consideration. For starters it's confusing to have different parts of .NET Framework on different support cycles where rolling it together would make more sense. Secondly the code for 2.1 is already written, released and depended upon so it's going to take vastly less resources to support 2.1 than actively develop it in tangent with .NET Core 3.0. If the same team is maintaining both I'd also assume the recent and more familiar, modular ASP.NET Core active code-base is going to be easier to support than the completely different classic ASP.NET code-base.

When MS announced EOL of Silverlight 5 in 2012 they're still supporting it till October 2021 (despite it being dropped in Chrome in 2015 and Firefox in 2017). This is for technology that's abandoned completely which isn't the case here, largely the same code-base, programming model, active dev team are still working on it, it's only running existing software on .NET Framework that's being abandoned.

Prior to this announcement there was strong messaging MS was never abandoning .NET Framework that it was great for Windows-only workloads (as contrast to .NET Core for cross-platform / high-perf workloads) and that ASP.NET Core was the future programming model that would support both .NET Framework and .NET Core in future with .NET Standard as the solution for developing libraries that target multiple platforms.

It's now clear that .NET Core is the future for all new projects but this is about how to treat existing investments and existing Customers who've made decisions based on this guidance up till now. How do existing .NET Dev teams progress when needing to support existing systems, they're going to be forced to remain on classic ASP.NET (where their existing skills/knowledge are being outdated by the day) whilst context switching to develop new Apps on .NET Core.

If I was forced to maintain systems on .NET Framework I'd much prefer to be developing it on the new ASP.NET programming model with access to an active knowledge-base/ecosystem then be forced to revert back to using old ASP.NET indefinitely but that's not going to be possible unless ASP.NET Core on FX has the same level of support as WebForms.

MS also has the opportunity to position ASP.NET Core on FX as a "stable" development environment (i.e. fixed at ASP.NET Core 2.1). It hasn't been easy being a .NET developer in the last few years since .NET Core started. We've effectively had to abandon all our efforts for trying to port to .NET Core <1.x with it being hard to keep up with the constant stream of breaking changes, it was only until .NET Core 2.x were we able to support it and migrate existing Apps over. On the other side existing ASP.NET Framework developers have seen their chosen platform stagnated and then superseded by the new ASP.NET Core programming model and by extension eroding their existing skills/knowledge. Terminating support for ASP.NET Core on FX kills a popular staged migration strategy towards .NET Core where they risk (without a contingency fallback) running on an abandoned platform unless they're able to upgrade their entire system to .NET Core (a risk that can prevent migration attempts from consideration) it also kills their opportunity to be able to participate in the future ASP.NET Core dev model if they're not able to migrate their existing systems which they work day-to-day on, which will only be possible if it enjoys the same support as WebForms - which I hope is still in consideration.

Nobody mentioned: in our asp.net core application we need to host WCF services and this is the only pain point to migrate from .net framework. I don't see any news about server side wcf support on .net core 3, sadly.

@DamianEdwards @davidfowl @natemcmaster We are in the same boat. My company has a number of products that run on ASP.Net Core on .Net Full framework, and we support these for a much longer time than 3 years, due to how slowly the industries we sell in moves. Extending the LTS for .net core 2.2 would be meaningless in our situation because we would have to port our ASP.net core applications back to ASP.Net. Surely this is defeating the point guys! Would you just suggest supporting applications for shorter periods of time? Unfortunately this is also something we do not have control of. The industries we work in can take a year just to roll out our new software.

Unfortunately this means that anybody who does on premise deployments still, cannot support their software for any longer than 3 years. As soon as you release an app targeting .netcore 3.0 for example, your customers have got 3 years and then are forced to upgrade. Some industries that'll be fine in, some it certainly won't.

That's the biggest problem with this, and makes .net core a complete non-go for a lot of people, I would imagine. I actually agree that in the end this is the right direction to go, but am certain this will stop a lot of places going to .net core.

Would really like a response from the .net team on this.

@davidfowl https://github.com/aspnet/AspNetCore/issues/3753#issuecomment-434594997

Oh well this just forces your libraries to be layered better 😉

Isn't this argument working in opposite direction?

What I cannot understand is what actually prevents you from proper layering architecture of ASP.NET Core?
So, yes, some runtime features are not available on .Net Framework, such as Span<T>, but it doesn't mean it is not available at all. It is available, it is just not as performant as on .Net core. We could deal with that.

Some low level implementations could be implemented in variations for .net core specifically and for .net standard. And I doubt there's much room for that, as APIs are usually available as NuGet packages.
Many library authors do support different implementations for different platforms, this is what has always been.

Could you please elaborate what exactly prevents you from supporting .Net Framework/.Net Standard. A few simple examples what cannot be abstracted in way to have platform-specific implementations?

prevents you from supporting .Net Framework/.Net Standard. A few simple examples what cannot be abstracted in way to have platform-specific implementations?

Off the top of my head, items requiring runtime or framework changes

• Interior GC pointers; so creating a safe Span from a ref only without an object: MemoryMarshal.CreateSpan<T>(ref T reference, int length)
• Utf8Strings
• Default interface implementations
• Threadpool custom work items
• Span overloads on base types: Stream, Sockets, TextReader/TextWriter, WebSockets
• IAsyncDisposable overloads on base types: Stream, Sockets, TextReader/TextWriter, WebSockets, etc.
• IAsyncEnumerator overloads on base types: Stream, Sockets, TextReader/TextWriter, WebSockets, etc.

Bonus items

• Hardware intrinsics (x86, x64, ARM)
• Escape analysis (new allocations to stack)
• Side-by-side runtime versions
• Fixing binding redirects and versioning

I don't understand why we can't just have a netstandard version that no longer supports netframework. Just like windows phone has no netstandard support beyond 1.2. Why can't we move the standard forward and allow implementations like netcore, mono, xamarin, etc match it eventually or never. Then its up to the library maker to decide which netstandard version they want to implement in order to maximize coverage.

This change makes it so xamarin and mono can no longer use aspnetcore. It makes it so library makes are forced to target both netcore and netstandard or worse yet abandon netstandard all together and only target netcore.

This will ultimately lead to the death of netstandard.

prevents you from supporting .Net Framework/.Net Standard. A few simple examples what cannot be abstracted in way to have platform-specific implementations?

Off the top of my head, items requiring runtime or framework changes

• Interior GC pointers; so creating a safe Span from a ref only without an object: MemoryMarshal.CreateSpan<T>(ref T reference, int length)
• Utf8Strings
• Default interface implementations
• Threadpool custom work items
• Span overloads on base types: Stream, Sockets, TextReader/TextWriter, WebSockets
• IAsyncDisposable overloads on base types: Stream, Sockets, TextReader/TextWriter, WebSockets, etc.
• IAsyncEnumerator overloads on base types: Stream, Sockets, TextReader/TextWriter, WebSockets, etc.

Bonus items

• Hardware intrinsics (x86, x64, ARM)
• Escape analysis (new allocations to stack)
• Side-by-side runtime versions
• Fixing binding redirects and versioning

Items in that first list sound like things that would be candidates for changes to netstandard though?

Most of them don't seem like they would be impossible to bring to other runtimes, but it appears that nobody wants to rev the CLR for a new version to bring Default Interface Implementations to .NET Framework.

At the same time, Microsoft don't appear to want to push forwards with a version of .NET Standard that is forever incompatible with .NET Framework. Otherwise this wouldn't really be a problem - just push forward with netstandard30 or netstandard40 and drop Framework support; and have .NET Core target one of those newer standards.

I feel like this thread etc. is the result of Microsoft effectively painting themselves into a corner.

At the same time, Microsoft don't appear to want to push forwards with a version of .NET Standard that is forever incompatible with .NET Framework.

This disingenuous; .NET Standard 2.1 is being finalized and it has 3104 new apis over .NET Standard 2.0, including Span overloads on base framework types; which may make it incompatible with .NET Framework.

.NET Standard is still moving forward.

Otherwise this wouldn't really be a problem - just push forward with netstandard30 or netstandard40 and drop Framework support; and have .NET Core target one of those newer standards.

The problem is making every runtime, not just Framework incompatable with one of the newer Standards; and then incompatable with every Standard after that. What goes into .NET Standard needs to be agreed by the various runtimes as things that can be implemented.

Will Mono and Unity's various GCs support interior pointers soon? If not adding them to .NET Standard will blocks them from that .NET Standard any future .NET Standard until their GCs are changed to deal with them. However; its better to add apis that they can implement now and save ones that they can't for a future standard.

Are the apis being added to Core the right apis to have permanently fixed forever and force every runtime; that wants to be compatible with the next Standard, to implement?

Some of the Core 2.1 apis changed between preview 1 and preview 2 (due to usage feedback); so its hard to even know what the apis are that are new in Core X until its released at which point its set in stone. Then which of them which are the correct set to add to the Standard for all runtimes to implement (or be left behind by).

The approach to .NET Standard is still more aggressive than browser standards when 2 browsers must implement the feature before a standard will be accepted.

It would be nice if a new .NET Standard could ship at the same time as .NET Core and all the runtimes could instantly implement it and ASP.NET Core could then use all the new apis via .NET Standard; but while nice as an ideal, its also not practical. There are even quite a few approved apis that haven't been implemented in .NET Core

The basic question is can ASP.NET Core use the apis that have been requested by it and ship in the .NET Core version that ships with it (as they simultaneously ship); or can it only use the apis that shipped in the previous version of .NET Core - which therefore have a chance of being in the .NET Standard version for that .NET Core? (As its looking like .NET Standard versions will lag in apis 1 version behind .NET Core currently; using the sample size of 1)

If ASP.NET Core can use the apis; then the apis get usage testing and evaluated if they are good apis; if they aren't then better apis can be proposed. If ASP.NET Core can't use them, then whether they are good apis is still fairly unknown when they become .NET Standard candidates.

nobody wants to rev the CLR for a new version to bring Default Interface Implementations to .NET Framework.

.NET Core by supporting traditional .NET Framework workloads (including WinForms and WPF) is essentially the rev'ing of the CLR; but done in a more sustainable, future proof manner?

This disingenuous; .NET Standard 2.1 is being finalized and it has 3104 new apis over .NET Standard 2.0, including Span overloads on base framework types; which may make it incompatible with .NET Framework.

Including .NET Framework 4.8 and .NET Framework 4.9?

There's always the possibility that future Framework updates will gain these new APIs. At the moment it seems set in stone that .NET Framework will never get DIM, hence, any interface with a DIM method could _never_ be ported to .NET Framework.

.NET Core by supporting traditional .NET Framework workloads (including WinForms and WPF) is essentially the rev'ing of the CLR; but done in a more sustainable, future proof manner?

And not backwards-proof. As much as Microsoft showed off things like Paint.Net running on .NET Core, I can't run my existing server-side projects on .NET Core, and neither can most people.

It would be nice if a new .NET Standard could ship at the same time as .NET Core and all the runtimes could instantly implement it and ASP.NET Core could then use all the new apis via .NET Standard; but while nice as an ideal, its also not practical.

This might also not be practical, but I think people would overall be a bit happier if there could be two versions of ASP.NET Core:

• A fast-moving bleeding-edge version that's tied to .NET _Core_ and can use any new API it so desires.
• A slower-moving LTS version that's tied to .NET _Standard_ and runs in more places; which eventually catches up with older bleeding-edge builds but always lags behind.

By tying it to .NET Core you're forcing a tradeoff that not everybody is happy with. I get the reasoning behind the gotta-move-fast approach, but there's also a legitimate concern for the overall .NET ecosystem.

• A fast-moving bleeding-edge version that's tied to .NET Core and can use any new API it so desires.
• A slower-moving LTS version that's tied to .NET Standard and runs in more places; which eventually catches up with older bleeding-edge builds but always lags behind.

So if ASP.NET Core 3.0 came out as .NET Core 3.0 only; but at some later date when their was a .NET Standard that had the apis; packages for ASP.NET Core 3.x were released that were .NET Standard also (even if ASP.NET Core had moved on to 4.0); would that meet your requirements?

@yaakov-h

A slower-moving LTS version that's tied to .NET Standard and runs in more places; which eventually catches up with older bleeding-edge builds but always lags behind.

What does this mean? You can always use ASP.NET Core 2.1 with the extended support that @DamianEdwards mentioned. My guess is though that even if that support was 10 years, it wouldn't satisfy the people complaining. The gut tells me that as long as there are new features being developed people will want access to them (even the ones currently on the slow train), but maybe I'm reading too much into these responses...

You can always use ASP.NET Core 2.1 with the extended support that

Don't split the community please !!
(base on the vote )Do you expect 1/3 developer stay in asp.net core 2.1? or expect 2/3 developers who create nuget packages that have to maintain 2 version of their library ?

@benaadams

So if ASP.NET Core 3.0 came out as .NET Core 3.0 only; but at some later date when their was a .NET Standard that had the apis; packages for ASP.NET Core 3.x were released that were .NET Standard also (even if ASP.NET Core had moved on to 4.0); would that meet your requirements?

Precisely.

@davidfowl

You can always use ASP.NET Core 2.1 with the extended support that @DamianEdwards mentioned. My guess is though that even if that support was 10 years, it wouldn't satisfy the people complaining.

There seems to be conflicting messages here:

1. It's fine to stay on 2.1, the older LTS version
2. ASP.NET Core is moving so fast that we can't even wait one release cycle between .NET Core and the subsequent .NET Standard.

I think (2) is causing a lot of confusion and fear of being left behind.

@John0King

(base on the vote )Do you expect 1/3 developer stay in asp.net core 2.1? or expect 2/3 developers who create nuget packages that have to maintain 2 version of their library ?

I expect library authors to decide what the minimum version of ASP.NET Core they care about supporting is and target that. It's what they are already doing today. Some libraries support ASP.NET Core 1.x and 2.x some just support 2.x. This is no different.

@yaakov-h

I don't quite understand what the conflicting messages are. The current 2.1 is LTS and runs on .NET Core and .NET Framework and is supported for 3 years. This isn't a new message it's the same message we've had from the start.

ASP.NET Core is moving so fast that we can't even wait one release cycle between .NET Core and the subsequent .NET Standard.

That's speculation based on the comments made here. Officially, we're tied to .NET Core's ship cycle and we're adding and consuming new APIs with every release already. ASP.NET Core running on .NET Framework was never meant to be a permanent thing (it's even called ASP.NET Core), it was always meant as a stepping stone. We just had to add enough of the core APIs back so that customers could reasonably write fully functioning applications.

Any response on this from the ms team?

Unfortunately this means that anybody who does on premise deployments still, cannot support their software for any longer than 3 years. As soon as you release an app targeting .netcore 3.0 for example, your customers have got 3 years and then are forced to upgrade. Some industries that'll be fine in, some it certainly won't.

That's the biggest problem with this, and makes .net core a complete non-go for a lot of people, I would imagine. I actually agree that in the end this is the right direction to go, but am certain this will stop a lot of places going to .net core.

Would really like a response from the .net team on this.

Unfortunately this means that anybody who does on premise deployments still, cannot support their software for any longer than 3 years

that is just bullshit, you can actually just have an upgrade. the only time where it does not work is inside an embedded environment, but embedded software has so much more problem than a support window of 3 years.

@schmitch I'm not sure what you mean? Obviously you can just upgrade, but for some industries upgrading to a new version of software becomes a massive project that can take years, dependent on release cycles and how technically progressive (or not) those industries are.

@davidfowl

My guess is though that even if that support was 10 years, it wouldn't satisfy the people complaining.

Not sure how you were expecting people to take it, everyone this decision effects are faced with the platform they were sold to move to not only doesn't have a future, but their existing investments built on the latest programming model is headed towards running on an unsupported platform (that as of this announcement) in less than 3 years. Others who thought about a careful staged migration to .NET Core via migrating to .NET Framework first are now faced with the risk that there will be no contingency to fallback on - it's have it run on a new .NET Core runtime or bust.

A developer platform shouldn't be the goal in itself, as there's exponentially greater value being created on the platform, then the value of the platform itself. Blindsiding moves like this makes it appear that the max efficiency of resources to increase velocity of the platform is more important than investments of the ecosystem being created on it. The ink on the .NET Core 2.1 bits are not even dry yet but existing systems (on FX) are already being treated as a liability (with the view of providing minimal support) instead of the asset and value they add to the ecosystem.

As has been mentioned, enterprise systems can move at glacial pace, often simultaneously balancing teams of devs delivering continual improvements that numbers of employees and customers need to use to derive constant ROI from them. Many migrations need to happen "in-flight" with careful planning and rigorous testing which can take years - time which they would prefer to use creating value then scrambling to get off the platform that's having support pulled from under them. Large brownfield systems aren't commodities like iPhones that can be easily discarded and seamlessly upgraded every few years, the older and longer systems are in development, the more value invested in it and the harder it will be to migrate off it, which becomes especially hard to absorb given there's no value created in migrations, it requires resources, absorbs opportunity cost, increases risk and the best they can hope for is a flawless migration with their existing systems running exactly the same as it did before.

Whatever expiry date is put on FX support there are going to be existing systems running past it that hit roadblocks or were otherwise infeasible to migrate off it. What becomes the guidance then?

ASP.NET Core 2.1 is already developed, the effort to have ASP.NET Core running on FX/.NET Core is a sunk cost already invested. So the decision should be framed as a matter of MS resources to maintain an already developed platform (after LTS) vs cumulative amount of cost, ill will and inertia generated for abandoning a popular platform.

I’m not sure I understand what’s being asked for then. The lifecycle for LTS has not changed since 2.1 came out. If you wrote an app on the LTS version whether .NET Core or .NET Framework, it would be 3 years until you were “unsupported”. I don’t quite understand how the rug is being pulled from underneath you in terms of support, that hasn’t changed. You would need to upgrade to get any platform updates.

Now I understand that 2.1 being the last LTS version supported on .NET Framework means there’s no place to upgrade to, but that’s where extended LTS support comes in. If the application can never move to .NET Core even after these 6 years because APIs are missing, please file issues so that we understand the gaps.

I’m not sure I understand what’s being asked for then.

This thread is requesting varying levels of commitments from MS ranging from: keep developing it in tandem with .NET Core, develop it on a "slow train", not abandoning ASP.NET Core 2.1 and maintain same level of support as WebForms, extend LTS. My preference would be to not abandon it as a hosting option for ASP.NET Core (edit: obv anything above that would be more preferable) which wouldn't hold back .NET Core only v3+ whilst providing a lot of utility for existing .NET FX investments.

Now I understand that 2.1 being the last LTS version supported on .NET Framework means there’s no place to upgrade to

Which means it's become an unsupported platform, anyone on it has to treat it like lava and scramble to get off it before it reaches its unsupported EOL end.

• Anyone who thought about using it as a staging platform for moving to .NET Core has become a less feasible option as they face the risk of being stranded on an unsupported platform if the migration takes longer than expected or they hit roadblocks if any of the dependencies they rely on can't run on .NET Core.
• Anyone forced to use their enterprise's existing managed infrastructure's .NET Framework servers can't participate in using the new dev model and ecosystem and have to see their existing classic ASP.NET knowledge/skills become less valuable each day.
• Teams can't migrate their existing .NET Framework required systems and will require context switching to new ASP.NET Core projects on .NET Core.
• No organization wants to be forced into an unplanned migration because the guidance they've relied to base their budget, planning and investment decisions have changed.

Again not a problem for greenfield projects, for people that can or were planning to migrate to .NET Core anyway or for anyone that doesn't have to maintain legacy systems, but it does impact the existing .NET FX ecosystem and ASP.NET Core has become poorer for no longer being able to consider utilizing the popular option of hosting on .NET FX.

In a perfect world everyone would be on .NET Core but there exists a considerable amount of investment in .NET FX that's being devalued with this decision.

If the application can never move to .NET Core even after these 6 years because APIs are missing,

There are many people who can't or don't want to move to .NET Core, they want it to share the same level of support as classic ASP.NET (which the current messaging suggests is indefinitely).

Missing APIs is not the only reason that prevents migration, e.g. they could be relying on a dependency where the dev team created it no longer exists, it's a critical component that can't be changed, it can't be refactored safely (e.g. has no tests), it's shared with other .NET FX-only systems, it's maintained by another dept that has no budget, capacity to change it or due to external factors like their enterprises managed infrastructure only supports running on .NET Framework servers.

Thanks for killing .NET Standard with this kind of decisions.

So far we have been ignoring .NET Core because there are plenty of third party Assemblies that don't yet target Core.

Many of the vendors that are willing to support Core, do so in an half heart way, e.g. Managed ODP.NET without the native APIs which are only available on .NET Framework.

Then you come around with this kind of decisions.

No we won't adopt .NET Core faster just because it is too much work for Microsoft to support .NET Framework and it isn't able to deliver on the .NET Standard that you guys pushed to start with.

@davidfowl I can give you 2 examples of what makes it hard to migrate to .NET Core - WCF (many existing enterprise apps use it, I believe others have raised that issue already), and lack of Adomd library in .NET Core/ NET Standard (that's for communicating with SSAS, also used in enterprise apps, that's tracked in SQL https://feedback.azure.com/forums/908035-sql-server/suggestions/35508349-adomd-core). Some other (winforms) should be fixed with .net core 3 compatibility pack (yay!) - we have to wait and see how it really works.

@mythz

This thread is requesting varying levels of commitments from MS ranging from: keep developing it in tandem with .NET Core, develop it on a "slow train", not abandoning ASP.NET Core 2.1 and maintain same level of support as WebForms, extend LTS. My preference would be to not abandon it as a hosting option for ASP.NET Core which wouldn't hold back .NET Core only v3+ whilst providing a lot of utility for existing .NET FX investments.

Well we're currently exploring extending LTS support but we're not considering first class .NET Framework support for ASP.NET Core forever (which is what you're asking for). This version of ASP.NET Core that you're looking for the same level of support as WebForms would only ever get security fixes and reliability fixes. I can guarantee you that as features appear in newer versions of ASP.NET Core, the satisfaction level of those using ASP.NET Core 2.1 will go down (at least, that's what my gut tells me) as those changes will still be out of reach.

Missing APIs is not the only reason that prevents migration, e.g. they could be relying on a dependency where the dev team created it no longer exists, it's a critical component that can't be changed, it can't be refactored safely (e.g. has no tests), it's shared with other .NET FX-only systems, it's maintained by another dept that has no budget, capacity to change it or due to external factors like their enterprises managed infrastructure only supports running on .NET Framework servers.

This is very common (even within Microsoft) and it's why we added that ability to reference .NET Framework dlls in .NET Core 2.0 because it turns out most assemblies are compatible even if they weren't compiled for .NET Core. Now there are some things that will never work (like AppDomains...) but I expect as we add more API surface, the set of libraries that don't just work will shrink to an insignificant number.

@pjmlp

I don't see how this kills .NET Standard. .NET Standard is way bigger than ASP.NET Core. It's about creating re-usable shared libraries (like Microsoft.Extensions*) that work on any supporting .NET platform.

So far we have been ignoring .NET Core because there are plenty of third party Assemblies that don't yet target Core.

Which ones? Are support for those on the way or will those assemblies never support .NET Core?

Many of the vendors that are willing to support Core, do so in an half heart way, e.g. Managed ODP.NET without the native APIs which are only available on .NET Framework.

I agree with this and have seen tons of crippled versions of libraries on .NET Core (even with some libraries that Microsoft ships) but I'd say that the tides are turning on that. Some of the reasons for that was because of the initial missing set of APIs that existed on .NET Core 1.0. With 2.0 and 2.1, we've seen a large set of libraries port more easily over to core/standard without much loss in functionality.

@voltcode Thanks for the concrete feedback! We expect some of these types of compatibility issues to go away or be minimal over the time span we support .NET Core projects today (3 years or so).

@davidfowl

....

So far we have been ignoring .NET Core because there are plenty of third party Assemblies that don't yet target Core.

Which ones? Are support for those on the way or will those assemblies never support .NET Core?

On our case ODP.NET is the obvious one, as Oracle is not porting 100% of the driver features into Core.

Many of the vendors that are willing to support Core, do so in an half heart way, e.g. Managed ODP.NET without the native APIs which are only available on .NET Framework.

I agree with this and have seen tons of crippled versions of libraries on .NET Core (even with some libraries that Microsoft ships) but I'd say that the tides are turning on that. Some of the reasons for that was because of the initial missing set of APIs that existed on .NET Core 1.0. With 2.0 and 2.1, we've seen a large set of libraries port more easily over to core/standard without much loss in functionality.

That is not how many of our customers see it though.

Just for you to get a feeling how this kind of decisions affects the future of .NET, on a recent project the customer payed the development effort to move an application from .NET Framework to Java for UNIX deployment, as he wasn't willing to bet on .NET Core and the crippled ODP.NET implementation, while the JDBC driver offers 1:1 feature parity with .NET Framework ODP.NET driver.

Others might choose another alternative stacks as well.

There are a ton of dependencies that won't and can't be ported in your average enterprise app.

This issue surfaced on the top of HN. You guys (@MSFT) might want to check there too. Only 1hr and already 50+ comments.

@davidfowl

I don't see how this kills .NET Standard. .NET Standard is way bigger than ASP.NET Core. It's about creating re-usable shared libraries (like Microsoft.Extensions*) that work on any supporting .NET platform.

I don't understand what ASP.NET Core is if not a re-usable shared library? If the trend for libraries to be modern and fast is to drop .NET Standard support then it's a tricky message. Should Newtonsoft.Json switch to .NET Core 3 only, if it can run a lot faster? Should Autofac?

I do understand the reasons behind this, but I'm not sure the arguments and evaluation has changed much since the last time this came up! I guess we'll wait and see...

I'm going to throw my use case out there and give some perspective on how things look at our shop right now as it relates to this:

AspNetCore has been amazing for our stack in terms of self-hosting (http.sys) a web API and static web content around various services. We came from Nancy which was solid, but also had many flaws from our perspective so we switched to AspNetCore about a year ago. Today, we are running every one of our codebases on 2.x. In many cases, we would be completely fine moving to a pure .NET Core target. But, there are also many services we built to leverage AspNetCore that also rely on things like System.DirectoryServices and System.Drawing. From the perspective of these services, we would change the web hosting technology before we moved off of .Net Framework. Unfortunately, due to the complexities of managing 2 different web hosting technologies simultaneously and our team size, we would likely also strike AspNetCore from the rest of our services altogether in favor of something more compatible across both targets.

To put it shortly - This decision will force us completely off AspNetCore at some point in the future (likely when LTS expires for 2.x), for what I do not know right now. If it comes down to it, we will likely write our own in-house solution to replace AspNetCore, as our use-cases in terms of actual # of AspNetCore features being used is quite narrow (that being said, the features we _do_ leverage provide a huge value-add for us today).

Others might choose another alternative stacks as well.

That's fair, but alternative stacks have the same support policy. Java have moved to a similar LTS model (https://www.oracle.com/technetwork/java/javase/eol-135779.html).

There are a ton of dependencies that won't and can't be ported in your average enterprise app.

@bencyoung

It's a framework, not a library. It's made up of a very large set of libraries that ship together.

I don't understand what ASP.NET Core is if not a re-usable shared library? If the trend for libraries to be modern and fast is to drop .NET Standard support then it's a tricky message. Should Newtonsoft.Json switch to .NET Core 3 only, if it can run a lot faster? Should Autofac?

I don't see how it's tricky. I'm 97% sure those libraries won't remove frameworks because their customers would complain. The bar is extremely high for removing frameworks and it's the same reason we kept Microsoft.Extensions.* on .NET Standard 2.0. I agree it would be fuzzy if we moved everything there but that's not what's happening here.

In a way this is just formalizing what the reality is already on .NET Core. We ship ASP.NET Core with .NET Core. On .NET Core ASP.NET Core is a shared framework, it isn't just a set of packages. Those packages never ship separately from the overall product so the benefits of referencing these individual packages is small (the package list is also small btw).

@robkeimig

But, there are also many services we built to leverage AspNetCore that also rely on things like System.DirectoryServices and System.Drawing

Those exist in the windows compact pack on .NET Core https://docs.microsoft.com/en-us/dotnet/core/porting/windows-compat-pack.

To put it shortly - This decision will force us completely off AspNetCore at some point in the future (likely when LTS expires for 2.x), for what I do not know right now. If it comes down to it, we will likely write our own in-house solution to replace AspNetCore, as our use-cases in terms of actual # of AspNetCore features being used is quite narrow (that being said, the features we do leverage provide a huge value-add for us today).

Would that also be the case if support was extended?

Additionally, now we'd have to trim off all of the other unsupported technologies (AppDomains, Remoting, etc.) first, instead of being able to do that work in parallel or at a later stage.

Why can't you migrate to 2.1 first?

The biggest reason I'd hesitate is that the 3 year support limit means that you can't stay their. It's a short term migration stepping stone, not a point where you can have a stable long term platform. Which means you have to take all the pain of forward migrating in one lump because you can't risk going halfway, pausing the migration to build a number of high priority new features and then attempt to finish the migration only to find a hard block and have to backport all your new features to the old code base.

The biggest reason I'd hesitate is that the 3 year support limit means that you can't stay their.

Sure, that's why we'd offer extended support as @DamianEdwards mentioned.

Just to show how much consequence does this decision create - what about Blazor ? Will it stop being based on ,netstandard ? Should we expect that too ? Blazor is being advertised as the next big thing. What else from github.com/aspnet that currently depends on netstandard, will ditch it and move to net core on the next major release? What are the plans for other things, in MSFT control but outside aspnet repo that will share aspnetcore's fate?

@davidfowl

Others might choose another alternative stacks as well.

That's fair, but alternative stacks have the same support policy. Java have moved to a similar LTS model (https://www.oracle.com/technetwork/java/javase/eol-135779.html).

The small detail that you are overlooking is that Java, and other stacks, are still compatible across versions unlike .NET Framework and .NET Core without any need for a Standard that is only partially implemented across runtime implementations.

For what it is worth, I'm currently working on deploying my company's first ASP.Net core app. We have a really heavy investment in the .NET Framework, so using ASP.Net Core on the .NET Framework as opposed to .NET Core was the obvious approach.

Now I'm wondering if I am setting us up for a lot of pain later.

There are a lot of interconnected concerns here. You say that ASP.Net core was never meant to only run on the .NET Framework. Microsoft's messaging about ASP.Net Core in the past failed to make that super clear.

Similarly many .NET Developers are used to the idea that the .NET Framework is the main implementation, and that generally the others are subsets, except of course for environment specific APIs. This has changed with .NET Core, but many people were generally under the impression that the "full" .NET Framework would end up supporting everything nearly .NET Core does (except for the tooling, and cross-platform compatibility, obviously), but just on a slower timescale, waiting for the kinks to be worked out before including them.

Recently there has been much suggestion that some really significant features might never make it to the .NET Framework. (e.g. That the compatibility risks of the Span type considered too severe to implement in .NET Framework 4.8 suggests they might never be implemented, since why would those risks be any lower in 4.9?. Similar concerns apparently surround Default Interface Methods.) That is a major paradigm shift that many developers will not be happy with!

The messages in this very thread suggest that Microsoft is starting to consider the .NET Framework as a legacy feature, something that will get less and less development attention over time, until it really only gets security fixes.

Microsoft has historically been awful about being clear about what they are actively developing, what they are mostly just maintaining with only sporadic new features, and what they plan to only really provide security and stability fixes for. It sounds a lot to me like the .NET Framework is not only in that second category now, but is really close to being in the third category.

That is really annoying. .NET Core has some issues that make it less than optimal for some enterprise applications. Sure using it on applications that have continuous ongoing development might be fine. But, as an example, most enterprises also have some applications that get deployed, and are only touched once every few years. That works poorly with .NET Core. Here enterprises have to struggle with short support cycles for most releases. And there being on Windows no mechanism currently exists to automatically install the new patch releases to get the security updates, etc.

So enterprises starting new projects are left wondering what to do. The more enterprise friendly .NET Framework is exhibiting pretty clear signs of becoming deprecated, and thus something better avoided for new development. On the other hand .NET Core exists but is substantially less enterprise friendly.

So this basically became a rant, but I hope this better illustrates the concerns many developers are having.

@davidfowl

But, there are also many services we built to leverage AspNetCore that also rely on things like System.DirectoryServices and System.Drawing

Those exist in the windows compact pack on .NET Core https://docs.microsoft.com/en-us/dotnet/core/porting/windows-compat-pack.

I was not aware that the compatibility pack supported this use case. Ideally, we would like to move everything forward to .NET Core, and this looks to be a really good answer (which we may have overlooked initially). We have no plans to move hosting of our services to Linux/OSX, so these pieces could fit together nicely for us.

Would that also be the case if support was extended?

In terms of support - I feel as if LTS of 2.x into 2021 is reasonable, considering all of the other constraints that are involved with something this far-reaching.

Based on what I am understanding now, we would likely feel comfortable upgrading to AspNetCore 3.x once we have a chance to review and convert .NET Framework projects to .NET Core projects (w/ compatibility pack usage as required).

Thank you for your followup.

I wrote in .NET (mostly C#) for 15 years in high pressure projects. I wasted so many years and customers money wasting time using an over engineered framework. I loved the concept of .NET Core. To me it was the speed of writing NodeJS projects but in the amazing .NET ecosystem (including all the fat). Unfortunately it failed on that promise, it's still (even with this new announcement) far too complicated to bloody use. For the last 3 years I've been building in NodeJS, sorry guys, it's just doesn't compare. Make it more simple and easy to use and you'll attract the wide developer community again.

For projects with hard, compiled binary .NET Framework dependencies (vendor stuff with no source code) that can run in ASP.NET Core 2.1 apps targeting .NET Framework deployed on Windows, will adding the Windows Compatibility Pack to the project keep them working on Core 3.0 if the hard dependencies reference types supplied by the pack?

There is a massive ecosystem of extremely mature commercial libraries that unfortunately have dependencies on System.Drawing, GDI and sometimes the Registry (!). If these will only now work with 2.1 and only supported for three years, this is an issue that could halt the adoption of Core in some enterprises.

.NET Core is making a full circle to reach the starting point.

I would suggest another approach: let .NET Framework incorporate the useful features of .NET Core, and then eliminate .NET Core altogether as an experimental dead-end branch. Thus stopping the segmentation and saving the technology for the greater benefit of customers. Somewhat controversial, but much saner approach product-wise.

@davidfowl

ASP.NET Core running on .NET Framework was never meant to be a permanent thing, it was always meant as a stepping stone

That’s just not true at all. The messaging on ASP.NET Core has always been that it is supported on both .NET Core and .NET Framework. Even the earliest announcements of .NET Core mentions both platforms for ASP.NET Core (back then ASP.NET 5).

The very well-known image that shows off .NET Standard also has ASP.NET Core span both Core and the full framework. And the official documentation even says: “There are no plans to remove support for targeting .NET Framework in ASP.NET Core.”

So yes, it’s obvious that this decision has changed by now, but saying that it was always like that is either just a lie, or a very bad communication done by Microsoft over years.

it's even called ASP.NET Core

Oh come on. After all this time people like me had to fight people to separate .NET Core and ASP.NET Core because they are not the same thing, don’t just use the similar name for your advantage here. That’s just not fair. The name change to “Core” was certainly not to link it explicitly to .NET Core. Also, EF Core has a “Core” as well but will continue to run on netstandard so that argument doesn’t work.

that’s where extended LTS support comes in. If the application can never move to .NET Core even after these 6 years […]

Where did this even come from now? Last time, the message was still “we are investigating an ‘extended support’ LTS offering”. Is this a real thing now and we get 6 years?

@pjmlp

The small detail that you are overlooking is that Java, and other stacks, are still compatible across versions unlike .NET Framework and .NET Core without any need for a Standard that is only partially implemented across runtime implementations.

Fair point, but I don't understand what that has to do with better support. The claim was made that switching to Java would be better because of less crippled libraries (which is a point in time issue) and enterprise support (longer support cycle).

@KevinCathcart

The messages in this very thread suggest that Microsoft is starting to consider the .NET Framework as a legacy feature, something that will get less and less development attention over time, until it really only gets security fixes.

Microsoft has historically been awful about being clear about what they are actively developing, what they are mostly just maintaining with only sporadic new features, and what they plan to only really provide security and stability fixes for. It sounds a lot to me like the .NET Framework is not only in that second category now, but is really close to being in the third category.

See https://blogs.msdn.microsoft.com/dotnet/2018/10/04/update-on-net-core-3-0-and-net-framework-4-8/

For projects with hard, compiled binary .NET Framework dependencies (vendor stuff with no source code) that can run in ASP.NET Core 2.1 apps targeting .NET Framework deployed on Windows, will adding the Windows Compatibility Pack to the project keep them working on Core 3.0 if the hard dependencies reference types supplied by the pack?

Yes, it's binary compatible.

There is a massive ecosystem of extremely mature commercial libraries that unfortunately have dependencies on System.Drawing, GDI and sometimes the Registry (!). If these will only now work with 2.1 and only supported for three years, this is an issue that could halt the adoption of Core in some enterprises

As I've mentioned several times on this thread. We added the ability to directly reference dependencies compiled against .NET Framework on .NET Core projects.

@poke You're right about the messaging, it wasn't clear at all, my mistake.

Where did this even come from now? Last time, the message was still “we are investigating an ‘extended support’ LTS offering”. Is this a real thing now and we get 6 years?

I made up 6, I don't know how extended support will be when we offer it.

.NET Core was always going to replace .NET Framework (Originally it was going to be .NET Framework 5), but the rewrite was so ambitious that it's taken util now to support desktop apps.

Wow, are there ever a lot of hilarious comments here. It seems like there is a lot of misplaced nerd rage, interspersed with people failing to read the article.

支持

@edandersen did you run ApiPort on these external dlls? It will show you if they use any APIs that aren't available on .NET Core. If it only uses available APIs then it shouldn't be a problem, otherwise, knowing which APIs are missing helps the discussion and feature prioritisation.
The windows compatibility pack already provides functionality for system.drawing and the registry. Did you try to run these things on .NET Core already? System.Drawing even works on *nix using mono's libgdiplus. This allows us to use ClosedXML on non-windows systems to work with Excel files.

The biggest .NET Framework dependency for "recent" applications at our company is WCF functionality.
The .NET Core WCF client libraries are improving. I haven't checked for the current status of how good they work with some services we consume but in the past, we were unable to talk to some services. But the missing functionality was already in their issue list. Simple services work well on the other hand!
On the other hand, there isn't a "drop in" replacement for hosting SOAP services in .NET Core. This would block migrating some applications to .NET Core (but as mentioned - there isn't a need to).
For a recent ASP.NET Core application we created an additional ASP.NET proxy web app that just hosts a WCF service and then forwards to the ASP.NET Core application via HTTP/JSON. Not very pretty and adds deployment complexity but it allows for some integration points.

I'm not saying that I really want WCF hosting capability in .NET Core, given that I get headaches configuring it . Some option to host SOAP services and generate WSDL would be cool though. I've seen a few OSS libraries trying to do that already. Maybe this will be enough.

@ davidfowl

Fair point, but I don't understand what that has to do with better support. The claim was made that switching to Java would be better because of less crippled libraries (which is a point in time issue) and enterprise support (longer support cycle).

The point is that while Java LTS versions are also three years, the compatibility among all major implementations is gold, which is something you guys are willing to throw out of the window here.

This whole .NET Framework, .NET Core, Xamarin, .NET Standard missteps is starting to look like the good old days of WinDev vs DevTools, just inside of .NET teams for a change.

So naturally customers are willing to move to platforms that don't look like internal teams are fighting for roadmap features.

These decisions don't inspire confidence.

This really does feel like a mistake on the .NET team's part, particularly in the context of the current climate!

For those mentioning Java, have you actually looked at what's going on over there recently? Between their absolutely insane lawsuit against Google over using it in Android and their latest licensing shenanigans, Oracle's behavior consistently appears to be that of a company that wants to kill off an unwanted product, rather than one that wants it to thrive!

This is the perfect time for Microsoft to capitalize on this with powerful marketing suggesting they're doing the exact opposite, and that .NET is the place to be for sane, stable, safe development options. Instead, we get... this. :disappointed:

@masonwheeler

We that work in both environments do actually appreciate the work Oracle
has been doing with Java.

It is those that seldom use Java in production, despise Oracle, that get
lost in hate arguments against them.

In what regards Android, I am fully supportive of the lawsuit, as Google
managed to fork the Java platform, thus succeeding where Microsoft failed
with J++. Still look forward to the day any random JAR in Maven Central is guaranteed to actually work on Android.

As for .NET, I am starting to get fed up with the continuous reboots of
how we are supposed to target Microsoft platforms.

The whole WinRT, UAP, UWP, .NET Native dropping F#, XNA, Core 1.0 has left
lots of sour grapes and this recent decision does not make things better
overall.

.NET is my favourite platform so please don't spoil it even further.

@mythz

Now I understand that 2.1 being the last LTS version supported on .NET Framework means there’s no place to upgrade to

Which means it's become an unsupported platform, anyone on it has to treat it like lava and scramble to get off it before it reaches its unsupported EOL end.

That's one of the points I don't really understand in the whole discussion. What do you really get from from the LTS support other than security fixes (which could be covered with the extended LTS support)?

In the mainstream LTS support there are just two things to expect:

• Security fixes
• Critical bugfixes

Most of the former ones (security fixes) will be patched through the Windows Update (since you target .NET Framework). So only security & critical bug fixes remaining are the one in ASP.NET Core itself.

Let's say its already know that the support ends 2018, I wouldn't expect anyone starting new projects in 2020, so its (imho) unlikely you find a critical show-stopper bug after 2021 (or 2026 or how long the extended support is meant to be).

That just leaves security bugs open, which is reasonable to cover with LTS.

In previous answers I saw mentioning of TLS 1.4 etc. these wouldn't be covered in an LTS anyways as that's a new feature anyways, which is same even for Java (Java 6 only having TLS 1.0 Support - TLS 1.1 if you count in the non-public updates only available to Oracle's extend support subscribers).

• Anyone who thought about using it as a staging platform for moving to .NET Core has become a less feasible option as they face the risk of being stranded on an unsupported platform if the migration takes longer than expected or they hit roadblocks if any of the dependencies they rely on can't run on .NET Core.
  But which APIs are the ones that are missing that you can now use with ASP.NET Core on .NET Framework, but can't on ASP.NET Core on .NET Framework + Compatibility packages?

I think that's the more critical point here, to identify this ones and either ship the missing APIs with future Compatbility packages or add them to .NET Core, making it possible to reference the .NET Framework libraries even when targeting .NET Core.

Since .NET Core you can reference (and use) any .NET Framework library in a .NET Core project as long as it only uses APIs available in .NET Standard or .NET Core.

This doesn't require the library author to update his libraries to target netstandard / netcoreapp.

Maybe it would help if Microsoft would extend the NuGet webpage/library by a feature / link next to each nuget package on nuget.org which shows a report if this library uses any incompatible APIs not available in specific versions of .NET Core?

For example

'Company.Example.MyLib` would show

• .NET Core 2.1: partial support (detailed report) -- where the detailed report would show Apis that work and which that don't
• .NET Core 3.0:; fully supported

This should be possible by running the .NET Portability Analyzer? A bonus would be, if it adds a list of public APIs that are safe to call (by analyzing the IL Code and see which other APIs its calling to make sure its safe or not)?

This would at least make it for developers easier to determine if a specific library they require for their project may run on .NET Core or not even if it doesn't explicitly calls it?

Right now its kinda a pain to figure that out if the APIs are supported or not, you need the library, run the analyzer locally on it. Many developers may not know they can use some of the libraries which are not officially supporting netstandard.

@davidfowl @terrajobst Would that be a feasible addition to NuGet? To make discoverability of -NET Core compatible .NET Framework libraries easier and faster?

• Anyone forced to use their enterprise's existing managed infrastructure's .NET Framework servers can't participate in using the new dev model and ecosystem and have to see their existing classic ASP.NET knowledge/skills become less valuable each day.

That's hardly a argument for or against the support of .NET Framework or not. People who are stuck on legacy dependencies and can't migrate to .NET Core (with compatibility pack or with .NET Framework libraries) won't be able to do neither after it. How would that change anything?

Still, parts of the monolithic applications can be split out and gradually move parts of the legacy application to new one, but thats a different story.

• No organization wants to be forced into an unplanned migration because the guidance they've relied to base their budget, planning and investment decisions have changed.

If the benefits outweight the investments why not? i.e. if there are unique features which give you a big value in return or huge performance boost.

If not, stay on the old system. Software development been like this forever. There are still companies running software developed in Fortune and Cobol.

There are many people who can't or don't want to move to .NET Core, they want it to share the same level of support as classic ASP.NET (which the current messaging suggests is indefinitely).

Missing APIs is not the only reason that prevents migration, e.g. they could be relying on a dependency where the dev team created it no longer exists, it's a critical component that can't be changed, it can't be refactored safely (e.g. has no tests), it's shared with other .NET FX-only systems, it's maintained by another dept that has no budget, capacity to change it or due to external factors like their enterprises managed infrastructure only supports running on .NET Framework servers.

Yea but which dependencies? Concrete examples would be necessary in order to identify which APIs these external dependencies are using. This API could be added to .NET Core 3.0 or a future version of .NET Core.

This makes it possible to use this .NET Framework library in .NET Core projects. The only problem is when the .NET Framework libraries use API which are not available in .NET Standard or .NET Core. But to fix that feedback is required to identify the libraries.

@pjmlp

@davidfowl

Others might choose another alternative stacks as well.

That's fair, but alternative stacks have the same support policy. Java have moved to a similar LTS model (https://www.oracle.com/technetwork/java/javase/eol-135779.html).

The small detail that you are overlooking is that Java, and other stacks, are still compatible across versions unlike .NET Framework and .NET Core without any need for a Standard that is only partially implemented across runtime implementations.

That's not exactly true for the later Java editions neither. Java 9 added the first step to modularize the runtime, which IS a breaking change. In Version 9, this has been disabled by default but in future versions, the flag will be enabled by default (or not being able to turn it off) and this does create breaking changes to legacy applications.

For example for the many libraries which do use internal APIs through some reflection magic can and will break with that change. And many of these libraries are, like in the .NET world, not maintained anymore, so updates are not to be expected.

@ TsengSR

In spite of the breaking changes introduced in Java 9, 100% of all relevant Java frameworks do work across Java 9, 10 and 11, which definitely isn't the case across .NET Framework, UWP and Core.

Imagine that even there are two official cross platform GUI frameworks, while we still don't get an official roadmap for Core!

@pjmlp

@ TsengSR

In spite of the breaking changes introduced in Java 9, 100% of all relevant Java frameworks do work across Java 9, 10 and 11, which definitely isn't the case across .NET Framework, UWP and Core.

Imagine that even there are two official cross platform GUI frameworks, while we still don't get an official roadmap for Core!

Sorry, that's complete non-sense.

The Java 9's internal modules, which prevent reflecting into these modules unless --add-opens is called (and iirc it was always supposed to be a temporary solution so people may continue to run their legacy application and removed a few versions later).

In case you missed the drama and the shitstrom when Java 9 was about to be realeased, this was the response to it:
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012673.html

To help the entire ecosystem migrate to the modular Java platform at a
more relaxed pace I hereby propose to allow illegal reflective access
from code on the class path by default in JDK 9, and to disallow it in
a future release.

Otherthing, Java EE 9 deprecated JAX-WS was deprecated and is to be removed in Java EE 11. That could be roughly seen as the equivalent of WCF. Any applicable using it can't be ported to a newer version neither without replacing it by something else, which is a migration process. No more or less different than migrating from ASP.NET Core on .NET Framework to ASP.NET Core on .NET Core (or from ASP.NET to ASP.NET [email protected] core)

https://www.oracle.com/corporate/features/understanding-java-9-modules.html

Greater platform integrity—Before Java 9, it was possible to use many classes in the platform that were not meant for use by an app’s classes. With strong encapsulation, these internal APIs are truly encapsulated and hidden from apps using the platform. This can make migrating legacy code to modularized Java 9 problematic if your code depends on internal APIs.

Any application which used these internal APIs (including all in sun.* namespace which some of the old libraries did use -- or used to use back when Java 9 was about to be released) or uses a 3rd party library which depends on this APIs or another library may be subject to this breaking change. Problem on it is, like in .NET Framework and .NET Core is that you don't see from the library alone which APIs are called or not.

@TsengSR

The Java 9's internal modules, which prevent reflecting into these modules unless --add-opens is called (and iirc it was always supposed to be a temporary solution so people may continue to run their legacy application and removed a few versions later).

Or you can use classpath mode and skip the mess that is modules. That mode will remain for the foreseeable future. And if you do get into modules you can explicitly declare dependencies into the packages of other modules.

Otherthing, Java EE 9 deprecated JAX-WS was deprecated and is to be removed in Java EE 11. That could be roughly seen as the equivalent of WCF.

All of J2EE has been deprecated and removed in Java 11, which is already out. But J2EE only defines the interfaces, not the implementation. To continue using J2EE, which I do, you just need to switch dependencies. All of the implementations were separate anyway, and they work fine in Java 11.

Any application which used these internal APIs (including all in sun.* namespace which some of the old libraries did use -- or used to use back when Java 9 was about to be released) or uses a 3rd party library which depends on this APIs or another library may be subject to this breaking change.

Which has always been the case. They were undocumented APIs. Nobody should have been using them and they could have changed or been removed at any time. Many of the commonly (ab)used internal APIs have been left as to not break existing programs, so that they can migrate to appropriate APIs in the future.

Some APIs have been deprecated, but we're talking specific APIs and not the entirety of the JRE or Java ecosystem. The work necessary to move from those APIs to newer, official and documented APIs are generally minimal.

And Java has always been more willing to break backward compatibility than .NET. For example, in Java it's now illegal to declare a type named var because that is reserved for local inference. In Java it's illegal to name a variable _ because that's reserved for use as a discard/wildcard. C# made the exact opposite decision in both cases, in the name of preserving backward compatibility.

Don't get me wrong, Java is it's own messes. Between modules, support for Java 8 nearing an end and Oracle getting greedy with JRE licensing there is a massive amount of opportunity for Microsoft to convert people. But that's very unlikely to happen if Microsoft is going to put out mixed messages regarding the future support and evolution of their platforms.

@TsengSR

That's one of the points I don't really understand in the whole discussion. What do you really get from from the LTS support other than security fixes (which could be covered with the extended LTS support)?

There's a ticking clock on that LTS which is going to end with nowhere to upgrade to which is the key point being glossed over when Java LTS is being thrown around in comparison. With Java and .NET Framework you've always had a high degree of confidence that you could upgrade existing systems with minimal effort given their strong focus on backwards compatibility. With there no longer been an upgrade path, existing systems are faced with being forced to migrate to a new runtime or keep running on an unsupported platform. For various reasons there will be systems where it will be infeasible to migrate to .NET Core leaving their future (with this decision) to hold running their critical business functions on an unsupported platform.

Not sure what the closest metaphor of this decision would be in Java land, maybe forcing existing systems to migrate to running on GraalVM, a lot of things will work, some wont, the larger the system the less confidence of being able to predict compatibility/issues until a migration is physically attempted.

I'd agree that a lot has been done to make migrations to .NET Core possible, but there's still going to be a number of external factors (inc outside of MS control) that's going to prevent migrations and this decision is only going to make migrations less likely as prior to this announcement ASP.Core/FX was a popular migration path, but it's no longer going to be prudent to recommend for an overall migration strategy to include migrating to a future unsupported platform, which is going to prevent many migrations from occurring resulting in more existing systems/devs being left on stagnated classic ASP.NET.

Most of the former ones (security fixes) will be patched through the Windows Update (since you target .NET Framework). So only security & critical bug fixes remaining are the one in ASP.NET Core itself.

Organizations don't want to base their enterprise on a partially supported platform in hope that any future bugs or security issues are only going to happen in the libraries that have been earmarked for support. It would go a long way if ASP.Core/FX would be covered by the same level of support as the rest of .NET Framework where any future security vulnerabilities are going to be resolved.

Currently only MS will be able to patch and release updated ASP.Core NuGet packages, with the interconnecting tree of dependencies being OSS isn't going to help much here unless 2.1 PR's they receive (post LTS) are going to be reviewed, accepted and released.

In the end after all the details have been discussed the ultimate question that still matters is:

Can we continue running our existing systems on ASP.Core/FX?

Technically it's going to be possible but without assurances that future critical bugs / security vulnerabilities are going to be resolved the recommendation has become NO, leaving the external ecosystem affected absorbing the pain of this decision.

If ASP.NET Core is going to be .NET Core only, how should we feel about the whole .NET Standard thing?

If Microsoft itself isn’t betting on it for (undoubtedly valid) reasons, why should we?

Will there be first-class, bleeding-edge .NET Core only libs and “simpler”, less advanced .NET Standard libs?

This seems to kill the drive to improve any non-.NET-Core platforms.

Hopefully someone can show me I’m wrong and ease my concerns.

Hi,
i see the value in pushing forward and i love it, but i see 3 main issues about this decision :
1) netstandard will be a second class citizen if nobody inside microsoft build something difficult with it, if you guys do not dogfood how can you ask other dev to do it? Today library authors have to work really hard, the support will not improve if internal ppl do not use the standard.
2) there is value in running aspnet core in other runtimes.
3) there is value in software running in old runtimes (with dependency that will never be touched) that should not be discarded lightly.

Then there is comunication : I think everyone would just love one .net runtime that runs everywhere, but that is utopia for the foreseeable future and netstandard was created as surrogate. From my point of view every project that does not target netstandard but a platform it's a step that does not go in the direction of that vision.
It's clear that .net framework it's in maintenance mode, .netcore will take it's place (leaving some dead body behind) and mono will run on devices, aot story and CoreRT do not look to advance.

With netcore 3.0 you are doing two things at once : supporting desktop workloads and "telling the ppl to jump right away to stay relevant". I think this will need a leap of faith from developers and it's far too optimistic because everybody knows that many projects won't be migrated due to some missing dependencies, that probably will be added in future 3.1/3.2 releases in 1-2 years (very close to the 3 LTS years of 2.1). In the mean time, devs that want to be relevant are blocked to use the 3.0 bits because of dependencies that they have no control of.

Will it be possible to postpone this decision after ppl have tested it and see the real implications ?
Is it possible to have aspnet core compiled to both netstandard and netcoreapp like you are prescribing library authors to do ? It's ok to have a degrated performance running on .net framework 😄

Roslyn now runs on .NETStandard 2.0 -> https://github.com/dotnet/roslyn/pull/30914

That certainly counts as something difficult!

@davidfowl

I believe this is going to start severely limiting options for the future development of .Net Framework systems that cannot migrate for various reasons, as the community is shifting efforts to ASP.Net Core.

For example Identity Server has already moved to ASP.Net Core and the recent post on the future of SignalR stated not surprisingly that ASP.Net Core SignalR will be the future focus of development effort, with ASP.Net SignalR being in maintenance mode - which at the time stated it will support .Net Framework & .Net Core and I expect this is a trend we'll continue to see.

I know that the LTS support for ASP.NET Core was already set at 3 years, but for on-premise deployment a longer lifecycle is needed as we have to provide support along these lines (4 years) to our customers.
During this period we need to to be able to release patches that include security fixes without any major application changes. This is to keep inline with our customers change control processes that would require extensive user acceptance testing by them for more major changes and so that we don't have to make major changes such as migrating to a newer version on releases that are in maintenance mode.

Is there any chance the LTS policy changing? something like Ubuntu's strategy of an LTS release every 2 years with 5 years support - although I'd ask for 6 so as to allow the current release to have 3+ years of support while the work to migrate to the new version is undertaken.

I understand that extended support has been mentioned but I assume this is something each of our clients would have to purchase, which I don't believe would be palatable if their initial installation (after dev, sales process, UAT etc.) at best has 2 years of support.

Also, curious how to treat .netstandard library in .netcore 3.0 times.
The slogan of .netstandard is "One library to rule them all".
Before this , it looks it means all.
After this, it looks it means a little .

Just to show how much consequence does this decision create - what about Blazor ? Will it stop being based on ,netstandard ? Should we expect that too ?

Can anyone clarify this?

So is the recommendation for libraries like Newtonsoft.Json (that can benefit from high performance) to switch to .NET Core rather than .NET Standard? I'm not seeing much of a distinction between that sort of library and ASP.NET Core. We embed REST services into larger applications - some of which can easily move to .NET Core and some can't.

In my understanding the recommendation for libraries is to target both .NET Core 3 and .NET Standard 2.x if you want to gain the advantages of the new APIs but don't want to lose audiences.

In my understanding the recommendation for libraries is to target both .NET Core 3 and .NET Standard 2.x if you want to gain the advantages of the new APIs but don't want to lose audiences.

I thought the road ahead was netstandard everywhere, and currently, we are just in a transition. But with a move like this, others will (or need) to follow and we're back to multi-targeting.

.NET Framework and .NET Core fill the same role, so I believe it's pretty much expected ASP.NET Core won't run on .NET Framework some day, be it now or later.

However, I see big issue on not running on .NET Standard X. To be honest I don't need asp.net core to run on xamarin or unity, but it's nice to be able to say that it could - it's just another set of libraries that runs on the .NET platform. By breaking off we are getting tighter integration between .NET Core and ASP.NET Core and I'm afraid by .NET Core 4.5 we are condemning Microsoft.AspNetCore and @davidfowl starting DNX 2.0.

On the other hand .NET Standard is definitely not a place to experiment and it's difficult to get things in properly, so can we maybe get a compromise? Would it be feasible to have ASP.NET Core current targeting only .NET Core, but LTS versions targeting .NET Standard? If an API doesn't find its way to .NET Standard is it really worth using it?

We could also look at this the way you probably intend to:

• .NET Core is for console/web/3rdparty desktop (standard + web specific api)
• Unity is for games (standard + game specific api)
• Xamarin is for devices/desktop (standard + device/desktop specific api)

But who pushes .NET Standard forward? As you've said before the resources are limited, so without having an actual need to push things in (which in my proposal would fall onto .net core/asp.net core team by needing changes to release LTS) I'm afraid .NET Standard will become quickly stale.

For those not paying attention it appears .NET Standard 2.1 just dropped support for .NET Framework.

Given many of the API additions in .NET Standard 2.1 require runtime changes in order to be meaningful, .NET Framework 4.8 will remain on .NET Standard 2.0 rather than implement .NET Standard 2.1. .NET Core 3.0 as well as upcoming versions of Xamarin, Mono, and Unity will be updated to implement .NET Standard 2.1.

https://blogs.msdn.microsoft.com/dotnet/2018/11/05/announcing-net-standard-2-1/

As much as it pains me to see the .Net Framework getting Silverlight-ed, what matters to me with respect to ASP.NET Core is that it should target .NET Standard.

As what is likely one of the largest reference applications in the Core/Standard ecosystem, I believe ASP.NET Core has a responsibility to be a champion of .Net Standard and all the good things it stands for.

I believe it's reasonable for ASP.NET Core to request changes to the standard that are then implemented in .NET Core.

In the same way that Span etc _is_ available in .Net Framework through a nuget package, I believe it's reasonable that if ASP.NET Core needs/wants to depend on something that is not yet in the .Net Standard, that dependency should be included in via a nuget package.

Finally, I hope (against all evidence to the contrary), that there will be a .Net Framework 5.0 that will target .Net Standard 3.0+ and will be a side-by-side installation with 4.x.

Finally, I hope (against all evidence to the contrary), that there will be a .Net Framework 5.0 that will target .Net Standard 3.0+ and will be a side-by-side installation with 4.x.

Yes, exactly. This is what I've been saying for years now: the CLR 2.0 architecture has served us well for a long time, but it's starting to get long in the tooth, and it's time for a fundamental upgrade of the same kind as Generics was. It may be somewhat painful to make the necessary changes, but they are necessary; updating with new, more powerful functionality is needed in the same way Generics were needed, and putting it off will only make that pain worse, not lessen it, when it finally happens.

That is exactly what .NET Core is, and this thread is the temporary pain being experienced.

@terrajobst said it won't happen: see thread : https://twitter.com/terrajobst/status/1059525279431815168?s=19

@gulbanana
Yes, except two things.

1. Core is not an upgrade from Framework; it's a parallel concept. There are so many really fundamental things it can't do, many of which, such as AppDomains, we're being told are unlikely to ever happen. For heaven's sake, we still don't even have a working Reflection.Emit! Considering how common that is in compilers and code generation tools, you'd think that would have been literally one of the first priorities, and yet here we are 4 years later and it doesn't work! This makes it very difficult to take the notion of "Core as a replacement/upgrade for .Net Framework" seriously.
2. Core is not radically upgrading the runtime, CLR 2.0 style. Over at "What language proposals would benefit from CLR changes?" we have a great list from the community of missing features that people consider important, that the CLR can't support, (or at least can't support without massive, ugly kludges to work around the CLR's limitations,) generally because of missing features in the type system. How many of the proposals in that topic are even being taken seriously at all by the Core team? And how many of the rest of them have been dismissed out of hand because the people running the project don't want to have to upgrade the runtime? We're getting DIMs and... anything else? Anything at all?

So no, .NET Core is not an upgraded .NET Framework that makes the much-needed CLR updates, because it's not an upgraded .NET Framework and the project team is doing all they can to avoid updating the CLR wherever possible. It's literally the exact opposite of that.

For heaven's sake, we still don't even have a working Reflection.Emit! Considering how common that is in compilers and code generation tools, you'd think that would have been literally one of the first priorities, and yet here we are 4 years later and it doesn't work! This makes it very difficult to take the notion of "Core as a replacement/upgrade for .Net Framework" seriously.

It would be great to understand what doesn't work. ASP.NET Core and EF uses reflection emit in a couple of places so I'm not aware of the big gaps. Can you elaborate here?

It's been there since at least 2.0.. iirc even 1.0 had DefineDynamicAssembly, though maybe not the whole suite of emit stuff.

I also find it hard to take seriously the idea that they're avoiding updating the CLR. Have you seen the sheer volume of work being done? https://github.com/dotnet/coreclr/commits/master
There are language features slated for C# 8 which will only work on .NET Core due to CLR changes, too. A lot of these objections just seem to be old information (which is fair enough, since Microsoft's plans have changed rapidly at times...)

@davidfowl

It would be great to understand what doesn't work. ASP.NET Core and EF uses reflection emit in a couple of places so I'm not aware of the big gaps. Can you elaborate here?

Admittedly it's been a few months since I checked, so this might have changed recently, but as far as I'm aware it's possible to create a new assembly in memory, but not to save it to disc because of arcane reasons involving the generation of PDB files, which makes Core useless to compiler maintainers such as myself.

Has this been fixed? I'd be delighted to hear that it has...

@gulbanna

I also find it hard to take seriously the idea that they're avoiding updating the CLR

What I said is that they're avoiding radically upgrading the CLR in the same fashion as the 2.0 update (generics.)

Specifically, they seem to be actively avoiding any changes that would add new fundamental kinds of types to the type system, (shapes, metaclasses, DUs, etc) or new IL instructions to the instruction set.

@masonwheeler

Admittedly it's been a few months since I checked, so this might have changed recently, but as far as I'm aware it's possible to create a new assembly in memory, but not to save it to disc

Looking at https://github.com/dotnet/corefx/issues/4491 (where you've commented in the past), I think the situation is still the same. Though I think missing one specific feature (even if it's an important one) is quite different from "we still don't even have a working Reflection.Emit".

which makes Core useless to compiler maintainers such as myself

How is Reflection.Emit ever useful for a compiler writer? I thought it was limited to producing assemblies for the current framework, so it couldn't be used to create e.g. .Net Standard assemblies at all, which I think would be a significant limitation for any compiler.

What I said is that they're avoiding radically upgrading the CLR in the same fashion as the 2.0 update (generics.)

I think there has been some inertia not to change the CLR, though there are also some very good reasons for that, especially if you consider that such changes are most useful and least painful when a platform is young.

I think that DIM are a sign that this might be changing, but I still wouldn't expect new IL instructions when JIT intrinsics can often work just as well, or new kinds of types when they can be reasonably encoded in the existing type system.

@svick

Though I think missing one specific feature (even if it's an important one) is quite different from "we still don't even have a working Reflection.Emit".

If you had a text editor that could let you type up text files but not save them, wouldn't you say it doesn't work?

How is Reflection.Emit ever useful for a compiler writer?

It's worked just fine so far. And as far as I'm aware it's the only compiler backend available that allows you to both generate new assemblies and save them or generate new assemblies in-memory and execute them.

still wouldn't expect new IL instructions when JIT intrinsics can often work just as well

Sure, but what about the cases where they won't?

or new kinds of types when they can be reasonably encoded in the existing type system.

Have you seen the proposal for implementing Shapes within the existing type system? There's nothing reasonable about it; it's a big, ugly kludge from beginning to end. (Nothing against the people who came up with it; it kind of has to be, given the limitations it's working with.) And good luck implementing metaclasses at all without CLR-level support!

We need an updated CLR to develop higher-level features in any kind of efficient manner, and no one is actually working to bring that about on Core.

Can somebody from the .net team please clarify what their recommendation for on-premise deployments is? Is it just "use asp.net regular"? I'm speaking specifically to @Edward84 's comments

Does this affect the Microsoft.Extensions.* support libraries? Specifically Microsoft.Extensions.Logging and Microsoft.Extensions.Configuration.

We have a large code base that share a common core API. Some of it is WinForms, some is classic ASP.NET, some WCF etc. And the newest applications are .NET Core (Not currently, but eventually when we've ported our core libraries to .NET standard)

We've chosen to base our core logging and configuration API on the abstractions in the libraries mentioned above.

So I'm wondering whether these are safe to use in a .NET Standard API referenced by both .NET Core and .NET Framework (4.7.2+) or may they also start using .NET Core only features?

@mvestergaard As mentioned in the announcement itself:

Microsoft.Extensions packages (such as logging, dependency injection, and config) will continue to support .NET Standard

And in @benaadams's comment in this thread:

Not all the libraries are moving to .NET Core only (e.g. Microsoft.Extensions.* are staying as .NET Standard)

@mvestergaard as already mentioned we are looking at our LTS policy to determine if things like extended support, longer periods, a "maintenance mode" period, etc. are useful and what they'd look like. We're also working to see if we can make the timing of new LTS trains more predictable (a model we see and really admire from other stacks that have an LTS model).

The biggest problem I have with this is not being able to use the mature packages that can only be used when targeting .NET Framework or ones that were simply not available outside of .NET Framework like those that needed System.Drawing and GDI+.

It seems the latter scenario is going to be supported in .NET Core 3.0, however AFAICT, we'll still miss out on using the stable, mature libraries that can only be used on .NET Framework.

An example of that is Entity Framework. We'll have to switch to the immature EF Core which seems to be a long way away from handling all the complex scenarios that the full EF could and which falls back to in-memory client evaluation behind your back to hide that problem which causes performance problems.

An example of that is Entity Framework. We'll have to switch to the immature EF Core which seems to be a long way away from handling all the complex scenarios that the full EF could ...

EF6 is going to be supported in .NET Core 3.0 as explained by @DamianEdwards on this weeks ASP.NET Community Standup - November 6, 2018 - ASP.NET Core 3.0 Features at 19:06

@benaadams that's great news! pretty obscure for such a big deal! :) good job finding that. Found another mention of it here.

@SaebAmini: You can use System. Drawing on .NET Core. See System.Drawing.Common and Scott Hanselmans Blogpost: https://www.hanselman.com/blog/HowDoYouUseSystemDrawingInNETCore.aspx,

And before that CoreCompat.System.Drawing existed, as a port of Mono's System.Drawing.

Is there any feature that is missing for your use case when running on .NET Core?

@TsengSR my specific scenario which made us target the .NET Framework was:

1. The need to use the Microsoft Solver Foundation package, only available in .NET Framework.
2. A barcode image generation package which used System.Drawing.
3. The need to use EF6.

This was about a year ago.

@SaebAmini: As it was mentioned earlier, EF6 support comes in .NET Core 3.0, System.Drawing is already there (and before that the CoreCompat package did existed and may have worked in your case) and for the Microsoft Solver Foundation Package, after running Portability API Analyzer:

See How to use Portability Analyzer

https://gist.github.com/TsengSR/f61c03c5f2d63dbe78d6b8c1eed08831 (download it and open the HTML, didn't find other place to put it in).

It shows 97.93% compatibility with .NET Core 2.0+Platform Extensions (which was released around a year ago) and it lists incompatible APIs, which are mostly related to System.Web which was deprecated and System.ServiceModel / System.Data.Linq.

Now, I didn't use this package before, and I'm not certain why a solver would need access to System.Web and HttpContext or the System.ServiceModel, but if you don't need any of theses (and you know your use case isn't calling this APIs), the chances are pretty high, that you could use it on .NET Core 2.0/2.1+Platform Extensions or on .NET Core 3.0, even if it doesn't specifically target the netstandard or netcoreapp20 target moniker.

So technically the chances were good that you could have migrated your application to .NET Core 2.0+Platform Extensions a year ago, if EF Core 2.0 could have covered the needs of your applications need (of course that requires some migration work and updates to work with EF Core 2.0).

Yes, it takes a bit more work to analyze the libraries in question or the feature for the replacement framework (EF6 -> EF Core 2.0/2.1), but its far from impossible. I don't think people can or should expect to port all of their code 1:1 to ASP.NET Core w/o doing any changes at all (outside of ASP.NET Core itself).

Just wished it would be more obvious to have API compatibility displayed, like with a "badge" (.NET Core 3.0 compatible) and/or a detailed api compatibility report somewhere on the nuget page to make it more obvious than having to download the package and then run it through the package analyzer.

I think this announcement would have been better received if it emphasised how much more compatible .NET Core has become. There are two enabling factors to move ASP.NET Core off .NET Framework:
1) Reducing the need for .NET Framework, making legacy deps available and improving interop and so on
2) Increasing the benefits of .NET Core, features and performance and reduced maintenance burden

Factor 2 looms large in the minds of people who have to actually build ASP.NET! However, there is little upside from a user’s point of view. People have a thing that works and their highest priority is that it should keep working. The good news is that in most cases, it will.

I agree with @gulbanana. .NET Core is now much more compatible with .NET Framework. In fact, I was able to launch pretty big .NET Framework apps just by renaming .exe to .dll and adding some missing .DLLs to the probing path.

The progress on dotnet command line tools is impressive. Especially the addition of .NET Core global tools. They make development a breeze.

AOT compilation with crossgen is great. I can go on and on.

tl/dr .NET Core is seriously impressive nowadays.

What is missing:

• The current customer communication strategy is lacking. Customers have a big disappointment when they hear their favorite .NET platform is being fragmented by Microsoft. You should be more clear here. For example, it would be a much better approach to directly advertise the singular, highly-compatible, fast and future-proof .NET implementation to people. Like .NET Core, the future of .NET, going to solve most of your problems, sky-rocket productivity, creativity, open new market niches etc
• Even more compatibility strategies out of the box
• Graphical user interface. I mean dotnet command line tools are great, but currently we have to use additional text editors and console to work on a almost every project in .NET SDK format. The Visual Studio UI is lacking in this regard. This puts big barriers to many people who have a habit to just point-and-click. This should be improved too
• LTS support

@TsengSR Thanks for your detailed response mate, great info! at the time using the barcode package wouldn't work as the project simply wouldn't compile complaining about different targets. Maybe I should give that another try. (unless you meant recompiling it ourselves and kinda inheriting it)

Not concerned about the effort really if that's reasonable. My main concern was being left high and dry with no option with EF being the main blocker and that seemingly is not going to happen. Great to see it's been well thought out. Although I agree with @gulbanana that these can be better advertised.

There are a lot of conflated issues here. My personal 2 cents is that leaving .NET Framework behind isn't such a big deal. What is concerning however is the total lack of any apparent support for standardization efforts (.NET Standard). Sure, you probably don't want to run ASP.NET Core on, say Unity today, but it isn't about today. It's about a year or two down the road, when another .NET runtime could come around, I would like to be able to say "Yeah, as soon as SuperNetRuntime supports .NET Standard 2.2 we can run ASP.NET Core 3 on it"...

Is there any chance to at least "gather" all the changes that were needed in .NET Core 3 for ASP.NET Core 3 and forward them to the .NET Standard working group as suggestions?

Hi, will packages published for .NetStandard 2.0 or .NetCore 2.0 continue to work with .NetCore 3.0. For eg: Oracle.ManagedDataAccess.Core target .NetCore 2.0

If there is backward compatibility, then moving to .NetCore 3.0 is suitable but if there is no support for older versions, then its really useless unless all play catch up.

.NetFramework has a history of compatibility even you can use .NetFramework 2.0 in latest versions so something need to be maintained for .NetCore also atleast 2.0 to 3.0 etc.

Thanks

Hi, will packages published for .NetStandard 2.0 or .NetCore 2.0 continue to work with .NetCore 3.0. For eg: Oracle.ManagedDataAccess.Core target .NetCore 2.0

Yes, .NET Core 3.0 maintains backwards compat so can use .NetStandard 1.0 -> .NetStandard 2.1 and .NetCore 1.0 -> .NetCore 2.2 libraries

@benaadams then thats good. Also will .net framework dll will work if they don't use any missing api?

Thanks

Also will .net framework dll will work if they don't use any missing api?

Yes, though its safer to use a .NET Standard library as you know that will work on .NET Core (and on Mono, Xamarin, Unity, UWP)

Additionally using the Windows Compatibility Pack adds another 20,000 APIs on top of .NET Standard 2.0 to bring .NET Core closer to .NET Framework (which you can do with .NET Core 2.1); and .NET Core 3.0 is the most compatible yet with EF6 (cross-plat), and on Windows: WinForms, WPF, COM Interop etc

Hi folks,
In order to give customers a reasonable stepping stone on their path to migrating applications to ASP.NET Core on .NET Core, we are going to extend support and servicing for ASP.NET Core 2.1.x on .NET Framework to match the current support policy for the other package-based ASP.NET frameworks, e.g. MVC 5.x, Web API 2.x, SignalR 2.x. This effectively means the ASP.NET Core 2.1.x related packages (final detailed list TBD) will be supported indefinitely, beyond the 3 year LTS period for the .NET Core 2.1 train overall.

Excellent news. Thank you for listening to your customers.

It's going to take us a very long time to port our old MVC app over as we've been on MVC since CTP3 and have just about every extension point used. This covers our concerns.

@DamianEdwards That’s great news! Just wondering though, is this fixed to 2.1.x or will this be updated to 2.2.x if that ends up becoming a LTS release? There has been a lot of effort going into 2.2 and it isn’t even released yet. And since it continues with netstandard compatibility and runs fine on the full framework, it would be kind of a waste to skip this completely for the extended support.

@poke while I understand your concern, we have to draw a line somewhere, and in this case we think it's better to keep the version aligned with the LTS that preceeds it. This is the trade off customers must decide for themselves when choosing between an LTS or Current train. New features don't come to LTS as they are about stability. The feedback was for longer term support and we have a train for that already so this is an extension of the train. 2.2 will not become LTS.

@DamianEdwards Yeah, I understand that, thanks for your reply. I was just asking because the last comment on this was that it hasn’t been decided yet, so I just wanted to know if this extended support would carry forward iff 2.2 became LTS.

And I think it’s important enough to highlight this so that people will not upgrade their framework apps to 2.2 if they have to rely on this extended support. Otherwise they will have to downgrade again.

New features don't come to LTS as they are about stability.

That does not really match the previous LTS decisions though.

@poke

That does not really match the previous LTS decisions though.

This confused me. In what way? Are you referring to the fact that 1.1 was added to the 1.x LTS train? If so, that was an anomaly of our first release train that won't be repeated. Moving forward, our intent is to get more consistent with which releases become LTS vs. Current (i.e where do I get stability vs. features).

@DamianEdwards I was mostly referring to the fact that every release so far has been a large feature release, and each LTS decision was usually made in retrospect (at least publicly).

@poke OK. Well, so far we've had 4 releases (1.0, 1.1, 2.0, 2.1) with the 5th coming shortly (2.2). Of those, only 1.0 and 2.0 were initially intended to be LTS, but due to a number of factors (mostly related to us being really new at doing engineering this way 😉) we ended up with 1.0, 1.1 and 2.1 being the LTS trains. 2.0 and 2.2 are (were, will) Current releases. At this stage, 3.0 will almost certainly be Current also (causing 2.2 to enter the Current "grace" period of 3 months) before 3.1 becomes the 3.x train LTS. Our hope is after that, the pattern and cadence will be more consistent (we'd love that) but so far our crystal ball has failed us.

@DamianEdwards Thanks for the insights! 😄 (Btw. I wasn’t trying to argue about this, I was just curious ;) )

A bigger issue for us is new REST APIs hosted in-process by legacy applications that aren't likely to move off .NET Framework any time soon. At least we know not to progress beyond .NET Standard 2 supporting libraries and ASP.NET Core 2.1 now! It's good the LTS period will be extended

Hey all, a quick question: What about those of us consuming native packages in the form of C++/CLI? Is that going to be supported in .Net Core anytime soon, or are we orphaned unless we do a massive rework to use P/Invoke?

@lokitoth - that would be a good question for the https://github.com/dotnet/core folks because it's more general than just ASP.NET Core.

@lokitoth yes, that will be supported, see https://github.com/dotnet/coreclr/issues/18013

o.O How did I miss that?

Okay, then I have no problems with this.

@danroth27 Could you tell us the impact of this issue for Client-Side-Blazor?

@Slkebe I don't expect any impact. Client-side Blazor apps are independent of whatever runtime or platform you decide to run on the server.

@danroth27 In my understanding, Client-side Blazor can run on mono because dependent Microsoft.AspNetCore.* packages target netstandard.
Am I missing something? Blazor has to keep targeting Microsoft.AspNetCore.* 2.1.X?

@Slkebe The client-side Blazor libraries only depend on components that will continue to target .NET Standard (like Microsoft.Extensions.* and friends). The server-side parts of Blazor that depend on ASP.NET Core will target .NET Core as described in this issue.

https://blogs.msdn.microsoft.com/dotnet/2018/11/05/announcing-net-standard-2-1/

What's the decision now? Target on .net standard 2.1 ?

@John0King There's no new decision.

This is bananas! B A N A N A S

i’m sympathetic to your point of view.

Apologies if this has already been brought up, but what about use cases where I just want to use Kestrel+some middleware as part of a non ASP.NET application? Will I have to pull in the entire 3.0 tree (which is not ideal, as my use case involves defining a custom SDK for consumers), or is this use case not supported on 3.x?

Currently I'm developing a ASP.NET Core application running on .NET Framework, because of the the included libraries. I'm using ASP.NET Core because of it's multi-auth - capabilities. I'm feeling fooled and dead locked.

I'm using ASP.NET Core because of it's multi-auth - capabilities.

@FlorianGrimm What specifically? Microsoft.Owin provided similar auth functionality for ASP.NET 4.

It's a hybrid app one source code (.exe) running on on-premises and azure, currently using windows auth, aad, basic auth and anonymous.

@FlorianGrimm Which library dependencies prevent you from using .NET Core?

Microsoft.Office.Project.Schema, Microsoft.SqlServer.TransactSql.ScriptDom and Microsoft.SharePointOnline.CSOM.

I hope the SharePoint Team will finish
https://sharepoint.uservoice.com/forums/329220-sharepoint-dev-platform/suggestions/16585795-support-net-core-with-csom
and I find other options than ilspy.

Any way I like ASP.NET Core and I hope the other Microsoft Teams will provide more .NET Core assemblies.

We periodically close 'discussion' issues that have not been updated in a long period of time.

We apologize if this causes any inconvenience. We ask that if you are still encountering an issue, please log a new issue with updated information and we will investigate.