Add option to do content comparision for config files

[mikkelhm]

In the current KuduSync, when doing the SmartCopy, we are doing comparisons between the files in the source and the destination. For most files its "just" a LastWriteTimeUtc comparison, but for web.config its an actual content comparison, but doing a SHA1 of the content in both source and destination.

I'm guessing the reason for this is that in come cases the web.config will be transformed in the webroot or just changed forth/back, or updated for some other reason, and therefore the LastWriteTimeUtc will be different, but the file it self wont. Then in order to prevent a app restart, it does content comparison on the web.config.

We now have a case where we are using KuduSync.exe to copy files that could have been transformed, and not only the web.config, but in theory all .config files in a solution. This means that when we are KuduSync'ing between source and destination, the source's LastWriteTimeUtc will be different than the destination, and therefore the file will be copied, even though the content are the same. As these config files are sometimes added as configSource in web.config, the copy of the file into webroot, will cause an app restart.

It would be great to add it as an option to do content comparison for all config files. The logic it self should be the same as is used in https://github.com/projectkudu/KuduSync.NET/blob/master/KuduSync.NET/KuduSync.cs#L197, just applied to config files, in stead of just the web.config.

Would this project accept a PR, with the above functionality? We would love to implements it, as it would prevent us from relying on custom builds/forks, and we think it would be something all could benefit from.

Also a bit of clarification on where this is used. We are using Azure Pack, which comes with Kudu installed to handle website deployments, so this is not run on "real" Azure. We are currently running the S48 release of Kudu on the installation.

[davidebbo]

@mikkelhm you're correct about the reason behind the current web.config logic. See #12.

It could make sense to extend that.

[sitereactor]

@davidebbo do you have any opinion on the implementation of @mikkelhm suggestion? We will schedule looking into this over the next two weeks, and happy to submit a PR. Would be good to get your input before we start working on it 😄

I guess our main question is how the configuration should be done - maybe something like an extra parameter to specify config files to treat as web.config and maybe wildcard to handle all config files *.config

[davidebbo]

Another thing to think about is that for web.config, the logic special cases it so it gets copied at the very end (since it causes an appdomain restart). Would you want the same behavior for those config files? I'd say we might as well all do them last.

Adding a new switch makes sense. To be fully generic, I guess it could be a list of wild cards, and not necessarily limited to config files. e.g. --fullCompareFiles foo.txt;*.config;*.bar

[davidebbo]

Fixed by #18