views:

356

answers:

1

Using subversion and Nant for building. I have a main project that depends on several sub-projects. The sub-projects exist as separate projects inside subversion.

My question is: Should the nant build script in the main project build all the referenced sub projects and itself? Or do the subprojects know how to build themselves and I somehow call the subproject build files from the main build file and somehow assemble all the output into the main projects build output?

I currently have the mainproject build file build all the subprojects. That is, I have nant targets for each subproject in the build file. However, this seems to create a tight coupling between the main build file and the subprojects. It would be nice if I could just say "sub projects know how to build themselves" and ask them to build themselves from the main project and assemble the output.

For reference, my repository looks like:

/Repo
  /MainProject
    /trunk
      /doc   <-- documentation
      /lib   <-- binary-only DLLs (usually 3rd party)
      /src   <-- source code for MainProject
      /svn-externals  <-- hold references to other projects in repository
...
  /ClassLib1
    /trunk
      /doc
      /lib
      /src
      /svn-externals
...
  /ClassLib2
    /trunk
      /doc
      /lib
      /src
      /svn-externals
...
  /ClassLibCommon
    /trunk
      /doc
      /lib
      /src
      /svn-externals

I'm pulling in the sub-projects using the subversion svn-externals property. So my working copy is like this:

/MainProject
  /build
  /doc
  /lib
  /src
    /MainProject
  /svn-externals
    /ClassLib1 <-- svn external to svn://xyz/repo/ClassLib1/trunk
      /doc
      /lib
      /src
      /svn-externals
        /ClassLibCommon <- svn external to svn://xyz/repo/ClassLibCommon/trunk
          ...
    /ClassLib2 <-- svn external to svn://xyz/repo/ClassLib2/trunk
      /doc
      /lib
      /src
      /svn-externals
        /ClassLibCommon <- svn external to svn://xyz/repo/ClassLibCommon/trunk
          ...
A: 

The answer to your question is of course "it depends".

What you don't say is how you reference the "sub-projects" in your solution or if they are used by other solutions (main projects)? Are they project references? If so, have nant call MSBuild to build the solution. This will build all the sub projects based on those dependencies. I can only assume this is how you have it set up.

Personally if I had a setup that looked like your I would not use project references nor would I have externals to all the code for each project. I would treat those sub projects the same as you treat your Third Party DLLs.

If you did this you would be using DLL references. This decouples the sub-porjects from your main project. This is the way I would go, especially if those sub-projects are referenced by other projects.

Yes, now you have to make some other decisions... such as how to store those in source control. You can have externals in your lib folder... or you can just put a copy of the DLL into your lib folder. This also depends on how you want to control versioning.

Also, you don't mention if you use some type of CI such as CC.Net. If you did you could have it trigger a rebuild of the main project if any of the sub-projects are modified.

PilotBob
The library projects are used by other "main" projects. They are project references.Two things: 1. The libraries are frequently changing. 2. I thought the conventional wisdom is don't store binaries for things you have source code for.
User
It depends. To me don't reference a project in more than one solution over rides that.I consider shared libraries not part of the main project. So, just like putting my Crystal report DLLs into svn I also put my internal Framework DLLs there too. Also, DLL references give you more control over the version of that library that you are using with each project. Of course you can do the above and not put the binaries into svn. Put them on a network share.
PilotBob
"To me don't reference a project in more than one solution overrides that" I'm not sure I understand this. Just to clarify, when I've been using the term "project" I mean it in the general sense not in the visual studio sense. So to my mind, by definition, a class library "project" (actually it's own solution) is intended to be used in more than one solution.
User
Yes, it is really a preference thing. As I said, from your description I would not include the common code of shared VS project in an application solution. We include the binaries of those the same as we do for 3rd party libs in svn. So, building one would not trigger building the others.
PilotBob