Question

I’m looking for what would be the most appropriate solution to share .net assemblies (both being in continuous development stage) between multiple development teams (not in the same office/repository).

First team has developed and packaged many useful and generic features in an assembly called core.dll that they are referencing (as a VS project) across their many applications and libraries. This assembly in turn references very standard assemblies like (system.dll, etc…) plus log4net.dll (as a third party in their repository):

• Core.dll
  • System.dll
  • …
  • Log4Net.dll

On my side I’ve developed a higher level assembly Library.dll in which i’d really like to incorporate for things developped in Core.dll instead of maintaining duplicate code:

• Library.dll
  • System.dll
  • …
  • Log4Net.dll <– I’m also using Log4Net!
  • Core.dll <— I’d like to replace my homemade code with it

Finally first team is in turn interested by my code to develop their own application:

• Application.exe
  • System.dll
  • …
  • Log4Net.dll
  • Core.dll
  • Library.dll

This looks like hell to keep loosely coupling between the two development teams:

• First, I may not use the same version of Log4Net.dll in Library.dll than in Core.dll (At least we can agree to use the same one or not to target for a specific version as this thrid party is quite stable)

• Second, when integrating back my Library.dll in Application.dll I may have been working from a different version of Core.dll as they will continuously have it to evolve.

Currently what I’m thinking of to keep loosely coupling between our teams is to have them to provide me with hidden ‘log4net’ reference like this:

// Create a single assembly hiding for Log4Net
ILMerge /out:DCore.dll Core.dll Log4Net.dll /internalize

And myself to do the same:

// Create a single assembly hiding for Log4Net and Core
ILMerge /out:DLibrary.dll Library.dll DCore.dll Log4Net.dll /internalize

I don’t kwon if this solution is appropriate, any other one preserving for our two teams to be tied one to another is warmly welcome.

NB1: I don’t think deploying libraries to the GAC is a good solution because both Core.dll and Library.dll are still in continuous development stage and cache will grow with too many useless side-by-side releases.

NB2: I’ve read this thread but I don’t know much about NuGet and if it’s appropriate here.

Answer 1

Personally I think NuGet will help you a lot in managing packages, its dependencies & versioning.
NuGet integrates well with all major CI servers and Visual Studio. More information could be found in NuGet documentation:

http://docs.nuget.org/docs/Creating-Packages/Hosting-Your-Own-NuGet-Feeds

You can read more about how NuGet handles assembly versioning in the following blog post:
http://blog.davidebbo.com/2011/01/nuget-versioning-part-1-taking-on-dll.html