-
Notifications
You must be signed in to change notification settings - Fork 25.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Microsoft.AspNetCore.App metapackage #6069
Changes from 5 commits
8dacdc8
4de23eb
2eb4ed2
352f1e0
b6a6e75
d91b3e5
958bba0
8f25b65
b94502a
b15d20f
f740744
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,58 @@ | ||
--- | ||
title: Microsoft.AspNetCore.App metapackage for ASP.NET Core 2.x and later | ||
author: Rick-Anderson | ||
description: The Microsoft.AspNetCore.App metapackage includes all supported ASP.NET Core and Entity Framework Core packages, along with their dependencies. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Technically not true since we specifically add Microsoft.AspNetCore.App to remove supported packages that had third party dependencies. |
||
manager: wpickett | ||
monikerRange: '>= aspnetcore-2.1' | ||
ms.author: riande | ||
ms.date: 09/20/2017 | ||
ms.prod: asp.net-core | ||
ms.technology: aspnet | ||
ms.topic: article | ||
uid: fundamentals/metapackage-app | ||
--- | ||
|
||
# Microsoft.AspNetCore.App metapackage for ASP.NET Core 2.1 | ||
|
||
This feature requires ASP.NET Core 2.1 and later targeting .NET Core 2.1 and later. | ||
|
||
The [Microsoft.AspNetCore.App](https://www.nuget.org/packages/Microsoft.AspNetCore.App) metapackage for ASP.NET Core includes: | ||
|
||
* All supported packages by the ASP.NET Core team. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This phrasing is not accurate since we don't include packages that contain third party dependencies like Redis. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @JunTaoLuo can you suggest better wording. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. All supported packages without third party dependencies of the ASP.NET Core team. |
||
* All supported packages by the Entity Framework Core. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The same clarification applies to EF packages. We should add "exception those that contain third party dependencies" or something similar. Though I don't like this wording either; allow me to clarify. We have removed most of the third party dependencies in the .App package. However, due to a variety of reasons, there are three exceptions to the rule. We continue to use Json.NET, Remotion.Linq and IX-Async packages in the .App metapackage. I think it may be better to phrase by listing the three third party dependencies first. Then "All supported packages by the ASP.NET Core team exception those containing third party dependencies other than the three previously mentioned." And the same for the EF packages. |
||
* Internal dependencies used by ASP.NET Core and Entity Framework Core. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What do you mean by this? What are the internal dependencies you are referring to? |
||
* 3rd-party dependencies used by ASP.NET Core and Entity Framework Core deemed necessary to ensure the major frameworks features function. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Let's remove this line to reduce the confusion. |
||
|
||
All the features of ASP.NET Core 2.1 and later and Entity Framework Core 2.1 and later are included in the `Microsoft.AspNetCore.App` package. The default project templates targeting ASP.NET Core 2.1 and later use this package. We recommend applications targeting ASP.NET Core 2.1+ and Entity Framework Core 2.1+ use the `Microsoft.AspNetCore.App` package. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Nit: We are switching between "2.1 and later" and "2.1+". We should just pick a convention and stick to it. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The style manual usually uses "or later" ... there's one spot tho where it references the phrase "and later." AFAIK, we've been using "or later" here and in the .NET Core docs. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 2.1 and later gets tedious when used multiple times in a sentence/paragraph. We can't use 2.1+ globally. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Truly, they're pretty vague on it. They just don't like "higher" and "greater" for versions. I bet they don't care all that much about the plus sign (or they forgot to mention it 😈). |
||
|
||
The version number of the `Microsoft.AspNetCore.App` metapackage represents the ASP.NET Core version and Entity Framework Core version (aligned with the .NET Core version). | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not sure if we can claim this. Technically aspnetcore and .net core are independently versioned. Most of the time, we will be aligned but this is not a promise going forward. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The ASP.NET Core version is currently aligned with the .NET Core version, and we hope to continue version alignment in the future. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. As much as this is likely the case for the majority of the time, I don't know if we can make this promise. There may be cases where the runtime is not updating but aspnetcore needs to ship an update in which case the versions will no longer align. Unless we promise to rev the entire stack any time there is a change anywhere. I'm not sure that's the model we are committed to adopting. |
||
|
||
Using the the `Microsoft.AspNetCore.App` metapackage provides version restrictions that protect your app: | ||
|
||
* Other packages added to your app cannot change the version of packages included in `Microsoft.AspNetCore.App`. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is a little more nuanced. First, if you add a direct reference to a package that's included in .App, you will be able to override the version number. |
||
* Version consistency ensures a reliable experience. `Microsoft.AspNetCore.App` was designed to prevent untested version combinations of related bits being used together in the same app. | ||
|
||
Applications that use the `Microsoft.AspNetCore.App` metapackage automatically take advantage of the .NET Core shared framework. When you use the `Microsoft.AspNetCore.App` metapackage, **no** assets from the referenced ASP.NET Core NuGet packages are deployed with the application — the .NET Core shared framework contains these assets. The assets in the shared framework are precompiled to improve application startup time. For more information, see "shared framework" in [.NET Core distribution packaging](/dotnet/core/build/distribution-packaging). | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The assets are contained in the ASP.NET Core shared framework not the .NET Core shared framework. |
||
|
||
Packages in the .NET Core shared framework are excluded in published application output. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Nit: It seems like this is related to the previous paragraph, so not sure why it's in its own section. |
||
|
||
The following *.csproj* file references the `Microsoft.AspNetCore.App` metapackage for ASP.NET Core: | ||
|
||
```xml | ||
<Project Sdk="Microsoft.NET.Sdk.Web"> | ||
|
||
<PropertyGroup> | ||
<TargetFramework>netcoreapp2.1</TargetFramework> | ||
</PropertyGroup> | ||
|
||
<ItemGroup> | ||
<PackageReference Include="Microsoft.AspNetCore.App" /> | ||
</ItemGroup> | ||
|
||
</Project> | ||
|
||
``` | ||
|
||
The preceding markup doesn't specify a version number for the `Microsoft.AspNetCore.App` NuGet package. The ASP.NET Core 2.1+ templates generate this markup without a version number. Not specifying a version is convent early in development when you want the latest version. Most teams will add a version number when deploying the app to ensure that development, test, and production are all using the same version. With a fixed version number, updates to the host will not cause the app to use a newer version of the NuGet package. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. convent? Word choice is a little confusing. Also, even while deploying an app, we don't recommend users to add a version number. We want the version number to remain implicit in all scenarios. The shared framework roll forward mechanism will always run the app on the latest version of the installed shared framework. To guarantee the same version is used in dev, test, and production, you'll need to ensure the same version of the shared framework is installed in all environments. |
||
|
||
If your application previously used `Migrating from Microsoft.AspNetCore.All`, see [Migrating from Microsoft.AspNetCore.All to Microsoft.AspNetCore.App](xref:fundamentals/metapackage#migrate). | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. previously used |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,9 +1,9 @@ | ||
--- | ||
title: Microsoft.AspNetCore.All metapackage for ASP.NET Core 2.x and later | ||
title: Microsoft.AspNetCore.All metapackage for ASP.NET Core 2.0 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We have the .All package for 2.1 as well so this should be 2.x. |
||
author: Rick-Anderson | ||
description: The Microsoft.AspNetCore.All metapackage includes all supported ASP.NET Core and Entity Framework Core packages, along with their dependencies. | ||
manager: wpickett | ||
monikerRange: '= aspnetcore-2.0' | ||
monikerRange: '>= aspnetcore-2.0' | ||
ms.author: riande | ||
ms.date: 09/20/2017 | ||
ms.prod: asp.net-core | ||
|
@@ -12,7 +12,10 @@ ms.topic: article | |
uid: fundamentals/metapackage | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. metapackage-all? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. No need to change the file name and the UID. |
||
--- | ||
|
||
# Microsoft.AspNetCore.All metapackage for ASP.NET Core 2.x | ||
# Microsoft.AspNetCore.All metapackage for ASP.NET Core 2.0 | ||
|
||
> [!NOTE] | ||
> We recommend applications targeting ASP.NET Core 2.1 and later use the [Microsoft.AspNetCore.App](xref:fundamentals/metapackage-all) rather than this package. See [Migrating from Microsoft.AspNetCore.All to Microsoft.AspNetCore.App](#migrate) in this article. | ||
|
||
This feature requires ASP.NET Core 2.x targeting .NET Core 2.x. | ||
|
||
|
@@ -33,3 +36,35 @@ You can use the package trimming process to remove packages that you don't use. | |
The following *.csproj* file references the `Microsoft.AspNetCore.All` metapackage for ASP.NET Core: | ||
|
||
[!code-xml[](../mvc/views/view-compilation/sample/MvcRazorCompileOnPublish2.csproj?highlight=9)] | ||
|
||
::: moniker range=">= aspnetcore-2.1" | ||
# Microsoft.AspNetCore.All metapackage for ASP.NET Core 2.1 and later version range locking | ||
|
||
`Microsoft.AspNetCore.All` 2.1 and later specifies package dependency ranges. The package dependency ranges ensure that only the excact version specified for each dependency is allowed. Any other dependency that attempts to lift a version for a component beyond what is specified in the meta-package will result in a NuGet warning, which the Microsoft.NET.Sdk will elevate to an error by default. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is not true, there is no version locking in Microsoft.AspNetCore.All. Version locking is only added to Microsoft.AspNetCore.All. |
||
|
||
::: moniker-end | ||
|
||
|
||
<a name="migrate"></a> | ||
## Migrating from Microsoft.AspNetCore.All to Microsoft.AspNetCore.App | ||
|
||
The following packages are direct dependencies of `Microsoft.AspNetCore.All` but not the `Microsoft.AspNetCore.App` package. | ||
|
||
* Microsoft.Data.Sqlite | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. How did you generate this list? I took a diff of the packages and these are the extra packages in .All and not in .App.
A few things to note. Microsoft.AspNetCore.Identity.Service.AzureKeyVault is not a shipping package and Microsoft.AspNetCore.AzureKeyVault.HostingStartup only exists in 2.0 and is not (and was never) included in the .All metapackage. |
||
* Microsoft.Data.Sqlite.Core | ||
* Microsoft.EntityFrameworkCore.Sqlite | ||
* Microsoft.EntityFrameworkCore.Sqlite.Core | ||
* Microsoft.Extensions.Caching.Redis | ||
* Microsoft.AspNetCore.DataProtection.AzureStorage | ||
* Microsoft.Extensions.Configuration.AzureKeyVault | ||
* Microsoft.AspNetCore.DataProtection.AzureKeyVault | ||
* Microsoft.AspNetCore.Identity.Service.AzureKeyVault | ||
* Microsoft.AspNetCore.AzureKeyVault.HostingStartup | ||
* Microsoft.AspNetCore.ApplicationInsights.HostingStartup | ||
|
||
To move from `Microsoft.AspNetCore.All` to `Microsoft.AspNetCore.App`, if your app uses any APIs from the above packages, or packages brought in by those packages, add references to those packages in your project. | ||
|
||
Any dependencies of the preceding packages that otherwise aren't dependencies of `Microsoft.AspNetCore.App` are not included implicitly. For example: | ||
|
||
* `StackExchange.Redis` as a dependency of `Microsoft.Extensions.Caching.Redis` | ||
* `Microsoft.ApplicationInsights` as a dependency of `Microsoft.AspNetCore.ApplicationInsights.HostingStartup` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The Microsoft.AspNetCore.App exists only for 2.1 and later. It does not exist in 2.0