Split the Core out of the Console project, in preparation for nugetizing it

[PaulStovell]

Hi @kzu,

Before I merge this, can you give me some background around why use Octodiff as a library rather than as an executable? You could already reference the .exe as if it were any other assembly (though I guess it might not work so well with NuGet, is that the issue?)

In Octopus we were going to use it as a library, but realized it would be better to run it as an executable. We never did much by way of tuning how the algorithm uses memory - you can imagine that for large files, it's allocating lots of dictionary entries and buffers for the chunks. Some of those might be big enough to go directly to the LOH (I can't recall). All of that could put a lot of pressure on the GC.

Calling it as an exe means it starts, does the job quickly without worrying too much about doing allocations smartly, then is terminated and the OS cleans it up. For something long-running like Octopus, that predictability and isolation is important.

I'm still open to considering this refactor, but it's not something we'd use ourselves, so I'd love to know more about the scenario.

[kzu]

There aren't much (any?) useful diff libraries on NuGet. This would hardly make a difference to Octopus, since you can even ILMerge it back to keep a single .exe if you wanted.

And for users like me which would love the easy of packaging, installing and updating of a nuget package, it's a great feature. i.e. a webhook made of Azure functions for example.

[tbolon]

I would love to be able to use this code as a Library.

We are considering using it to optimize patch download for our client app. Deploying an additional exe on the customer computer is always risky, because of the AV/signature/lock hell...

So I would like to use directly this code Inside our core exe, already trusted by the client pc.

I can help back in this PR if conflicts need to be resolved.

[GrzegorzBlok]

Hi guys, If any of you are interested in Octodiff as a library I already made a lib of it: https://github.com/GrzegorzBlok/FastRsyncNet I added xxHash64 as a default hash algorithm so it is significantly faster and produces smaller signatures than Octodiff SHA1 version. xxHash64 has an excellent hash quality (distribution, collision and performance), but lacks cryptographic properties that are not needed in case of rsync algorithm.

The SHA1 is still supported so signatures and deltas from Octodiff still works correctly.

If you @tbolon or anyone else wants to use it I nugetized it: https://www.nuget.org/packages/FastRsyncNet/

[droyad]

OctoDiff - Split the Core out of the Console project, in preparation for nugetizing it #9

[CLAassistant]

All committers have signed the CLA.

[droyad]

OctoDiff has since been made available on NuGet and can be consumed programatically.