Sharing open source .net libraries

Question

Let's say I've written SuperTest on top of nUnit 2.1 and I'd like to share my creation with the world. Jess would love to use my library and she also wants to use nUnit directly as well. Her app HeadBook uses nUnit 2.8

The scenarios I can see for a source release:

1. She checks out the SuperTest source which ships with nUnit 2.1, copies in nUnit 2.8, recompiles SuperTest, copies SuperTest.dll into HeadBook
2. She checks out the SuperTest source which doesn't ship with nUnit but contains a reference which must be supplied. She copies in nUnit 2.8, recompiles SuperTest, copies SuperTest.dll into HeadBook

The scenarios I see for a binary release:

1. She downloads SuperTest 1.0 binaries, puts SuperTest.dll and nUnit 2.1 into the GAC and references SuperTest from the GAC
2. She downloads SuperTest 1.0 binaries, copies the dlls into HeadBook and recompiles HeadBook to work with nUnit 2.1
3. She downloads SuperTest 1.0 binaries which have been ILMERGED into one dll, copies into headbook and references that

I'm trying to work out the best way to set up this project. It seems like the best way to do it is to include a copy of nUnit, have a local reference and ilmerge as a build step.

I'd like to avoid SuperTest being recompiled with different versions of dependencies I haven't tested against but I probably also want to avoid the gac so deployment is painless.

Would ilmerge be the best approach?

Answer 1

I think that the best approach is to try to follow nUnit releases so SuperTest is always in sync with the upstream dependencies. That way, you get source releases (branches on the SCM) and binary releases (just build it once) that match upstream and you don't need any of this.

Failing that, ie, you cannot commit to follow nUnit releases, I tend to agree that bundling your own version and merging the assemblies is easiest for everybody.

Answer 2

Sign your binary release. Assemblies with strong names will load the correct version, side-by-side if necessary. Then you include a copy of the nUnit 2.1 assembly you're using and you're all set.