Patches

Well, I'd start by reading this Wikipedia article for a good overview of the theory and practice of software patching:

http://en.wikipedia.org/wiki/Patch_(computing)

I think the only time when you'd plan for a possible patch is, if you knew that part of the software was flakey, but needed to release it anyway at the client's insistence or at least with the client's knowledge.

In general it's much more difficult to alter a piece of a program rather than just replace the whole program. It has to be remembered that the client will usually only have the binary, not the source code, so you need to find a way of injecting machine code into the binary (in the case of an unmanaged executable) or IL into the binary (in the case of a managed executable).

I would say that this is even more difficult for managed rather than unmanaged executables because it's not just the code you have to worry about but its effects on the metadata and security of the .NET assembly. Moreover, if the assembly contains code which you wouldn't want your competitors to get their hands on, it might have been obfuscated prior to release.

For these and other reasons, I never attempt to patch .NET assemblies myself - I always provide a replacement for the whole program.

Anyway don't let me put you off, if you're really interested in pursuing this :)

Here's a recent Code Project article I found on writing a .NET patching tool which contains a link to a library someone has written to help with modifying IL:

http://www.codeproject.com/useritems/NetDasm.asp

1 Reply

Know the answer? Post it — somebody with the same question will find it here.

Alan19y ago
Well, I'd start by reading this Wikipedia article for a good overview of the theory and practice of software patching:

http://en.wikipedia.org/wiki/Patch_(computing)

I think the only time when you'd plan for a possible patch is, if you knew that part of the software was flakey, but needed to release it anyway at the client's insistence or at least with the client's knowledge.

In general it's much more difficult to alter a piece of a program rather than just replace the whole program. It has to be remembered that the client will usually only have the binary, not the source code, so you need to find a way of injecting machine code into the binary (in the case of an unmanaged executable) or IL into the binary (in the case of a managed executable).

I would say that this is even more difficult for managed rather than unmanaged executables because it's not just the code you have to worry about but its effects on the metadata and security of the .NET assembly. Moreover, if the assembly contains code which you wouldn't want your competitors to get their hands on, it might have been obfuscated prior to release.

For these and other reasons, I never attempt to patch .NET assemblies myself - I always provide a replacement for the whole program.

Anyway don't let me put you off, if you're really interested in pursuing this :)

Here's a recent Code Project article I found on writing a .NET patching tool which contains a link to a library someone has written to help with modifying IL:

http://www.codeproject.com/useritems/NetDasm.asp