How Do You Organise Your External Libraries In A Large Code Base

Just wondered how the community organises .net DLL libraries when working in a big team and with tens of diff开发者_如何学运维erent solutions?

I am particularly curious about whether people choose to have some sort of 'library' folder which contains all the external DLLs that all projects use and whether people version their DLLs or just overwrite the DLL when a new release of the DLL happens and hope that the .NET solution on next recompile picks this up

I am also not clear whether you can simply drop a different version of a DLL into a folder and have the solution pick this up or whether .net enforces you to use a specific version (Note: We dont need to sign any of our assemblies)

I have a dedicated folder in our repository for 3rd party libraries and DLLs which all the projects can reference.

As for the versioning thing I do that on a case by case basis. For some libraries which aren't updated often or which I don't plan on ever needing to update to the latest version if it comes out, I just put the DLL there.
However, for major libraries which update often I usually do the following pattern:

<LibName>/Current/<LibName>.dll
<LibName>/v1.1/<LibName>.dll
<LibName>/v1.2/<LibName>.dll

Most projects will simply reference the dll in the "Current" folder. However, if there is a problem then they can reference an older one. The benefit here is that if you find a problem it is very easy to switch references to see if it existed in an older version.

NOTE: if a project depends on another project you need to use the same version between projects, so it's best to try and make everything use the latest if possible.

Currently would typically have a Libs directory which gets checked in with the rest of the solution, and relative references to the DLLs from each project. As long as a new version has the same name, it will be picked up - just make sure all projects in your solution reference the same path.

Going forward however, the emerging best practice would be to use NuGet to manage your dependencies to third party libraries. We are just starting to deploy this now - already great for external libraries like Prism, but also allows you to create central repositories for your own shared libraries.