1

POSSIBLY POINTLESS BACKSTORY

In an effort to get out of NuGet hell (formerly dependency hell) my team has decided to switch to considerably larger solutions focused on our major divisions in the company. In the past we would have a core DLL that contained the most common code for a particular system and multiple solutions that pulled that DLL in through NuGet. This resulted in a lot of packages, and even more solutions, which ultimately meant a highly fractured collection of code for each division.

Our new approach is to move towards using a large comprehensive core library that gets exposed through a Web API. We also plan to serve up the core DLL through a NuGet package for situations where Web API performance is not suitable.

A basic solution will have 3 projects: Core, API, and Wrapper. The Wrapper project provides methods for accessing the API through simple methods rather than re-writing all the Web API calls in our apps that will use it. More complex solutions will have additional projects such as Windows services and console apps to run as scheduled tasks.

The 3 basic projects will all share the same version number because they're tightly coupled. The problem arises when including other projects that should not use the same version number in their builds.

THE REAL QUESTION

I have a solution with 4 projects: A, B, C, and D, A-C are always updated together and share the same version number. D is a service project that has its own logic in it that can change independently of the other projects, and therefore should have its own version numbering. However, to avoid confusion, D should be deployed with the correctly versioned DLLs from A-C. (Meaning that if D is on 2.0.0, and A-C are 1.0.0, the DLLs from A-C in the install directory should show 1.0.0 in their details.)

With that in mind, is there a way in TeamCity to build and control the version numbering so that the projects that need to be unique can be, and still reference the correct dependencies?

Notes:

  • I know that the easiest solution is to simply move the special projects to their own solutions and reference the core DLL, but that's part of what we're trying to get away from.
  • We want to be able to have proper build numbers on our finished files, as well as have tags in Git from successful builds.
  • As far as I can tell, the AssemblyInfo Patcher feature in TeamCity can only overwrite the whole version. If it could simply overwrite the build number then I could control version numbers right in my source code.
Logarr
  • 2,120
  • 1
  • 17
  • 29
  • I'd love to hear why this should be closed... – Logarr May 27 '15 at 20:18
  • It's marked as 'Too broad' which seems about right. The point of SO is to solve a development (code) issue, not a development environment issue. And especially not to recommend a development & repository naming solution. I feel your pain (and understand your problem) but it's a very big problem for SO to tackle. – KevinDTimm May 27 '15 at 20:21
  • There are plenty of TeamCity and versioning related questions on this site. I'm not asking for a naming solution of any kind. – Logarr May 27 '15 at 20:23
  • I may have gone a little rogue on the answer - mea culpa. Note I have not voted to close. – KevinDTimm May 27 '15 at 20:24

1 Answers1

0

Well you are right AssemblyInfo Patcher won't help in this case, as it updates all assemblyinfo files or global assembly info file. There is no straight forward way I am afraid but I think you could try something like below:

  • Rather than building the solution, build individual projects using .csproj files, i.e. break compilation into 4 steps one for each project (A-D).
  • Use AssemblyInfo patcher for A-C projects so they can simply use Teamcity version %build.number%.
  • Add a pre-build event to D csproj to update its assemblyinfo information. You'll need to define a variable in teamcity for first 3 bits of its version say DVersion(1.0.0), the last part of it can come from %build.counter% variable. Pass this version (%DVersion%.%build.counter%) as a parameter to D csproj file build step.
  • Finally update teamcity build number by writing logs to something like ##teamcity[buildNumber '%build.number%-%DVersion%']
Mohammad Nadeem
  • 9,134
  • 14
  • 56
  • 82