CODEWITHSUNDEEP
tfsmsbuildnugetversioningassemblyversions
Liero
Liero

Reputation: 27348

Nuget/Assembly versioning -Should I increase version even if nothing has changed?

I have solution with couple project and each project is built on tfs server and packed into separate nuget package.

When I run build on build server, new version of nuget packages are created and published. I used the same auto incremented version number for all packages.

  1. Should I create new version of the package even if nothing has changed in that particular project?

  2. Is there any tool or article that would help me to publish new packages only if the actual project (or mayne one of its dependencies) has changes? Does anyone did that?

EDIT:

In my solution I have projects ( * format project(references) -> Package Name):

and shared version.txt.

when I change project C build on build server, all packages are repacked with version.txt on build server and published.

Then I have different solution, that consumes those packages.

Upvotes: 1

Views: 693

Answers (1)

Paulo Suassuna
Paulo Suassuna

Reputation: 131

Since you can't consider you'll be able to pack the other projects whenever you want to pack one of them:

Can you consider that every time you want to create a specific project's nuget the other projects will be ready to be packed too? Or there will be, maybe, commited in progress development on the other projects. – Paulo Suassuna 55 mins ago

no, I can't consider that. – Liero 18 mins ago

You shouldn't create new versions of all projects every time you want to pack a solution's project. Instead, you should create always the one and only you want to pack. Also, I guess you're using project reference between solution's project. You shouldn't do that either, in that case, because you'll be referencing unstable versions of your projects. Example:

You want to nuget pack project B with a brand new check-in:

  • You check-in the change in B
  • Some bad check-in gets into A
  • You build your solution on your build server
  • build packs a bad nuget for A
  • Your B NuGet package will reference a bugged A NuGet package.

Actually, you should treat them as different products, so you should change them for nuget reference. That way, you guarantee you're a using a stable version of the other projects. Example

You want to nuget pack project B with a brand new check-in:

  • You check-in the change in B (B references a stable 1.0 nuget package of A)
  • Some bad check-in gets into A
  • You build your solution on your build server
  • Build packs new B with A.1.0.nupkg dependency (It doesn't matter if latest A has a bad check-in)
  • You have a good B NuGet package in the end.

You may keep all projects under a single solution, but be sure to change the reference between them as NuGet reference.

Upvotes: 1

Related Questions