在网络环境中自我更新桌面应用程序的最佳实践

Question

我已经通过谷歌和SO搜索了这个问题的可能答案，但只能找到分散在这个地方的一小部分信息，其中大多数似乎都是个人意见。

我知道这个问题可以被认为是主观的，但我不是在寻找个人观点，而是寻找具有理由的事实（例如过去的经验），甚至是寻找描述最佳实践的博客/维基的单一链接（这是我更诚实的）。我不想要的是如何使这项工作，我知道如何创建自我更新的桌面应用程序。

我想了解创建自我更新桌面应用程序的最佳做法。我特别好奇的那种最佳实践是：

• 如果客户端软件已过期，您是否强制更新，但在尝试与其他版本的软件或数据库本身进行通信时不会中断？如果是这样，你如何表示这种突破性变化？
• 您应该多久检查一次更新？每周/每日/每小时，究竟是为什么？
• 用户是否可以看到更新或从UI的角度在幕后运行？
• 如果不是重大更新，您是否应该通知用户有可用的更新？ （例如，在应用程序的远程部分修复单个按钮，只有一个用户实际需要）
• 您是否应该尝试修补应用程序，还是从头开始重新下载整个应用程序？
• 您是否应该允许用户从中央位置更新或仅允许通过指定的应用程序进行更新？ （适用于封闭式业务应用程序）。

当然有关于这些东西的书面规则/建议？关于许多应用程序最烦人的事情之一是更新，因为很难在“过时”和“在用户面前”找到良好的平衡。

如果有人认为这是用单个客户端编写的.net C＃，在与更新服务器具有持续可用连接的机器上运行，所有这些机器都通过应用程序相互通信，并且所有这些机器都与中央数据库服务器。

Answer 1

很难给出一般答案。这取决于上下文：更新的关键性，它是什么类型的应用程序，用户首选项，＃users，网络宽度等。以下是一些选项/权衡。

• 如果客户端软件已过期，您是否强制更新，但在尝试与其他版本的软件或数据库本身进行通信时不会中断？如果是这样，你如何表示这种突破性变化？

  作为开发人员，您最感兴趣的是让所有应用程序尽可能地保持最新状态。这减少了您的维护工作量。因此，如果用户不介意，您应该更新。

• 您应该多久检查一次更新？每周/每日/每小时，究竟是为什么？

  如果更新对用户是透明的，不要求立即重新启动应用程序，那么我建议您在通信带宽允许的情况下尽可能频繁地执行此操作（考虑更新检查频繁）但很小 - 下载很少但很大）

• 更新是对用户可见还是从UI的角度在幕后运行？

  取决于用户首选项，还取决于更新类型：错误修复与功能/ UI更改（用户会感到困惑，看到外观已经改变而没有先前的警报）

• 如果不是重大更新，您是否应该通知用户有可用的更新？ （例如，在应用程序的远程部分修复单个按钮，只有一个用户实际需要）

  与上一个问题相同的论点

• 您是否应该尝试修补应用程序，还是从头开始重新下载整个应用程序？

  如果应用尺寸较小，请从头开始下载。这将防止创建不同补丁（“DLL地狱”）之间不匹配的所有类型的奇怪错误。但是，这可能需要大量下载时间或对您的网络造成严重损失。

• 您是否应允许用户从中央位置更新或仅允许通过指定的应用程序进行更新？ （对于封闭的业务应用程序）。

  我认为

Answer 2

许多软件忽略的一个最佳做法：要求在用户关闭应用程序时更新，而不是在它刚刚启动时更新。

令人难以置信的是有多少应用程序没有这样做（例如Firefox）。您刚刚运行该应用程序，您想立即使用它，而是提示您是否要更新，当然这需要花费5分钟并且需要重新启动应用程序。

这是无意义的。只需在最后进行更新。

Answer 3

根据实际经验，不要忘记添加更新更新引擎的功能。这意味着执行更新通常是两步法

1. 检查更新引擎是否有更新
2. 检查实际应用程序是否有更新

  

如果是客户端，您是否强制更新？   软件已过时，但不会   在尝试沟通时打破   与其他版本的软件或   数据库本身？如果是这样，你怎么样   表示这种突破性变化？

通常的做法是使用“ProtocolVersion”方法来指示允许的最低/最旧版本。

“ProtocolVersion”可以由客户端或服务器提供，具体取决于客户端和服务器之间的信任级别。在低信任级别中，最好让客户端提供“ProtocolVersion”，然后在客户端更新之前拒绝访问服务器端。在“高信任级别”场景中，让服务器提供它接受的“ProtocolVersion”更容易，然后适应这一点的所有逻辑 - 包括更新客户端应用程序 - 仅在客户端中实现。提供版本检查/处理代码只需要在一个地方的好处。

Answer 4

• 除非律师要求，否则不要试图强制更新。向用户显示她可以接受或忽略的更新通知。如果她拒绝了，请尽量不要对同一版本发送垃圾邮件。帮助她做出决定，包括发布说明的链接或更改的简短摘要。
• 每周将是一个很好的默认更新检查间隔，但让用户选择此选项，包括从网络上完全禁用更新检查。不要经常检查，因为她可能会使用昂贵的移动数据计划，或者她只是不喜欢应用程序打电话回家的想法。
• 更新检查部分应完全无声。如果找到更新，则显示该用户的通知。在下载和安装过程中，显示​​进度条。
• 为了简单起见，请通知用户任何较新的版本。如果您不想通过频繁更新来惹恼他们，包括一些小错误修复，请不要在更新检查程序监视的下载位置发布每个次要版本
• 维护所有以前发布的版本的补丁太多了。如果下载大小成为一个问题，找出一些其他方式，而不是补丁，使其更小（7-zip压缩自解压exe，将应用程序拆分为多个具有独立版本的MSI包等）

还有两件事：

即使我没有使用您的应用程序，也不要将更新引擎实现为在后台持续运行的进程。我的PC已经有10个这样的进程占用了资源，这非常烦人。

更新更新引擎本身时，一方面需要让引擎运行以显示安装进度UI，另一方面必须关闭更新过程以避免由于exe文件被锁定。有许多事情，例如从％TEMP％运行帮助程序，使用Windows Installer重新启动管理器，在启动安装包之前重命名updater exe文件等。在构建更新引擎时请记住这一点。

Answer 5

• 如果客户端软件已过期，您是否强制更新，但在尝试与其他版本的软件或数据库本身进行通信时不会中断？如果是这样，你如何表示这种突破性变化？

询问用户。

• 您应该多久检查一次更新？每周/每日/每小时，究竟是为什么？

询问用户。

• 用户是否可以看到更新或从UI的角度在幕后运行？

询问用户。

• 如果不是重大更新，您是否应该通知用户有可用的更新？ （例如，在应用程序的远程部分修复单个按钮，只有一个用户实际需要）

询问用户（注意此处的趋势？）。

• 您是否应该尝试修补应用程序，还是从头开始重新下载整个应用程序？

通常情况下，补丁，如果应用程序具有任何重要的大小。

就“询问用户”的反应而言，并不意味着每次都会提示他们。相反，给他们选项来设置他们应该被提示什么以及应该做什么不可见的（并且第一次发生给定的事情，问他们将来应该做什么，并记住那）。这应该不是很困难，你会从很大一部分用户群中获得很多善意，因为很难有固定的设置适合​​每个使用你的应用程序的人的愿望。如果有疑问，可以选择更多的选项，而不是更少的选项 - 特别是当它们是那种对代码来说相当简单的选项时。