2
votes

We have a couple of projects and that have dependencies on each other. So for example we have project bar that relies on project foo. The foo project is an SDK (base library) that we want to include in all the other projects because we find that we are solving the same sort of problems over and over again.

At the moment project foo and bar are built independently and the bar project has a reference to the foo.dll and it is stored in the bar\lib folder in SVN. So if we make any changes to the foo project then we have to take the latest build, check out the bar project and copy over the new DLLs and commit again. This is a little manual and annoying. Especially because we have about 3 or 4 projects relying on the foo libraries now.

I don't want to stick EVERYTHING in one solution because that seems a little stupid. The foo project shouldn't change that often and provides an SDK. They are not related to each other. We already keep related projects together in solutions. We have some solutions with 4-5 projects with their test projects already. Sticking everything together would create a solution with 40-50 projects and that seems like a nightmare.

What I would like to achieve with TeamCity is that if any changes are made to Foo that it automatically triggers a new build of bar using the updated DLLs of Foo. That way if somebody makes a breaking change we find immediately. Then the culprit either has to fix his buggy commit or make the necessary changes in all the dependant projects.

What we have done so far is we already have most of our solutions building in TeamCity, running unit tests and creating artifacts. I have tried to setup an artifact dependency in the bar build configuration on the foo build. This should copy foo\build\release\foo.dll to bar\lib\foo.dll. We get errors at the moment stating

Failed to resolve artifact dependency xxx ... java.io.FileNotFoundException ... Access Denied

What is the best practise for doing what we are trying? Are we going about the right way? If we are doing it the right way how do we resolve this error?

1

1 Answers

3
votes

You can use SVN externals to share assemblies between projects from a central place.

At the end of a build we always tag the output in SVN and also replace the contents of a latest folder with the latest build output e.g.

_output\v1.2.3\

_output\v1.2.4\

_output\latest\

So latest will contain the same as the v1.2.4 folder. So in development we always have our project dependencies targeted at the latest folder, thus whenever the project is checked out it will always load the latest successfully build assemblies.

This way we can chain build configurations in TeamCity so that, using your example, when FOO is successfully built BAR is built immediately after; and because it checks out the FOO assembly from the latest folder the BAR project is built with the latest changes.

This is what makes it Continuous Integration, not just a Build Process.

Apologies for any typos. I'm in a tiny camperv on my netbook; the keys are tiny and there isn't much elbow room!