

Please specify the version in 'C: \git \mysolution \Packages.props ' or set VersionOverride to override the centrally defined version.


The package reference ' ' should not specify a version.

To get started, you need to create an MSBuild project at the root of your solution named “Packages.props” that declares the version of the packages you’re going to use. If you don’t know what it’s a project SDK you can read more about it here: If you want to know more about project SDK you can read more about it here: MSBuild 15.0 introduced the concept of the “project SDK”, which simplifies using software development kits that require properties and targets to be imported. it’s a project SDK built by Microsoft themself. That’s why in most cases I like to manage the package versions in a central point inside my solution and if the solution contains multiple applications then every application uses the same nuget version and every application is affected when I modify the package version but at least I don’t have to navigate between the dependency mesh of multiples projects being referenced between them.Īlso in case that I have multiple applications inside a single solution and I want to update a package version of only one of them I tend to move the application that I want to modify and place it in a new solution just by itself.Īnyways, in this post I want to show you some of the different options available when you want to centrally manage nuget versions within a solution. NET applications is having them splitted in multiple csharp projects inside a single solution, even with the proliferation of microservices is pretty common seeing the client and the business logic decoupled in multiple projects inside a single solution.Īnd that behaviour is even more common if you’re using some kind of software architecture like “Domain Driven Design”, “ Hexagonal Architecture” or “Clean Architecture”.Ī common problem that usually appears when the number of projects begins to pile up inside a single solution is mantaining consistency between nuget versions, and quite some times you end up with every project using a different version of the same package.Īnd that problem is even worse if there are multiple applications inside a single solution and those applications are sharing projects between them, at that point it becomes a nightmare trying to maintain a consistent package version across all projects because when you try to update a package you might be affecting multiple applications without even knowing.
