Patching a .NET Application

Question

Today I was debugging an issue a customer had remotely, and rather than build a whole new installation and send it to him, I just compiled the dll, made sure the version information was identical to the one he had installed, and replaced the old dll with the one I had just built on his machine (backed the other one up just in case), and everything still seemed to work fine, with the added benefit of more verbose logging which is what I added in.

My question is this: is this how patching software works in general? Or is what I did a very dangerous thing to do? If this is the bad way to go about it, what would be the best way to implement patching our software for bugfixes in the future?

Answer 1

The idea of patching is to modify in place the existing installation of a product. How you go about doing it: replacing files, applying a binary diff, etc, isn't important.

How you did your upgrade is fine; except that it's not scalable. If the version information is the same, it's up to you to manually track which binaries your customer has installed, instead of having it captured in an "About" dialog.

Also, many development shops archive builds that get sent to customer, and so how do you archive this configuration?

Not a huge deal, but it becomes a pain as you support more customers.

Answer 2

No, this isn't bad - in fact, DLLs are supposed to work this way. As long as you didn't break the ABI or API, (you just added logging, that's cool) you should be able to replace the contents underneath and restart the program.

Also, from a legal perspective, the LGPL wouldn't work without this. (One of the provisions in the license is that a user may replace your copy of the library with one they build/provide/find.)

You may be thinking of "patching with a hex editor" where you modify the binary without recompiling it. That's more dangerous.