I've got a bunch of .dll assemblies, such as HtmlAgilityPack and MoreLinq. Where am I supposed to put these files? I usually toss them somewhere in my Projects folder, but then I'm always digging around for them. Is there a standard place to put them?
views:
102answers:
6
+6
A:
There's no standard place to put them, but make sure you:
- Put them in one place
- Include them in source control.
I put all my required dll's in a top level directory in my solution called "Dependencies", parallel to the project folders. I have them in source control such that when new developers check out the solution, it all compiles and works right off. It's the only way to go.
I include only the .dll files absolutely needed. This keeps it light, which is good, but then when I find some other part of MVC Contrib or whatever that I need, I have to go find the unzipped directory, which might not even be on my computer! Others put entire library directories (readme.txt and all) as part of their source control linked to the solution. This ensures you and future developers will have everything they need, but adds a little dead weight. Either is a good strategy.
Patrick Karcher
2010-10-09 20:07:15
I disagree with putting referenced assemblies in source control. How can your build system ever use newer versions if you so choose? It sounds like you would have to go through every single project and add the new assembly versions, then check the projects back in. Sounds inefficient.
Matthew Ferreira
2010-10-09 20:23:49
DLL dependencies have to be controlled otherwise you cannot guarantee that your source will build every time when you check out or get latest. How often would you change lib vesions? Not very often. I'd branch everything, update the DLL references throughout the projects, build all, run all tests and once happy re-integrate with the main "trunk". You will end up in a world of pain if individual developers use whatever DLL versions they like, and they are not version controlled.
IanT8
2010-10-09 20:41:14
@Matthew, I think we might have different situations. If you have different solutions with common dependencies, and in your situation you can update their dependencies at the same time, and you are solo or maintain a very good system for ensuring consistent library usage between devs, and depending on your build system, etc., then I can see where you're coming from. I have a solution with 4 projects whose external libraries **won't** match other company solutions, and with developers coming and going off of the project. Doing it the way I describe is definitely best for me.
Patrick Karcher
2010-10-09 21:43:05
@Patrick, I'll certainly give you that. Of course I don't know your project's requirements. We've actually gone both ways at my company, and found having an assembly repository was best for our needs. Our needs are not your needs however, so definitely do what works best for you.
Matthew Ferreira
2010-10-10 00:46:52
+2
A:
The visual studio directory in My Documents seems like a logical place to put them. I don't know if it's the best or anything wrong with it but at least all the libraries are found in one place.
%USERPROFILE%\My Documents\Visual Studio XXXX\Libraries
Jeff M
2010-10-09 20:10:53
+1
A:
At my company we place all our shared DLL assemblies onto a network drive in a folder called Assemblies. From there, we use SyncToy to mirror changes between that folder and a folder on our local development machines (in my case C:\Assemblies with subfolders for different versions or useful third party assemblies). Using the "Reference Paths" feature of Visual Studio projects makes it very easy to select different assembly versions based only on locations.
For projects at home, I would definitely go with the idea mentioned by Jeff M of placing them in the Visual Studio folder under My Documents.
Matthew Ferreira
2010-10-09 20:15:57
+1
A:
In a folder UNDER your solution directory, e.g. "external" or "library". That way your continuous integration system (or other team members) can do a pull of one root from your source control system and have everything they need.
In SVN, use svn:externals to pull that directory from a different root so you can easily share library DLLS (and library projects) between solutions.
Hightechrider
2010-10-09 20:24:25
+1
A:
In the office we have a share on the network for referenced asseblies. These could be 3rd party or assemblies of our own that could be shared between projects.
I also, don't like the idea of putting the dll files in source control. If all the developers have access to the share all will work fine.
George Handlin
2010-10-09 20:29:24
Works for the developers, sure, but if it's an open-source project, your users need the library too.
Mark
2010-10-09 20:45:25
+1
A:
Having a "Lib" folder at the same level as source projects is a common way.
To be honest, it's not the dependencies my projects have that I find hard to manage, it's the dependencies the dependencies have. I'd just like to mention NHibernate, Castle Windsor and the various Castle Windsor Facilities in particular. Getting all of those to play together on my last project cost me a lot of time.
For open source projects, I also like to have the source code handy because sometimes its useful to debug into the source code. (And sometimes because the documentation is so poor, you have to read the source code to find out how it works). I've seen VS projects arranged so that the project references the DLL yet at the same time, VS knows where to find the source code, as I write I can't quite remember how to do that.
So, a Lib folder for DLLs works for me; I often call it "Shared Dependencies".
As for open-source source code, I don't have a standard way to version that because each project is structured differently and has a different build process. I don't like to tinker with the open-source project structure or build method because then, I take responsibility for it. If for some reason, it won't build, or builds incorrectly, or produces a faulty DLL, the cause would be exceedingly difficult to track down, and I'd have to get deep into troubleshooting all of that which I dont care about at all.
IanT8
2010-10-09 21:07:41