aspnetcore 🚀 - Assemblies being removed from Microsoft.AspNetCore.App 3.0

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?

dustinmoris on 31 Oct 2018

👍30

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

davidfowl on 2 Nov 2018

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

CwjXFH on 3 Nov 2018

👍2

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

dustinmoris on 3 Nov 2018

👍7

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

davidfowl on 3 Nov 2018

👎5 😕2 👀1 👍1

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

dustinmoris on 3 Nov 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).

davidfowl on 3 Nov 2018

👍2

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.

dustinmoris on 5 Nov 2018

👍28

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.

forki on 5 Nov 2018

👍23

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.

aidapsibr on 5 Nov 2018

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

forki on 5 Nov 2018

👍1

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

dustinmoris on 5 Nov 2018

👍5

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.

gerardtoconnor on 5 Nov 2018

👍18

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

mythz on 5 Nov 2018

👍21 ❤3

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

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)
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.
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.
@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.
"Vanilla" is subjective. For many of our users, MVC and SignalR are "vanilla".
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.

natemcmaster on 5 Nov 2018

👍8 ❤6

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?

Bomret on 5 Nov 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?

aidapsibr on 5 Nov 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.

natemcmaster on 5 Nov 2018

@Natemcmaster: I'm on my phone now, but thanks for the explanation and I just
realised that this is about the metapackage while I was talking about the
shared framework.

dustinmoris on 5 Nov 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’t 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.

Bomret on 5 Nov 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.

forki on 5 Nov 2018

👍7

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.

Bomret on 5 Nov 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 on 5 Nov 2018

👍1

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

dustinmoris on 6 Nov 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.

davidfowl on 6 Nov 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?

mythz on 6 Nov 2018

👍13 ❤6

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

poke on 6 Nov 2018

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.

Like what?

dustinmoris on 6 Nov 2018

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.

Yes please do tell, comes across a bit patronising, most of us are involved in alternative frameworks built on core middleware/kestrel so we have a decent idea of what we're using, controllers and Razor views are a small subset of MVC, we know that. The F# frameworks, Giraffe/Saturn & Zebra, perform better than MVC with better routing and simplified processing model. In rendering, Zebra x2 faster than MVC on TechEmpower, this is why we rather keep it out by default. if assembly-trimming/linker is able to reduce footprint later then that is at least something but would be ideal if it was not included by default to allow a more even playing field for other frameworks, gain maximum draw to asp.net core platform.

gerardtoconnor on 6 Nov 2018

👍7 ❤3

@mythz from an organizational perspective you're right, there are some logical divisions here. However any subdividing comes with significantly added complexity and engineering overhead that takes time away from improving the product's features. When we expect a significant majority of customers to take advantage of the MVC components then it's just not worth the cost to split them out. The downsides for devs that don't use them are negligible, a few extra MB in the install directory and no runtime impact unless you load them.

Tratcher on 6 Nov 2018

I can only point to @mythz to illustrate the point. The more coupled things are, the more they get entangled. I mean Wat!? MVC influences the build of an Asp app even if you don’t reference it anywhere?!

@poke
As the others have already written: it is not. It is bundling stuff that has nothing to do with a base runtime. Image the express framework would have been bundled with node by default, you think the ecosystem would have become so vibrant and diverse?

I also absolutely don’t get how removing MVC, SingalR etc. from the base install and providing them as a single NuGet package each can be labeled as „added complexity“. Devs install extra packages in most cases anyway. And if providing them as extra packages would increase restore times „significantly“, they’ too fat anyway.

Bomret on 7 Nov 2018

👍7

@Tratcher

However any subdividing

The subdividing this is referring to is the decoupling of MVC so ASP.NET Core Apps could have a minimal useful baseline without any opinionated developer frameworks that prescribe what they should use to develop ASP.NET Core Apps.

comes with significantly added complexity and engineering overhead that takes time away from improving the product's features.

To clarify how this reads: it requires too much engineering overhead to remove unnecessary overhead from every ASP.NET Core App that doesn't use MVC because if MVC had to work like every other alternative framework that would significantly add complexity "to MVC".

If MVC requires significant complexity to work within the same extensibility options that every other alternative framework has to function within then that's indicative of a problem with MVC and any features added to make it work more seamlessly could be added to everyone's benefit. Just like dissecting a monolith the complexity of the tooling and runtime would be leaner and less complex with the added complexity moved to where it belongs into MVC and its integration/tooling.

Instead we ended up with the situation where MVC is entrenched in the default tooling which can break publishing projects and bloat the outputs of projects that don't use it. Since it doesn't work like everything else there's no way to tell it that you're using MVC or any way to tell it you're not using MVC, it's always assumed.

When we expect a significant majority of customers to take advantage of the MVC components

