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

[DamianEdwards]

Discussion for aspnet/Announcements#243

[ericwj]

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

Finalize design-time service provider

[DamianEdwards]

@ericwj it's to do with this issue: aspnet/DependencyInjection#524

[bradwilson]

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

[DamianEdwards]

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

[bradwilson]

@DamianEdwards Of course. Totally makes sense. 😺

[gulbanana]

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 👍

[gulbanana]

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

[davidfowl]

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.

[thiennn]

How about refactoring of Microsoft.AspNetCore.Razor aspnet/Razor#1084 ? Any update update about this?

[ikourfaln]

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.

[CMircea]

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?

[AdamDotNet]

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