CODEWITHSUNDEEP
.netversion-control
Dinesh Manne
Dinesh Manne

Reputation: 1932

Location of Third Party Dll's in Version Control for .NET Project

What would be the ideal location (directory) to check in Third Party Reference Dll's for a .NET Project in a version control system. Typically i have seen most people to put them under bin, so that the runtime can automatically pickup these files. However is that the right way to go.

I originally wanted to have a separate directory which is parallel to bin called lib which will contain all third party Dll's , but this needs changes to the applications config file so that the lib directory is picked up by the run time. My idea over here is that lib will contain third party dll's while bin will contain the projects Binary (could be Dll or Exe)

What is the preferred way, The concentration over is the location in the Version Control and not just the Physical File System.

Upvotes: 7

Views: 5468

Answers (3)

Bradley Grainger
Bradley Grainger

Reputation: 28207

We use the following directory structure (more details available on my blog):

Solution\
  Libraries\
    third-party DLLs here
  Source\
    Project1\
    Project2\

Each project references (using the "Browse" tab in the Add Reference dialog) the assemblies in the "Libraries" folder. These are automatically copied to each project's "bin" folder at compile time. (The "Libraries" folder is, of course, committed to version control.)

Upvotes: 12

SClark
SClark

Reputation: 83

I assume those 3rd party DLLs would be used in more that one project of yours. Therefore putting the DLL directly under bin of every project means you end-up having as many DLL copies (in the VCS) as there are projects, which is not elegant. As Andrew H. mentionned, if the DLLs are truly common, they should be put in a common directory that will be refered to by all other projects that need it. The only catch here is being able to distinguish different versions of the same DLL: over time, you may end up with something like:

/common/ThirdPartyLibrary.dll  (version 1.2)    
/common/ThirdPartyLibrary.dll  (version 1.3)

The best way I know (for now) around that is renaming the 3rd party DLL with an explicit version number and refer to that new name in your project, such that your project will always, for sure, refer to the right version. Like:

/common/ThirdPartyLibrary_v1.2.dll    
/common/ThirdPartyLibrary_v1.3.dll

Upvotes: 2

Andrew Hare
Andrew Hare

Reputation: 351566

Have the separate directory contain the third-party assemblies (this will make things easier to maintain in source control) and then create references in your project to those assemblies. Then, on build, your third-party assemblies will be copied into your \bin and you won't have to make any configuration changes.

Upvotes: 9

Related Questions