Proposal: Adding dotnet CLI support for projects onboarded to CPM #11849
Conversation
|
|
|
@pragnya17 |
…cussions with feature owner and PM
…m/NuGet/Home into dev-pragnya17-CPMDotnetCLISupport
|
The spec has been reviewed and changes have been made according to the feedback received. |
There was a problem hiding this comment.
Nice job @pragnya17!
It would be great if we can clarify the second scenario about the updating package version.
I wonder if @JonDouglas had a chance to look over that.
I also have some minor spec comments.
| </Project> | ||
| ``` | ||
|
|
||
| #### After `add package` is executed:<br> |
There was a problem hiding this comment.
I think this behavior might not be super obvious to the end user.
If I am already managing a package centrally, it feels like the version that should be installed is the existing one, and ideally not update it.
Version updates should only happen explicitly or through an update command.
There was a problem hiding this comment.
We went down this path because dotnet add package command currently updates the package version if the package refence already exists.
If it is not ideal for dotnet add package command to update the package version then should we raise a warning instead of updating the version in the directory.packages.props file for projects onboarded onto CPM?
| </Project> | ||
| ``` | ||
|
|
||
| In case there are multiple `Directory.packages.props` files in the repo, all of them should be searched for a matching package reference. Once a matching package reference is found, its package version can be updated appropriately. |
There was a problem hiding this comment.
I imagine the intention here is if multiple Directory.Packages.props file apply correct?
This is something that the user can only do manually.
There was a problem hiding this comment.
I imagine the intention here is if multiple Directory.Packages.props file apply correct?
You are correct. Incase if others are curious, as per Central Package Management rules, only the closest Directory.Packages.props file is evaluated for a given project.
Repository
|-- Directory.Packages.props
|-- Solution1
|-- Directory.Packages.props
|-- Project1
|-- Solution2
|-- Project2
However, I think customers can specify an Import statement in Solution1\Directory.Packages.props file to import properties from Repository\Directory.Packages.props
Repository
|-- Directory.Packages.props
|-- Solution1
|-- Directory.Packages.props (specifies an import statement pointing to the props file in the parent folder)
|-- Project1
|-- Solution2
The current spec suggests that dotnet add package command should walk through the hierarchy of directory.packages.props file (using Import statements) and update the package version in the appropriate props file.
This is something that the user can only do manually.
Once we get clarity on https://github.com/NuGet/Home/pull/11849/files#r890672222 conversation then we consider this scenario as out of scope / future possibilities for this work.
There was a problem hiding this comment.
There might be some implementational complexity with multiple files.
Example, what if both files have it?
You'd then need to know where it's coming from, which is probably more complicated than a V1.
I'd encourage explicitly saying that scenarios with multiple Directory.Packages.props are out of scope for now.
|
|
||
| In case there are multiple `Directory.packages.props` files in the repo, all of them should be searched for a matching package reference. Once a matching package reference is found, its package version can be updated appropriately. | ||
|
|
||
| ### Other Scenarios that can be considered |
There was a problem hiding this comment.
This is probably something best handled in a Future possibilities section.
|
|
||
| While the above cases must be considered to solve the issue, there are a few other cases that can be considered to make the product more usable: | ||
|
|
||
| 1. If the project has the `<ManagePackageVersionsCentrally>` set to true, but the `Directory.packages.props` file has not been created yet the file should be created. At this point, package references can be updated according to the cases discussed above. |
There was a problem hiding this comment.
It's worth calling out what would actually happen here today, even if we're not promising/committing to the improvements themselves.
There was a problem hiding this comment.
I added a table in the revised proposal #11873 explaining current and new behavior for every scenario.
|
|
||
| 1. If the project has the `<ManagePackageVersionsCentrally>` set to true, but the `Directory.packages.props` file has not been created yet the file should be created. At this point, package references can be updated according to the cases discussed above. | ||
| 2. If the `Directory.packages.props` file has been created but the `<ManagePackageVersionsCentrally>` property has not been set to true, it should be set to true. | ||
| 3. If the project has the `<ManagePackageVersionsCentrally>` set to false, the project should not be considered as onboarded to CPM. Therefore the `Directory.packages.props` file should be deleted if it exists and only `.csproj` files should be modified. |
There was a problem hiding this comment.
| 3. If the project has the `<ManagePackageVersionsCentrally>` set to false, the project should not be considered as onboarded to CPM. Therefore the `Directory.packages.props` file should be deleted if it exists and only `.csproj` files should be modified. | |
| 3. If the project has the `<ManagePackageVersionsCentrally>` set to false, the project should not be considered as onboarded to CPM. Therefore the `Directory.packages.props` file in the project folder should be deleted if it exists and only `.csproj` files should be modified |
Tracking issue #11858
Rendered Design Spec
Proposal for 11807