Rational Team Concert and .Net development - Managing Binaries

Question

We're currently on a company-wide project that will replace IBM ClearCase 7.0.1 with IBM Rational Team Concert 3.0. We mostly use Microsoft .NET platform.

I'm satisfied with RTC source control capabilities, but I'm wondering how to manage binaries references using RTC. Many systems here share components on binary level, and I can't see a way of managing these references on the tool.

Some consultants have suggested for us to use a "binary component", parallel to the "source component", (for each system) where we would store the compiled binaries and use them for references.

Is this the best way to do that? Dear RTC experts, please advise.

obs.: My attempts to use NuGet internally have failed so far.

Answer 1

We're currently on a company-wide project that will replace IBM ClearCase 7.0.1

Me too!

Some consultants have suggested for us to use a "binary component"

When it comes to binary management, you have two topics:

• development dependencies:
  • third-party binaries: all the binaries you need for development won't always be part of the release.
  • in-house binaries (you should be in binary dependency from other projects, instead of recompiling their sources)
• release management: what you are putting into production, ie all the exe you are "publishing" (in one way or the other) in order for ITP (prod and release management team) to come and pick-up said binaries and deploy them into production

For all those kinds of deliveries, I would suggests against putting them into RTC: its "Jazz source control" component remains a source VCS.

An external "artifact repository" like Nexus, or for .Net project, a referential based on NuGet (even if you attempt is not successful so far), is more appropriate.

You can find more detail on the integration between Nexus and RTC in:

^{you need to setup a Jazz account}

• How do I use the Jazz SCM Provider for Maven?
• Maven SCM plugin extension for RTC

(both mentioned in this thread)

Answer 2

I typically advocate building everything from source if source is available. Otherwise, a deployment object library (artifact repository) is warranted (e.g. like what AntHillPro has).