A couple of questions regarding TeamCity

Question

I've wanted to install a CI server for a big project for quite some time, but didn't have the time needed, nor the people above me cared too much about it, they just said "that's interesting, and it could save us some time" but never made anything for it...

I alreayd had some experience with CC.NET, but just in small projects, and for the sake of learning the basics of it. Lately had a bit more of spare time, so decided to give TeamCity a try, and set it for the big project.

There are, however, two problems popping out at me when dealing with references:

1) When working with multiple projects, I try not to make big solutions containing all of them (plus is not always possible), since I also work with SVN, I use the relative paths that point to the compiled assemblies from the other projects (eg.: ....\Library A\trunk\Library\bin\release\LibraryA.dll). It has always worked well for me and the co-workers that have participated in the project, but I'm having difficulties to make the TC project to pick it up, how should I set up my dependencies?

2) One of the libraries is made by another company, and the SVN repository is shared with them. They recently had to add access to an Oracle DB, and they work with the Oracle Data Provider, which seems to work with an assembly registered in the GAC, but when building the solution, it outputs another similar assembly but with a different assembly version (correct me if I'm wrong, I've always worked with the built-in Oracle provider since it was more than enough). At my company side, we work with that "output assembly", and the project compiles and works fine, but we previously have to change the reference, and modifying the project file in the repository would not be possible, is there any work-around for this?

Thanks for your replies.

Answer 1

For 1) you can use Svn externals to grab assemblies and other dependencies from other projects when your project is built by TC.

You can also set TC to detect when externals have changed and build the project with the latest versions, or you can chain TC projects together so they build in sequence.

I've put alot of time into getting a CI server up and running at our place and it has really paid off. It still takes a bit of time to keep things ticking over but would seriously recommend you get something up and running.

Sorry can't help you with 2).

Answer 2

Solved #2 by modifying the reference properties and setting it not to look for the specific version. The other company seems to have accepted it.

Still haven't had the time check the VCS Checkout rules for #1.

Answer 3

For 1) You could set the ReferencePath for the Projects and point to the Directories with the compiled Assemblies.

In our TC Configuration we load all TeamCity Dependencies to a SubDirectory called "Dependencies" and set the ReferencePath for the Compiler to this Directory.

With the MSBuild Runner this is very easy:

In den .proj for the Build you need to define a Property (we call it ReferencePath)

<PropertyGroup>
    <ReferencePath>$(MSBuildProjectDirectory)\Dependencies\</ReferencePath>
</PropertyGroup>

And then call the MSBuild Task with it:

<MSBuild Projects="$(ProjectFiles)" Properties="Configuration=Release;ReferencePath=$(ReferencePath)" Targets="Rebuild" />

@(ProjectFiles) is a simple ItemGroup that collects all .csproj-Files.

<ItemGroup>
    <ProjectFiles Include="$(MSBuildProjectDirectory)\**\*.csproj" />
</ItemGroup>

Answer 4

Thanks for all the replies, learnt a couple new things.

Yesterday could play a bit more with TC, learnt more about VCS checkout rules, and found out, that #1 can be easily solved with artifacts (with that name I didn't realize at first what they were), so I'm using that and my projects are built with no problems so far.

What do you people think about this approach? The libraries giving me problems where "core" libraries of the same project, so I already had set a project for them as well.