There is a strange correlation between automobiles and line of business software applications when it comes to performing some standard repairs.
Consider the following scenario, you are happily working away at your job or out dining with your friends or family and when you come out to your vehicle, it has a flat tire. While this does not happen that often, it is a pretty common occurrence.
This common occurrence can look like this in an ASP.Net application….
In fact it is so likely to happen that most (if not all) automobile manufactures include the necessary equipment to keep you moving along when this happens. So where in your trunk or hidden under your seats are usually a spare tire. a jack, a wrench, and in some cases a special adaptor to loosen on special lock lug nut. The lock lug nut is a lug nut that is specific to each manufacturer and is meant to deter criminals from stealing your tires.
After a little work you can get your tire replaced or if you do not feel handy enough you can call for some help to get your spare tire put on and your flat tire put into your trunk so that you can get to a repair station. Once you get to a repair station they will ask for your lock nut. The repair stations do not want spend the time working with the wrong tools to get your new tire on.
This is where I can relate this analogy back to software. I consider all of those 3rd part controls, open source libraries and tools the lock nuts of software. We call these lock nuts system dependencies. You must handle all of your dependencies with extreme care. All of these tools can prevent your ability to maintain a software system in the future.
Why? If you do not keep your dependencies in your source control tree than when it comes time to build your software after you rebuild your machine or when it comes time to fix a bug brought on by environmental changes this simple thing can turn an easy fix into an impossible task.
The fix to this problem is pretty simple.. Grab all of those evil 3rd party assemblies and specific versions of libraries and include them in your source control tree. Here is the /lib folder of the CodeCampServer project. This seems like such a simple little thing yet so many developers make the mistake of ignoring their dependencies and instead keep relying on remembering where they put the installer for the specific version of a control their project needs which is sitting on the company file server. I cringe thinking about all the developers who will stumble on this code years down the road.