views:

441

answers:

2

If I compile a C# project twice, I will get two assemblies. These assemblies aren't exactly the same (using a binary diff). I can think of reasons why this is so, but the fact remains that the source for the two assemblies are identical.

I am concerned with creating a patch between these assemblies, and applying the patch on a customer machine.

Does anyone know of a library (preferably .NET) or tool with which I can create and apply patches?

Ideally it should also handle small changes, like changing dependencies on a project level or tweaking a few lines in the source. It does not have to be able to cope with larger changes, because I am happy to replace assemblies in full in this case.

Update:

I think a bit more background might help clarify what I'm getting at. I've got a continuous integration server building my application. I change the file and assembly version to reflect the build number and version I'm building. I could have done it differently, but this is the option I like.

This causes assembly references to change when I build my application, but I'm happy with that. I'm now concerned with distributing an update to a previously released version. I build updates using InstallShield. The assemblies available to InstallShield are reduced to small patches. These do not increase the size of the update by a lot.

My application has a few data files, which are basically encrypted archives containing assemblies. InstallShield does not have access to these assemblies or understand my archive. It does not know how to decrypt and extract it. I've written my own patch routine which finds changed files in the previous archive and replaces them with the new updated version. Basically a search and replace strategy.

The one archive contains almost a hundred (and growing) of these assemblies and some of these assemblies contain large data files as resources. These assemblies are dependent on assemblies which are part of the application. They are also compiled during the continuous integration build. Not compiling them during the build will leave room for dependency issues and I'm not willing to try and manage that. Every time I create a patch, all of these assemblies are included. I'm now looking at options to decrease the patch size by generating patches for these assemblies.

+2  A: 

This is not .net but should be able to generate a patch file for you -

http://www.tibed.net/vpatch/

I used to use it for gaming and maps e.t.c. but it should work with any two files.

Wil
I'll have a look and see if it does what I need. Thanks!
Christo
I had a look at vpatch. It works even better than I expected and will work perfectly. Thanks again!
Christo
+6  A: 

I'd recommend replacing your assemblies. Patching has always been a little problematic - at least in comparison to replacement. Assembly files tend to be fairly small, so replacing them is usually not a very large task.

Typically, the reason that assemblies change if the source is identical typically has to do with one of a few things. Your project may have changes, but more likely, one of the assembly's referenced assemblies has changed. In that case, you'll want to be distributing the full set of assemblies, including the referenced assembly, or you'll get versioning issues and breakage on the customer's machines.

Creating a new installable is usually much simpler and safer than trying to patch a machine in place.

Reed Copsey
+1 for good, sensible advice.
Cyril Gupta
Why not patch it? If references changed that might have a small impact, but a proper patch would transform assembly A to B and only include the necessary bits to change the assembly references within A.
Christo
Many years of trying to patch software in the field has made me weary of any patching solution. Both my company and vendors we've used have been down this road, and without fail, have found it to be problematic at best. It works, most of the time, but when there's a problem, it's horribly difficult to correct. It's very difficult to do everything a proper installation can handle from a patch, and bandwidth for downloading updates is cheap. Patching just isn't worth the effort.
Reed Copsey