Well that's going to be expected, to the detriment of every other alternative it's the prescribed framework bundled in the default minimum recommended install, like Apple giving everyone a free U2 song whether they like it or not.

The downsides for devs that don't use them are negligible

Would devs benefit from a healthier ecosystem with more variety, options and innovation?

Do devs benefit from the added confusion and blurring definition of what an "ASP.NET Core App" is? "It used to be like node.js for .NET, but now it's more of an opinionated single vendor framework where essentially every App starts with a bunch of opinionated stuff that prescribes how you should build Web Apps, you can think of it as every App being pre-installed with express and its dependencies by default - you're expected to use it"

Do devs benefit from the special casing of MVC? It's not installed or updated like anything else and relies on hidden tooling and magic behavior that you have to scrounge around to know exists and disable. Special casing like this is what adds accidental complexity, when reasoning about your project you have to maintain a different set of rules for how MVC works vs how everything else works.

If it were explicit, it would improve readability and you could tell from the project configuration that it's an MVC App, e.g:

Microsoft.AspNetCore.Mvc

Which signals it's an MVC App and to install all the dependencies and auto configure all the bespoke tooling MVC needs - ideally using the same open extensible model everyone else has access to.

By keeping it in the default "Microsoft.AspNetCore.App" project you're forever tying it with every ASP.NET Core App and making it disadvantageous for anything better to come along. ASP.NET Web Pages was another Razor view framework added to ASP.NET years ago that was installed and also had its invasive magic behavior enabled by default. It came with its own Web Matrix IDE that's no longer supported or available for download so what we’re left with is a case where the complexity of a dead technology is forever embedded in classic ASP.NET and actively causes issues for other active Web Frameworks tying to use Razor .cshtml pages which forever need to carry around the baggage below to explicitly prevent Web Pages from breaking their view frameworks with:

<appSettings>
    <add key="webPages:Enabled" value="false" />
</appSettings>

To re-iterate the feature requests in order of preference would be to:

Change "Microsoft.AspNetCore.App" to be the minimal useful baseline for all ASP.NET Core Apps (i.e. w/o MVC).
Maintain a meta package like "Microsoft.AspNetCore.Base" that everyone not using MVC could use as the minimal useful baseline.

If none of these are going to be considered can we at least have a project-wide flag like mvc:enabled = false that all MVC tooling could check against to disable and prevent them from running?

mythz on 7 Nov 2018

👍11 ❤4

@mythz you're putting words in my mouth. The added complexity is not to MVC, it's to build infrastructure, packaging, installers, etc. necessary to create and ship yet another layer of components regardless of what that layering consists of.

If none of these are going to be considered can we at least have a project-wide flag like mvc:enabled = false that all MVC tooling could check against to disable and prevent them from running?

Can you be more specific about what tooling features you'd like to see disabled? That might be worth a separate issue.

Tratcher on 7 Nov 2018

@Tratcher

The added complexity is not to MVC, it's to build infrastructure, packaging, installers, etc. necessary to create and ship yet another layer of components regardless of what that layering consists of.

i.e. the added complexity of what would be required in order to get MVC to work.

Can you be more specific about what tooling features you'd like to see disabled? That might be worth a separate issue.

The 2 issues I ran into was needing to manually configure /p:MvcRazorCompileOnPublish=false which was preventing my project (without .cshtml pages) to publish. The other flag that should be disabled is:

<PreserveCompilationContext>false</PreserveCompilationContext>

As with most magic behavior I'm assuming there's more but only find out about them when I run into it.

Basically a flag to specify that MVC is not used and to disable all tooling or concessions enabled by default that was added because of MVC.

mythz on 7 Nov 2018

👍1

@mythz go ahead and file that issue.

Tratcher on 7 Nov 2018

You can actually make a similar shared framework for service stack if the extra MVC and SignalR dlls are a concern for your users.

davidfowl on 8 Nov 2018

@davidfowl That actually sounds pretty awesome, I could see a few different use cases for community provided frameworks. Is there any documentation on that?

aidapsibr on 8 Nov 2018

As you can imagine, it’s not something we’d build first class support for as the number of people that do this is small. That’s said you can look at how we build ours and mimic that behavior.

davidfowl on 8 Nov 2018

@davidfowl The minimal base package would be useful for all non MVC apps - e.g. there's going to lot of other lightweight apps and micro services that's going to want to bypass all frameworks and write directly to the response themselves. IMO this option should be available in the box, we'd prefer not to start from an unofficial base composed of package versions we don't have control over. Ideally everything would be additive from the base package instead of starting off from a different tangent maintained externally. But maybe this is one area where the external community can come together to maintain a base "AspNetCore" subset that's useful for all non MVC Apps and Frameworks.

With that said where should we look to create a custom Framework? Maybe it will be as easy as starting from a copy of what was used to create "Microsoft.AspNetCore.App" and stripping out all non-essential libraries to get it back to a minimal useful subset.

