C# – Nant: How to structure svn:externals for building class libraries that reference 3rd party dll’s

cclass-librarynantsvn

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?

Best Answer

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.

Related Topic