Reputation: 24232
I have a solution with a number of libraries. They are all published as NuGet packages, using the automatic package versioning offered by Azure DevOps.
Some of these libraries depend on others from the same solution. My current workflow is to make changes in library A, launch a build to publish a new package version, then make library B use the new version of A.
I'd like to use project references instead, but I'm clueless as to how I can make packaging still work correctly. An example scenario:
I found some blog posts by Microsoft from 2016 that explore the subject (part 1 and part 2), but there doesn't seem to be a follow-up.
Has this problem been solved yet or do I have to continue with my current method?
Upvotes: 0
Views: 132
Reputation: 2138
In your scenario you don't really need to create and consume a package to share code within a solution. NuGet packages are really just ways to share code outside of a solution and once a NuGet package is installed all that is really happening is that the dependent project is copying the assembly into its build outputs from where the NuGet package is unpacked.
Producing NuGet packages is still worthwhile if you believe that the libraries that you are using within your solution might need to be used by others in discrete codebases, but NuGet doesn't add much (if any) value intra-solution.
Assembly versioning can still be achieved independent of package versioning so that the version of the assemblies you are referencing intra-solution are the same as the versions that you might be delivering in NuGet packages for other teams to share.
Matt Cooper referenced a blog post about GitVersion above. That is a great way to automatically generate version numbers based on the source code and I highly recommend it (I often use the Mainline option).
Upvotes: 1