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

[natemcmaster]

This is a discussion item for https://github.com/aspnet/Announcements/issues/324.

[poke]

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.

[mythz]

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

[kevinchalet]

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

[John0King]

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.

[mythz]

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.

[iJzFan]

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

[Sebazzz]

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.

[gulbanana]

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.

[benaadams]

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?

[John0King]

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

[dasMulli]

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.

[gulbanana]

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

[dasMulli]

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:

[gulbanana]

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.

[Sebazzz]

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

[dasMulli]

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.

[gulbanana]

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,

[yaakov-h]

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.

[davidfowl]

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?

[yaakov-h]

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

[davidfowl]

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

[gulbanana]

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.

[yaakov-h]

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

[terrajobst]

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

[davidfowl]

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

[kevinchalet]

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.

[Kukkimonsuta]

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.

[voltcode]

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?

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

[terrajobst]

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.

[khellang]

Don't make me think it's convergence

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

[kevinchalet]

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?

[terrajobst]

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.

[yaakov-h]

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?

[terrajobst]

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

[kevinchalet]

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.

[terrajobst]

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.

[poke]

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.

[kevinchalet]

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:

[davidfowl]

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.

[HaloFour]

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

[kevinchalet]

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.

[terrajobst]

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.

[terrajobst]

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

[masonwheeler]

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

[gulbanana]

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

[HaloFour]

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

[yaakov-h]

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.

[terrajobst]

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.

[daveaglick]

@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