New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
natemcmaster opened this Issue Oct 29, 2018 · 203 comments

Comments

Projects
None yet
@natemcmaster
Member

natemcmaster commented Oct 29, 2018

This is a discussion item for aspnet/Announcements#324.

@poke

This comment has been minimized.

Contributor

poke commented Oct 29, 2018

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.

@natemcmaster natemcmaster modified the milestones: 3.0.0, Discussions Oct 29, 2018

@mythz

This comment has been minimized.

mythz commented Oct 30, 2018

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

@PinpointTownes

This comment has been minimized.

PinpointTownes commented Oct 30, 2018

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

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

This comment has been minimized.

John0King commented Oct 30, 2018

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

This comment has been minimized.

mythz commented Oct 30, 2018

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

This comment has been minimized.

iJzFan commented Oct 30, 2018

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

@Sebazzz

This comment has been minimized.

Sebazzz commented Oct 30, 2018

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

This comment has been minimized.

gulbanana commented Oct 30, 2018

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

This comment has been minimized.

Contributor

benaadams commented Oct 30, 2018

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 #3757 (comment) 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

This comment has been minimized.

John0King commented Oct 30, 2018

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

@dasMulli

This comment has been minimized.

Contributor

dasMulli commented Oct 30, 2018

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

This comment has been minimized.

gulbanana commented Oct 30, 2018

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

@dasMulli

This comment has been minimized.

Contributor

dasMulli commented Oct 30, 2018

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:

img_6086 3

@gulbanana

This comment has been minimized.

gulbanana commented Oct 30, 2018

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

This comment has been minimized.

Sebazzz commented Oct 30, 2018

@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

This comment has been minimized.

Contributor

dasMulli commented Oct 30, 2018

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

This comment has been minimized.

gulbanana commented Oct 30, 2018

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 comment has been minimized.

yaakov-h commented Oct 30, 2018

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

This comment has been minimized.

Member

davidfowl commented Oct 30, 2018

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

This comment has been minimized.

yaakov-h commented Oct 30, 2018

@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

This comment has been minimized.

Member

davidfowl commented Oct 30, 2018

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

@gulbanana

This comment has been minimized.

gulbanana commented Oct 30, 2018

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

This comment has been minimized.

yaakov-h commented Oct 30, 2018

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

@TsengSR

This comment has been minimized.

TsengSR commented Nov 8, 2018

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

@gulbanana

This comment has been minimized.

gulbanana commented Nov 8, 2018

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.

@hrumhurum

This comment has been minimized.

hrumhurum commented Nov 8, 2018

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

This comment has been minimized.

SaebAmini commented Nov 9, 2018

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

@thatnerdyguy

This comment has been minimized.

thatnerdyguy commented Nov 9, 2018

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?

@wahmedswl

This comment has been minimized.

wahmedswl commented Nov 12, 2018

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

@benaadams

This comment has been minimized.

Contributor

benaadams commented Nov 12, 2018

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

@wahmedswl

This comment has been minimized.

wahmedswl commented Nov 12, 2018

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

Thanks

@benaadams

This comment has been minimized.

Contributor

benaadams commented Nov 12, 2018

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

@DamianEdwards

This comment has been minimized.

Member

DamianEdwards commented Nov 12, 2018

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.

@chrisjsmith

This comment has been minimized.

chrisjsmith commented Nov 13, 2018

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.

@poke

This comment has been minimized.

Contributor

poke commented Nov 13, 2018

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

@DamianEdwards

This comment has been minimized.

Member

DamianEdwards commented Nov 13, 2018

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

@poke

This comment has been minimized.

Contributor

poke commented Nov 13, 2018

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

@DamianEdwards

This comment has been minimized.

Member

DamianEdwards commented Nov 13, 2018

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

@poke

This comment has been minimized.

Contributor

poke commented Nov 13, 2018

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

@DamianEdwards

This comment has been minimized.

Member

DamianEdwards commented Nov 13, 2018

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

@poke

This comment has been minimized.

Contributor

poke commented Nov 13, 2018

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

@bencyoung

This comment has been minimized.

bencyoung commented Nov 14, 2018

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

@lokitoth

This comment has been minimized.

lokitoth commented Nov 14, 2018

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?

@Eilon

This comment has been minimized.

Member

Eilon commented Nov 14, 2018

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

@Suchiman

This comment has been minimized.

Suchiman commented Nov 14, 2018

@lokitoth yes, that will be supported, see dotnet/coreclr#18013

@lokitoth

This comment has been minimized.

lokitoth commented Nov 14, 2018

o.O How did I miss that?

Okay, then I have no problems with this.

@SIkebe

This comment has been minimized.

SIkebe commented Nov 16, 2018

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

@danroth27

This comment has been minimized.

Member

danroth27 commented Nov 16, 2018

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

@SIkebe

This comment has been minimized.

SIkebe commented Nov 17, 2018

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

@danroth27

This comment has been minimized.

Member

danroth27 commented Nov 17, 2018

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

@John0King

This comment has been minimized.

John0King commented Nov 17, 2018

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 ?

@khellang

This comment has been minimized.

khellang commented Nov 17, 2018

@John0King There's no new decision.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment