Nant: How to structure svn:externals for building class libraries that reference 3rd party dll's.

Question

I'm using subversion and nant (and visual studio IDE)

I've been following the suggested project structure at http://blog.jpboodhoo.com/NAntStarterSeries.aspx which advocates self contained subversion directories where a developer can do a checkout and immediately build a project in a single step.

My repo structure is like:

/Repo
  /MainProject
    /trunk
      /doc   <-- documentation
      /lib   <-- binary-only DLLs
      /src   <-- source code for MainProject
      /tools <-- holds tools like nant, nunit, etc
...
  /ClassLibrary1
    /trunk
      /doc
      /lib
      /src
      /tools
...
  /ClassLibrary2
    /trunk
      /doc
      /lib
      /src
      /tools

What's not clear is how to structure a project that has class libraries which in turn reference third party library dll's themselves.

Currently, I have a main project with a working directory like

Example:

/MainProject
  /build
  /lib
  /src
    /MainProject
    /ClassLibrary1 <-- svn external to svn://server/repo/ClassLibrary1/trunk/src
    /ClassLibrary2 <-- svn external to svn://server/repo/ClassLibrary2/trunk/src
  /tools
  ...

When building MainProject, I compile the class libraries and output the dll's to the build folder. However, the class libraries themselves have 3rd party binary-only DLL's that they reference.

My questions is in order to build the MainProject I have to somehow get the 3rd party DLL's from the class libraries into the build output. How do I do that?

Thoughts: 1. Should I store copies of these 3rd party dlls in the MainProject's lib folder? 2. Or should my svn:external reference be to the trunk of the class library project rather than the src so that I can access the class library's lib folder? 3. Should I use the subversion 1.6 feature of svn:externals to individual files?

Answer 1

1. Should I store copies of these 3rd party dlls in the MainProject's lib folder? I prefer to store any external libraries in a binaries directory under trunk but next to source...or call it references, dependencies, etc. This then allows any developer to get latest and all that is needed will come down. It doesn't need to be part of the project per se. It just needs to be accessible when the build is performed.

2. Or should my svn:external reference be to the trunk of the class library project rather than the src so that I can access the class library's lib folder? I don't prefer this approach as it makes the process of getting a new developer up and running more convoluted. I think an assembly can go into its own repository when it has a level of importance on to itself. But I would never reference its output. It should have a build process wrapped around it that promotes a mechanism to "deploy" the output to the above references or dependencies directory. However automating the deployment like that might be fraught with issues. It would be better if the assembly had its own process around it. And when a new version of the assembly were released it would be manually embraced by a developer on the project that needed it. They could then test it, accept it, and place it into their build process. Obviously if that assembly changes on a daily basis some automation may be required.

3. Should I use the subversion 1.6 feature of svn:externals to individual files? No. I prefer to keep a project/solution as a self contained entity. Having tenticals spread out all of the place makes dependencies more painful. Keep silos as hard as possible...bring new things in as manual as possible...or as manual as the frequency that things change will allow.

Answer 2

Personally I bring in the trunk of the referenced libraries. (Actually, I bring in the root of a tag, but that's beside the point).

If you keep a separate copy of the required dll's, then you're not really allowing the referenced library to determine what it needs for itself because all that logic is duplicated in the project. The same thing happens if you use multiple externals references or file externals to bring in the code and the dll's.

My principle here is that - the library knows what it needs, a single external reference to the library can get that library and everything it needs.

That way if you change the library's references, you can be confident that any and all projects will just pick that up. (if the IDE doesn't support this, that's the IDE's problem, not subverion's). You can also be confident as a project that if you change the version of the library you're pointing to, you'll automatically get the right references as well, and don't need to go debugging build failures to work out what's gone wrong.