views:

33

answers:

3

We are using TFS and VS 2010.

I have been working on a project that is using TFS as source control. I have quite a few dlls that I have downloaded (such as log4net) and referenced in my project.

When a new programmer connected to TFS and got my project out of source control, it failed to build as it said it was missing all these referenced dlls.

What did I do wrong here? How can I include those referenced DLLs in source control. Do I need to add all these dlls to my project before referencing them? when i referenced them, I just browsed to where they were on my file system.

Thank you!

+3  A: 

I've found the best practice for 3rd party DLLs is to create a "Library" folder in your sln/proj file structure and copy all the necessary DLLs into this local folder for reference. You'll also want to make sure these DLLs are checked into source control. This way, everyone who works on the project gets the exact same versions of all DLLs, and the reference paths are exactly the same.

Referencing 3rd party libs in a arbitrary download or install location will be problematic, because it will require all developers to maintain the same download structure for all DLLs. Also, if everyone references DLLs outside of the project structure, it's harder to guarantee that everyone's on the same version.

The other option would be to have everyone install the DLLs into the GAC, but that can be a real pain too, especially with version management and deployment.

Andy White
This has the added benefit that any developer (new or otherwise) could just get latest, hit F5, and be up and running without the "where do I get DLL X or how do I install DLL Y"
Hector
+1  A: 

I've tried various methods for dealing with this and have settled on dropping required dll's in the bin folder and making sure they are included in the project for source control. I've heard people say this might not be a good idea but nobody has provided good reasoning for it and it's worked well for me.

My second choice would be to carve out some space on a network share and organize the various 3rd party dll's there. You can put your files in folders with verion numbers to keep things straight and everyone should have access to everything they need, so long as everyone uses the normal network paths as a reference.

Adding a seperate folder within the project is also workable but seems messy, since you end up with extra files that you don't want included in your release.

lincolnk
+1  A: 

Andy's suggestion is a good one and I've used that in the past. At my current job, we have a "reference" folder on a network share for all of us to build from. We have a very fast network here, though and all developers are in a single office. This solution won't work as well if you have a lot of remote developers or a slow network.

Steve Danner