Manage references in source control with Visual Studio

Question

I'm having trouble managing my .dll references in projects in Visual Studio. All the registered .NET and COM references work fine but when it comes to .dll files on disk, if I refer to my files on disk, my colleagues will be missing references because they may have it in a different location on disk etc. Does Visual Studio have a environment variable like $PATH or something so that each computer have paths it will look in first before saying that it can't find a reference? Or is keeping the .dll references in the source control a better option?

Ok, it worked perfectly. In VS, I just added a folder to the solution, added the dlls to the folder and added everything to source control. I referred to those dlls in individual projects and when I get the latest version from other computers, it linked properly. Thanks guys

Answer 1

I like to add a solution folder the the solution, which I then place all my external DLL's in. From there I reference that rather than a specific folder on PC.

So yes they are in source, but why not. Especially when managing updates.

Works great for me.

Answer 2

A general rule of thumb: Put the dlls in source control and wherever possible add references by project file rather than dll

Answer 3

Create a "references" folder in source control that contains any referenced assemblies that you require. If the source is available for those assemblies, store it as well.

I think it's good practice to include all assemblies that are not part of the OS or .NET framework. For instance, you don't want to go having to install Enterprise Library or any other assemblies when getting started on a new developer install (on a new machine or a reinstall of the OS).

Answer 4

I have a common folder in source where all true third party dlls are stored. Under each project I have the following three folders:

• 3rdParty - An svn:externals link to any of the 3rd party dlls needed from the common set.
• References - An svn:externals link to the "Assemblies" folder of any in-house built projects.
• Assemblies - This is where the build output of a project will go. This way other projects that may need to reference the assemblies have a single place to go for the project and using svn:externals can control which version they wish to use.

\root
     \Common.3rdParty (common third party dlls)
     \Solution
        \Project1
           \3rdParty (svn:externals links to common third party dlls that are needed)
           \Assemblies (Project's build output)
           \References (svn:externals links to referenced project "Assemblies" folders)
           \[Project's Folders...]
        \Solution.sln

More Info Here

Answer 5

This works for me, both in subversion and VSS.

\root
    \trunk
       foobar.sln (solution file goes here)
        \References
            foo.dll (3rd party, ie. you don't compile this)
            bar.dll
            (Don't put dll's for Project 1 here, Visual Studio will take care of it)
        \Project1
           .proj file goes here
              \bin  (don't put dll's here!)
        \Project2  (This might reference Project1

Don't put dll's into \bin because repositories like VSS like to make them readonly, which interrupts clean and re-build.

Visual Studio doesn't understand dependencies above the solution level, so if you have solutions that depend on solutions, you'll have to show that in your build scrips/build server.