- You might forget to update the dlls when they are changed
- You might only update one dll when they are changed
- You might deploy the application in a way that means the defect is not noticed until runtime
What can you do? You have several approaches you can take:
- Hope it never happens (the most common and least effective measure)
- You can write a process which reminds people to update dlls - not bad but people don't always read or understand the implications of processes
- You can write a tool that updates things automatically - good idea but can require investment in the development for a simple scenario. Also how do we monitor whether it is working?
- Write unit tests that can test for the presence of the correct items - a good idea generally if possible but how to ensure they are kept up-to-date and are testing all the right places?
- You can design projects to not require such a dependency - best idea if it is possible without any other knock-on disadvantages or..
- A combination of the above dependent on the exact requirements.
As I have said before, anything is better than nothing. There is no single solution because all decisions in life have pros and cons which need to be considered objectively rather than dismissing out of hand. How much damage could occur if the defect is injected. Charge that at £1000/$1500 per day and then how much to develop or create the solution? Even a minor bug can have knock-on effects, both causing other defects and also damage to reputation before you have even thought about fixing the defect itself. The fix is then another potential defect injection since systems are rarely tested to the same degree after a bug fix than they are initially. Basically, even a small defect fix, if you are going to fix it, costs thousands in real terms, money which you are NOT going to get from the customer. Get it right the first time since you will not have time to do it right a second time if you didn't have time to do it right in the first place!