|
|
In the absence of a debugger, product logging is the next most powerful way to understand where the code failed on a customer's machine. Hopefully, your product already includes substantial logging. But as we discussed in Chapter 5, you can't log everything, and sooner or later, you'll come across a case where you need to know the value of a variable at a certain point, except you failed to write that value in the log. No problem; just create a new version of the DLL or EXE with increased logging and ask the customer to produce the bug again with this new version. That way you'll get the information you need to solve the problem. Customers are usually willing to do this once or twice before becoming annoyed.
But there's one part of this trick that is not at all obvious—anytime you send a patched file to a customer, make sure it has some immediately obvious side effect so you can easily verify the new version is installed. Usually this means writing something to the log that says "THE NEW VERSION HAS BEEN INSTALLED." Otherwise, you'll be amazed by the number of times customers somehow mess up the installation of the new files, and then send you logs from a run of the program with the original version still in place.
In the old COM days, it was easy to mess up the installation of a DLL, because you not only had to copy it to the right directory, you often had to remember to register it with the RegSvr32 tool. Customers often neglected that step. .NET is much nicer in this respect, because most .NET assemblies just need to be dropped in the right directory and that's it. Is that too much to ask customers to do? Apparently so. Ninety percent of semi-technical users will manage this task fine, but you'll occasionally get a customer who somehow blows it. You might expect the issue to go away if you provide an idiot-proof automatic installer to copy the new file to the right directory. But amazingly, no. You'll still get customers who just plain forgot to run the installer.
That's why you need a way to tell whether the customer installed your logging DLL or not. You need to make sure the DLL you prepare will immediately write something recognizable to the log. Merely adding additional logging to the function you think is buggy won't be sufficient, because what if that function doesn't even get reached? Add some logging you know will definitely be reached. Then, you will instantly know whether or not the customer installed your DLL correctly.
By the way, I've learned the hard way that this piece of advice doesn't only apply to logging DLLs. After sending the new logging DLL to the customer, you'll eventually find the problem and then you'll want to give the customer an even newer DLL that actually fixes the bug. Make sure you change the logging of this version, too. Otherwise, you'll get calls from customers telling you the patch you sent them didn't solve their problem—when the reality is that they're merely still using the unpatched version without knowing it.
|
|