Patching a .NET Application

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 ju开发者_如何学编程st 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?

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.

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.

Well, technically it could do, but practically you will probably get lost in lot of customers each having different binaries that do not differ even in version number.

Morover, if you're fixing a bug, probably you should somehow update all customers. I think it will be better to find solution based on frequent releases and self-updating feature for the application.

Some version numbers consist of four parts:

Major, Minor, Build, and Revision.

The revision would be used for updates to a product that fix security patches or other serious issues. Firefox would be one example.

With your approach, you didn't seem to use a revision and used the same major, minor, and build numbers as the previous version. Adding a revision to the version number can make it easier to determine which versions of a product were patched.