My company is planning to integrate 3 in-house libraries into all of our applications (with possibly more on the way), and I'm wondering what the best way to go about this would be.

My initial reaction is to put the code of all 3 into a single library and use that in all of our applications, but it seems like that would end up being an unwieldy solution (especially if we develop any further libraries). This could also be a nightmare to debug.

My ideal solution would be to bundle all the individual libraries into a single library using project references. This library would allow access to and initialize the child libraries using data passed to it via the main program. Then I'm guessing that I'd be able to add the bundled library to each of our programs by referencing the bundled project.

Will referencing the bundled library project give my application access to all the libraries the available to the bundled library? Is there a better approach to use here?

  • 2
    Why don't you just leave those 3 libs separated and reference them individually? However, what you are really looking for is probably an inhouse Nuget repository, look here: docs.nuget.org/create/hosting-your-own-nuget-feeds Then you can make a Nuget package from your 3 libs.
    – Doc Brown
    Jun 15, 2016 at 19:00
  • I thought that creating a central library would be better because they all need to be configured using the same info (server, database, wcf services) which are based on the commandline passed to an application. It also seemed like I would run into fewer dll issues if I were to reference the central library, because it would try to rebuild the library project every time I ran the application from Visual Studio. Am I out to lunch on that?
    – Rolan
    Jun 15, 2016 at 19:13

1 Answer 1


If your create a fourth lib and use project references, you will not get the desired result, that way a consumer of that lib will still need to reference all the libs individually. However, at least you can put the initialization code in that fourth lib.

Your first alternative will most probably work well when you still keep each of the current libs in its own namespace, and use tool like NDepend to make sure there are no cyclic references (or no references at all, if that is what you have now) between the different namespaces. That will keep the libs in a state where you can still separate them at any time and use them individually, if you need that. And yes, with a growing number of libs that will help you to keep the build times low (however, I would not bother about this as long as your projects do reference more than 100 assemblies, but YMMV).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.