When you make references to .dlls, either your own or third-party libraries, in your final application these .dlls are just thrown willy-nilly into the same folder as your .exe. Well as anyone with OCD can tell you, this is just not acceptable. Even if you don’t have OCD once you have enough .dlls it starts to get hard to find things in that folder. Now there are options for storing things in the GAC and such but my days as a Macintosh programmer want me to just take a folder, drag it to a new computer and have the application run, I’m not big on having dependent files hidden away in the deep dark recesses of the hard drive.
Getting organized is as simple as finding the app.config file in your Visual Studio solution and adding a new section. If you don’t have an app.config file you can create one manually but it’s easier to just right-click on your solution, go to the bottom of the context menu that opens and select Properties. In the tab that opens you can select the “Settings” tab as shown and just create an entry for anything. You can always delete it later but I’ve never created an application where I didn’t at least store the one item here (typically the names of .xml files that hold all my other settings).
This technique only works if you store your .dlls in a directory inside the directory that holds your executable. The <probing> tag with the “privatePath” attribute is what you need to add, but my app.config didn’t have the required runtime element so here’s the entire nested element structure that I added.
Now, you don’t have to use a folder named “lib”, just change that portion to anything you want. If you want to use multiple directories employ a semicolon delimited list like “lib;bin;lib\modules”, you get the idea. On a recent project the results looked like this: