Skip to content
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

Use Directory.Packages.props for package management #264

Open
stevemonaco opened this issue Aug 19, 2024 · 1 comment
Open

Use Directory.Packages.props for package management #264

stevemonaco opened this issue Aug 19, 2024 · 1 comment

Comments

@stevemonaco
Copy link

stevemonaco commented Aug 19, 2024

Is your feature request related to a problem? Please describe.

$AvaloniaVersion can't be upgraded outside of manual editing (AFAIK) whereas Directory.Packages.props can be updated in IDE and is more intended for centralized package management.

Describe the solution you'd like

Create and use Directory.Packages.props for centralized package versioning. Remove explicit Version attributes from PackageReference in csproj.

Describe alternatives you've considered

Keep the existing $AvaloniaVersion. This may be required so that we can create new Avalonia projects in existing .NET solutions? Other .NET project templates don't seem to use this newer feature yet either.

Additional context

"Manage NuGet Packages for Solution" works in VS. Will need to check/verify support in Rider, VS Code, and dotnet CLI. Project templates seem to have already dropped built-in .NET Framework support, so that's less of an issue.

There may be some learning curve issues across the user base with Directory.Packages.props as I'm not sure how well-known the feature is. Avalonia itself still doesn't use it. See this project as an example.

@maxkatz6
Copy link
Member

It works in Rider fine, as well as CLI.
While I don't see reasons not to add it to our templates (at least as an option, enabled by default).

Centralized package management can be really annoying at times. Especially when you have multiple nuget sources (you need to manually map packages to them https://learn.microsoft.com/en-us/nuget/consume-packages/package-source-mapping). And when you have submodules, you better use VersionOverride always together with normal Version in shared projects. But neither of this is really a blocker for tempaltes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants