From 7ec3ecb977e5415f87678b5279ea7bd0fba470de Mon Sep 17 00:00:00 2001 From: Kartheek Penagamuri <52756182+kartheekp-ms@users.noreply.github.com> Date: Wed, 22 Jun 2022 16:43:44 -0700 Subject: [PATCH 01/20] work --- .../cpm-dotnet-cli-add-package-support.md | 20 +++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/proposed/2022/cpm-dotnet-cli-add-package-support.md b/proposed/2022/cpm-dotnet-cli-add-package-support.md index 5ec86a7..91b4e1f 100644 --- a/proposed/2022/cpm-dotnet-cli-add-package-support.md +++ b/proposed/2022/cpm-dotnet-cli-add-package-support.md @@ -22,6 +22,26 @@ Users wanting to use CPM onboarded projects and dotnet CLI commands. When `dotnet add package` is executed in a project onboarded to CPM (meaning that the `Directory.packages.props` file exists) there are a few scenarios that must be considered. +| Scenario # | PackageReference exists? | VersionOverride exists? | PackageVersion exists? | Is Version specified from the commandline | New behavior in dotnet CLI | In Scope | +| ---- |----- | ----- | ---- |---- | ----- | ---- | +| 1 | ❌ | ❌ | ❌ | ❌ | Add PackageReference to the project file. Add PackageVersion to the Directory.Packages.Props file. Use latest version from the package sources| ✔️ | +| 2 | ❌ | ❌ | ❌ | ✔️ | Add PackageReference to the project file. Add PackageVersion to the Directory.Packages.Props file. Use version specified in the command line | ✔️ | +| 3 | ❌ | ❌ | ✔️ | ❌ | N/A | ❌ | +| 4 | ❌ | ❌ | ✔️ | ✔️ | N/A | ❌ | +| 5 | ❌ | ✔️ | ❌ | ❌ | N/A | ❌ | +| 6 | ❌ | ✔️ | ❌ | ✔️ | N/A | ❌ | +| 7 | ❌ | ✔️ | ✔️ | ❌ | N/A | ❌ | +| 8 | ❌ | ✔️ | ✔️ | ✔️ | N/A | ❌ | +| 9 | ✔️ | ❌ | ❌ | ❌ | N/A | ❌ | +| 10 | ✔️ | ❌ | ❌ | ✔️ | N/A | ❌ | +| 11 | ✔️ | ❌ | ✔️ | ❌ | N/A | ❌ | +| 12 | ✔️ | ❌ | ✔️ | ✔️ | N/A | ❌ | +| 13 | ✔️ | ✔️ |❌ | ❌ | N/A | ❌ | +| 14 | ✔️ | ✔️ | ❌ | ✔️ | N/A | ❌ | +| 15 | ✔️ | ✔️ | ✔️ | ❌ | N/A | ❌ | +| 16 | ✔️ | ✔️ | ✔️ | ✔️ | N/A | ❌ | + + | Scenario # | PackageReference exists? | Directory.Packages.Props file exists? | Is ManagePackageVersionsCentrally property set to true? | Is VersionOverride? | Current behavior | New behavior in dotnet CLI | In Scope | | ---- |-----| -----|-----|----------|----------|----------|----------| | 1 | ❌ | ✔️ | ✔️ (in Directory.Packages.Props or .csproj file) | ❌ | Restore failed with NU1008 error and NO edits were made to the csproj file (same in VS and dotnet CLI) | `PackageReference` should be added to .(cs/vb)proj file and `PackageVersion` should be added to the closest `Directory.Packages.Props` file | ✔️ | From 39d848ce97842053596742ddd2b681f3526c0067 Mon Sep 17 00:00:00 2001 From: Kartheek Penagamuri <52756182+kartheekp-ms@users.noreply.github.com> Date: Wed, 22 Jun 2022 17:59:57 -0700 Subject: [PATCH 02/20] more updates --- .../cpm-dotnet-cli-add-package-support.md | 43 ++++++++----------- 1 file changed, 17 insertions(+), 26 deletions(-) diff --git a/proposed/2022/cpm-dotnet-cli-add-package-support.md b/proposed/2022/cpm-dotnet-cli-add-package-support.md index 91b4e1f..e4cec4d 100644 --- a/proposed/2022/cpm-dotnet-cli-add-package-support.md +++ b/proposed/2022/cpm-dotnet-cli-add-package-support.md @@ -22,33 +22,24 @@ Users wanting to use CPM onboarded projects and dotnet CLI commands. When `dotnet add package` is executed in a project onboarded to CPM (meaning that the `Directory.packages.props` file exists) there are a few scenarios that must be considered. -| Scenario # | PackageReference exists? | VersionOverride exists? | PackageVersion exists? | Is Version specified from the commandline | New behavior in dotnet CLI | In Scope | +| Scenario # | PackageReference exists? | VersionOverride exists? | PackageVersion exists? | Is Version specified from the commandline | New behavior in dotnet CLI | In Scope for V1?| | ---- |----- | ----- | ---- |---- | ----- | ---- | -| 1 | ❌ | ❌ | ❌ | ❌ | Add PackageReference to the project file. Add PackageVersion to the Directory.Packages.Props file. Use latest version from the package sources| ✔️ | -| 2 | ❌ | ❌ | ❌ | ✔️ | Add PackageReference to the project file. Add PackageVersion to the Directory.Packages.Props file. Use version specified in the command line | ✔️ | -| 3 | ❌ | ❌ | ✔️ | ❌ | N/A | ❌ | -| 4 | ❌ | ❌ | ✔️ | ✔️ | N/A | ❌ | -| 5 | ❌ | ✔️ | ❌ | ❌ | N/A | ❌ | -| 6 | ❌ | ✔️ | ❌ | ✔️ | N/A | ❌ | -| 7 | ❌ | ✔️ | ✔️ | ❌ | N/A | ❌ | -| 8 | ❌ | ✔️ | ✔️ | ✔️ | N/A | ❌ | -| 9 | ✔️ | ❌ | ❌ | ❌ | N/A | ❌ | -| 10 | ✔️ | ❌ | ❌ | ✔️ | N/A | ❌ | -| 11 | ✔️ | ❌ | ✔️ | ❌ | N/A | ❌ | -| 12 | ✔️ | ❌ | ✔️ | ✔️ | N/A | ❌ | -| 13 | ✔️ | ✔️ |❌ | ❌ | N/A | ❌ | -| 14 | ✔️ | ✔️ | ❌ | ✔️ | N/A | ❌ | -| 15 | ✔️ | ✔️ | ✔️ | ❌ | N/A | ❌ | -| 16 | ✔️ | ✔️ | ✔️ | ✔️ | N/A | ❌ | - - -| Scenario # | PackageReference exists? | Directory.Packages.Props file exists? | Is ManagePackageVersionsCentrally property set to true? | Is VersionOverride? | Current behavior | New behavior in dotnet CLI | In Scope | -| ---- |-----| -----|-----|----------|----------|----------|----------| -| 1 | ❌ | ✔️ | ✔️ (in Directory.Packages.Props or .csproj file) | ❌ | Restore failed with NU1008 error and NO edits were made to the csproj file (same in VS and dotnet CLI) | `PackageReference` should be added to .(cs/vb)proj file and `PackageVersion` should be added to the closest `Directory.Packages.Props` file | ✔️ | -| 2 | ❌ | ❌ | ✔️ in (cs/vb)proj file | ❌ | Restore failed with NU1008 error and NO edits were made to the csproj file (same in VS and dotnet CLI) | `PackageReference` and `Version` should be added to .(cs/vb)proj file.| ✔️ | -| 3 | ❌ | ✔️ | ❌ | ❌ | `PackageReference` and `Version` added to .(cs/vb)proj file. | In addition to the current behavior `Directory.packages.props` file should be deleted if it exists in the project folder | ❌ | -| 4 | ✔️ | ✔️ | ✔️ | ❌ | **dotnet CLI** - Restore failed with NU1008 error and NO edits were made to the csproj file. **VS** - Clicked on Update package in PM UI. New `PackageVersion` added to csproj file and `Directory.packages.props` file was not updated | No changes should be made to the `Directory.Packages.Props` file. Add `VersionOverride` attribute to the existing `PackageReference` item in .(cs/vb)proj file. If `VersionOverride` is already specified then the value should be updated.|✔️ [More Info](https://github.com/NuGet/Home/pull/11849#discussion_r890639808) | -| 5 | ✔️ | ✔️ | ✔️ | ✔️ | **dotnet CLI** - Restore failed with NU1008 error and NO edits were made to the csproj file. **VS** - Clicked on Update package in PM UI. New `PackageVersion` added to csproj file and `VersionOverride` in .csproj file was not updated | Update `VersionOverride` attribute value in the corresponding `PackageReference` item in .(cs/vb)proj file. | ✔️ | +| 1 | ❌ | ❌ | ❌ | ❌ | Add PackageReference to the project file. Add PackageVersion to the Directory.Packages.Props file. Use latest version from the package sources. | ✔️ | +| 2 | ❌ | ❌ | ❌ | ✔️ | Add PackageReference to the project file. Add PackageVersion to the Directory.Packages.Props file. Use version specified in the commandline. | ✔️ | +| 3 | ❌ | ❌ | ✔️ | ❌ | Add PackageReference to the project file. No changes to the Directory.Packages.Props file. Basically we are reusing the version defined centrally for this package. | ✔️ | +| 4 | ❌ | ❌ | ✔️ | ✔️ | Add PackageReference to the project file. Update PackageVersion in the Directory.Packages.Props file. | ✔️ | +| 5 | ❌ | ✔️ | ❌ | ❌ | Not a valid scenario because a VersionOverride can't exist without PackageReference. | ❌ | +| 6 | ❌ | ✔️ | ❌ | ✔️ | Not a valid scenario because a VersionOverride can't exist without PackageReference. | ❌ | +| 7 | ❌ | ✔️ | ✔️ | ❌ | Not a valid scenario because a VersionOverride can't exist without PackageReference. | ❌ | +| 8 | ❌ | ✔️ | ✔️ | ✔️ | Not a valid scenario because a VersionOverride can't exist without PackageReference. | ❌ | +| 9 | ✔️ | ❌ | ❌ | ❌ | Emit an error -OR- Remove Version from PackageReference, Add PackageVersion to the Directory.Packages.Props file. Use Version from PackageReference if it exists otherwise use latest version from the package sources. | ✔️ | +| 10 | ✔️ | ❌ | ❌ | ✔️ | Emit an error -OR- Remove Version from PackageReference, Add PackageVersion to the Directory.Packages.Props file. Use Version passed to the commandline. | ✔️ | +| 11 | ✔️ | ❌ | ✔️ | ❌ | No-op -OR- update to latest | ✔️ | +| 12 | ✔️ | ❌ | ✔️ | ✔️ | Update PackageVersion in the Directory.Packages.Props file. | ✔️ | +| 13 | ✔️ | ✔️ |❌ | ❌ | Update VersionOverride in the existing PackageReference item, use latest version from the package sources. | ✔️ | +| 14 | ✔️ | ✔️ | ❌ | ✔️ | Update VersionOverride in the existing PackageReference item, use version specified in the commandline. | ✔️ | +| 15 | ✔️ | ✔️ | ✔️ | ❌ | Update VersionOverride in the existing PackageReference item, use latest version from the package sources. | ✔️ | +| 16 | ✔️ | ✔️ | ✔️ | ✔️ | Update VersionOverride in the existing PackageReference item, use version specified in the commandline. | ✔️ | > [!NOTE] > Scenarios with multiple Directory.Packages.props are out of scope for now. From 773a7c81aa6db07ccc31e37b6b9a9346f5b5091e Mon Sep 17 00:00:00 2001 From: Kartheek Penagamuri <52756182+kartheekp-ms@users.noreply.github.com> Date: Wed, 22 Jun 2022 18:07:49 -0700 Subject: [PATCH 03/20] more updates --- proposed/2022/cpm-dotnet-cli-add-package-support.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposed/2022/cpm-dotnet-cli-add-package-support.md b/proposed/2022/cpm-dotnet-cli-add-package-support.md index e4cec4d..ad10601 100644 --- a/proposed/2022/cpm-dotnet-cli-add-package-support.md +++ b/proposed/2022/cpm-dotnet-cli-add-package-support.md @@ -35,7 +35,7 @@ When `dotnet add package` is executed in a project onboarded to CPM (meaning tha | 9 | ✔️ | ❌ | ❌ | ❌ | Emit an error -OR- Remove Version from PackageReference, Add PackageVersion to the Directory.Packages.Props file. Use Version from PackageReference if it exists otherwise use latest version from the package sources. | ✔️ | | 10 | ✔️ | ❌ | ❌ | ✔️ | Emit an error -OR- Remove Version from PackageReference, Add PackageVersion to the Directory.Packages.Props file. Use Version passed to the commandline. | ✔️ | | 11 | ✔️ | ❌ | ✔️ | ❌ | No-op -OR- update to latest | ✔️ | -| 12 | ✔️ | ❌ | ✔️ | ✔️ | Update PackageVersion in the Directory.Packages.Props file. | ✔️ | +| 12 | ✔️ | ❌ | ✔️ | ✔️ | Update PackageVersion in the Directory.Packages.Props file, use version specified in the commandline. | ✔️ | | 13 | ✔️ | ✔️ |❌ | ❌ | Update VersionOverride in the existing PackageReference item, use latest version from the package sources. | ✔️ | | 14 | ✔️ | ✔️ | ❌ | ✔️ | Update VersionOverride in the existing PackageReference item, use version specified in the commandline. | ✔️ | | 15 | ✔️ | ✔️ | ✔️ | ❌ | Update VersionOverride in the existing PackageReference item, use latest version from the package sources. | ✔️ | From 7e689ac67bdc44247033c976b756e7f8f762439d Mon Sep 17 00:00:00 2001 From: Kartheek Penagamuri <52756182+kartheekp-ms@users.noreply.github.com> Date: Wed, 22 Jun 2022 18:11:10 -0700 Subject: [PATCH 04/20] update --- proposed/2022/cpm-dotnet-cli-add-package-support.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposed/2022/cpm-dotnet-cli-add-package-support.md b/proposed/2022/cpm-dotnet-cli-add-package-support.md index ad10601..1597591 100644 --- a/proposed/2022/cpm-dotnet-cli-add-package-support.md +++ b/proposed/2022/cpm-dotnet-cli-add-package-support.md @@ -34,7 +34,7 @@ When `dotnet add package` is executed in a project onboarded to CPM (meaning tha | 8 | ❌ | ✔️ | ✔️ | ✔️ | Not a valid scenario because a VersionOverride can't exist without PackageReference. | ❌ | | 9 | ✔️ | ❌ | ❌ | ❌ | Emit an error -OR- Remove Version from PackageReference, Add PackageVersion to the Directory.Packages.Props file. Use Version from PackageReference if it exists otherwise use latest version from the package sources. | ✔️ | | 10 | ✔️ | ❌ | ❌ | ✔️ | Emit an error -OR- Remove Version from PackageReference, Add PackageVersion to the Directory.Packages.Props file. Use Version passed to the commandline. | ✔️ | -| 11 | ✔️ | ❌ | ✔️ | ❌ | No-op -OR- update to latest | ✔️ | +| 11 | ✔️ | ❌ | ✔️ | ❌ | No-op -OR- Update PackageVersion in the Directory.Packages.Props file, use latest version from the package sources. | ✔️ | | 12 | ✔️ | ❌ | ✔️ | ✔️ | Update PackageVersion in the Directory.Packages.Props file, use version specified in the commandline. | ✔️ | | 13 | ✔️ | ✔️ |❌ | ❌ | Update VersionOverride in the existing PackageReference item, use latest version from the package sources. | ✔️ | | 14 | ✔️ | ✔️ | ❌ | ✔️ | Update VersionOverride in the existing PackageReference item, use version specified in the commandline. | ✔️ | From 858b4ad835463fc2d8b16f405f4994aa49643239 Mon Sep 17 00:00:00 2001 From: Kartheek Penagamuri <52756182+kartheekp-ms@users.noreply.github.com> Date: Thu, 23 Jun 2022 07:57:38 -0700 Subject: [PATCH 05/20] work --- proposed/2022/cpm-dotnet-cli-add-package-support.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposed/2022/cpm-dotnet-cli-add-package-support.md b/proposed/2022/cpm-dotnet-cli-add-package-support.md index 1597591..0be053c 100644 --- a/proposed/2022/cpm-dotnet-cli-add-package-support.md +++ b/proposed/2022/cpm-dotnet-cli-add-package-support.md @@ -22,7 +22,7 @@ Users wanting to use CPM onboarded projects and dotnet CLI commands. When `dotnet add package` is executed in a project onboarded to CPM (meaning that the `Directory.packages.props` file exists) there are a few scenarios that must be considered. -| Scenario # | PackageReference exists? | VersionOverride exists? | PackageVersion exists? | Is Version specified from the commandline | New behavior in dotnet CLI | In Scope for V1?| +| Scenario # | PackageReference exists? | VersionOverride exists? | PackageVersion exists? | Is Version passed from the commandline? | New behavior in dotnet CLI | In Scope for V1?| | ---- |----- | ----- | ---- |---- | ----- | ---- | | 1 | ❌ | ❌ | ❌ | ❌ | Add PackageReference to the project file. Add PackageVersion to the Directory.Packages.Props file. Use latest version from the package sources. | ✔️ | | 2 | ❌ | ❌ | ❌ | ✔️ | Add PackageReference to the project file. Add PackageVersion to the Directory.Packages.Props file. Use version specified in the commandline. | ✔️ | From 041684f6812281df81e0b5c9d18c80add6ed4252 Mon Sep 17 00:00:00 2001 From: Kartheek Penagamuri Date: Thu, 23 Jun 2022 12:29:57 -0700 Subject: [PATCH 06/20] more updates to the document --- .../cpm-dotnet-cli-add-package-support.md | 270 ++++-------------- 1 file changed, 57 insertions(+), 213 deletions(-) diff --git a/proposed/2022/cpm-dotnet-cli-add-package-support.md b/proposed/2022/cpm-dotnet-cli-add-package-support.md index 0be053c..1cbeeda 100644 --- a/proposed/2022/cpm-dotnet-cli-add-package-support.md +++ b/proposed/2022/cpm-dotnet-cli-add-package-support.md @@ -4,229 +4,73 @@ - Issue: [11807](https://github.com/NuGet/Home/issues/11807) - Status: In Review -## Problem Background +## Summary The dotnet add package command allows users to add or update a package reference in a project file through the Dotnet CLI. However, when this command is used in a project that has been onboarded to Central Package Management (CPM), it poses an issue as this error is thrown: `error: NU1008: Projects that use central package version management should not define the version on the PackageReference items but on the PackageVersion items: [PackageName]`. -Projects onboarded to CPM use a `Directory.packages.props` file in the root of the repo where package versions are defined centrally. Ideally, when the `dotnet add package` command is used, the package version should only be added to the corresponding package in the `Directory.packages.props` file. However, currently the command attempts to add the package version to the `` in the project which conflicts with the CPM requirements that package versions must only be in the `Directory.packages.props` file. +The main goal is to add support for `dotnet add package` to be used with projects onboarded onto CPM. Regardless of whether the package has already been added to the project or not, the command should allow users to add packages or update the package version in the `Directory.packages.props` file. -## Goals +## Motivation -The main goal is to add support for `dotnet add package` to be used with projects onboarded onto CPM. Regardless of whether the package has already been added to the project or not, the command should allow users to add packages or update the package version in the `Directory.packages.props` file. +Projects onboarded to CPM use a `Directory.packages.props` file in the root of the repo where package versions are defined centrally. Ideally, when the `dotnet add package` command is used, the package version should only be added to the corresponding package in the `Directory.packages.props` file. However, currently the command attempts to add the package version to the `` in the project which conflicts with the CPM requirements that package versions must only be in the `Directory.packages.props` file. -## Customers +Users wanting to use CPM onboarded projects and dotnet CLI commands will be benefited. -Users wanting to use CPM onboarded projects and dotnet CLI commands. +## Explanation -## Solution +### Functional explanation When `dotnet add package` is executed in a project onboarded to CPM (meaning that the `Directory.packages.props` file exists) there are a few scenarios that must be considered. -| Scenario # | PackageReference exists? | VersionOverride exists? | PackageVersion exists? | Is Version passed from the commandline? | New behavior in dotnet CLI | In Scope for V1?| +| Scenario # | PackageReference exists? | VersionOverride exists? | PackageVersion exists? | Is Version passed from the commandline? | New behavior in dotnet CLI | In Scope | | ---- |----- | ----- | ---- |---- | ----- | ---- | -| 1 | ❌ | ❌ | ❌ | ❌ | Add PackageReference to the project file. Add PackageVersion to the Directory.Packages.Props file. Use latest version from the package sources. | ✔️ | -| 2 | ❌ | ❌ | ❌ | ✔️ | Add PackageReference to the project file. Add PackageVersion to the Directory.Packages.Props file. Use version specified in the commandline. | ✔️ | -| 3 | ❌ | ❌ | ✔️ | ❌ | Add PackageReference to the project file. No changes to the Directory.Packages.Props file. Basically we are reusing the version defined centrally for this package. | ✔️ | -| 4 | ❌ | ❌ | ✔️ | ✔️ | Add PackageReference to the project file. Update PackageVersion in the Directory.Packages.Props file. | ✔️ | -| 5 | ❌ | ✔️ | ❌ | ❌ | Not a valid scenario because a VersionOverride can't exist without PackageReference. | ❌ | -| 6 | ❌ | ✔️ | ❌ | ✔️ | Not a valid scenario because a VersionOverride can't exist without PackageReference. | ❌ | -| 7 | ❌ | ✔️ | ✔️ | ❌ | Not a valid scenario because a VersionOverride can't exist without PackageReference. | ❌ | -| 8 | ❌ | ✔️ | ✔️ | ✔️ | Not a valid scenario because a VersionOverride can't exist without PackageReference. | ❌ | -| 9 | ✔️ | ❌ | ❌ | ❌ | Emit an error -OR- Remove Version from PackageReference, Add PackageVersion to the Directory.Packages.Props file. Use Version from PackageReference if it exists otherwise use latest version from the package sources. | ✔️ | -| 10 | ✔️ | ❌ | ❌ | ✔️ | Emit an error -OR- Remove Version from PackageReference, Add PackageVersion to the Directory.Packages.Props file. Use Version passed to the commandline. | ✔️ | -| 11 | ✔️ | ❌ | ✔️ | ❌ | No-op -OR- Update PackageVersion in the Directory.Packages.Props file, use latest version from the package sources. | ✔️ | -| 12 | ✔️ | ❌ | ✔️ | ✔️ | Update PackageVersion in the Directory.Packages.Props file, use version specified in the commandline. | ✔️ | -| 13 | ✔️ | ✔️ |❌ | ❌ | Update VersionOverride in the existing PackageReference item, use latest version from the package sources. | ✔️ | -| 14 | ✔️ | ✔️ | ❌ | ✔️ | Update VersionOverride in the existing PackageReference item, use version specified in the commandline. | ✔️ | -| 15 | ✔️ | ✔️ | ✔️ | ❌ | Update VersionOverride in the existing PackageReference item, use latest version from the package sources. | ✔️ | -| 16 | ✔️ | ✔️ | ✔️ | ✔️ | Update VersionOverride in the existing PackageReference item, use version specified in the commandline. | ✔️ | - -> [!NOTE] -> Scenarios with multiple Directory.Packages.props are out of scope for now. - -### 1. The package reference does not exist - -If the package does not already exist, it should be added along with the appropriate package version to `Directory.packages.props`. The package version should either be the latest version or the one specified in the CLI command. Only the package name (not the version) should be added to `` in the project file. - -#### Before `add package` is executed - -The props file: - -```xml - - - true - - - - -``` - -The .csproj file: - -```xml - - - net6.0 - enable - enable - - - - - -``` - -#### After `add package` is executed - -`dotnet add ToDo.csproj package Newtonsoft.Json -v 13.0.1` - -The props file: - -```xml - - - true - - - - - -``` - -The .csproj file: - -```xml - - - net6.0 - enable - enable - - - - - - -``` - -In case there are multiple `Directory.packages.props` files in the repo, the props file that is closest must be considered. - -```xml -Repository - |-- Directory.Packages.props - |-- Solution1 +| 1 | ❌ | ❌ | ❌ | ❌ | Add `PackageReference` to the project file. Add `PackageVersion` to the `Directory.Packages.Props` file. Use latest version from the package sources. | ✔️ | +| 2 | ❌ | ❌ | ❌ | ✔️ | Add `PackageReference` to the project file. Add `PackageVersion` to the `Directory.Packages.Props` file. Use version specified in the commandline. | ✔️ | +| 3 | ❌ | ❌ | ✔️ | ❌ | Add `PackageReference` to the project file. No changes to the `Directory.Packages.Props` file. Basically we are reusing the version defined centrally for this package. | ✔️ | +| 4 | ❌ | ❌ | ✔️ | ✔️ | Add `PackageReference` to the project file. Update `PackageVersion` in the `Directory.Packages.Props` file. | ✔️ | +| 5 | ❌ | ✔️ | ❌ | ❌ | Not a valid scenario because a `VersionOverride` can't exist without `PackageReference`. | ❌ | +| 6 | ❌ | ✔️ | ❌ | ✔️ | Not a valid scenario because a `VersionOverride` can't exist without `PackageReference`. | ❌ | +| 7 | ❌ | ✔️ | ✔️ | ❌ | Not a valid scenario because a `VersionOverride` can't exist without `PackageReference`. | ❌ | +| 8 | ❌ | ✔️ | ✔️ | ✔️ | Not a valid scenario because a `VersionOverride` can't exist without `PackageReference`. | ❌ | +| 9 | ✔️ | ❌ | ❌ | ❌ | Emit an error -OR- Remove Version from `PackageReference`, Add `PackageVersion` to the `Directory.Packages.Props` file. Use `Version` from `PackageReference` if it exists otherwise use latest version from the package sources. | ✔️ | +| 10 | ✔️ | ❌ | ❌ | ✔️ | Emit an error -OR- Remove ``Version from `PackageReference`, Add `PackageVersion` to the `Directory.Packages.Props` file. Use `Version` passed to the commandline. | ✔️ | +| 11 | ✔️ | ❌ | ✔️ | ❌ | No-op -OR- Update `PackageVersion` in the `Directory.Packages.Props` file, use latest version from the package sources. | ✔️ | +| 12 | ✔️ | ❌ | ✔️ | ✔️ | Update `PackageVersion` in the `Directory.Packages.Props` file, use version specified in the commandline. | ✔️ | +| 13 | ✔️ | ✔️ |❌ | ❌ | Update `VersionOverride` in the existing `PackageReference` item, use latest version from the package sources. | ✔️ | +| 14 | ✔️ | ✔️ | ❌ | ✔️ | Update `VersionOverride` in the existing `PackageReference` item, use version specified in the commandline. | ✔️ | +| 15 | ✔️ | ✔️ | ✔️ | ❌ | Update `VersionOverride` in the existing `PackageReference` item, use latest version from the package sources. | ✔️ | +| 16 | ✔️ | ✔️ | ✔️ | ✔️ | Update `VersionOverride` in the existing `PackageReference` item, use version specified in the commandline. | ✔️ | + +### Technical explanation + +NuGet restore operation generates `{projectName}.nuget.dgspec.json` file that file that maintains a project's top-level dependencies along with other metadata for `PackageReference` style projects. +- `dgspec.json` file will have `centralPackageVersionsManagementEnabled` property set to `true` for projects onboarded onto CPM. +- `dotnet add pacakge` command currently access [`ProjectRestoreMetadata`](https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Core/NuGet.ProjectModel/ProjectRestoreMetadata.cs) to perform preview restore. +- [`ProjectRestoreMetadata.CentralPackageVersionsEnabled`](https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Core/NuGet.ProjectModel/ProjectRestoreMetadata.cs#L119) flag will be accessed while executing `dotnet add package` command to verify if the project has onboarded onto CPM. If yes, the scenarios listed in the functional explanation will be handled accordingly. + +## Unresolved Questions + +- Scenarios with multiple `Directory.Packages.props` are out of scope for now. In case there are multiple `Directory.packages.props` files in the repo, the props file that is closest must be considered. + + ``` + Repository |-- Directory.Packages.props - |-- Project1 - |-- Solution2 - |-- Project2 -``` - -In the above example, the following scenarios are possible: - -1. Project1 will evaluate the Directory.Packages.props file in the Repository\Solution1\ directory. -2. Project2 will evaluate the Directory.Packages.props file in the Repository\ directory. - -***Sourced from - -### 2. The package reference does exist - -If the package already exists in `Directory.packages.props` the version should be updated in `Directory.packages.props`. The package version should either be the latest version or the one specified in the CLI command. The `` in the project file should not change. - -#### Before `add package` is executed -The props file: - -```xml - - - true - - - - - -``` - -The .csproj file: - -```xml - - - net6.0 - enable - enable - - - - - - -``` - -#### After `add package` is executed - -`dotnet add ToDo.csproj package Newtonsoft.Json -v 13.0.1` - -No changes should be made to the `Directory.Packages.Props` file. Add `VersionOverride` attribute to the existing `PackageReference` item in .(cs/vb)proj file. If `VersionOverride` is already specified then the value should be updated. - -The .csproj file: - -```xml - - - net6.0 - enable - enable - - - - - - -``` - -### 3. The package reference does exist with an VersionOverride - -If the package already exists in `Directory.packages.props` the version should be updated in `Directory.packages.props`. The package version should either be the latest version or the one specified in the CLI command. The `` in the project file should not change. - -#### Before `add package` is executed - -```xml - - - true - - - - - -``` - -```xml - - - true - - - - - -``` - -#### After `add package` is executed - -- No changes should be made to the `Directory.packages.props` file. -- The version specified in the `VersionOverride` atribute value of `PackageReference` element in the project file should be updated. - -`dotnet add ToDo.csproj package Newtonsoft.Json -v 13.0.1` - -```xml - - - true - - - - - -``` + |-- Solution1 + |-- Directory.Packages.props + |-- Project1 + |-- Solution2 + |-- Project2 + ``` + + In the above example, the following scenarios are possible: + + 1. Project1 will evaluate the Directory.Packages.props file in the Repository\Solution1\ directory. + 2. Project2 will evaluate the Directory.Packages.props file in the Repository\ directory. + + Sourced from + +- The abscence of `Directory.Packages.Props` file for CPM onboarded projects fallback to the current behavior that is adding/updating `PackageReference` & `Version` to the project file. As per [Jeff Kluge's](https://github.com/jeffkl) comment [on a GitHub issue](https://github.com/NuGet/Home/issues/11903#issuecomment-1161996051), `At this time, the customers must use a file named Directory.Packages.props or set an MSBuild property to indicate what file you want to use. Using other files and importing it manually is not a supported scenario.` + +- Scenarios `10` and `11` mentioned in the `Functional explanation` requires clarity about the command functionality. + +- `dotnet add package` by design supports only `PackageReference` style projects. Hence `Packages.Config` style projects remain unsupported. \ No newline at end of file From cd93547d8576cc5bc233cf78aca538a21c132263 Mon Sep 17 00:00:00 2001 From: Kartheek Penagamuri Date: Thu, 23 Jun 2022 12:42:09 -0700 Subject: [PATCH 07/20] more updates --- proposed/2022/cpm-dotnet-cli-add-package-support.md | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/proposed/2022/cpm-dotnet-cli-add-package-support.md b/proposed/2022/cpm-dotnet-cli-add-package-support.md index 1cbeeda..bd9513e 100644 --- a/proposed/2022/cpm-dotnet-cli-add-package-support.md +++ b/proposed/2022/cpm-dotnet-cli-add-package-support.md @@ -47,11 +47,11 @@ NuGet restore operation generates `{projectName}.nuget.dgspec.json` file that fi - `dgspec.json` file will have `centralPackageVersionsManagementEnabled` property set to `true` for projects onboarded onto CPM. - `dotnet add pacakge` command currently access [`ProjectRestoreMetadata`](https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Core/NuGet.ProjectModel/ProjectRestoreMetadata.cs) to perform preview restore. - [`ProjectRestoreMetadata.CentralPackageVersionsEnabled`](https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Core/NuGet.ProjectModel/ProjectRestoreMetadata.cs#L119) flag will be accessed while executing `dotnet add package` command to verify if the project has onboarded onto CPM. If yes, the scenarios listed in the functional explanation will be handled accordingly. +- Leverage the existing functionality in [`MSBuildAPIUtility.cs`](https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Core/NuGet.CommandLine.XPlat/Utility/MSBuildAPIUtility.cs) to modify the `PackageReference` items in project and `PackageVersion` items in the Directory.Packages.Props file. ## Unresolved Questions - Scenarios with multiple `Directory.Packages.props` are out of scope for now. In case there are multiple `Directory.packages.props` files in the repo, the props file that is closest must be considered. - ``` Repository |-- Directory.Packages.props @@ -61,16 +61,10 @@ NuGet restore operation generates `{projectName}.nuget.dgspec.json` file that fi |-- Solution2 |-- Project2 ``` - In the above example, the following scenarios are possible: - 1. Project1 will evaluate the Directory.Packages.props file in the Repository\Solution1\ directory. - 2. Project2 will evaluate the Directory.Packages.props file in the Repository\ directory. - + 2. Project2 will evaluate the Directory.Packages.props file in the Repository\ directory. Sourced from - - The abscence of `Directory.Packages.Props` file for CPM onboarded projects fallback to the current behavior that is adding/updating `PackageReference` & `Version` to the project file. As per [Jeff Kluge's](https://github.com/jeffkl) comment [on a GitHub issue](https://github.com/NuGet/Home/issues/11903#issuecomment-1161996051), `At this time, the customers must use a file named Directory.Packages.props or set an MSBuild property to indicate what file you want to use. Using other files and importing it manually is not a supported scenario.` - - Scenarios `10` and `11` mentioned in the `Functional explanation` requires clarity about the command functionality. - - `dotnet add package` by design supports only `PackageReference` style projects. Hence `Packages.Config` style projects remain unsupported. \ No newline at end of file From b31635b74b1789f5238f1fbe3a38aa927ea1ac98 Mon Sep 17 00:00:00 2001 From: Kartheek Penagamuri Date: Thu, 23 Jun 2022 13:00:29 -0700 Subject: [PATCH 08/20] updates --- proposed/2022/cpm-dotnet-cli-add-package-support.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/proposed/2022/cpm-dotnet-cli-add-package-support.md b/proposed/2022/cpm-dotnet-cli-add-package-support.md index bd9513e..199c2de 100644 --- a/proposed/2022/cpm-dotnet-cli-add-package-support.md +++ b/proposed/2022/cpm-dotnet-cli-add-package-support.md @@ -32,8 +32,8 @@ When `dotnet add package` is executed in a project onboarded to CPM (meaning tha | 6 | ❌ | ✔️ | ❌ | ✔️ | Not a valid scenario because a `VersionOverride` can't exist without `PackageReference`. | ❌ | | 7 | ❌ | ✔️ | ✔️ | ❌ | Not a valid scenario because a `VersionOverride` can't exist without `PackageReference`. | ❌ | | 8 | ❌ | ✔️ | ✔️ | ✔️ | Not a valid scenario because a `VersionOverride` can't exist without `PackageReference`. | ❌ | -| 9 | ✔️ | ❌ | ❌ | ❌ | Emit an error -OR- Remove Version from `PackageReference`, Add `PackageVersion` to the `Directory.Packages.Props` file. Use `Version` from `PackageReference` if it exists otherwise use latest version from the package sources. | ✔️ | -| 10 | ✔️ | ❌ | ❌ | ✔️ | Emit an error -OR- Remove ``Version from `PackageReference`, Add `PackageVersion` to the `Directory.Packages.Props` file. Use `Version` passed to the commandline. | ✔️ | +| 9 | ✔️ | ❌ | ❌ | ❌ | Emit an error -OR- Remove `Version` from `PackageReference`, Add `PackageVersion` to the `Directory.Packages.Props` file. Use `Version` from `PackageReference` if it exists otherwise use latest version from the package sources. | ✔️ | +| 10 | ✔️ | ❌ | ❌ | ✔️ | Emit an error -OR- Remove `Version` from `PackageReference`, Add `PackageVersion` to the `Directory.Packages.Props` file. Use `Version` passed to the commandline. | ✔️ | | 11 | ✔️ | ❌ | ✔️ | ❌ | No-op -OR- Update `PackageVersion` in the `Directory.Packages.Props` file, use latest version from the package sources. | ✔️ | | 12 | ✔️ | ❌ | ✔️ | ✔️ | Update `PackageVersion` in the `Directory.Packages.Props` file, use version specified in the commandline. | ✔️ | | 13 | ✔️ | ✔️ |❌ | ❌ | Update `VersionOverride` in the existing `PackageReference` item, use latest version from the package sources. | ✔️ | @@ -47,7 +47,7 @@ NuGet restore operation generates `{projectName}.nuget.dgspec.json` file that fi - `dgspec.json` file will have `centralPackageVersionsManagementEnabled` property set to `true` for projects onboarded onto CPM. - `dotnet add pacakge` command currently access [`ProjectRestoreMetadata`](https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Core/NuGet.ProjectModel/ProjectRestoreMetadata.cs) to perform preview restore. - [`ProjectRestoreMetadata.CentralPackageVersionsEnabled`](https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Core/NuGet.ProjectModel/ProjectRestoreMetadata.cs#L119) flag will be accessed while executing `dotnet add package` command to verify if the project has onboarded onto CPM. If yes, the scenarios listed in the functional explanation will be handled accordingly. -- Leverage the existing functionality in [`MSBuildAPIUtility.cs`](https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Core/NuGet.CommandLine.XPlat/Utility/MSBuildAPIUtility.cs) to modify the `PackageReference` items in project and `PackageVersion` items in the Directory.Packages.Props file. +- Leverage the existing functionality in [`MSBuildAPIUtility.cs`](https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Core/NuGet.CommandLine.XPlat/Utility/MSBuildAPIUtility.cs) to modify the `PackageReference` items in project and `PackageVersion` items in the `Directory.Packages.Props` file. ## Unresolved Questions @@ -65,6 +65,6 @@ NuGet restore operation generates `{projectName}.nuget.dgspec.json` file that fi 1. Project1 will evaluate the Directory.Packages.props file in the Repository\Solution1\ directory. 2. Project2 will evaluate the Directory.Packages.props file in the Repository\ directory. Sourced from -- The abscence of `Directory.Packages.Props` file for CPM onboarded projects fallback to the current behavior that is adding/updating `PackageReference` & `Version` to the project file. As per [Jeff Kluge's](https://github.com/jeffkl) comment [on a GitHub issue](https://github.com/NuGet/Home/issues/11903#issuecomment-1161996051), `At this time, the customers must use a file named Directory.Packages.props or set an MSBuild property to indicate what file you want to use. Using other files and importing it manually is not a supported scenario.` -- Scenarios `10` and `11` mentioned in the `Functional explanation` requires clarity about the command functionality. -- `dotnet add package` by design supports only `PackageReference` style projects. Hence `Packages.Config` style projects remain unsupported. \ No newline at end of file +- The abscence of `Directory.Packages.Props` file for CPM onboarded projects fallback to the current behavior that is adding/updating `PackageReference` & `Version` to the project file. As per [Jeff Kluge's](https://github.com/jeffkl) comment [on a GitHub issue](https://github.com/NuGet/Home/issues/11903#issuecomment-1161996051), `At this time, the customers must use a file named Directory.Packages.props or set an MSBuild property to indicate what file you want to use. Using other files and importing it manually is not a supported scenario.`. +- Scenarios `9`, `10` and `11` mentioned in the `Functional explanation` requires clarity about the command functionality. +- `dotnet add package` by design supports only `PackageReference` style projects. Hence `Packages.Config` style projects remain unsupported. Currently there are 2 behaviors defined for those code paths in this proposal. \ No newline at end of file From 3990c047eafd31652b80a9c3c38df72847379087 Mon Sep 17 00:00:00 2001 From: Kartheek Penagamuri Date: Thu, 23 Jun 2022 13:13:59 -0700 Subject: [PATCH 09/20] updates --- .../cpm-dotnet-cli-add-package-support.md | 82 ++++++++++++++++++- 1 file changed, 80 insertions(+), 2 deletions(-) diff --git a/proposed/2022/cpm-dotnet-cli-add-package-support.md b/proposed/2022/cpm-dotnet-cli-add-package-support.md index 199c2de..52cbd8c 100644 --- a/proposed/2022/cpm-dotnet-cli-add-package-support.md +++ b/proposed/2022/cpm-dotnet-cli-add-package-support.md @@ -27,13 +27,13 @@ When `dotnet add package` is executed in a project onboarded to CPM (meaning tha | 1 | ❌ | ❌ | ❌ | ❌ | Add `PackageReference` to the project file. Add `PackageVersion` to the `Directory.Packages.Props` file. Use latest version from the package sources. | ✔️ | | 2 | ❌ | ❌ | ❌ | ✔️ | Add `PackageReference` to the project file. Add `PackageVersion` to the `Directory.Packages.Props` file. Use version specified in the commandline. | ✔️ | | 3 | ❌ | ❌ | ✔️ | ❌ | Add `PackageReference` to the project file. No changes to the `Directory.Packages.Props` file. Basically we are reusing the version defined centrally for this package. | ✔️ | -| 4 | ❌ | ❌ | ✔️ | ✔️ | Add `PackageReference` to the project file. Update `PackageVersion` in the `Directory.Packages.Props` file. | ✔️ | +| 4 | ❌ | ❌ | ✔️ | ✔️ | Add `PackageReference` to the project file. Update `PackageVersion` in the `Directory.Packages.Props` file with the version specified in the commandline. | ✔️ | | 5 | ❌ | ✔️ | ❌ | ❌ | Not a valid scenario because a `VersionOverride` can't exist without `PackageReference`. | ❌ | | 6 | ❌ | ✔️ | ❌ | ✔️ | Not a valid scenario because a `VersionOverride` can't exist without `PackageReference`. | ❌ | | 7 | ❌ | ✔️ | ✔️ | ❌ | Not a valid scenario because a `VersionOverride` can't exist without `PackageReference`. | ❌ | | 8 | ❌ | ✔️ | ✔️ | ✔️ | Not a valid scenario because a `VersionOverride` can't exist without `PackageReference`. | ❌ | | 9 | ✔️ | ❌ | ❌ | ❌ | Emit an error -OR- Remove `Version` from `PackageReference`, Add `PackageVersion` to the `Directory.Packages.Props` file. Use `Version` from `PackageReference` if it exists otherwise use latest version from the package sources. | ✔️ | -| 10 | ✔️ | ❌ | ❌ | ✔️ | Emit an error -OR- Remove `Version` from `PackageReference`, Add `PackageVersion` to the `Directory.Packages.Props` file. Use `Version` passed to the commandline. | ✔️ | +| 10 | ✔️ | ❌ | ❌ | ✔️ | Emit an error -OR- Remove `Version` from `PackageReference`, Add `PackageVersion` to the `Directory.Packages.Props` file. Use `Version` passed in the commandline. | ✔️ | | 11 | ✔️ | ❌ | ✔️ | ❌ | No-op -OR- Update `PackageVersion` in the `Directory.Packages.Props` file, use latest version from the package sources. | ✔️ | | 12 | ✔️ | ❌ | ✔️ | ✔️ | Update `PackageVersion` in the `Directory.Packages.Props` file, use version specified in the commandline. | ✔️ | | 13 | ✔️ | ✔️ |❌ | ❌ | Update `VersionOverride` in the existing `PackageReference` item, use latest version from the package sources. | ✔️ | @@ -49,6 +49,84 @@ NuGet restore operation generates `{projectName}.nuget.dgspec.json` file that fi - [`ProjectRestoreMetadata.CentralPackageVersionsEnabled`](https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Core/NuGet.ProjectModel/ProjectRestoreMetadata.cs#L119) flag will be accessed while executing `dotnet add package` command to verify if the project has onboarded onto CPM. If yes, the scenarios listed in the functional explanation will be handled accordingly. - Leverage the existing functionality in [`MSBuildAPIUtility.cs`](https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Core/NuGet.CommandLine.XPlat/Utility/MSBuildAPIUtility.cs) to modify the `PackageReference` items in project and `PackageVersion` items in the `Directory.Packages.Props` file. +
+ Sample C# code snippet for working with MSBuild API to update the project files + + Thanks to [Jeff Kluge's](https://github.com/jeffkl) for this code snippet with us. + + ```cs + Project project = new Project(@"D:\Samples\CentralPackageManagementExample\src\ClassLibrary1\ClassLibrary1.csproj"); + string id = "Newtonsoft.Json2"; + string version = "2.0.0"; + // Find the last declared item with a matching the package ID + ProjectItem packageReference = project.Items.LastOrDefault(i => i.ItemType == "PackageReference" && i.EvaluatedInclude.Equals(id)); + // Find the last declared item with a matching the package ID + ProjectItem packageVersion = project.Items.LastOrDefault(i => i.ItemType == "PackageVersion" && i.EvaluatedInclude.Equals(id)); + // Add a item if one does not already exist + if (packageReference != null) + { + // Determine which to add to by searching for the first one available: + // Find the first in the project so we know what ItemGroup to add to + // -or- + // Use the first first ItemGroup + // -or- + // Add a new ItemGroup + ProjectItemGroupElement itemGroupElement = project.Xml.ItemGroups.FirstOrDefault(i => i.Items.Any(i => i.ItemType == "PackageReference")) + ?? project.Xml.ItemGroups.FirstOrDefault() + ?? project.Xml.AddItemGroup(); + // TODO: Add the item in sorted order + // Add the item + itemGroupElement.AddItem("PackageReference", id); + // Save the main project + project.Save(); + } + // Add a to Directory.Build.props if one does not already exist + if (packageVersion == null) + { + // Technically the Directory.Package.props path is stored in an MSBuild property + string directoryPackagesPropsPath = project.GetPropertyValue("DirectoryPackagesPropsPath"); + // Get the Directory.Build.props + ProjectRootElement directoryBuildPropsRootElement = project.Imports.FirstOrDefault(i => i.ImportedProject.FullPath.Equals(directoryPackagesPropsPath)).ImportedProject; + // Get the ItemGroup to add a PackageVersion to + // Find the first that contains a + // -or- + // Find the first + // -or- + // Add an + ProjectItemGroupElement packageVersionItemGroupElement = directoryBuildPropsRootElement.ItemGroups.FirstOrDefault(i => i.Items.Any(i => i.ItemType == "PackageVersion")) + ?? directoryBuildPropsRootElement.ItemGroups.FirstOrDefault() + ?? directoryBuildPropsRootElement.AddItemGroup(); + // Add a item + ProjectItemElement packageVersionItemElement = packageVersionItemGroupElement.AddItem("PackageVersion", id); + // Set the Version attribute + packageVersionItemElement.AddMetadata("Version", version, expressAsAttribute: true); + directoryBuildPropsRootElement.Save(); + } + // Only update if it doesn't currently have the specified value + else if (!packageVersion.GetMetadataValue("Version").Equals(version)) + { + // Determine where the item is decalred + ProjectItemElement packageVersionItemElement = project.GetItemProvenance(packageVersion).LastOrDefault()?.ItemElement; + if (packageVersionItemElement == null) + { + throw new Exception("Failed to find item provenance"); + } + // Get the Version attribute + ProjectMetadataElement versionAttribute = packageVersionItemElement.Metadata.FirstOrDefault(i => i.Name.Equals("Version")); + if (versionAttribute != null) + { + // Set the Version + versionAttribute.Value = version; + } + else + { + // Add the Version attribute + packageVersionItemElement.AddMetadata("Version", version, expressAsAttribute: true); + } + packageVersionItemElement.ContainingProject.Save(); + } + ``` +
## Unresolved Questions - Scenarios with multiple `Directory.Packages.props` are out of scope for now. In case there are multiple `Directory.packages.props` files in the repo, the props file that is closest must be considered. From 65090295251306800b4468d0dc8370400834bc77 Mon Sep 17 00:00:00 2001 From: Kartheek Penagamuri Date: Thu, 23 Jun 2022 13:14:55 -0700 Subject: [PATCH 10/20] typo --- proposed/2022/cpm-dotnet-cli-add-package-support.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/proposed/2022/cpm-dotnet-cli-add-package-support.md b/proposed/2022/cpm-dotnet-cli-add-package-support.md index 52cbd8c..e1e9106 100644 --- a/proposed/2022/cpm-dotnet-cli-add-package-support.md +++ b/proposed/2022/cpm-dotnet-cli-add-package-support.md @@ -53,7 +53,7 @@ NuGet restore operation generates `{projectName}.nuget.dgspec.json` file that fi Sample C# code snippet for working with MSBuild API to update the project files Thanks to [Jeff Kluge's](https://github.com/jeffkl) for this code snippet with us. - + ```cs Project project = new Project(@"D:\Samples\CentralPackageManagementExample\src\ClassLibrary1\ClassLibrary1.csproj"); string id = "Newtonsoft.Json2"; @@ -127,6 +127,7 @@ NuGet restore operation generates `{projectName}.nuget.dgspec.json` file that fi } ``` + ## Unresolved Questions - Scenarios with multiple `Directory.Packages.props` are out of scope for now. In case there are multiple `Directory.packages.props` files in the repo, the props file that is closest must be considered. From fdc275bbf21a934114e8943b633a07488a078950 Mon Sep 17 00:00:00 2001 From: Kartheek Penagamuri <52756182+kartheekp-ms@users.noreply.github.com> Date: Thu, 23 Jun 2022 14:25:46 -0700 Subject: [PATCH 11/20] fix typo (package) --- proposed/2022/cpm-dotnet-cli-add-package-support.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/proposed/2022/cpm-dotnet-cli-add-package-support.md b/proposed/2022/cpm-dotnet-cli-add-package-support.md index e1e9106..3dda6c1 100644 --- a/proposed/2022/cpm-dotnet-cli-add-package-support.md +++ b/proposed/2022/cpm-dotnet-cli-add-package-support.md @@ -45,7 +45,7 @@ When `dotnet add package` is executed in a project onboarded to CPM (meaning tha NuGet restore operation generates `{projectName}.nuget.dgspec.json` file that file that maintains a project's top-level dependencies along with other metadata for `PackageReference` style projects. - `dgspec.json` file will have `centralPackageVersionsManagementEnabled` property set to `true` for projects onboarded onto CPM. -- `dotnet add pacakge` command currently access [`ProjectRestoreMetadata`](https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Core/NuGet.ProjectModel/ProjectRestoreMetadata.cs) to perform preview restore. +- `dotnet add package` command currently access [`ProjectRestoreMetadata`](https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Core/NuGet.ProjectModel/ProjectRestoreMetadata.cs) to perform preview restore. - [`ProjectRestoreMetadata.CentralPackageVersionsEnabled`](https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Core/NuGet.ProjectModel/ProjectRestoreMetadata.cs#L119) flag will be accessed while executing `dotnet add package` command to verify if the project has onboarded onto CPM. If yes, the scenarios listed in the functional explanation will be handled accordingly. - Leverage the existing functionality in [`MSBuildAPIUtility.cs`](https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Core/NuGet.CommandLine.XPlat/Utility/MSBuildAPIUtility.cs) to modify the `PackageReference` items in project and `PackageVersion` items in the `Directory.Packages.Props` file. @@ -146,4 +146,4 @@ NuGet restore operation generates `{projectName}.nuget.dgspec.json` file that fi Sourced from - The abscence of `Directory.Packages.Props` file for CPM onboarded projects fallback to the current behavior that is adding/updating `PackageReference` & `Version` to the project file. As per [Jeff Kluge's](https://github.com/jeffkl) comment [on a GitHub issue](https://github.com/NuGet/Home/issues/11903#issuecomment-1161996051), `At this time, the customers must use a file named Directory.Packages.props or set an MSBuild property to indicate what file you want to use. Using other files and importing it manually is not a supported scenario.`. - Scenarios `9`, `10` and `11` mentioned in the `Functional explanation` requires clarity about the command functionality. -- `dotnet add package` by design supports only `PackageReference` style projects. Hence `Packages.Config` style projects remain unsupported. Currently there are 2 behaviors defined for those code paths in this proposal. \ No newline at end of file +- `dotnet add package` by design supports only `PackageReference` style projects. Hence `Packages.Config` style projects remain unsupported. Currently there are 2 behaviors defined for those code paths in this proposal. From c87a6db159a5d8b7a4aa2733666458f337a2d1a3 Mon Sep 17 00:00:00 2001 From: Kartheek Penagamuri <52756182+kartheekp-ms@users.noreply.github.com> Date: Thu, 23 Jun 2022 14:38:09 -0700 Subject: [PATCH 12/20] typo --- proposed/2022/cpm-dotnet-cli-add-package-support.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposed/2022/cpm-dotnet-cli-add-package-support.md b/proposed/2022/cpm-dotnet-cli-add-package-support.md index 3dda6c1..9e0c22a 100644 --- a/proposed/2022/cpm-dotnet-cli-add-package-support.md +++ b/proposed/2022/cpm-dotnet-cli-add-package-support.md @@ -52,7 +52,7 @@ NuGet restore operation generates `{projectName}.nuget.dgspec.json` file that fi
Sample C# code snippet for working with MSBuild API to update the project files - Thanks to [Jeff Kluge's](https://github.com/jeffkl) for this code snippet with us. + Thanks to [Jeff Kluge's](https://github.com/jeffkl) for sharing this code snippet with us. ```cs Project project = new Project(@"D:\Samples\CentralPackageManagementExample\src\ClassLibrary1\ClassLibrary1.csproj"); From 22a50b360d1208ba4a2bc2bcfe0e0bfe031a12e3 Mon Sep 17 00:00:00 2001 From: Kartheek Penagamuri <52756182+kartheekp-ms@users.noreply.github.com> Date: Thu, 23 Jun 2022 21:28:29 -0700 Subject: [PATCH 13/20] typo --- proposed/2022/cpm-dotnet-cli-add-package-support.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposed/2022/cpm-dotnet-cli-add-package-support.md b/proposed/2022/cpm-dotnet-cli-add-package-support.md index 9e0c22a..78e458a 100644 --- a/proposed/2022/cpm-dotnet-cli-add-package-support.md +++ b/proposed/2022/cpm-dotnet-cli-add-package-support.md @@ -52,7 +52,7 @@ NuGet restore operation generates `{projectName}.nuget.dgspec.json` file that fi
Sample C# code snippet for working with MSBuild API to update the project files - Thanks to [Jeff Kluge's](https://github.com/jeffkl) for sharing this code snippet with us. + Thanks to [Jeff Kluge](https://github.com/jeffkl) for sharing this code snippet with us. ```cs Project project = new Project(@"D:\Samples\CentralPackageManagementExample\src\ClassLibrary1\ClassLibrary1.csproj"); From 9bbd4a8fae81ea49c407a815b0826d5e3bfecb6f Mon Sep 17 00:00:00 2001 From: Kartheek Penagamuri <52756182+kartheekp-ms@users.noreply.github.com> Date: Thu, 23 Jun 2022 21:30:03 -0700 Subject: [PATCH 14/20] update --- proposed/2022/cpm-dotnet-cli-add-package-support.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposed/2022/cpm-dotnet-cli-add-package-support.md b/proposed/2022/cpm-dotnet-cli-add-package-support.md index 78e458a..11f6aee 100644 --- a/proposed/2022/cpm-dotnet-cli-add-package-support.md +++ b/proposed/2022/cpm-dotnet-cli-add-package-support.md @@ -50,7 +50,7 @@ NuGet restore operation generates `{projectName}.nuget.dgspec.json` file that fi - Leverage the existing functionality in [`MSBuildAPIUtility.cs`](https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Core/NuGet.CommandLine.XPlat/Utility/MSBuildAPIUtility.cs) to modify the `PackageReference` items in project and `PackageVersion` items in the `Directory.Packages.Props` file.
- Sample C# code snippet for working with MSBuild API to update the project files + Sample C# code snippet for working with MSBuild API to update the project and Directory.Packages.Props files Thanks to [Jeff Kluge](https://github.com/jeffkl) for sharing this code snippet with us. From e01cd9b8f74700c8f1ec42c806ebfd8513bbd34b Mon Sep 17 00:00:00 2001 From: Kartheek Penagamuri <52756182+kartheekp-ms@users.noreply.github.com> Date: Thu, 23 Jun 2022 21:31:59 -0700 Subject: [PATCH 15/20] update --- proposed/2022/cpm-dotnet-cli-add-package-support.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/proposed/2022/cpm-dotnet-cli-add-package-support.md b/proposed/2022/cpm-dotnet-cli-add-package-support.md index 11f6aee..797e581 100644 --- a/proposed/2022/cpm-dotnet-cli-add-package-support.md +++ b/proposed/2022/cpm-dotnet-cli-add-package-support.md @@ -145,5 +145,5 @@ NuGet restore operation generates `{projectName}.nuget.dgspec.json` file that fi 2. Project2 will evaluate the Directory.Packages.props file in the Repository\ directory. Sourced from - The abscence of `Directory.Packages.Props` file for CPM onboarded projects fallback to the current behavior that is adding/updating `PackageReference` & `Version` to the project file. As per [Jeff Kluge's](https://github.com/jeffkl) comment [on a GitHub issue](https://github.com/NuGet/Home/issues/11903#issuecomment-1161996051), `At this time, the customers must use a file named Directory.Packages.props or set an MSBuild property to indicate what file you want to use. Using other files and importing it manually is not a supported scenario.`. -- Scenarios `9`, `10` and `11` mentioned in the `Functional explanation` requires clarity about the command functionality. -- `dotnet add package` by design supports only `PackageReference` style projects. Hence `Packages.Config` style projects remain unsupported. Currently there are 2 behaviors defined for those code paths in this proposal. +- Scenarios `9`, `10` and `11` mentioned in the `Functional explanation` requires clarity about the command functionality. Currently there are 2 behaviors defined for these scenarios code paths in this proposal. +- `dotnet add package` by design supports only `PackageReference` style projects. Hence `Packages.Config` style projects remain unsupported. From a89f7fd5af9df6a09496e5212aab9a744378c8b0 Mon Sep 17 00:00:00 2001 From: Kartheek Penagamuri <52756182+kartheekp-ms@users.noreply.github.com> Date: Thu, 23 Jun 2022 21:33:05 -0700 Subject: [PATCH 16/20] update --- proposed/2022/cpm-dotnet-cli-add-package-support.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposed/2022/cpm-dotnet-cli-add-package-support.md b/proposed/2022/cpm-dotnet-cli-add-package-support.md index 797e581..046618a 100644 --- a/proposed/2022/cpm-dotnet-cli-add-package-support.md +++ b/proposed/2022/cpm-dotnet-cli-add-package-support.md @@ -145,5 +145,5 @@ NuGet restore operation generates `{projectName}.nuget.dgspec.json` file that fi 2. Project2 will evaluate the Directory.Packages.props file in the Repository\ directory. Sourced from - The abscence of `Directory.Packages.Props` file for CPM onboarded projects fallback to the current behavior that is adding/updating `PackageReference` & `Version` to the project file. As per [Jeff Kluge's](https://github.com/jeffkl) comment [on a GitHub issue](https://github.com/NuGet/Home/issues/11903#issuecomment-1161996051), `At this time, the customers must use a file named Directory.Packages.props or set an MSBuild property to indicate what file you want to use. Using other files and importing it manually is not a supported scenario.`. -- Scenarios `9`, `10` and `11` mentioned in the `Functional explanation` requires clarity about the command functionality. Currently there are 2 behaviors defined for these scenarios code paths in this proposal. +- Scenarios `9`, `10` and `11` mentioned in the `Functional explanation` requires clarity about the command functionality. Currently there are 2 behaviors defined for these scenarios in this proposal. - `dotnet add package` by design supports only `PackageReference` style projects. Hence `Packages.Config` style projects remain unsupported. From 76641a4b0b3f24056997d3ff93f859fe15aa1d32 Mon Sep 17 00:00:00 2001 From: pragnya17 <59893188+pragnya17@users.noreply.github.com> Date: Thu, 30 Jun 2022 09:50:12 -0700 Subject: [PATCH 17/20] Updates after design spec PR review meeting --- .../2022/cpm-dotnet-cli-add-package-support.md | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/proposed/2022/cpm-dotnet-cli-add-package-support.md b/proposed/2022/cpm-dotnet-cli-add-package-support.md index 046618a..679d8c6 100644 --- a/proposed/2022/cpm-dotnet-cli-add-package-support.md +++ b/proposed/2022/cpm-dotnet-cli-add-package-support.md @@ -32,13 +32,13 @@ When `dotnet add package` is executed in a project onboarded to CPM (meaning tha | 6 | ❌ | ✔️ | ❌ | ✔️ | Not a valid scenario because a `VersionOverride` can't exist without `PackageReference`. | ❌ | | 7 | ❌ | ✔️ | ✔️ | ❌ | Not a valid scenario because a `VersionOverride` can't exist without `PackageReference`. | ❌ | | 8 | ❌ | ✔️ | ✔️ | ✔️ | Not a valid scenario because a `VersionOverride` can't exist without `PackageReference`. | ❌ | -| 9 | ✔️ | ❌ | ❌ | ❌ | Emit an error -OR- Remove `Version` from `PackageReference`, Add `PackageVersion` to the `Directory.Packages.Props` file. Use `Version` from `PackageReference` if it exists otherwise use latest version from the package sources. | ✔️ | -| 10 | ✔️ | ❌ | ❌ | ✔️ | Emit an error -OR- Remove `Version` from `PackageReference`, Add `PackageVersion` to the `Directory.Packages.Props` file. Use `Version` passed in the commandline. | ✔️ | -| 11 | ✔️ | ❌ | ✔️ | ❌ | No-op -OR- Update `PackageVersion` in the `Directory.Packages.Props` file, use latest version from the package sources. | ✔️ | +| 9 | ✔️ | ❌ | ❌ | ❌ | Emit an error. (The other considered option was: Remove `Version` from `PackageReference`, Add `PackageVersion` to the `Directory.Packages.Props` file. Use `Version` from `PackageReference` if it exists otherwise use latest version from the package sources. However, this might require more user research.) | ✔️ | +| 10 | ✔️ | ❌ | ❌ | ✔️ | Emit an error. (The other considered option was: Remove `Version` from `PackageReference`, Add `PackageVersion` to the `Directory.Packages.Props` file. Use `Version` passed in the commandline. However, this might require more user research.) | ✔️ | +| 11 | ✔️ | ❌ | ✔️ | ❌ | No-op. (The other considered option was: Update `PackageVersion` in the `Directory.Packages.Props` file, use latest version from the package sources. However, we decided it would be best to only update a version when the user explicitly passes in the commandline argument.) | ✔️ | | 12 | ✔️ | ❌ | ✔️ | ✔️ | Update `PackageVersion` in the `Directory.Packages.Props` file, use version specified in the commandline. | ✔️ | -| 13 | ✔️ | ✔️ |❌ | ❌ | Update `VersionOverride` in the existing `PackageReference` item, use latest version from the package sources. | ✔️ | +| 13 | ✔️ | ✔️ |❌ | ❌ | No-op. | ✔️ | | 14 | ✔️ | ✔️ | ❌ | ✔️ | Update `VersionOverride` in the existing `PackageReference` item, use version specified in the commandline. | ✔️ | -| 15 | ✔️ | ✔️ | ✔️ | ❌ | Update `VersionOverride` in the existing `PackageReference` item, use latest version from the package sources. | ✔️ | +| 15 | ✔️ | ✔️ | ✔️ | ❌ | No-op. | ✔️ | | 16 | ✔️ | ✔️ | ✔️ | ✔️ | Update `VersionOverride` in the existing `PackageReference` item, use version specified in the commandline. | ✔️ | ### Technical explanation @@ -144,6 +144,8 @@ NuGet restore operation generates `{projectName}.nuget.dgspec.json` file that fi 1. Project1 will evaluate the Directory.Packages.props file in the Repository\Solution1\ directory. 2. Project2 will evaluate the Directory.Packages.props file in the Repository\ directory. Sourced from -- The abscence of `Directory.Packages.Props` file for CPM onboarded projects fallback to the current behavior that is adding/updating `PackageReference` & `Version` to the project file. As per [Jeff Kluge's](https://github.com/jeffkl) comment [on a GitHub issue](https://github.com/NuGet/Home/issues/11903#issuecomment-1161996051), `At this time, the customers must use a file named Directory.Packages.props or set an MSBuild property to indicate what file you want to use. Using other files and importing it manually is not a supported scenario.`. -- Scenarios `9`, `10` and `11` mentioned in the `Functional explanation` requires clarity about the command functionality. Currently there are 2 behaviors defined for these scenarios in this proposal. -- `dotnet add package` by design supports only `PackageReference` style projects. Hence `Packages.Config` style projects remain unsupported. + + Another potential solution would be to create a command line argument that takes in the `Directory.packages.props` file's path that the user intends to update, rather than choosing the closest props file by deafult. +- The absence of the `Directory.Packages.Props` file for CPM onboarded projects means that the project is not onboarded to CPM. As per [Jeff Kluge's](https://github.com/jeffkl) comment [on a GitHub issue](https://github.com/NuGet/Home/issues/11903#issuecomment-1161996051), `At this time, the customers must use a file named Directory.Packages.props or set an MSBuild property to indicate what file you want to use. Using other files and importing it manually is not a supported scenario.`. Therefore the tool will fall back to the current behavior that is adding/updating the `PackageReference` & `Version` in the project file. + - If a user wants to onboard to CPM, they will have to create the `Directory.Packages.Props` explicitly through a CLI commandline argument/CLI command or manually. This will ensure that the file is created in the intended location. In any case, the `Directory.Packages.Props` file will not be implicitly created for the user. +- `dotnet add package` by design supports only `PackageReference` style projects. Hence `Packages.Config` style projects remain unsupported. If a user does try to use a `Packages.Config` style project with CPM, an error message should be displayed. From d106893b6e222096989af3e0a510405763c055f0 Mon Sep 17 00:00:00 2001 From: Kartheek Penagamuri <52756182+kartheekp-ms@users.noreply.github.com> Date: Thu, 30 Jun 2022 11:50:05 -0700 Subject: [PATCH 18/20] Update proposed/2022/cpm-dotnet-cli-add-package-support.md Co-authored-by: Nikolche Kolev --- proposed/2022/cpm-dotnet-cli-add-package-support.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposed/2022/cpm-dotnet-cli-add-package-support.md b/proposed/2022/cpm-dotnet-cli-add-package-support.md index 679d8c6..82334cd 100644 --- a/proposed/2022/cpm-dotnet-cli-add-package-support.md +++ b/proposed/2022/cpm-dotnet-cli-add-package-support.md @@ -145,7 +145,7 @@ NuGet restore operation generates `{projectName}.nuget.dgspec.json` file that fi 2. Project2 will evaluate the Directory.Packages.props file in the Repository\ directory. Sourced from - Another potential solution would be to create a command line argument that takes in the `Directory.packages.props` file's path that the user intends to update, rather than choosing the closest props file by deafult. + Another potential solution would be to create a command line argument that takes in the `Directory.Packages.props` file's path that the user intends to update, rather than choosing the closest props file by deafult. - The absence of the `Directory.Packages.Props` file for CPM onboarded projects means that the project is not onboarded to CPM. As per [Jeff Kluge's](https://github.com/jeffkl) comment [on a GitHub issue](https://github.com/NuGet/Home/issues/11903#issuecomment-1161996051), `At this time, the customers must use a file named Directory.Packages.props or set an MSBuild property to indicate what file you want to use. Using other files and importing it manually is not a supported scenario.`. Therefore the tool will fall back to the current behavior that is adding/updating the `PackageReference` & `Version` in the project file. - If a user wants to onboard to CPM, they will have to create the `Directory.Packages.Props` explicitly through a CLI commandline argument/CLI command or manually. This will ensure that the file is created in the intended location. In any case, the `Directory.Packages.Props` file will not be implicitly created for the user. - `dotnet add package` by design supports only `PackageReference` style projects. Hence `Packages.Config` style projects remain unsupported. If a user does try to use a `Packages.Config` style project with CPM, an error message should be displayed. From 7f53d61dccea7036eb0532787b10acdeee1e297c Mon Sep 17 00:00:00 2001 From: pragnya17 <59893188+pragnya17@users.noreply.github.com> Date: Thu, 30 Jun 2022 16:16:17 -0700 Subject: [PATCH 19/20] Update file name, because casing matters --- proposed/2022/cpm-dotnet-cli-add-package-support.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/proposed/2022/cpm-dotnet-cli-add-package-support.md b/proposed/2022/cpm-dotnet-cli-add-package-support.md index 82334cd..3c8ea1a 100644 --- a/proposed/2022/cpm-dotnet-cli-add-package-support.md +++ b/proposed/2022/cpm-dotnet-cli-add-package-support.md @@ -8,11 +8,11 @@ The dotnet add package command allows users to add or update a package reference in a project file through the Dotnet CLI. However, when this command is used in a project that has been onboarded to Central Package Management (CPM), it poses an issue as this error is thrown: `error: NU1008: Projects that use central package version management should not define the version on the PackageReference items but on the PackageVersion items: [PackageName]`. -The main goal is to add support for `dotnet add package` to be used with projects onboarded onto CPM. Regardless of whether the package has already been added to the project or not, the command should allow users to add packages or update the package version in the `Directory.packages.props` file. +The main goal is to add support for `dotnet add package` to be used with projects onboarded onto CPM. Regardless of whether the package has already been added to the project or not, the command should allow users to add packages or update the package version in the `Directory.Packages.props` file. ## Motivation -Projects onboarded to CPM use a `Directory.packages.props` file in the root of the repo where package versions are defined centrally. Ideally, when the `dotnet add package` command is used, the package version should only be added to the corresponding package in the `Directory.packages.props` file. However, currently the command attempts to add the package version to the `` in the project which conflicts with the CPM requirements that package versions must only be in the `Directory.packages.props` file. +Projects onboarded to CPM use a `Directory.Packages.props` file in the root of the repo where package versions are defined centrally. Ideally, when the `dotnet add package` command is used, the package version should only be added to the corresponding package in the `Directory.Packages.props` file. However, currently the command attempts to add the package version to the `` in the project which conflicts with the CPM requirements that package versions must only be in the `Directory.Packages.props` file. Users wanting to use CPM onboarded projects and dotnet CLI commands will be benefited. @@ -20,7 +20,7 @@ Users wanting to use CPM onboarded projects and dotnet CLI commands will be bene ### Functional explanation -When `dotnet add package` is executed in a project onboarded to CPM (meaning that the `Directory.packages.props` file exists) there are a few scenarios that must be considered. +When `dotnet add package` is executed in a project onboarded to CPM (meaning that the `Directory.Packages.props` file exists) there are a few scenarios that must be considered. | Scenario # | PackageReference exists? | VersionOverride exists? | PackageVersion exists? | Is Version passed from the commandline? | New behavior in dotnet CLI | In Scope | | ---- |----- | ----- | ---- |---- | ----- | ---- | @@ -130,7 +130,7 @@ NuGet restore operation generates `{projectName}.nuget.dgspec.json` file that fi ## Unresolved Questions -- Scenarios with multiple `Directory.Packages.props` are out of scope for now. In case there are multiple `Directory.packages.props` files in the repo, the props file that is closest must be considered. +- Scenarios with multiple `Directory.Packages.props` are out of scope for now. In case there are multiple `Directory.Packages.props` files in the repo, the props file that is closest must be considered. ``` Repository |-- Directory.Packages.props From 1d62d4466e924d3d69de2b22bd9113211dbd83c7 Mon Sep 17 00:00:00 2001 From: pragnya17 <59893188+pragnya17@users.noreply.github.com> Date: Fri, 1 Jul 2022 14:56:31 -0700 Subject: [PATCH 20/20] Update wording for dgspec.json file --- proposed/2022/cpm-dotnet-cli-add-package-support.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/proposed/2022/cpm-dotnet-cli-add-package-support.md b/proposed/2022/cpm-dotnet-cli-add-package-support.md index 3c8ea1a..24cc223 100644 --- a/proposed/2022/cpm-dotnet-cli-add-package-support.md +++ b/proposed/2022/cpm-dotnet-cli-add-package-support.md @@ -43,8 +43,8 @@ When `dotnet add package` is executed in a project onboarded to CPM (meaning tha ### Technical explanation -NuGet restore operation generates `{projectName}.nuget.dgspec.json` file that file that maintains a project's top-level dependencies along with other metadata for `PackageReference` style projects. -- `dgspec.json` file will have `centralPackageVersionsManagementEnabled` property set to `true` for projects onboarded onto CPM. +The `dotnet add [package]` command generates a `{projectName}.nuget.dgspec.json` file that that maintains a project's top-level dependencies along with other metadata for `PackageReference` style projects. +- The `dgspec.json` file will have `centralPackageVersionsManagementEnabled` property set to `true` for projects onboarded onto CPM. - `dotnet add package` command currently access [`ProjectRestoreMetadata`](https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Core/NuGet.ProjectModel/ProjectRestoreMetadata.cs) to perform preview restore. - [`ProjectRestoreMetadata.CentralPackageVersionsEnabled`](https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Core/NuGet.ProjectModel/ProjectRestoreMetadata.cs#L119) flag will be accessed while executing `dotnet add package` command to verify if the project has onboarded onto CPM. If yes, the scenarios listed in the functional explanation will be handled accordingly. - Leverage the existing functionality in [`MSBuildAPIUtility.cs`](https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Core/NuGet.CommandLine.XPlat/Utility/MSBuildAPIUtility.cs) to modify the `PackageReference` items in project and `PackageVersion` items in the `Directory.Packages.Props` file.