Aspnetcore: Discussion: Breaking changes to Microsoft.AspNetCore.App in 3.0

[natemcmaster]

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

[daveaglick]

Two points concern me about the announcements (I'll combine my comments here even though they also relate to https://github.com/aspnet/Announcements/issues/324 and #3753):

we will stop producing many of the NuGet packages that we have been shipping since ASP.NET Core 1.0.

ASP.NET Core will only run on .NET Core starting from 3.0. Moving forward, you can simply think of ASP.NET Core as being part of .NET Core.

I understand why the team is moving this direction (at least I think I do) and it makes sense in the context of ASP.NET Core being solely a framework for web application development. If all I want to do is write an ASP.NET Core application then this all seems perfectly reasonable. _However_, ASP.NET Core has become much more than just a self-contained framework for some library authors (myself included).

I'm relieved to see that at least the Microsoft.Extensions packages will still be published to NuGet as netstandard (this would be an even bigger deal if not, since those packages are more widely considered to be "utility" libraries for use outside ASP.NET Core). However, moving other packages to FrameworkReference (which apparently isn't even well-defined for library authors yet, and which I don't have a ton of confidence will get fully worked out before 3.0 ships) and dropping netstandard support has some big impacts for those libraries that do currently depend on these other packages.

I suspect there's a feeling that the use of these other non-Microsoft.Extensions libraries outside of ASP.NET Core itself is minimal within the community, but I've seen their application steadily grow and am disappointed by the loss of opportunity this represents. It means anyone building general-purpose libraries the depend on them will need to 1) figure out how to manage working with FrameworkReference in a library context and all the challenges/differences that entails and 2) drop netstandard as a target, which may not be a huge deal, but is disappointing nonetheless as it has transitive implications and doesn't go with the ".NET Standard is what libraries should be targeting" ethos.

For some concrete examples, here's some of the ASP.NET Core packages I use in Wyam that are impacted by these announcements:

• Microsoft.AspNetCore.Hosting - powers the embedded preview web server
• Microsoft.AspNetCore.Kestrel - powers the embedded preview web server
• Microsoft.AspNetCore.StaticFiles - allows the preview server to serve up the generated static files
• Microsoft.AspNetCore.WebSockets - drives the LiveReload functionality in the preview server
• Microsoft.AspNetCore.Razor.* - provides Razor template parsing and compilation for static site generation
• Microsoft.AspNetCore.Mvc.Razor (and related) - allows Razor templates to act like ASP.NET Core MVC with layouts, partials, tag helpers, etc.

These packages are consumed by various Wyam netstandard support libraries because Wyam can be used from clients in both .NET Framework and .NET Core or be embedded within other applications (LINQPad is a favored client). But that's just my libraries - I know of several other projects off the top of my head that rely on one or more of these:

• RazorLight
• Gazorator
• Nancy (which has been planning on implementing ASP.NET Core Razor support at some point)

A GitHub search for <PackageReference Include="Microsoft.AspNetCore.Hosting" currently produces 5,916 results and <PackageReference Include="Microsoft.AspNetCore.Mvc.Razor" currently produces 1,382 results. Many of those are references for ASP.NET Core applications, but browsing through the results shows a wide variety of other applications and libraries as well.

Particularly, I'm worried about these two general use cases:

• Embedded web servers (including web sockets, static files, and all the other optional ASP.NET Core functionality)
• Razor template parsing (with or without MVC-like conventions and support)

Just for those use cases alone I imagine there's a large potential set of consumer libraries beyond ASP.NET Core applications, and I'll guess there's other good general use cases I haven't thought of too.

TL;DR: I can't help but feel like these changes "break" the way .NET is meant to be consumed and begin to lock ASP.NET Core into a very narrow set of use cases while removing the ability to play nicely with more conventional .NET library development.

[gulbanana]

FrameworkReference is a great option to have, but can’t it be just an option? So much work has been done to modularise this functionality and it would be a real waste to lose that.

ASP.NET Core running on .NET Core is fine, but libraries which are ok with only supporting .NET Core in turn should be able to continue using bits of it as libraries.