mythz on 8 Nov 2018

👍1

@mythz why do you even need a framework, you can just use Kestrel the server directly. This just to say that maybe your version of light isn't somebody else's idea of light or core. We currently have an opinion and it would be amazing if the community could step up here and make templates and an alternative shared framework that was sufficiently minimal. We're OSS, everything required to make something custom is there and we're very responsive and will gladly help.

@natemcmaster Can help with details on how to make a custom shared framework.

davidfowl on 8 Nov 2018

❤1 🎉1 👍1

@davidfowl you suggested to make a custom one, I'm only after being able to start from a minimal useful base without opinionated frameworks. We don't want to reference multiple packages individually for the same reason the recommendation is for all ASP.NET Core Apps to reference "Microsoft.AspNetCore.App" - it's more accessible to be able to reference a single package.

This just to say that maybe your version of light isn't somebody else's idea of light or core.

Everyone seems to be pretty unanimous here that MVC doesn't belong in the base package. The only other "product" that appears to be included is SignalR which I'd imagine would have less usage than MVC and less reason for inclusion. I'm not intimately familiar with what's in each package but everything else appears to be generically useful and a conducive part of the ASP.NET Core "platform".

mythz on 8 Nov 2018

OK let me throw out a suggestion to try to be constructive here. We're not changing Microsoft.AspNetCore.App, we think it's something that a majority of users will need and use. Lets introduce another layer that is this "core" shared framework (we did something like this originally with https://www.nuget.org/packages/Microsoft.AspNetCore/2.2.0-preview3-35497). That's the shared framework you would base these other frameworks (like Nancy and ServiceStack) on top of.

We'll still ship our default templates with Microsoft.AspNetCore.App same as now but framework authors such as yourself can have other templates that use the base shared framework.

PS: This thread doesn't remotely begin represent any sort of majority of our customers so I wouldn't draw conclusions from here alone. We get feedback from lots of places and github has our most vocal and passionate guidance.

davidfowl on 8 Nov 2018

👍8 ❤2 🎉1

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.

mythz on 8 Nov 2018

and now it gets interesting. as david already said: people have different
ideas of what "core" means. From my POV I don't think DependencyInjection
should be in. /shrug

Am Do., 8. Nov. 2018 um 08:30 Uhr schrieb Demis Bellot <
[email protected]>:

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
https://www.nuget.org/packages/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.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/aspnet/AspNetCore/issues/3755#issuecomment-436898980,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADgNOzUVEHlJNBrPD5P2BsQj6UQdqyvks5us92zgaJpZM4YAsZ1
.

forki on 8 Nov 2018

👍1

@mythz Most of those are include transitively.

@forki 😆 Welcome to our world.

davidfowl on 8 Nov 2018

❤1 😄1

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.

dustinmoris on 8 Nov 2018

👎2

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

davidfowl on 8 Nov 2018

👍5

@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 https://github.com/fsharp/fslang-suggestions/issues/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

NinoFloris on 9 Nov 2018

👍2

you are confronted with DI anyway

I know and we had that discussion multiple times. It's just I'd rather not
;-) but it is what it is...

Am Fr., 9. Nov. 2018, 10:57 hat Nino Floris notifications@github.com
geschrieben:

@forki https://github.com/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
https://github.com/fsharp/fslang-suggestions/issues/255 so ¯_(ツ)_/¯

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

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/aspnet/AspNetCore/issues/3755#issuecomment-437309244,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADgNGP3d8R0otOAuUQC7AYK6O2dzJ3mks5utVGegaJpZM4YAsZ1
.

forki on 9 Nov 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 https://github.com/aspnet/AspNetCore/pull/6035

natemcmaster on 19 Dec 2018

Update the original post to include Microsoft.AspNet.WebApi.Client. See https://github.com/aspnet/AspNetCore/pull/6552#issuecomment-453177732.

natemcmaster on 10 Jan 2019

🎉1

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

simeyla on 21 Feb 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.

natemcmaster on 21 Feb 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.

Eilon on 5 Apr 2019

Added Microsoft.Extensions.DependencyModel to the list. Changed as part of https://github.com/aspnet/AspNetCore/pull/10271

pranavkm on 20 May 2019

Question here @natemcmaster @DamianEdwards, there is mention of the templates having all that is needed to build locally. With this thought and the remove of the Auth libraries, does that mean that any auth template will not build offline in 3.0? I understand that no auth library will work offline, but if I have no nuget cache, I could theoretically get a build failure after newing a new auth template if I was offline. That seems like a bad experience.

isaacrlevin on 7 Jun 2019

