I have a solution with 10 projects, I used to distribute this as an SDK with an installer back in the day.

To change that in VSTS I added the steps to create a package per project, every time I make a change, a build is triggered and a PS script change the version of the nuspec files, in the end the packages are pushed to a feed, if I made a change to just one project the build pushes a new version of every packages even though there are no changes in all of them.

Someone told me this was wrong, I should not push a new version if there was no change in the package and every package has to be created separately.

That makes sense, but in my case, I have to create 9 more builds in VSTS, replace the project references for nuget dependencies, and, if I ever need to change two projects I have to modify one, commit the change, then open the second project update the nuget reference and make the change, which seems like a lot of extra work.

So my question is, is there a best practice or recommendation about the flow in creating a group of nuget packages?

  • 1
    VSTS has directory filtering. You can keep your repository as a whole, but you might need those 9 new builds. – RubberDuck Sep 6 '17 at 16:19

I am not an expert on NuGet or VSTS so can only offer general advice.

As a general pattern, not just NuGet, for interlinked projects the pattern consists of:

  • structuring your project to have common code clearly separated from application or project code.
  • Minimising or removing all inter-dependencies between projects - ideally all of the projects should be self contained and externally dependent only on common code.
  • Good build tools that only re-build the projects that are impacted and can automate distribution of the resulting builds.
  • A clear and stable API for all inter-project communications, (which includes file structures and anything else that is exchanged between projects).
  • Including versioning in any exchanges and attempting to maintain backwards compatibility where possible so if projects get out of step they either still work or give a clear and helpful error.
  • Using semantic versioning or compatibility masks to flag when updates are likely to need to be more widely performed.
  • Lots of testing, preferably automated testing, so when you are considering pushing a new version of one package all of the other packages are tested to see if they are still compatibly with that revised version and if changes impact other projects it is flagged that they need to get updated at the same time.

A general rule of thumb is that if your change does not impact anything that is likely to be consumed by one of your other projects then it is unlikely to require changes to the other projects.

You can also look at:

  • Automated updating of the interlinked versions of packages
  • Are the updated references predictable.
  • Using a more sane or less MS project management system than VSTS that handles interlinked projects better.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.