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: Breaking changes to Microsoft.AspNetCore.App in 3.0 #3757
Comments
Two points concern me about the announcements (I'll combine my comments here even though they also relate to aspnet/Announcements#324 and #3753):
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 I suspect there's a feeling that the use of these other non- For some concrete examples, here's some of the ASP.NET Core packages I use in Wyam that are impacted by these announcements:
These packages are consumed by various Wyam
A GitHub search for Particularly, I'm worried about these two general use cases:
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. |
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. |
@daveaglick thanks for detailing your concerns. Allow me to share more technical details to see if they address your concerns.
|
I think it's fair to say that anything that depends on the
Will inherently need to target ASP.NET Core and thus .NET Core.
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.
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. |
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. |
@natemcmaster Thanks for the reply. It does put me a little more at ease, particularly this part:
That addresses my main concern - I understand and can live with the This follow-up comment from @davidfowl gave me pause though:
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. |
I'm confused about how <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 |
@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. |
@daveaglick which independent components? |
@davidfowl See my first comment above - I personally use:
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." |
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. |
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. |
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.
I think if it this way:
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. |
Great changes |
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. |
This is a discussion item for aspnet/Announcements#325
The text was updated successfully, but these errors were encountered: