Two of the interesting features of .NET development for me are the config file and drag-n-drop deployments. Its a great way to manage an app without recompilation or to deploy new features without an installer.
A recent development at work was pointing to a failing service. When examining the message in the Event Viewer, it was a very plain Jane generic message. I suggested a solution that would expand the message to include the messages from all of the inner exceptions as well, instead of just printing the top-level Exception.Message. My manager asked how hard this would be.
"It shouldn't be too hard. We add a method to parse the exception into a message including all of its inner exception messages as well. We should be able to drop it into the same directory and it should just start reporting the new message format."
The other developer working with me chortled at my excessive use of the word "should". In the months that I have been on this contract and working with this code base, I often find that things arent going by the book, for whatever reason. So I have begun to become jaded to trusting tried and true favored features like drag-n-drop deployment.
After creating the method and recompiling the code, we dropped in our new exe to replace the too terse service. And it worked. This turned out to be one of those instances that was the exception that proves the rule.
So now with more verbose error information in hand, my boss was able to continue the investigation and lay it at the door of the proper folks. And I was able to rest easy knowing that .NET does still occasionaly work like it should here.