[natemcmaster]

@daveaglick thanks for detailing your concerns. Allow me to share more technical details to see if they address your concerns.

• We are not deprioritizing or disabling the ability to author a class library that depends on ASP.NET Core API. The ASP.NET Core team will ship packages like this, too, so this is something that must work in 3.0. For example, Microsoft.AspNetCore.DataProtection.StackExchangeRedis doesn't qualify to be part of Microsoft.AspNetCore.App (it has a 3rd party dependency) so this will ship as a NuGet package. Wyam, RazorLight, Nancy, and others will also be able to ship their class libraries as NuGet packages with a dependency on ASP.NET Core's API.

• Microsoft.Extensions in 2.x can be used outside of ASP.NET Core scenarios, and that will still be true in 3.0.

• Class and app library authors can continue to consume these Microsoft.Extensions as PackageReference. If a project also has a FrameworkReference and PackageReference to the same API, the SDK will de-duplicate and resolve version conflicts. It already handles this for System.* NuGet packages and netstandard2.0, and we are planning to use a similar approach for ASP.NET Core 3.0. See https://github.com/aspnet/AspNetCore/issues/3609.

• <FrameworkReference> is primarily a change to the way an application compiles. The ASP.NET Core runtime APIs aren't changing much in terms of layering and design. You should still be able to write an app or library that uses Microsoft.AspNetCore.* APIs for non-web-server reasons, but those API will only be available for libraries and projects using the netcoreapp3.0 target framework.

[davidfowl]

@daveaglick

I think it's fair to say that anything that depends on the HttpContext is tied to ASP.NET Core. So anything like this:

Embedded web servers (including web sockets, static files, and all the other optional ASP.NET Core functionality)

Will inherently need to target ASP.NET Core and thus .NET Core.

@gulbanana

FrameworkReference is a great option to have, but can’t it be just an option? So much work has been done to modularise this functionality and it would be a real waste to lose that.

That gives the illusion that they are indeed usable as individual packages. When they eventually will land in an application that is shipping all of these components together on a specific ship cycle.

• We don't test newer versions of ASP.NET Core on older versions of .NET Core
• We don't test mixing and matching versions of the various ASP.NET Core packages versions

This change makes that a bit more clear that ASP.NET Core is indeed a unit that ships together and isn't meant to be used peacemeal (at least these core pieces).

That said, there are likely some refactoring that could be factored out (like Razor runtime support). I do think ASP.NET Core itself though shouldn't get the same treatment, it is a platform.

[poke]

With EF Core being removed from the shared framework, what is the story on Identity? Microsoft.AspNetCore.Identity.EntityFrameworkCore is the default store implementation and (obviously) has a reference on EF Core. So this cannot be part of the shared framework itself and will require a separate reference. But what will happen to Microsoft.AspNetCore.Identity itself?

Especially with the move to Identity Server as a simple to set up solution, I believe that in-app identity management will continue to become less interesting. Identity will become more like a specialized thing to set up when you really need it, while the average application will use external authentication providers using open protocols like OIDC. So I would like to see Identity to be removed from the shared framework as well, if only to make the choice to use Identity a more explicit one and to instead promote the use of alternative ways for authentication.

[daveaglick]

@natemcmaster Thanks for the reply. It does put me a little more at ease, particularly this part:

able to ship their class libraries as NuGet packages with a dependency on ASP.NET Core's API

That addresses my main concern - I understand and can live with the netstandard -> netcoreapp move.

This follow-up comment from @davidfowl gave me pause though:

This change makes that a bit more clear that ASP.NET Core is indeed a unit that ships together and isn't meant to be used peacemeal (at least these core pieces).

I understand there are resource constraints and that the team has a mandate to build a web application framework. That said, there are a lot of really cool components comprising ASP.NET Core that stand on their own, and a lot of work has already gone into making them (mostly) independent. If I know one thing about the OSS community it's that we're resourceful and will use whatever is available to build cool shit.

