Managing third party components in .net project.

Question

How do you manage the third party components that is used in a .net project. I currently add a folder called references that contains all the dlls used and all the projects refer those from there. This folder in checked in along with the source code to source control. I wanted to know if there was a better approach that others were following.

Answer 1

Another option is to stick the 3rd party dlls into the gac. Then you only have to worry about deploying them once.

Answer 2

You're doing it right.

I have a directory called lib which contains all my third parties libraries and source code. Having that checked in and having relative references means other developers can check out your code and hit the ground running without having to figure out which other libraries to install.

If you're using svn you can also use svn:externals to manage third party libraries (so you can update them directly from another subversion repository). Git has submodules which does the same thing.

Answer 3

I follow a similar sort of pattern

/ProjectName
   /conf <-- IIS Settings go here
   /docs <-- documentation
   /lib <-- Third Party Assemblies go here
   /src/Web <-- WebApp goes here
   ProjectName.sln <-- Solution file
   ProjectName.build <-- Nant Build script

the webapp references the lib folder for the 3rd party libraries.

I check all this into source control,

the bit that sometimes gets me is when I have the source to the 3rd party library, currently i do not include it within this folder structure.

Answer 4

Agree with jonnii, I do exactly the same with most 3rd party assemblies, the only exception is the NUnit DLL's that goes in a solution folder as I might need those in several test projects within the solution

Answer 5

Putting them in separate directory under source control is definitely a good idea. What I've done is to maintain a separate repository of libraries, etc., that I might use, and pull them into my working copy as part of the checkout. I'm using Subversion, and the svn:externals property works a treat for this sort of set-up, as the dependencies are pulled down automatically as part of any checkout. It simplifies my automated build configurations no end, and, were anyone but me to work on them, they'd be able to do a single svn checkout and get the lot.

Answer 6

The best answer is to use a Solution Items folder for your solution. Create the physical structure for your 3rd party references underneath your solution's physical folder (mine often looks something like this:

Solution Items / References / log4net / 1.2.10 / log4net.dll
Solution Items / References / somethingelse / 1.2.3 / somethingelse.dll

.) Then in your solution create that identical folder structure (sadly you can't just drag and drop from the physical structure.) Then drag and drop the dlls into the appropriate places. Set the references in your project to those files and Bob's your uncle!