As I was trying to complete the integration of a new feature into our application I figured it was about time that I fired up the service (the app is a windows service for background processing). Low and behold when I did all hell broke lose. Yes, I have spent almost 2 weeks working on the feature and have yet to do a full end to end test, but this is not an issue as I feel comfortable that my feature will work since my coverage is high and my test count is also high.
When I started to look into the issue I noticed the following in my error logs
Could not load file or assembly 'nunit.framework, Version=126.96.36.199, Culture=neutral, PublicKeyToken=96d09a1eb7f44a77' or one of its dependencies.
This error made no damn sense, because why would I need to reference NUnit for a production dll (no, we are not using compile arguments to turn on/off NUnit)???? I knew the issue, some dll had reference to NUnit when it should not. But hunting this down was going to be a bear (our product has about 20-25 dlls, and 5 or 6 solution files). I had 2 choices, either open up each solution file and look at the references for EVERY dll… OR use reflector.
Some of you may not realize, but reflector not only allows you to peer into the source code of a dll, but it also allows you to quickly analyze the dependencies (and their dependencies) of a dll. So, about 3 minutes after I fired up Reflector I knew the which dll was the issue and was able to replace it (I had completely forgot that in a lazy haze I added nunit to one of my projects as I was too lazy to move over to the test project to do a simply POC test ((yes I am VERY lazy)) )
So the next time you find yourself needing to determine dependencies, remember there are many ways to solve this problem, but Reflector may be your best bet.
Till next time,
11-11-2009 7:09 AM