-
Notifications
You must be signed in to change notification settings - Fork 252
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
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
|
||
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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