{"action":"created","issue":{"url":"https://api.github.com/repos/dotnet/designs/issues/8","repository_url":"https://api.github.com/repos/dotnet/designs","labels_url":"https://api.github.com/repos/dotnet/designs/issues/8/labels{/name}","comments_url":"https://api.github.com/repos/dotnet/designs/issues/8/comments","events_url":"https://api.github.com/repos/dotnet/designs/issues/8/events","html_url":"https://github.com/dotnet/designs/issues/8","id":236041229,"node_id":"MDU6SXNzdWUyMzYwNDEyMjk=","number":8,"title":"Runtime Package Store","user":{"login":"bleroy","id":1165609,"node_id":"MDQ6VXNlcjExNjU2MDk=","avatar_url":"https://avatars0.githubusercontent.com/u/1165609?v=4","gravatar_id":"","url":"https://api.github.com/users/bleroy","html_url":"https://github.com/bleroy","followers_url":"https://api.github.com/users/bleroy/followers","following_url":"https://api.github.com/users/bleroy/following{/other_user}","gists_url":"https://api.github.com/users/bleroy/gists{/gist_id}","starred_url":"https://api.github.com/users/bleroy/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/bleroy/subscriptions","organizations_url":"https://api.github.com/users/bleroy/orgs","repos_url":"https://api.github.com/users/bleroy/repos","events_url":"https://api.github.com/users/bleroy/events{/privacy}","received_events_url":"https://api.github.com/users/bleroy/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":12,"created_at":"2017-06-14T23:54:25Z","updated_at":"2018-12-13T16:02:22Z","closed_at":"2018-12-13T16:02:23Z","author_association":"NONE","body":"# Runtime Package Store\r\n\r\nStarting with .NET Core 2.0, it's possible to package and deploy applications against a known set of packages that exist on the target environment. The benefits in doing so are smaller deployments, lower disk space usage, and in some cases improved startup performance.\r\n\r\nThis feature is implemented by a runtime package store, which is a location on disk where packages are stored, and that the runtime can find, access, and use. That location is a *store* directory, next to the `dotnet` host. Under this directory, there are subdirectories for target frameworks, under which the package store follows a NuGet layout.\r\n\r\nThe second part of the implementation is a \"target manifest\", which is a list of packages that compose a runtime package store, and that developers can target when publishing their application. The target manifest is typically provided by the owner of the targeted production environment.\r\n\r\nThe feature is also used implicitly by ASP.NET applications: the set of packages composing the ASP.NET Web framework is installed as part of the setup packages authored by Microsoft. When publishing an ASP.NET application, the published application is trimmed to only include the application's packages, and not the framework's packages.\r\n\r\n## Goals\r\n\r\n- Smaller deployments\r\n- Lower disk space usage\r\n- Faster startup times\r\n\r\n## Publishing an application against a target manifest\r\n\r\nIf you have a target manifest file on disk, you can specify it when publishing your app with the [`dotnet publish`](../tools/dotnet-publish.md) command:\r\n\r\n```\r\ndotnet publish --manifest path/to/the/target-manifest.xml\r\n```\r\n\r\nThe resulting published application should only be deployed to an environment that has the packages described in the target manifest. Failing to do so would result in the application not starting.\r\n\r\nIt's possible to specify multiple target manifests when publishing an application. The application will then be trimmed for the union of packages specified in those target manifests.\r\n\r\n## Specifying a target manifest in the project file\r\n\r\nInstead of specifying a target manifest in a [`dotnet publish`](../tools/dotnet-publish.md) command, it's possible to specify the manifest or manifests to use in the project file as a semicolon-separated list of paths under a `TargetManifestFiles` tag.\r\n\r\n```xml\r\n<PropertyGroup>\r\n  <TargetManifestFiles>path/to/the/target-manifest.xml</TargetManifestFiles>\r\n</PropertyGroup>\r\n```\r\n\r\nThis should only be done when the target environment for the application is well-known.\r\n\r\nA different case would be an open-source project: the users of the project will likely deploy to a variety of different production environments, which may have different sets of packages pre-installed. Maintainers of the project can't make assumptions about the target manifest, and users should instead rely on the `--manifest` option of [`dotnet publish`](../tools/dotnet-publish.md) instead.\r\n\r\n## ASP.NET implicit store\r\n\r\nThe default ASP.NET targets included with the `Microsoft.AspNetCore.All` meta-package include target manifests. As a consequence, `dotnet publish` of an ASP.NET application when it references this package will result in a published application that contains only the application and its assets, and not ASP.NET itself.\r\n\r\nWhen an ASP.NET published application gets deployed, one should make sure that the target environment has ASP.NET installed, as the presence of .NET Core alone will not be sufficient.\r\n\r\nIf the application needs to be published to such an environment that doesn't include ASP.NET, it is possible to opt out of the implicit store by specifying a `PublishWithAspNetCoreTargetManifest` flag set to false in the project file, as you can see in the following example.\r\n\r\n```xml\r\n  <PropertyGroup>\r\n    <PublishWithAspNetCoreTargetManifest>false</PublishWithAspNetCoreTargetManifest>\r\n  </PropertyGroup>\r\n```\r\n\r\nThe ASP.NET runtime package store will be installed as part of the SDK packages distributed by Microsoft, and will also be available as a separate download so that any deployment environment can be prepared to receive published ASP.NET applications.\r\n\r\n## Preparing a runtime environment\r\n\r\nThe administrator of a runtime environment can optimize for certain types of applications by building a runtime package store and the corresponding target manifest.\r\n\r\nThe first step is to create an XML file that describes the packages that must compose the runtime package store. The format of this file is compatible with the `csproj` format. Here's an example of such a file that adds `Newtonsoft.Json` and `System.Runtime.Serialization.Primitives` to the package store:\r\n\r\n```xml\r\n<Project Sdk=\"Microsoft.NET.Sdk\">\r\n  <ItemGroup>\r\n    <PackageReference Include=\"Newtonsoft.Json\" Version=\"9.0.1\" />\r\n    <PackageReference Include=\"System.Runtime.Serialization.Primitives\" Version=\"4.1.1\" />\r\n  </ItemGroup>\r\n</Project>\r\n```\r\n\r\nThe runtime package store can then be provisioned by running a `dotnet store --manifest [target-manifest.xml] --runtime [runtime id] --framework [target framework]` command. Multiple file paths can be passed to a single [`dotnet store`](../tools/dotnet-store.md) command.\r\n\r\nThe output of the command is a package store under the `.dotnet/store` subdirectory of the user profile, unless a specific location has been specified using the `--output` option. The root directory of the store contains a target manifest `artifact.xml` file, that can be made available to be downloaded by application authors who want to target this store when publishing.\r\n\r\n## Feedback\r\n\r\nPlease share your feedback.\r\n"},"comment":{"url":"https://api.github.com/repos/dotnet/designs/issues/comments/447022196","html_url":"https://github.com/dotnet/designs/issues/8#issuecomment-447022196","issue_url":"https://api.github.com/repos/dotnet/designs/issues/8","id":447022196,"node_id":"MDEyOklzc3VlQ29tbWVudDQ0NzAyMjE5Ng==","user":{"login":"richlander","id":2608468,"node_id":"MDQ6VXNlcjI2MDg0Njg=","avatar_url":"https://avatars3.githubusercontent.com/u/2608468?v=4","gravatar_id":"","url":"https://api.github.com/users/richlander","html_url":"https://github.com/richlander","followers_url":"https://api.github.com/users/richlander/followers","following_url":"https://api.github.com/users/richlander/following{/other_user}","gists_url":"https://api.github.com/users/richlander/gists{/gist_id}","starred_url":"https://api.github.com/users/richlander/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/richlander/subscriptions","organizations_url":"https://api.github.com/users/richlander/orgs","repos_url":"https://api.github.com/users/richlander/repos","events_url":"https://api.github.com/users/richlander/events{/privacy}","received_events_url":"https://api.github.com/users/richlander/received_events","type":"User","site_admin":false},"created_at":"2018-12-13T16:02:22Z","updated_at":"2018-12-13T16:02:22Z","author_association":"MEMBER","body":"This feature was implemented in .NET Core 2.0. We have moved to a new scheme called \"frameworks\" that needs to be documented as part of .NET Core 3.0."}}
{"actor":{"display_login":"richlander"}}