Assemblies being removed from Microsoft.AspNetCore.App 3.0

[natemcmaster]

💡 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 Remove Microsoft.AspNet.WebApi.Client and Newtonsoft.Json.Bson from shared fx #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 [Announcement] Empty Microsoft.AspNetCore.Server.Kestrel.Https assembly being removed #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
• Microsoft.Extensions.DependencyModel
• System.Net.WebSockets.WebSocketProtocol (Removed WebSocketProtocol from the shared framework #6699)

[dustinmoris]

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]

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

[CwjXFH]

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

[dustinmoris]

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

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

[dustinmoris]

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]

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]

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]

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.

[aidapsibr]

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]

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

[dustinmoris]

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

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]

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

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]

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?

[aidapsibr]

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

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

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

[Bomret]

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

[forki]

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]

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]

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

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

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]

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

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

[isaacrlevin]

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.

[natemcmaster]

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 dotnet/dotnet-docker#237, NuGet/Home#6309, and http://blog.ctaggart.com/2019/03/using-nuget-lock-file-for-reproducible.html).

[isaacrlevin]

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

[buvinghausen]

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

[davidfowl]

@buvinghausen aspnet/Announcements#324

[natemcmaster]

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

[dcb99]

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

[Pilchie]

Closing, since we have shipped 3.0 today.

[davidfowl]

We need to move this list to the docs

[pranavkm]

@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

[DamianEdwards]

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

[pranavkm]

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

[DamianEdwards]

That's the one :)

[jahmai-ca]

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.

[Tratcher]

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.

[jahmai-ca]

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?

[Tratcher]

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.

[jahmai-ca]

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.