Even though it's probably a small fraction of the overall ASP.NET Core constituency, I'd urge the team to keep in mind there are users that think of it as more than _just_ a web application framework, want to use those components piecemeal, and have a good reason for doing so. And not just for those specific use cases I've detailed above, but for all the future use cases I haven't thought of too.

[vcsjones]

I'm confused about how Sdk and FrameworkReference work together. For example, if in a few months I have a WPF app that needs to use parts of ASP.NET Core - say for query string generation with Microsoft.AspNetCore.WebUtilities - would I be able to do something like this?

<Project Sdk="Microsoft.NET.Sdk.Wpf">
  <PropertyGroup>
    <TargetFramework>netcoreapp3.0</TargetFramework>
    <OutputType>WinExe</OutputType>
  </PropertyGroup>
  <ItemGroup>
    <FrameworkReference Include="Microsoft.AspNetCore.App" />
  </ItemGroup>
</Project>

Today I can do this using Microsoft.AspNetCore.WebUtilities since it is netstandard.

[poke]

@vcsjones You can generally use multiple SDKs and framework references within the same project. So yeah, you will be able to just add a framework reference to ASP.NET Core when you need to reference something of it. The framework reference basically acts as a replacement to the package reference.

[davidfowl]

@daveaglick which independent components?

[daveaglick]

@davidfowl See my first comment above - I personally use:

• Microsoft.AspNetCore.Hosting
• Microsoft.AspNetCore.Kestrel
• Microsoft.AspNetCore.StaticFiles
• Microsoft.AspNetCore.WebSockets
• Microsoft.AspNetCore.Razor.*
• Microsoft.AspNetCore.Mvc.Razor.*

But my concern is more about being able to use ASP.NET Core components independently _in general_. For example, I only just started to use Microsoft.AspNetCore.WebSockets last week. If this discussion had happened before then, and no one spoke up to advocate for that particular library being carved out, would I have been sunk had I needed it in the future? You folks are doing a ton of really cool stuff and I want to use it in all sorts of interesting and unforeseen ways.

I guess it comes down to a question of who the customers for ASP.NET Core are and who the team is committed to supporting. If the answer is "ASP.NET Core is a web framework and any other use is unsupported and at your own risk" then that would be good to know, however unfortunate. I hope the answer is more like "ASP.NET Core is a collection of libraries that comprise a web framework but can also be used to build web related functionality into your own libraries and applications."

[davidfowl]

We’re looking to replace the WebHost with the generic host (which is Microsoft.Extensions) and thus packages.

Razor warrants a larger discussion about what feature set we need to make available for all platforms outside of MVC. Today things aren’t factored that way and you need to pull in big chunks of MVC to do Razor properly.

The other components you mention are part of asp.net core and are not independent. Middleware is tied to the tech (basically anything that touches the HttpContext). I’m actually not sure what you mean by independent here. You just happen to be using pieces of them instead of all but that’s not independent, as they ship as a suite. Some things are truly coupled and others aren’t we’re trying to find that balance.

[davidfowl]

I hope the answer is more like "ASP.NET Core is a collection of libraries that comprise a web framework but can also be used to build web related functionality into your own libraries and applications."

No that’s exactly what ASP.NET is not. That was the .NET Core 1.0 vision that we’ve moved away from. We’re now a platform. We ship a monolith that versions together with .NET Core and we don’t ship or test them separately.

[natemcmaster]

@poke: With EF Core being removed from the shared framework, what is the story on Identity?

Microsoft.AspNetCore.Identity remains in the shared framework. If you use EF Core, you can pull in Microsoft.AspNetCore.Identity.EntityFrameworkCore as a package reference.

@vcsjones: I'm confused about how Sdk and FrameworkReference work together.

I think if it this way:

• Sdk maps to the primary IDE behavior you want. i.e. does debug launch a browser or a Windows app?
• <FrameworkReference> is like a collection of <Reference> items. They control what API is available to the compiler.

We're considering having the Sdk you set _imply_ a set of FrameworkReference's, but haven't committed to that yet until we think we have a sensible set of defaults that works well for Wpf, WinForms, AspNetCore, class libraries, and test projects.

[dotnetchris]

Great changes

[aspnet-hello]

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.