Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Microsoft.AspNetCore.App metapackage #6069

Merged
merged 11 commits into from
May 16, 2018
Merged
Show file tree
Hide file tree
Changes from 4 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
59 changes: 59 additions & 0 deletions aspnetcore/fundamentals/metapackage-app.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,59 @@
---
title: Microsoft.AspNetCore.App metapackage for ASP.NET Core 2.x and later
Copy link
Contributor

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

author: Rick-Anderson
description: The Microsoft.AspNetCore.App metapackage includes all supported ASP.NET Core and Entity Framework Core packages, along with their dependencies.
Copy link
Contributor

Choose a reason for hiding this comment

The 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-all
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Rick-Anderson Did you mean "-app" here?

---

# 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.
Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@JunTaoLuo can you suggest better wording.
Most of the supported packages by the ASP.NET Core team.
How about
All supported packages by the ASP.NET Core team except a few that that contain third party dependencies like Redis.

Copy link
Contributor

Choose a reason for hiding this comment

The 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.
Copy link
Contributor

Choose a reason for hiding this comment

The 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.
Copy link
Contributor

Choose a reason for hiding this comment

The 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.
Copy link
Contributor

Choose a reason for hiding this comment

The 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.
Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Collaborator

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copy link
Collaborator

Choose a reason for hiding this comment

The 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).
Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copy link
Contributor

Choose a reason for hiding this comment

The 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`.
Copy link
Contributor

Choose a reason for hiding this comment

The 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.
Second, we don't technically prevent you from adding a package that has a transitive (not direct) dependency on a package that is included in .App. In this case, nuget will produce an error. The phrasing suggests, to me at least, that we have additional consolidation logic to set all packages to the version that's specified in .App which is not accurate.

* 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).
Copy link
Contributor

Choose a reason for hiding this comment

The 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.
Copy link
Contributor

Choose a reason for hiding this comment

The 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.
Copy link
Contributor

Choose a reason for hiding this comment

The 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).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

previously used Migrating from Microsoft.AspNetCore.All? You mean previously used Microsoft.AspNetCore.All?

41 changes: 38 additions & 3 deletions aspnetcore/fundamentals/metapackage.md
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
Copy link
Contributor

Choose a reason for hiding this comment

The 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
Expand All @@ -12,7 +12,10 @@ ms.topic: article
uid: fundamentals/metapackage
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

metapackage-all?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Expand All @@ -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.
Copy link
Contributor

Choose a reason for hiding this comment

The 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
Copy link
Contributor

Choose a reason for hiding this comment

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

Microsoft.AspNetCore.ApplicationInsights.HostingStartup
Microsoft.AspNetCore.AzureAppServices.HostingStartup
Microsoft.AspNetCore.AzureAppServicesIntegration
Microsoft.AspNetCore.DataProtection.AzureKeyVault
Microsoft.AspNetCore.DataProtection.AzureStorage
Microsoft.AspNetCore.Server.Kestrel.Transport.Libuv
Microsoft.AspNetCore.SignalR.Redis
Microsoft.Data.Sqlite
Microsoft.Data.Sqlite.Core
Microsoft.EntityFrameworkCore.Sqlite
Microsoft.EntityFrameworkCore.Sqlite.Core
Microsoft.Extensions.Caching.Redis
Microsoft.Extensions.Configuration.AzureKeyVault
Microsoft.Extensions.Logging.AzureAppServices
Microsoft.VisualStudio.Web.BrowserLink

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`