54

In my project I'm using some third-party libraries. I include them using the references folder in Visual Studio.

But where should I save the DLL files? They are referenced from a path in the file system, but it would be nice if I can include it into the project. But how?

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131

8 Answers8

68

This is what I do:

  • Create a lib folder at the solution level
  • Download and copy all my third-party DLL files into there
  • Reference from the lib folder
  • Put all those DLL files in the source control. I am using Subversion, and I add them manually but this is one-off.

You can also add a solution folder and add them there.

UPDATE 2012-12-19

The answer above was when NuGet was in infancy. FWIW, my approach where we have NuGet items:

  1. Do as above for plain DLL file dependencies (where they don't have a NuGet pkg)
  2. Enable "Package Restore" for the solution
  3. Change packages.config file if needed to lock down the version to a particular package
  4. Do not store the package themselves in the version control system (set ignore for Git, Mercurial, etc.)

I actually use NuGet for managing even internal dependencies and have a private feed.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Aliostad
  • 80,612
  • 21
  • 160
  • 208
  • 3
    +1 for the reminder to add them to the source control... It should be obvious, but its often overlooked. – Heiko Hatzfeld Nov 25 '10 at 13:29
  • 2
    Same procedure as we use where I work. Important to add to source control to make sure that it will work for all other developers also. – Øyvind Bråthen Nov 25 '10 at 13:38
  • Cheers, I've been mulling this question over for a few days but that seems like solid advice. – deanvmc Jun 02 '11 at 12:53
  • 1
    @Tyler no. You will call PM> Update-Package in NuGet console. – Aliostad Jan 03 '13 at 18:58
  • Can you clarify that when you say 'solution level' you mean at the level where the `.sln` file is stored? – deed02392 Sep 18 '13 at 09:21
  • @ØyvindKnobloch-Bråthen exactly what I mean. – Aliostad Sep 18 '13 at 14:10
  • Thanks, good approach. You mentioned you use NuGet even for managing internal dependencies and have a private feed, are there any good how-to's on doing this, and will it be picked up in the MS Build Task/Targets as well or would they also need some editing? – Mickey Puri Dec 22 '13 at 10:53
  • @MickeyPuri have a look here http://docs.nuget.org/docs/creating-packages/hosting-your-own-nuget-feeds – Aliostad Dec 23 '13 at 11:42
  • Why do you make `lib` a solution folder and not a project folder? (A project folder is easier to manage with version control.) – Isaac Kleinman Feb 25 '14 at 21:54
  • That's great. When I added a lib folder at solution (.sln) level, added the external references to the project from there and updated on GitHub ignoring debug and release folders, the referenced DLLs got compiled/resolved automatically when I downloaded the project from the GitHub again. Thanks @Aliostad – Khadim Ali Apr 05 '16 at 13:35
9

Typically, the structure of my projects looks like this (at a minimum):

projectname
   - trunk
       - src
       - lib
   - support
       - docs
   - releases

The trunk folder contains the copy of the source that I am working on right now. Also, there's a directory 'lib', which contains all the third-party assemblies that are referenced by my project.
(I reference the assemblies at that position).

The 'releases' folder contains branches of the trunk. For instance, when v1 is released, a branch is taken of the trunk so that I have a copy of the source code and all its dependencies that is necessary to build version 1 of the application. (This is handy for bugfixes. Fix the bug in that branch, merge the fix to the trunk, rebuild that branch and you have a fixed v1 of your application).

All these things go into source control. (Yes, the referenced assemblies as well). By doing so, it is very easy if another colleague has to work on the project as well. He just gets the latest version from source-control, and he (or she) has everything in place in order to be able to compile and build).

(Note that this is also true if you use something like CruiseControl for continuous integration).

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Frederik Gheysels
  • 56,135
  • 11
  • 101
  • 154
4

You should look at NuGet. It's a package management extension for Visual Studio 2010 designed exactly for what you want.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Antony Scott
  • 21,690
  • 12
  • 62
  • 94
4

In the properties window of Visual Studio for the reference to the dll, there is a Property called 'Copy Local' - set this to true, and they'll be copied to your local project's bin directory

Dean Chalk
  • 20,076
  • 6
  • 59
  • 90
4

Take a look at NuGet (package manager for Visual Studio)...

NuGet is a Visual Studio extension that makes it easy to install and update open source libraries and tools in Visual Studio.

Then read this NuGet doc to get the crème de la crème:

Using NuGet without committing packages to source control

Leniel Maccaferri
  • 100,159
  • 46
  • 371
  • 480
2

Do have a look at Tree Surgeon - Creates a development tree for a .NET project, which can be a good starting point and from there you can improvise.

abhilash
  • 5,605
  • 3
  • 36
  • 59
1

Personally, I have a folder in my source control for 3rd party DLLs (with a folder for each company, organisation) and reference them from there.

These files are then available for all developers who download the source and can be updated easily.

Jonathon Bolster
  • 15,811
  • 3
  • 43
  • 46
1

To answer this properly you need to differentiate between the environment and working set.

Environment:

  • This is all the tools and libraries required to build your solution.
  • Things in the environment are expected to stay reasonably constant.
  • Things in the environment are usually versioned and you should be able to have multiple versions side by side.
  • Things in the environment are usually licensed.
  • Environment is not under source control.
  • A good example would be Visual Studio.

Working Set:

  • This is basically your source code.
  • It is all the requirements needed to get to your final executable.
  • You shuold expect the working set to change a lot during development.
  • The working set should be under source control.

You need to decide into which category your component fits.

Nobody
  • 4,731
  • 7
  • 36
  • 65