C# – Managing in-house NuGet packages with source code access

I'm using Azure DevOps (formerly VSTS), and while this question is old, it may have value for others.

My understanding of best practice is:

• Use semantic versioning
• Separate package groups into distinct repositories where possible
• Don't update a package version if the package isn't changed
  • This is tricky with version data coming from a CI build and n package projects in a .sln
• Organize NuGet feeds such that any feed can be used by any number of projects, but any one project uses only one feed (ie. employ upstream feeds)

Only Version Changed Packages

There are legitimate situations for many projects in a single solution

This has almost always been true.

Avoid the build collection balloon

For those situations, you CAN do as you have stated in your question and create a build for each .csproj file in the .sln and trigger on the path containing that .csproj, but I might not recommend it.

Though I like the idea of discrete identification of why a build exists, I don't like the idea of creating a new build pipeline any time a developer adds a project to the .sln. As I'm wearing 2 hats - one as the primary DevOps Engineer and another as a Sr. Developer - I don't like setting myself up for loads of new build pipeline requests from my team if I can help it.

Powershell to the rescue

It's a common (and accurate) saying:

Just because you CAN do something in Powershell doesn't mean you should.

However, I don't believe I'm abusing this tool here.

I'm opting to let the build chew on the .sln file and build everything, and even create a new package version for all the projects based on the build number.

But... When it comes time to move the packages into the Build Artifact Staging area, I want Powershell to take the generic Copy Files task to school and only copy packages produced by a .csproj that has actually been changed.

How?

By iterating over the commits linked to the build and first using git cat-file -p $commit to make sure that the commit isn't a Merge (non-merge commits only have 1 parent listed) and then use git diff-tree --no-commit-id --name-only -r $commit to get the files changed for those commits. With that data in hand I can index the direct sub-directories of my build trigger directory (read: the directory containing the .sln), which should be the project directories, and copy the packages where the package name contains the project directory name.

Because our convention for where projects live under a solution is well developed, I can make certain assumptions about what should be done based on the output of the git commands.

Why?

Doing this "Dynamic Artifact Composition" allows the .sln to grow or shrink naturally and no additional changes to the CI are required. New projects are detected and their packages included, while removed projects are simply no longer available to produce a package for the script to copy.

This approach also gives a direct relationship between the artifact produced, which only includes Some.Lib.1.0.1907.302.nupkg, with the commits shown in the build summary, which show changes to src/sln/Some.Lib/logic/ChangedClass.cs for example.

Pump the breaks

I mentioned our convention. You need to make sure you can actually do this based on what your project and solution directory structure looks like. Solution authoring allows one to have a lot of freedom for adding projects that live outside the solution directory. While this doesn't remove the option to do it this way, you need to make sure your script is flexible according to your environment.