Yes, that is one of the outcomes of this change. As of Preview 6 (coming soon), dotnet new mvc, dotnet new razor, dotnet new web and others don't have any PackageReferences, so they shouldn't be impacted, but specifying additional options, like --auth individual may result in a PackageReference being present which requires a package download.

We are making an intentional tradeoff here. Although the templates that have PackageReference's will not restore offline on a clean machine, we are also avoiding many the issues that come from trying to make a pre-populated offline NuGet cache (for starters, checkout https://github.com/dotnet/dotnet-docker/issues/237, https://github.com/NuGet/Home/issues/6309, and http://blog.ctaggart.com/2019/03/using-nuget-lock-file-for-reproducible.html).

natemcmaster on 7 Jun 2019

👍1

@natemcmaster totally understand and I get the reasoning, just needs to be well documented or there are going to be a ton of issues opened up upon the initial 3.0 release where people say dotnet new webapp --auth Individual doesn't build.

isaacrlevin on 7 Jun 2019

Can anyone educate me on why Microsoft.AspNetCore.Authentication.JwtBearer is compiled with a dependency on .netcoreapp3.0? Can it not be on .netstandard2.x? I want to use it in a class library and I like to keep my classlibs all .netstandard

buvinghausen on 20 Jun 2019

@buvinghausen https://github.com/aspnet/Announcements/issues/324

davidfowl on 20 Jun 2019

👍1

@Pilchie I think this issue is worth calling out in documentation for ASP.NET Core 3.0. As mentioned above, users upgrading to 3.0 will need to add <PackageReference> to compensate for API that moved out of Microsoft.AspNetCore.App.

natemcmaster on 24 Jul 2019

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

We certainly don't, and I know quite a few people at other shops who are using .net core for serverless apps, web apis, etc, where we have absolutely zero need for MVC.

dcb99 on 24 Jul 2019

Closing, since we have shipped 3.0 today.

Pilchie on 24 Sep 2019

We need to move this list to the docs

davidfowl on 24 Sep 2019

@davidfowl it's been added: https://docs.microsoft.com/en-us/aspnet/core/migration/22-to-30?view=aspnetcore-3.0&tabs=visual-studio#remove-obsolete-package-references

pranavkm on 24 Sep 2019

@pranavkm that list is actually the exact opposite: Things that are no longer packages but are likely still in the shared framework.

This is about things that were removed from the shared framework, but are likely now available as only packages.

@scottaddie this is the list we'll need to reference in the ASP.NET Core library authoring doc.

DamianEdwards on 1 Oct 2019

@DamianEdwards this - https://docs.microsoft.com/en-us/aspnet/core/migration/22-to-30?view=aspnetcore-3.0&tabs=visual-studio#add-package-references-for-removed-assemblies?

pranavkm on 1 Oct 2019

That's the one :)

DamianEdwards on 2 Oct 2019

Late to the party but this doesn't feel like its helping me achieve the goal of simplifying my development.

a) It seems that now if there is an improvement to an AspNetCore component (say, SignalR), then we need to wait for a new "dotnet pack" for Microsoft.AspNetCore.App to be released to use it, taking with it everything else in that pack?
b) Can no longer create utility classes for AspNetCore in netstandard class libraries (for example, Auth middleware). Now class libraries need to be netcoreapp3.0 to house this stuff. This means splitting our utility class libraries into netstandard / netcore implementations.
EDIT: c) How do I actually define which version of the pack I am using if I do <Project Sdk="Microsoft.NET.Sdk.Web">? Obviously we want to have reproducible builds on different branches after updating dotnet.

jahmai on 2 Oct 2019

a) It seems that now if there is an improvement to an AspNetCore component (say, SignalR), then we need to wait for a new "dotnet pack" for Microsoft.AspNetCore.App to be released to use it, taking with it everything else in that pack?

SignalR ships on the same schedule as the rest of AspNetCore so there is no scheduling change here.

Tratcher on 2 Oct 2019

SignalR ships on the same schedule as the rest of AspNetCore so there is no scheduling change here.

So this is just a bad example? Can the same be said about all the other NuGet packages that were removed?

jahmai on 2 Oct 2019

SignalR ships on the same schedule as the rest of AspNetCore so there is no scheduling change here.

So this is just a bad example? Can the same be said about all the other NuGet packages that were removed?

I think so. All .NET Core and ASP.NET Core components use the same ship schedule. If something didn't then it would have to ship in its own package.

Tratcher on 2 Oct 2019

I think so. All .NET Core and ASP.NET Core components use the same ship schedule. If something didn't then it would have to ship in its own package.

I'll take your word for it. I don't have any specific counter examples. It just didn't "feel" that way when updating the AspNetCore NuGet packages in the past.

jahmai on 2 Oct 2019

Aspnetcore: Assemblies being removed from Microsoft.AspNetCore.App 3.0

Most helpful comment

All 73 comments

Related issues