修补 .NET 应用程序
今天我正在远程调试客户遇到的一个问题，我没有构建一个全新的安装并将其发送给他，而是编译了 dll，确保版本信息与他安装的版本信息相同，然后替换了旧的 dll与我刚刚在他的机器上构建的一个（备份另一个以防万一），一切似乎仍然工作正常，还有更详细的日志记录的额外好处，这就是我添加的。
我的问题是：这就是修补软件的一般工作原理吗？或者我所做的事情是一件非常危险的事情吗？如果这是一个糟糕的方法，那么将来对我们的软件进行补丁修复的最佳方法是什么？
Today I was debugging an issue a customer had remotely, and rather than build a whole new installation and send it to him, I just compiled the dll, made sure the version information was identical to the one he had installed, and replaced the old dll with the one I had just built on his machine (backed the other one up just in case), and everything still seemed to work fine, with the added benefit of more verbose logging which is what I added in.
My question is this: is this how patching software works in general? Or is what I did a very dangerous thing to do? If this is the bad way to go about it, what would be the best way to implement patching our software for bugfixes in the future?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
修补的想法是就地修改产品的现有安装。如何去做：替换文件、应用二进制差异等并不重要。
您的升级方式没有问题；但它不可扩展。如果版本信息相同，则需要您手动跟踪客户安装了哪些二进制文件，而不是在“关于”对话框中捕获它。
此外，许多开发商店都会归档发送给客户的构建，那么如何归档此配置呢？
没什么大不了的，但当你支持更多的客户时，它就会变得痛苦。
The idea of patching is to modify in place the existing installation of a product. How you go about doing it: replacing files, applying a binary diff, etc, isn't important.
How you did your upgrade is fine; except that it's not scalable. If the version information is the same, it's up to you to manually track which binaries your customer has installed, instead of having it captured in an "About" dialog.
Also, many development shops archive builds that get sent to customer, and so how do you archive this configuration?
Not a huge deal, but it becomes a pain as you support more customers.
不，这还不错 - 事实上，DLL应该以这种方式工作。只要您没有破坏 ABI 或 API（您刚刚添加了日志记录，这很酷），您应该能够替换下面的内容并重新启动程序。
此外，从法律角度来看，如果没有这一点，LGPL 将无法发挥作用。 （许可证中的一项规定是，用户可以用他们构建/提供/查找的库替换您的库副本。）
您可能会考虑“使用十六进制编辑器进行修补”，在其中修改二进制文件而不重新编译它。那就更危险了。
No, this isn't bad - in fact, DLLs are supposed to work this way. As long as you didn't break the ABI or API, (you just added logging, that's cool) you should be able to replace the contents underneath and restart the program.
Also, from a legal perspective, the LGPL wouldn't work without this. (One of the provisions in the license is that a user may replace your copy of the library with one they build/provide/find.)
You may be thinking of "patching with a hex editor" where you modify the binary without recompiling it. That's more dangerous.
好吧，从技术上讲它可以做到，但实际上您可能会迷失在许多客户中，每个客户都有不同的二进制文件，甚至版本号也没有区别。
此外，如果您正在修复错误，可能您应该以某种方式更新所有客户。我认为最好找到基于应用程序的频繁发布和自我更新功能的解决方案。
Well, technically it could do, but practically you will probably get lost in lot of customers each having different binaries that do not differ even in version number.
Morover, if you're fixing a bug, probably you should somehow update all customers. I think it will be better to find solution based on frequent releases and self-updating feature for the application.
某些版本号由四个部分组成：
主要版本、次要版本、构建版本和修订版本。
该修订版将用于修复安全补丁或其他严重问题的产品更新。 Firefox 就是一个例子。
按照您的方法，您似乎没有使用修订版，并且使用了与先前版本相同的主要版本、次要版本和内部版本号。添加版本号修订可以更轻松地确定产品的哪些版本已修补。
Some version numbers consist of four parts:
Major, Minor, Build, and Revision.
The revision would be used for updates to a product that fix security patches or other serious issues. Firefox would be one example.
With your approach, you didn't seem to use a revision and used the same major, minor, and build numbers as the previous version. Adding a revision to the version number can make it easier to determine which versions of a product were patched.