Skip to content
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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Assemblies being removed from Microsoft.AspNetCore.App 3.0 #3755

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

Comments

Projects
None yet
@natemcmaster
Copy link
Member

natemcmaster commented Oct 29, 2018

馃挕 Working draft: this list will may fluctuate as we continue to work on ASP.NET Core 3.0.

In ASP.NET Core 3.0, we plan to remove the following assemblies from Microsoft.AspNetCore.App. These APIs will still be available as NuGet packages.
To upgrade your project from ASP.NET Core 2.1 to 3.0, you may need to add several <PackageReference> items for the following

  • Microsoft.AspNet.WebApi.Client (cref #6552)
  • Microsoft.AspNetCore.Authentication.Facebook
  • Microsoft.AspNetCore.Authentication.Google
  • Microsoft.AspNetCore.Authentication.JwtBearer
  • Microsoft.AspNetCore.Authentication.MicrosoftAccount
  • Microsoft.AspNetCore.Authentication.OpenIdConnect
  • Microsoft.AspNetCore.Authentication.Twitter
  • Microsoft.AspNetCore.Authentication.WsFederation
  • Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore
  • Microsoft.AspNetCore.Identity.EntityFrameworkCore
  • Microsoft.AspNetCore.Identity.UI
  • Microsoft.AspNetCore.JsonPatch
  • Microsoft.AspNetCore.MiddlewareAnalysis
  • Microsoft.AspNetCore.Mvc.Razor.Extensions
  • Microsoft.AspNetCore.NodeServices
  • Microsoft.AspNetCore.Owin
  • Microsoft.AspNetCore.Razor.Design
  • Microsoft.AspNetCore.Razor.Language
  • Microsoft.AspNetCore.Server.Kestrel.Https (cref #4228 )
  • Microsoft.AspNetCore.SpaServices
  • Microsoft.AspNetCore.SpaServices.Extensions
  • Microsoft.CodeAnalysis.Razor
  • Microsoft.EntityFrameworkCore
  • Microsoft.EntityFrameworkCore.Abstractions
  • Microsoft.EntityFrameworkCore.Analyzers
  • Microsoft.EntityFrameworkCore.Design
  • Microsoft.EntityFrameworkCore.InMemory
  • Microsoft.EntityFrameworkCore.Relational
  • Microsoft.EntityFrameworkCore.SqlServer
  • Microsoft.EntityFrameworkCore.Tools
  • Microsoft.Extensions.Caching.SqlServer
  • Microsoft.Extensions.DiagnosticAdapter
  • System.Net.WebSockets.WebSocketProtocol (#6699)
@dustinmoris

This comment has been minimized.

Copy link

dustinmoris commented Oct 31, 2018

I think MVC packages should become additional NuGet packages too. MVC is great, but unlike vanilla ASP.NET Core it is extremely opinionated how a we application should be laid out which is really not everyone's cup of tea, let alone even fits with the paradigm of all .NET languages. I really believe the shared ASP.NET Core framework deserves to be MVC free or have a second MVC free version of it. What do you think?

@davidfowl

This comment has been minimized.

Copy link
Member

davidfowl commented Nov 2, 2018

What would the benefit be? How would this make the lives of people building ASP.NET Core applications better?

@CwjXFH

This comment has been minimized.

Copy link

CwjXFH commented Nov 3, 2018

Great! I just need what i need when i use asp.net core.

@dustinmoris

This comment has been minimized.

Copy link

dustinmoris commented Nov 3, 2018

@davidfowl

What would the benefit be? How would this make the lives of people building ASP.NET Core applications better?

For the same reasons why you don't include the packages listed on the top of this issue. I just think that it's always easier to add more packages into the framework that will be shipped with .NET Core 3.0 than to remove packages later down the line. Why don't you start adding the smallest common denominator to run a vanilla ASP.NET Core app and then offer the rest as NuGet packages. If this turns out to be an issue for developers then you can always add more stuff later, but you will not be able to remove things later as easily anymore.

@davidfowl

This comment has been minimized.

Copy link
Member

davidfowl commented Nov 3, 2018

Because we have to strike a balance with being useful by default as well.

@dustinmoris

This comment has been minimized.

Copy link

dustinmoris commented Nov 3, 2018

Ok, well I think vanilla ASP.NET Core is already useful (and I thought you think so too, otherwise why didn't you make it useful?), but if you have already set your mind on what should be in the framework and what not then nevermind ;)

@davidfowl

This comment has been minimized.

Copy link
Member

davidfowl commented Nov 3, 2018

If you were being a purist, you wouldn't have most of the middleware or MVC or SignalR in the box because they aren't strictly necessary. Drawing this line between what the default set of things should be and not is pretty much a gut feel and fuzzy thing (based on experience, looking at other platforms past and present and making a call). As of ASP.NET Core 3.0 we don't have plans to pull those out (at least right now).

@dustinmoris

This comment has been minimized.

Copy link

dustinmoris commented Nov 5, 2018

Yeah I know this is always a tough call to make, but I am sometimes not sure what the justification is for the tendency (by Microsoft) to bloat things more than necessary. The way how you position your own products on the market is how it is going to be perceived. ASP.NET Core is supposed to be the new modern composable and flexible web framework, but the way how you position everything is that ASP.NET Core is useless unless you force MVC + SignalR + Identity + EF down on everyone. In my opinion you have already made the call of where the lines should be drawn, that's why MVC and SignalR are not embedded in ASP.NET Core but a separate frameworks which can be added when desired, so why are you blurring these lines now? It feels inconsistent and I can't think of any value you get from it. Instead of just promoting ASP.NET Core + a thriving open source eco system you are promoting a very narrow web experience. All it does is create frustration with those who want to be slightly different and more work for yourself as you end up pushing things on people which they might not want.

It's not like people will not use MVC if you don't stuff it into the default framework. Make it a single NuGet package and nobody will complain that they have to get MVC from NuGet. It's more likely that more people will come and ask why you bloated the default framework with things they don't want like me.

I take that this is a discussion and still something which you guys might consider, so if there's one thing I would like you to ask is bring this question up with your team perhaps again and see if you're all really set on this or if you can soften towards my idea :)

P.S: Not sure if that's the case, but I hope that SignalR is a separate NuGet package as well. It's like as if you'd include Bootstrap and Angular2 into your default framework. If these two products were developed by Microsoft then you'd probably do it, but it wouldn't make sense and I think only because they are done by a third party you see how it doesn't make sense.

@forki

This comment has been minimized.

Copy link
Contributor

forki commented Nov 5, 2018

TBH I'd love to see more stuff removed from default installation. Especially MVC. This is what makes alternative Frameworks on top of ASP.NET Core even more attractive. Also I wonder why things like ContentResult live in MVC and not in core. It's used a lot in azure functions and now I always have to reference the MVC stuff - just for ContentResult.

@psibernetic

This comment has been minimized.

Copy link

psibernetic commented Nov 5, 2018

I think the point is more that it shouldn't really negatively impact you to have the MVC stuff in the ASPNET SDK. Most devs will be using it so shipping it that way is preferred over bloating restore load. If you don't want it, you can just not use it. Most of the packages listed above bring in 3rd party dependencies (json), have some heavy aspect (razor), or are conceptually separate from ASPNET and often referenced outside of the SDK (EFCore).

As much as I agree with defaulting to minimums to foster an equal playing field for OSS frameworks, that does have to be balanced. In the early days of core (beta and even 1.0) things were packages everywhere and that was WAY more confusing and restore took forever.

@forki

This comment has been minimized.

Copy link
Contributor

forki commented Nov 5, 2018

@psibernetic even if stuff is in separated packages the .net core installer can put these packages alreadyin local caches.

@dustinmoris

This comment has been minimized.

Copy link

dustinmoris commented Nov 5, 2018

@psibernetic You are the second person mentioning that it's important to balance, but what does that even mean? The balance between what? Let's not talk about extremes, because that's obviously not good, let's talk about realistic proposals here. If MVC is a single NuGet package, in which way does it impact usability? It really doesn't and that's my point. Thinking that you are going to solve one extreme by implementing the opposite extreme is narrow thinking. There's many in-between. The framework doesn't have to be bloated and MVC and SignalR doesn't have to be fragmented into 100 packages either. Both can be avoided at the same time.

Give me one real world case where having MVC as a single NuGet package would be confusing, the restore would take forever, or any of the other negatives which you have mentioned?

And talking about restore time...

IMHO it's more important to have fast starting containers or serverless architecture (as that's what has a real world impact on business) than having a slightly faster build on a developer machine. Yes, the latter is also hugely important and I want it to be blazingly fast, but if I'd have to rank the importance then I rather take a minor hit on my dev machine than my production infrastructure in the cloud. So keeping the footprint as small as possible is just (if not more) important than keeping the restore time down.

@gerardtoconnor

This comment has been minimized.

Copy link

gerardtoconnor commented Nov 5, 2018

What would the benefit be? How would this make the lives of people building ASP.NET Core applications better?

I think it is unwanted bloatware for all other users who are not using MVC, like CandyCrush pre-installed on my Windows 10 PC. Asp.net core preached it was becoming less opinionated with fully configurable, as needed middleware etc. dotnet templates allow for MVC to be a default included package without it needing to be baked into core?

There are many other frameworks out there like Nancy, ServiceStack, and Giraffe that all have their merits and should not have the bloat/conflicts with an unwanted/unneeded MVC force install. It just seems inconsistent given authentication, razor, EF etc are all packaged out but MVC, the golden child gets to be part of the core framework when it's not core?

If it is due to MVC being so tightly coupled to core that decoupling would be a ton of work, I can get that, but on the basis of it generally making some devs lives easier, seems lazy and very much like the old asp.net MVC mentality I hoped we were steering away from.

@mythz

This comment has been minimized.

Copy link

mythz commented Nov 5, 2018

.NET Core was supposed to be the lean modular clone of node.js for .NET but it doesn't look like it has any intention of replicating the characteristics that fosters its thriving, vibrant ecosystem - a small, flexible unopinionated core with features included in core benefiting all that thanks to not being bundled with any opinionated web framework, is ripe with experimentation enjoying a healthy number of popular frameworks with their own independent communities.

I mean I get the ASP.NET team believe they're building the best framework they can, but not everyone agrees with all the opinions being chosen or the level of complexity required to get something done. Everything in .NET Core was developed with the benefit of hindsight with a lot being inspired by what approaches was seen become successful on other platforms, by baking in opinions of what technologies to use you're starving the next innovation coming from .NET and even when the next thing does gather traction on other platforms ASP.NET Core will be at a disadvantage to replicate its success since we'll be forever paying the default "MVC tax" going forward where everyone is expected to use its dev model for all Web Apps ad infinitum.

Node's lightweight-ness also makes it suitable for developing a number of other use-cases like Electron, Native Mobile Apps, IOT, shell scripts, etc. i.e. none of which benefit from having a web framework bundled in the default install. The more bloated the default install becomes the less useful it becomes for usage in other scenarios.

IMO the default should be back to .NET Core's original vision of having a lean, modular core with the focus being on making it easier to add features (that everyone can take advantage of), i.e. not by bundling it by default and bloating the default install.

@natemcmaster

This comment has been minimized.

Copy link
Member Author

natemcmaster commented Nov 5, 2018

Thank you for the feedback. Let me share some thoughts.

  1. We are not trimming assemblies because we just feel like it. Each assembly we remove is a breaking change and adds to the cost of upgrading from 2.x to 3.0. These are the guiding principles we use to decide on what goes into Microsoft.AspNetCore.App: https://github.com/aspnet/AspNetCore/blob/master/docs/SharedFramework.md. The assemblies we are proposing to remove are missing some of the criteria for inclusion in the shared framework. Notably, these assemblies either: (1) have dependencies on 3rd party code that we have no ability to service (2) the assemblies themselves are being deprecated in 3.0 or (3) they implement protocols or auth mechanism which are highly subject to change (for instance, Facebook/Google/Twitter could decide tomorrow to change the way auth works)

  2. Removing MVC from Microsoft.AspNetCore.App is not something we would consider. While we recognize not every user references MVC in their application, we believe this is a central piece of ASP.NET Core's offering. We plan to keep this in Microsoft.AspNetCore.App.

  3. MVC has been part of Microsoft.AspNetCore.App since 2.1, but as you'll see in 2.1 "Empty Web" templates, you don't have to use MVC. Its presence in the shared framework does not force you to use it in your application. You're still welcome to use alternatives, write your own view framework, or use the more "raw" aspnetcore APIs to directly read and write HTTP requests and responses.

  4. @dustinmoris : I just think that it's always easier to add more packages into the framework that will be shipped with .NET Core 3.0 than to remove packages later down the line. Why don't you start adding the smallest common denominator to run a vanilla ASP.NET Core app and then offer the rest as NuGet packages. If this turns out to be an issue for developers then you can always add more stuff later, but you will not be able to remove things later as easily anymore.

    That is exactly what we are trying to do. It is easier to add than remove. We added too many things in 2.0, and we are re-adjusting back to what we believe is a maintainable set of things for the foreseeable road ahead. Most of the assemblies removed from Microsoft.AspNetCore.App will still be offered as NuGet packages. If we were to find later that 90% of all customers reference the same package, that's a good candidate for the shared framework. As mentioned in the guidance doc, however, how much an API is used is an important metric, but not the only factor we consider.

  5. "Vanilla" is subjective. For many of our users, MVC and SignalR are "vanilla".

  6. A few people have said that .NET Core was supposed to be this or that or some other thing. Things change, we gather user feedback, we observe how the product is used, and we attempt adjust the defaults to match what we think will benefit the largest number of customers. The adjustments proposed in this issue are a reflection of feedback we have received on .NET Core 2.x.

Final thought: this issue is not going to make everyone happy. If it seems as if we are ignoring your feedback, I apologize. Please recognize that we have hundreds of thousands of customers, and only a small number of them come to GitHub to share feedback. We also collect information from in-person visits, phone calls, emails, social media, customer support requests, blogs, Visual Studio telemetry, and more. All of this is part of what we consider as we make decisions and what is part of the default experience and what is not.

If something is not clear about our motivations or reasons, please let me know and I'll try to clarify.

@Bomret

This comment has been minimized.

Copy link

Bomret commented Nov 5, 2018

If you have so much direct customer contact, when was the last time you asked how many of them are using MVC and SignalR? Is there real usage metrics behind this stance on definitely keeping them instead of having each in one single NuGet package that can be very easily installed when needed?

@psibernetic

This comment has been minimized.

Copy link

psibernetic commented Nov 5, 2018

@dustinmoris including MVC in the shared runtime means it is shipped pre-compiled, this is a benefit that would be lost, which would increase startup times at a minimum, making it, IMO, a poor trade-off in your example of fast starting docker containers. In addition to that, every deploy would now need to ship the packages along with the app since it isn't in the runtime, this increases the deployment package size of every MVC app. Finally, any package dependent on MVC in the runtime also has to become a separate deployable, not sure how many if any this is since I can't find the full list.

All of that said, and mind you I have 0 affiliation with Microsoft or aspnet team, I COULD see a separate runtime shipped that was a barebones aspnetcore one IF the community really vocalized it and proved it was a major want. The mission is providing a great experience for as many applications and devs as possible and the fact at the moment is an incredibly high percentage of those benefit from MVC in the shared runtime. @natemcmaster is there a preferred way for the concerned individuals to vote for this for the future, GitHub issue perhaps, and is this a reasonable solution?

@natemcmaster

This comment has been minimized.

Copy link
Member Author

natemcmaster commented Nov 5, 2018

@psibernetic you're welcome to start a new GitHub issue for removing MVC from the shared framework, but as I stated above, removing MVC from Microsoft.AspNetCore.App is not something we would consider, so this issue is unlikely to gain traction within our team.

@Bomret Almost every real-world customer app we've inspected uses MVC in some way. There are many benefits of keeping it in the shared framework, and I don't see any clear reasons why we should remove it.

@dustinmoris

This comment has been minimized.

Copy link

dustinmoris commented Nov 5, 2018

@Bomret

This comment has been minimized.

Copy link

Bomret commented Nov 5, 2018

@natemcmaster I think @forki, @dustinmorris, @gerardtoconnor and @mythz have stated very sound reasons that I have not yet heard counter arguments against. Would have been very nice to have a base web runtime/lib that framework authors could build on top like nodejs instead of bundling opinionated stuff with it. As it was mentioned before, node is so successful because it doesn鈥檛 mandate too much but provides nice abstractions that you can built on top of. MVC would not be gone, it would just step down and become a choice to make among a variety of other web libs and frameworks. By including it, you make a stance for it. Of course most devs just take it as it is shipped with the runtime, instead of looking further. In my honest opinion, that just sounds like politics and marketing - no offense.

@forki

This comment has been minimized.

Copy link
Contributor

forki commented Nov 5, 2018

It's called "Microsoft.AspNetCore.App", why not create a second one "Microsoft.AspNetCoreMVC.App"?

Anyway I understand it's very hard to draw the line, but I think the general feedback here is that you folks have a growing number of people who likes what you did with aspnet core, but who doesn't really like the stuff like MVC, razor, EF or signalR.

@Bomret

This comment has been minimized.

Copy link

Bomret commented Nov 5, 2018

Indeed. You can count on the community to be vibrant enough to come with loads of ideas for libs and frameworks to handle api, web, websockets, templates, db access and so on. You guys would be providing one option for those with MVC, Razor, EF etc. but just not the only nor default one.

@dustinmoris

This comment has been minimized.

Copy link

dustinmoris commented Nov 5, 2018

@natemcmaster My mistake, I was actually talking about the shared framework in this issue here. I think the same reasons also apply to the meta package, but to be honest I am less bothered about that, because I can already reference individual packages instead of the meta package, but I cannot easily trim down a shared framework if I want to keep a container as small as possible, so your suggestion of opening a new issue for the shared framework makes sense 馃憤

@dustinmoris

This comment has been minimized.

Copy link

dustinmoris commented Nov 6, 2018

@natemcmaster Could you quickly confirm if I understood things correctly:

  • There will be a shared ASP.NET Core framework baked into the next .NET Core runtime (3.0), which means that ASP.NET Core gets shipped as part of the .NET Core installation on an environment.

  • Additionally there is a meta package called Microsoft.AspNetCore.App and Microsoft.AspNetCore.All which are a collection of NuGet packages for ASP.NET Core apps

  • The shared ASP.NET Core framework < the Microsoft.AspNetCore.App meta package which includes things like EF Core?

  • I can build an ASP.NET Core web app without having to include the Microsoft.AspNetCore.App meta package which contains EF Core, SignalR, MVC, etc. if I just want to create an extremely tiny API?

  • Whatever you guys are doing, it will be possible to create a Docker container with only the most minimal dependencies for ASP.NET Core in order to run a tiny API?

@davidfowl

This comment has been minimized.

Copy link
Member

davidfowl commented Nov 6, 2018

There will be a shared ASP.NET Core framework baked into the next .NET Core runtime (3.0), which means that ASP.NET Core gets shipped as part of the .NET Core installation on an environment.

Yes

Additionally there is a meta package called Microsoft.AspNetCore.App and Microsoft.AspNetCore.All which are a collection of NuGet packages for ASP.NET Core apps

No. There's a new concept called a FrameworkReference and Microsoft.AspNetCore.App will be one of those. Microsoft.AspNetCore.All will not exist in 3.0.

The shared ASP.NET Core framework < the Microsoft.AspNetCore.App meta package which includes things like EF Core?

No, it does not include EF.

Whatever you guys are doing, it will be possible to create a Docker container with only the most minimal dependencies for ASP.NET Core in order to run a tiny API?

With assembly trimming and the linker yes, not by removing packages because there won't be any for ASP.NET Core.

@mythz

This comment has been minimized.

Copy link

mythz commented Nov 6, 2018

@natemcmaster

We are not trimming assemblies because we just feel like it. Each assembly we remove is a breaking change and adds to the cost of upgrading from 2.x to 3.0.

The right place to do any corrections would be within the v3 major version window which is effectively the only time that changes like this could occur, i.e. the same time as other packages are removed.

Removing MVC from Microsoft.AspNetCore.App is not something we would consider. While we recognize not every user references MVC in their application.

It's called "Microsoft.AspNetCore.App" which logically reads as "reference this package" if you're creating an "ASP.NET Core App".

we believe this is a central piece of ASP.NET Core's offering. We plan to keep this in Microsoft.AspNetCore.App.

This is getting closer to the crux of the issue where it appears the goals of ASP.NET Core is moving away from fostering a lean, open node.js-esque style ecosystem. Is it the teams intention for everyone to conflate ASP.NET Core Apps as synonymous with MVC Apps? Some of the selling points of ASP.NET Core were "Pay to play" and decoupled "layering" but this suggests that an "ASP.NET Core App" is forever intended to = MVC App.

It would clearer for everyone involved if the packages were more explicit where:

  • Microsoft.AspNetCore.App => Base for all ASP.NET Core Apps
  • Microsoft.AspNetCore.Mvc => ASP.NET Core MVC App

But if "Microsoft.AspNetCore.App" is untouchable could we at least have an official "base line" meta package (or FrameworkReference) with just the core server features (i.e. without any opinionated libs), some potential naming:

  • Microsoft.AspNetCore.[Base | Bare | Lite | Basic]

("Core" would've also been appropriate but there's already an over usage of the term).

Without there being a official meta package/name it's not going to be as accessible as the currently recommended "Microsoft.AspNetCore.App" that's the recommended basis for all ASP.NET Core Apps.

Constraints breed innovation where if MVC could only run on the same playing field as everyone else maybe we could all have access to a feature that allows us to easily and explicitly declare which products (aka suite of packages) Apps need, e.g it could look something like:

  • Microsoft.AspNetCore.Mvc+SignalR+EF

Where everyone could easily declare and only install what they need and the tooling behind the scenes could combine the "Microsoft.AspNetCore.Mvc", "Microsoft.AspNetCore.SignalR" and "Microsoft.AspNetCore.EF" meta packages. (Or alt superior solution to fulfill the intent).

Its presence in the shared framework does not force you to use it in your application.

Sounds like the rationale for every monolith ever created. "You don't have to use everything we bundle, it's just there for your convenience".

You're still welcome to use alternatives, write your own view framework,

It's not as welcoming as you'd think, for example whilst we were developing our own "view framework" alternative to MVC and Razor we ran into magic behavior in .NET Core where the build would fail when running the standard command to publish a .NET Core project, i.e:

 dotnet publish -c Release

Which would fail with:

EXEC(1,11): error CS0246: The type or namespace name 'System' could not be found (are you missing a using directive or an assembly reference?) [C:\src\NetC
oreWebApps\WebApp\src\WebApp\WebApp.csproj]
EXEC(1,54): error CS0518: Predefined type 'System.String' is not defined or imported [C:\src\NetCoreWebApps\WebApp\src\WebApp\WebApp.csproj]
C:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.aspnetcore.mvc.razor.viewcompilation\2.0.0\build\netstandard2.0\Microsoft.AspNetCore.Mvc.Razor.ViewCompilation.targets(60,5):

Surprising behavior given we were developing an alternative to MVC which explicitly didn't reference MVC, Razor or include any .cshtml pages since its purpose was to build Apps without using them.

After scouring multiple GitHub threads trying out different workarounds I found others experiencing the same issue where the solution ended up opting out of MVC Razor compilation breaking builds with:

dotnet publish -c Release /p:MvcRazorCompileOnPublish=false

Which allowed the project to be published. During the time trialing different switches to fix the broken build we also discovered we could reduce our published footprint by the 150 .dlls in /refs/*.dll by opting out of the metadata that was unnecessarily bloating our .NET Core 2.0 Web App by opting out of metadata needed by Razor with:

<PreserveCompilationContext>false</PreserveCompilationContext>

So basically forced to play whack-a-mole to find out which switches we need to tell the tooling we're not using MVC to prevent it from breaking project builds and from outputting unnecessary metadata only MVC/Razor Apps need. It would've been much more preferable to start with a "base" metadata package where such issues couldn't be possible as the tooling couldn't assume every App was using MVC because the MVC bits wouldn't exist.

Whilst it's easy to say ASP.NET Core is still a welcoming platform that encourages experimentation, creation and usage of alternative "view frameworks", bundling prescribed opinionated Web Frameworks like MVC is just about the most hostile thing that could be done to discourage creation and usage of said alternatives. Taking a moment to have a look around at the number of popular alternatives emerging is a good gauge to see how inviting the platform is for them.

If it's intended that every ASP.NET Core App should include MVC than every other alternative "view framework" (including a single .cs file drop-in of ext methods) is going to appear to be more "heavy-weight" and cumbersome than using the bundled MVC, since they all need to be bundled with it + anything else the view framework needs.

In summary, it would be preferable if "MVC" was opt-in and not included in the .App package, but if the decision is irreversible, could we at least have an official base-line meta package base that doesn't include it?

Please recognize that we have hundreds of thousands of customers, and only a small number of them come to GitHub to share feedback.

IMO the demand for non bloated starting package is being under represented, anecdote: of all the C#/.NET project templates we've created for VS 2012, VS 2013, VS 2015, VS 2017 and .NET Core, consistently the most popular template by far has always been the "Empty" template, which was also a frequent criticism of classic ASP.NET that VS.NET's default empty ASP.NET Template wasn't Empty enough. This was when you could create an "Empty" classic ASP.NET .NET Framework without MVC, but now in the newer, lighter and more modular ASP.NET Core framework, MVC comes bundled within the minimum recommended starting package.

We also collect information from in-person visits, phone calls, emails, social media, customer support requests, blogs

People don't like bloat which is often equated with unremovable complexity, what's likely being requested is to make projects as simple as possible, which is what should be the focus and can be done without bloating default projects.

In my experience being explicit is simpler to reason about than bloated frameworks with magic behavior. If it's explicit you can interact with it, search for it, read about it, remove it, test running without using it (to see if it's the cause of issues) and it's visible when comparing projects of different configurations. But with the magic behavior of MVC tooling breaking builds of my mvc/razor-less project above, I had no idea which part of my project was triggering it, why it's even running, how to disable it or how to resolve it. I'm still not confident that my projects not using MVC aren't being slowed down because MVC is bundled or that it's generating a sub optimal output because it needs to accommodate for MVC or Razor.

Visual Studio telemetry, and more.

It's going to be hard to compare the telemetry of the popularity of a base-line meta package that doesn't exist, if it did IMO it would have more than enough popularity to merit it's inclusion. Previously "Microsoft.AspNetCore.All" aimed for the other end of the spectrum and included the universe but not the more useful inverse of having a minimal useful baseline.

It stands to reason if you're not building an MVC App and the option of choosing a base-line without it is just as accessible, why wouldn't you choose it over the more bloated starter option containing MVC?

@poke

This comment has been minimized.

Copy link
Contributor

poke commented Nov 6, 2018

@Bomret

Would have been very nice to have a base web runtime/lib that framework authors could build on top like nodejs instead of bundling opinionated stuff with it.

But that's exactly how it works. You are free to compose your application in the way you want to use it. If you don't want to use MVC, just don't add the middleware. Yes, the templates are opionated but you can change your app to do what you want, using whatever you want.

I think you are misinterpreting the shared framework a bit here. You just have to see it as a kind of standard library that ships with .NET Core. To make a Node reference: Imagine the current version of Express was bundled with Node. You don't have to use it but it's already there when you want to use it.

And as for MVC, I believe you are not exactly aware what MVC actually includes in ASP.NET Core. If you don't want to use controllers and Razor views, fine, but you will probably still use quite a lot MVC functionality in your app anyway.

@mythz

This comment has been minimized.

Copy link

mythz commented Nov 8, 2018

Yeah I think that's closer to containing a lot of the essentials to configuring an App up and getting it up and running. From the deps in Microsoft.AspNetCore.App we're also using:

  • Microsoft.Extensions.Primitives
  • Microsoft.AspNetCore.Http
  • Microsoft.AspNetCore.Http.Abstractions
  • Microsoft.AspNetCore.Http.Extensions
  • Microsoft.AspNetCore.Hosting.Abstractions
  • Microsoft.AspNetCore.Logging.Abstractions
  • Microsoft.Extensions.DependencyInjection.Abstractions
  • Microsoft.Extensions.Configuration.Binder
  • Microsoft.AspNetCore.Cryptography.KeyDerivation

So stuff like HTTP, Hosting, Logging and Configuration abstractions (useful for most HTTP apps) would also be nice to be included and anything else anyone deems appropriate. My only preference is to not have MVC/SignalR included.

@forki

This comment has been minimized.

Copy link
Contributor

forki commented Nov 8, 2018

@davidfowl

This comment has been minimized.

Copy link
Member

davidfowl commented Nov 8, 2018

@mythz Most of those are include transitively.

@forki 馃槅 Welcome to our world.

@dustinmoris

This comment has been minimized.

Copy link

dustinmoris commented Nov 8, 2018

We're not changing Microsoft.AspNetCore.App, we think it's something that a majority of users will need and use.

Famous last words. This this the justification of every bad decision - "WE think THEY need it".

You know what I think? Microsoft should start treating its developer base as independent intelligent engineers and not as sheep developers, and yes you guys have many sheep developers, who will follow and use whatever you throw at them, but it's the other, more vocal devs who will make a vibrant community and build new startups on the .NET stack.

Sometimes it's good to listen to power users.

@davidfowl

This comment has been minimized.

Copy link
Member

davidfowl commented Nov 8, 2018

Regardless, we're not going to change Microsoft.AspNetCore.App. I offered a compromise that I think satisfies the requirements here.

@NinoFloris

This comment has been minimized.

Copy link

NinoFloris commented Nov 9, 2018

@forki if you're using aspnet core you're confronted with DI anyway, better to make it include convenience methods by default (Get service, GetRequiredService and the likes are in that package). And hey F# cannot even create those on its own due to the missing T :> U constraint fsharp/fslang-suggestions#255 so 炉_(銉)_/炉

I would like to have that base shared framework @davidfowl mentioned... I think @mythz and @dustinmorris would both be ok with such an approach. This is also opportune for Saturn @Krzysztof-Cieslak

@forki

This comment has been minimized.

Copy link
Contributor

forki commented Nov 9, 2018

@natemcmaster

This comment has been minimized.

Copy link
Member Author

natemcmaster commented Dec 19, 2018

Updated the original post to include:

  • Microsoft.AspNetCore.Authentication.JwtBearer
  • Microsoft.AspNetCore.Authentication.OpenIdConnect

These are being pulled out of the shared framework and will ship as NuGet packages. These assemblies have a dependency on the IdentityModel APIs which do no yet fit the guidelines for the shared framework. We have begun working with the IdentityModel team and consider putting these back into the shared framework in the future. cref #6035

natemcmaster added a commit that referenced this issue Dec 19, 2018

Remove JwtBearer and OIDC authentication from the shared framework
These are being pulled out of the shared framework and will ship as NuGet packages. These assemblies have a dependency on the IdentityModel APIs which do no yet fit the guidelines the shared framework.

cref #3755
@natemcmaster

This comment has been minimized.

Copy link
Member Author

natemcmaster commented Jan 10, 2019

Update the original post to include Microsoft.AspNet.WebApi.Client. See #6552 (comment).

@simeyla

This comment has been minimized.

Copy link

simeyla commented Feb 21, 2019

I often get confused enough as it is what I need to include.

Talking Visual Studio - Am I supposed to open up the Microsoft.AspNetCore.App node and cross reference everything under there with what I may have individually installed?

I'm doing some housecleaning and see I have these packages. So which are redundant?

<PackageReference Include="Microsoft.ApplicationInsights.AspNetCore" Version="2.6.0-beta2" />
<PackageReference Include="Microsoft.AspNetCore.App" />
<PackageReference Include="Microsoft.AspNetCore.NodeServices" Version="2.2.0" />
<PackageReference Include="Microsoft.AspNetCore.SpaServices.Extensions" Version="2.2.0" />
<PackageReference Include="Microsoft.EntityFrameworkCore" Version="2.2.1" />
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="2.2.1" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="2.2.1">

I was quite surprised to see that even SpaServices and EntityFramework tools are currently included (which I hadn't realized before - and is great) - but I've also got some old 2.2.1 references which can't be helping anything.

Point being - can some better coordination work be done with Visual Studio team to ensure that the IDE is just a little more intelligent with understanding these mega packages and telling me it's safe to remove something - and then in v3 telling me I need to add it back in again ;-)

@natemcmaster

This comment has been minimized.

Copy link
Member Author

natemcmaster commented Feb 21, 2019

@simeyla thanks for the feedback. What you are saying is related to subject, but it's not exactly what this thread is about. Tooling to optimize package references would be a new Visual Studio feature. This feature could be generally useful, not only for this scenario, so I'd suggest sending this feedback to Visual Studio directly. In VS, use "Help > Send Feedback...". If you share the link after you create the post, I can forward it internally to our peer teams that work on VS.

In 3.0, we will eliminate the Microsoft.AspNetCore.App metapackage altogether and make lots of adjustments to which packages we ship. We've started documenting how to upgrade from 2.x to 3.0 and will continue to update this doc as we finalize the list of assemblies shipping in 3.0.

@Eilon Eilon modified the milestones: 3.0.0-preview4, Discussions Apr 5, 2019

@Eilon

This comment has been minimized.

Copy link
Member

Eilon commented Apr 5, 2019

Moving to 'Discussions' milestone because this item isn't tracking any work, but rather we will update it as details of the implementation change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can鈥檛 perform that action at this time.