Aspnetcore: Discussion for ASP.NET Core 2.0.0-preview2 high-level planning

Created on 15 May 2017  路  33Comments  路  Source: dotnet/aspnetcore

Discussion for aspnet/Announcements#243

Most helpful comment

@bradwilson we could open that package up, but we don't have a dependency-trimming-on-publish feature for .NET Framework like we do for .NET Core 2.0 (the runtime store and publish target manifests). So, if you used it on .NET Framework, you'd end up with ~180 assemblies in your application's output folder. We didn't want to lead customers to that outcome.

All 33 comments

Can you comment on this? Could this be something of benefit in Universal projects too?

Finalize design-time service provider

@ericwj it's to do with this issue: https://github.com/aspnet/DependencyInjection/issues/524

Curious about this:

Excludes the Microsoft.AspNetCore.All meta-package. This package will remain netcoreapp2.0 only as it is intended to be used along with the .NET Core 2.0 runtime store

Is there a technical reason? It seems like you're punishing .NET Framework users by saying they must continue to reference the dozen+ packages individually (not to mention that it makes moving from netcoreapp to net4x slightly more challenging, because you can't just change the TFM).

@bradwilson we could open that package up, but we don't have a dependency-trimming-on-publish feature for .NET Framework like we do for .NET Core 2.0 (the runtime store and publish target manifests). So, if you used it on .NET Framework, you'd end up with ~180 assemblies in your application's output folder. We didn't want to lead customers to that outcome.

@DamianEdwards Of course. Totally makes sense. 馃樅

yeah, that would've been a bit of a trap. i was planning to reference .All from a netstandard library and now know to avoid it 馃憤

I'm curious about why the runtime store could have an effect on throughput. Something to do with crossgen..?

I'm curious about why the runtime store could have an effect on throughput. Something to do with crossgen..?

Yes, it's because of crossgen.

How about refactoring of Microsoft.AspNetCore.Razor https://github.com/aspnet/Razor/issues/1084 ? Any update update about this?

Thank you, But what about adding identity options to SPA Services templates, it will be useful because we need a best practice to manage authorization in Angular (for example) side by side with Identity.

Fix issues of running on .NET Framework by way of:

  • Updating code to use new APIs in netstandard2.0
  • Disabling the feature when running on .NET Framework
  • Cross-compiling to net461 (last resort)

This doesn't make sense. Disabling the feature should be a last resort.
IIRC .NET Framework 4.6.1 will support .NET Standard 2.0 in its entirety, so in what cases would a feature not work on the full framework?

@CMircea My understanding is because .Net Core 2.0 (a _superset_ of .Net Standard 2.0) has APIs available that aren't in .Net Framework 4.6.1 (a _different superset_ of .Net Standard 2.0).

I think the ASP.Net team has said that since they can build up .Net Core just as fast as they can build up ASP.Net Core, but the same isn't true of the slower moving full Framework, that it can end up that .Net Core gets APIs added for the purpose of making ASP.Net Core better, hence the possible discrepancy.

  • Kestrel

    • Edge-server readiness features, e.g. timeouts, limits

:tada: :+1: :rocket: :heart_eyes:

@thiennn what specifically? @rynowak can answer any questions you have about the refactoring.

@davidfowl , I thought might related to issues below and we have been waiting for a long time, since migrated from project.json to csproj

@CMircea I updated it to hopefully be clearer. We'll only disable the feature if the APIs required don't exist in .NET Framework at all, and there is no suitable workaround.

@DamianEdwards, thanks!

Disabling the feature when running on .NET Framework if APIs are only available in netcoreapp2.0

Is there a summary of what features those might be? Perhaps that's still being worked out

great stuff, edge support especially :)

one of them was mentioned in the asp.net community standup - there's a cert management thing in there which can allow devs to auto-update what i think was an iis express cert from an error page using some new core-only apis. in .net framework the error page just won't have that convenience option, but will otherwise function the same

@aL3891 @gulbanana so far, that's the only one we're aware of.

seems like a pretty harmless omission.

How about adding identity options to SPA Services templates, it will be useful because we need to manage authorization in SPA frameworks such as Angular side by side with ASP.NET Identity.

Looking at number of reactions/comments to https://github.com/aspnet/JavaScriptServices/issues/548, sample authentication is most wanted feature for SPA.

Just a note that some of the planned work has been moved out this release, either to the next 2.0.0 release, or a release after that, e.g. 2.1.0. I've updated the announcement and we'll include more detail where applicable in the next releases' planning announcement.

@DamianEdwards Is there a way we can see what has been moved out? Like, a new high-level planning issue for vnext or something? (just to keep an eye on what you kind folks are thinking about wanting for the future, etc).

cheers!

I noticed aspnetcore-ci-dev MyGet feed is now versioning AspNetCore packages with the preview3-* tag. - https://dotnet.myget.org/feed/aspnetcore-ci-dev/package/nuget/Microsoft.AspNetCore.All

Is this tag meant to be in line with the GitHub milestones on the Announcements repo?
https://github.com/aspnet/Announcements/milestones

Are we waiting for internal notes/announcements to be filtered through to the public repos?

@PureKrome that's coming, I'll post that once we're closer to shutting down this milestone. For now I've updated the current milestone planning announcement so you can see what's been cut.

@shaunol the builds always just produce the next logical pre-release version after we branch for the current release. That is, aspnetcore-ci-dev now contains builds for the release after preview2. For preview2 builds you should use aspnetcore-release.

Do we need any preview version of Visual Studio 2017 for this? or the standard Visual Studio 2017 v15.2 is enough?

Hi everyone,

I've got a question. If you don't want to have further discussion in this particular issue then let me know and I can ask in a new issue.

The question: What is the full list of 'edge-server readiness' features?

I'm mostly asking for educational purposes as I'm interested in server-side software myself, and it'd be cool to have a comprehensive list of best-practice features for a production-grade server application.

Thank you.

/cc @davidfowl @halter73

@Lothy Kestrel added a few more limits which are briefly described in the "Kestrel Improvements" section of this blog post. One thing that missing in that blog post is the min response data rate, but you can use it just like the min request body data rate. You just need to change all instances of "RequestBody" to "Response". Otherwise, the APIs are identical.

Even prior to 2.0, Kestrel enforced various limits. You can see all the new and old limits with their default values in KestrelServerLimits. Right now, we're finishing up the official documentation.

Now that we've added these new configurable limits, we now support running Kestrel exposed to the internet without a reverse proxy being required to fill in the gaps. Of course, you're still welcome to continue using a reverse proxy if that works better for your scenario.

This issue is being closed because it has not been updated in 3 months.

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

Was this page helpful?
0 / 5 - 0 ratings