Conversation
There was a problem hiding this comment.
Pull request overview
This PR updates documentation for the dotnet store command and the runtime package store to clearly indicate that the feature is deprecated, not supported on modern .NET, and generally should not be used. It adds prominent warnings, cautions, and a workaround note to reduce confusion for users encountering this legacy feature.
Changes:
- Updated
dotnet storecommand docs with front matter metadata, an AI usage flag, and high-visibility warnings about deprecation and known issues on .NET 6 and later. - Updated the runtime package store article with warnings, cautions, and clearly marked legacy sections, including a discouraged workaround, to emphasize that the feature is deprecated and not supported on modern .NET.
- Added a reference link to the relevant GitHub issue documenting the
dotnet store/crossgen problems.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| docs/core/tools/dotnet-store.md | Marks the command as deprecated/unsupported, updates metadata, and adds cautions about failures and unreliable behavior on .NET 6+. |
| docs/core/deploying/runtime-store.md | Clearly flags the runtime package store as deprecated/unsupported, updates historical description language, adds cautions around usage and publishing, marks ASP.NET Core 2.0 behavior as legacy, and links to the tracking GitHub issue. |
| > [!WARNING] | ||
| > The runtime package store feature is **no longer supported or under active development**. While the `dotnet store` command still exists, it has known issues with .NET 6 and later versions, and **it is not recommended for use**. The .NET team plans to eventually stop shipping this command altogether. For more information, see [GitHub issue #24752](https://github.com/dotnet/sdk/issues/24752). | ||
|
|
||
| Starting with .NET Core 2.0, it was possible to package and deploy apps against a known set of packages that exist in the target environment. The intended benefits were faster deployments, lower disk space usage, and improved startup performance in some cases. However, this feature is now deprecated. |
There was a problem hiding this comment.
The tense in this sentence is inconsistent: "Starting with .NET Core 2.0, it was possible to package and deploy apps against a known set of packages that exist in the target environment." To keep the timeline clear and match the rest of the paragraph, use either consistent past tense (for example, changing "exist" to "existed") or rephrase in second person to describe the historical behavior more cleanly.
| Specify the target manifests in the project file only when the target environment for the app is well-known, such as for .NET Core projects. This isn't the case for open-source projects. The users of an open-source project typically deploy it to different production environments. These production environments generally have different sets of packages pre-installed. You can't make assumptions about the target manifest in such environments, so you should use the `--manifest` option of [`dotnet publish`](../tools/dotnet-publish.md). | ||
|
|
||
| ## ASP.NET Core implicit store (.NET Core 2.0 only) | ||
| ## ASP.NET Core implicit store (.NET Core 2.0 only - Legacy) |
There was a problem hiding this comment.
In the heading "ASP.NET Core implicit store (.NET Core 2.0 only - Legacy)", the spaced hyphen in "only - Legacy" is inconsistent with the documentation style guidelines for dashes. Consider either removing the spaces around the dash or simplifying the parenthetical (for example, just "(.NET Core 2.0, legacy)") to keep the heading formatting consistent.
2 participants
Summary
Fixes #48203
Internal previews