❔ issue with central package management
I added a
Directory.Packages.props to the root of project and edited .csproj file like this:
27 Replies
I don't see the contents of Directory.Packages.props. Also, you reference two other projects: do either of those reference the Scrutor package?
Directory.Packages.props:
Yes, Application project references it, but... but before I added D.P.props there was an error, because there is no reference in
.csproj fileRight, if one of the projects you depend on references a package, by default your project inherits that reference
I'm not sure what relevance D.P.props has here
Before I added this file it was different - even though Infrastructure refers to Application, there was an error when I tried to use a package that was not referenced by Infrastructure, and then the Rider IDE prompted me to refer to this package
"Infrastructure" is the csproj you posted in the original question?
yes
Okay, I removed the ProjectReference in Application, but the problem still remains
Even after a clean/rebuild?
Which problem? That you're able to refer to Scrutor but don't think you're referencing it?
yes
yes, even so
In VS, you can expand the project in the solution explorer and see a list of packages that are references. Is there something similar in Rider?
Unless I'm missing something very obvious here, your D.P.props has:
I guess don't understand why it's a surprise that your project has a reference to Scrutor, in that case?
Yes, DPProps has, but Blog.Infrastructure.csproj have no PackageReference to scrutor:
But... You've got a D.P.props which does have a reference
And everything in D.P.props is automatically applied to all projects
Hmm, I didn't think so.
I did the CPM with the help from the article (https://timdeschryver.dev/blog/directorypackagesprops-a-solution-to-unify-your-nuget-package-versions) and I thought that this file does not apply the package reference to all projects, but just indicates what version the packages should be
Directory.Packages.props, a solution to unify your NuGet package ve...
The Consolidate view is dead, long live
Directory.Packages.props. Use the Directory.Packages.props file to define your NuGet package versions in a single file.Aha right you are, I mis-remembered how it worked
Although, I don't see
<Sdk Name="Microsoft.Build.CentralPackageVersions" Version="2.1.3" /> mentioned anywhere in https://devblogs.microsoft.com/nuget/introducing-central-package-management/The NuGet Blog
Introducing Central Package Management - The NuGet Blog
Central Package Management Dependency management is a core feature of NuGet. Managing dependencies for a single project can be easy. Managing dependencies for multi-project solutions can prove to be difficult as they start to scale in size and complexity. In situations where you manage common dependencies for many different projects,
The other option is that you're referencing a package which has a dependency on Scrutor
This would be a good test
I don't see anything you described. But maybe the Nuget GUI will work?
oh no, sorry, i see it
it seems to have imported all the packages mentioned in DPProps
I'm suspicious of that
<Sdk... lineWith or without this line, it's the same. I borrowed it from this repository: https://github.com/ardalis/CleanArchitecture
GitHub
GitHub - ardalis/CleanArchitecture: Clean Architecture Solution Tem...
Clean Architecture Solution Template: A starting point for Clean Architecture with ASP.NET Core - GitHub - ardalis/CleanArchitecture: Clean Architecture Solution Template: A starting point for Clea...
I'm just going by the MS blog
I did everything as it is written there, but the issue remains as it was before. Looks like I'll have to go back to the old way of versioning dependencies - via .csproj files.
Thanks for the help
Have you ruled out Rider as a cause? I'm not sure how involved it gets here
I.e. just building with
dotnetI have already built via
dotnet build
and did before dotnet clean
:/There's still the possibility that 1) That Rider GUI is wrong, and 2) You're picking up Scrutor as a transitive dependency of something else
it's PackageVersion not PackageReference
Aha, that's an important spot
Was this issue resolved? If so, run
/close - otherwise I will mark this as stale and this post will be archived until there is new activity.