How to Build Multiple Dependent .NET Solutions in TeamCity?

Question

We've got an application which components are developed in multiple Visual Studio solutions (.sln). From time to time a solution is added or removed. The build output such as DLLs are copied into a shared folder. Projects from other solutions reference those DLLs. Here's a simplified example: solutions A and B consist of two projects each. The project B2 of solution B references project A2 of solution A.

Side note: We're in the process to replace the shared drive with NuGet packages; however, the following question is still apparent.

TeamCity supports build dependencies. This video demonstrate how to set it up manually.

However, we would like TeamCity to automatically(!!) resolve dependencies between projects. So in the above example we'd like that TeamCity builds solution A first and solution B next. How can we configure TeamCity to pick up these dependencies automatically without maintaining them manually?

Answer 1

Unfortunately it can't automatically. You can consider writing your own plugin.

You would usually setup a snapshot dependency, in your example B build would have a snapshot dependency on A build.

In the case of when you have moved to NuGet, it will restore whatever the solution is referencing. You might want to have snapshot dependency like above but not required, each solution would determine what it needs.

Update 1 - Automating

I think you should be able to do it with the Rest API, documentation is not very clear but I did find this gist which has an example of adding and deleting snapshots.

You'll probably need to work out some convention that projects are setup with to make it easier to match projects.

You should also checkout the plugins page for libraries that abstract the API.

Answer 2

I have asked this question in the JetBrains Developer Community. JetBrain's comment on this:

[...] it is not a TeamCity-specific issue since I expect that you should be able to reproduce such a build procedure locally on developer machines. [...] the .net ecosystem itself doesn't provide a solution. There is [...] the option to write your own plug-in for msbuild or generate solutions (.sln files). [...]

In other words: even using the latest version TeamCity 9 there is no automated way to solve the described problem out of the box. There are multiple alternatives though from fully manual set-ups to custom tooling:

• Change multi-solution approach to single solution.
• Change to NuGet rather than manually set up assembly references.
• Set up dependencies in TeamCity manually.
• Write your own plug-in; see also JonSquared's answer.
• Write a custom tool that generates a single solution (SLN) which can be digested by TeamCity.

Answer 3

NuGet is certainly a better approach then having the assemblies on a shared drive, so I'm glad to see you're moving in that direction.

As for automatically building consuming projects after a dependant project has been built, you have a few options to trigger the build. Either:

1. Use the NuGet build trigger This allows triggering a build when a new package version is added.
2. Set up a build dependency between the project.

The next part is tricky and you have a few (tough) choices. The challenge you have is packages are defined in packages.config and while you can update the package using NuGet update, you need to decide if you want TeamCity to check in the changes. So some ideas on what you can do are:

1. Check if a package update is available (using NuGet update) and fail the build if there is. This is used as a notification to developers to then manually update the package and deal with any integration issues that may arise.
2. Update the packages and check in packages.config. This should be done on a new build configuration which is triggered when a new dependency is available. As this will create a check in, your existing project build will run using the new packages.config.

I would suggest starting with 1) and then move on to 2) when you're feeling confident with the workflow and things aren't going wrong.

What you are trying to do is quite tough, so I hope I've given you more solutions to consider. But I think it's a worthwhile exercise that will help you in the long run. Unfortunately there isn't a one size fits all so you'll have to experiment and mature your processes.

While TeamCity is a great system, it does fall short specifically in how you are attempting to use it. I suggest having a look at ThoughWorks GO. It's better suited for what you are trying to achieve, but unfortunately not as intuitive and mature as TeamCity. http://www.go.cd