在 .net 中智能部署 dll答案

【问题标题】：Smart deployment of dll's in .net在 .net 中智能部署 dll
【发布时间】：2010-07-26 13:45:16
【问题描述】：

我们目前有一个总共大约 22 兆的应用程序。我们当前的部署方法是将应用程序部署到我们的每个客户端服务器，如果有新版本可用，则使用小型更新程序将所有文件复制到本地 PC。问题是 22 megs 所花费的时间比我们想要推送更新的时间要长。特别是因为我们每两周更新一次。我们正在寻找一种方法来缩短该时间。

我们最初的想法是让本地电脑只复制自上次部署以来已更改的 dll。我们在这方面遇到了一些麻烦，因为时间戳使获取文件的准确哈希值进行比较变得困难。版本号可能可以正常工作，但我们必须找到一种方法，仅在代码更改时才对文件进行版本控制。

只是想知道是否有人在处理类似过程方面取得了成功或建议。

【问题讨论】：

标签： c# .net deployment

【解决方案1】：

我们会在国际范围内将文件推送到我们正在远程处理的设备上。

我们的解决方案是创建一个自定义工具来执行此操作（它实际上做了很多其他事情），它执行一种“增量复制” - 即仅推送已更改的文件部分。

这让您不必担心文件时间戳等问题 - 您最终在远端得到的文件与近端文件是逐字节相同的，但如果唯一实际更改的是内部时间戳，那么很少有数据需要通过网络传输。

我们使用的算法大致基于 rsync 的工作方式 (http://samba.anu.edu.au/rsync/tech_report/)，尽管我们是用 C# 从头开始编写的。

但是，在您的情况下，设置 rsync 和批处理文件以使用正确的环境/选项调用它实际上可能会更简单。这里有一个Win32版本的rsync：http://www.itefix.no/i2/node/10650，我使用成功。

【讨论】：

这是非常实用的建议。
这听起来可能是最好的选择。如果可能的话，我不是必须手动滚动东西的超级粉丝，所以也许我会考虑部署 rsync。谢谢。
看起来这对我们有用，我不负责最终决定，但我同意史蒂夫的这个“非常实用的建议”。

【解决方案2】：

时间戳对哈希没有影响，但更新版本号肯定会改变哈希。

【讨论】：

如果我打开 Visual Studio 并打开一个新的 winforms 应用程序。然后我编译并以 WindowsFormsApplication1.exe 结束。然后我将其重命名为 WindowsFormsApplication2.exe。我重新编译而不做任何更改。这会再次创建一个 WindowsFormsApplication1.exe。如果我通过 MD5 或仅使用 winmerge 之类的差异工具比较这些文件，它们是不同的。也许它不是时间戳，而是依赖于编译。项目文件设置为 AssemblyVersion 1.0.0.0 和 AssemblyFileVersion 1.0.0.0，因此不会根据时间更改版本。有什么想法吗？
编译后的文件包含时间戳。
反功能？也许，但它提供了一种 O(1) 方法来判断文件可能是否不同，而您的哈希是确保两个文件相同的昂贵方法，这是不一样的测试。时间戳是 Windows Portable Executable 格式的一部分 - 如果您真的想使用它，请参阅 microsoft.com/whdc/system/platform/firmware/pecoff.mspx（或网络上的许多其他文章）
另一个想法 - 请记住，MS 工具使用时间戳来匹配 PDB 文件及其相关的二进制文件，因此如果您玩带有时间戳的游戏，您可能会遇到这种情况。不过，可以告诉大多数调试器忽略时间戳不匹配。
@Will：PE 标头具有校验和，具有强名称的 .NET 程序集具有签名哈希，所以这不是真正的问题。但是，坚持这个话题，我唯一想要标准化时间戳的时间是官方版本。话虽如此，您链接的文档甚至会让我感到紧张，因为延迟加载目录表引用了早期绑定 DLL 依赖项的时间戳。

【解决方案3】：

看看ClickOnce deployment是否能满足你的需求。

【讨论】：

我正在考虑将此作为一种选择（如果没有其他原因我一直打算这样做的话），但乍一看它似乎不能满足我们的需求。