Where to store 3rd party libraries?

Question

I have asp.net mvc 2 application.

Now I'm reimplementing it for working with Ninject. All is fine except one thing: where should I store Ninject.dll??

I've created lib directory inside my appdir and made reference to lib/Ninject.dll.

But may be there are some general conventions on how to act in such cases?

Answer 1

The convention is using this folder structure:

• Project trunk.
  • build
    • Build scripts.
  • db
    • Database staff. (you should version control the db with the all code).
  • docs
    • Documentation, specification and all what that related.
  • lib
    • Ninject
  • src
    • ProjectName.Core
    • ProjectName.UI
    • ProjectName.sln

Answer 2

UPDATE: FYI - Here's a link to how the MVC team structure their own repository.

As part of my MVC directory setup, I place libraries outside the project in their own folder structure and add references to those libraries.

So my checked out directory structure would look something like:

Apps
   Project 1
    - Project files 

   Project 2
   - Project files 

Libraries
- LibraryName
-- LibraryVersion

This provides a standard place for all libraries to be placed, particular useful when multiple projects are using the same libraries and having one south of truth.

Makes trouble shooting build server reference issues much easier too.

HTH

Answer 3

I think it depends on what you're going to do with the application. If the project will be shared with other developers I would use one of the structures outlined in the other answers. However if this is a project internal to your organization where you'll have multiple projects and developers, hopefully all sharing the libraries. I would use something like this, where the library contains only DLLs:

• Library
  • Ninject
    • 1.0
    • 1.5
    • 2.0
  • NHibernate
    • 2.1.0
    • 2.1.2
• Project 1
• Project 2

This is a structure we have implemented in our development process. We have multiple projects using different versions of the same library. We can migrate applications to newer versions of the library very easily. This also prevents having seven copies of a DLL in seven different projects.

For our own internally developed libraries the code is stored in the tree under a project with the DLLs being copied to the Library branch. Our projects then reference the release versions.

This structure makes it easy to keep versions of open source libraries in sync (e.g. Hibernate, Fluent NHibernate, and NHibernate Linq).