1

I have a solution with multiple netstandard2.0 projects that each build their own Nuget package:

+ MySln.sln
--+ MySln.ProjectOne
--+ MySln.ProjectTwo
--+ MySln.ProjectThree

My CI script works off the solution and is basically this:

dotnet restore MySln.sln
dotnet pack /p:PackageVersion=$(buildVersion) MySln.sln
                --configuration release -o $(artifactDirectory)

This creates three Nuget packages, one for each ProjectOne, ProjectTwo, and ProjectThree.

The problem is that the CI is triggered on any commit, so I build all three even when I just e.g., make a change to ProjectTwo or to something unrelated to any of the projects.

I wonder now what the best (that is: Simplest to maintain, especially when adding new Projects) approach would be to only publish Nuget packages where the actual sources changed. I can't just do a binary diff because compiled assemblies are different on every compile because of the compiler timestamp, and the version number is different every time as well because of the build server.

I can think of doing something where I fingerprint all the sources of a package* (which includes more than just the .cs file, e.g., embedded resources, a license file, etc.), but before I build my own, I wonder if there's some sort of common solution to this already; I assume other projects have ran into this.

*Or more sane, do a git log -n 1 --pretty=format:%H -- MySln.ProjectOne for each project.

Michael Stum
  • 177,530
  • 117
  • 400
  • 535
  • BTW, what's wrong with publishing the same packages all the times? Disk space is cheap. – Lex Li Aug 30 '18 at 16:30
  • 1
    @LexLi But any developer using those packages sees that there is an update even though there isn't. And when doing stable releases, it's harder to see which packages have actually changed since the last one. – Michael Stum Aug 30 '18 at 16:37
  • @MichaelStum did you come up with a solution to this? – Darius Jul 08 '21 at 13:44

0 Answers0