15

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

我知道这个问题可能被认为是主观的，但我不是在寻找个人意见，而是在寻找有原因的事实（例如过去的经验），甚至是指向描述最佳实践的博客/wiki 的单个链接（这是我更愿意说实话）。我不想要的是如何使这项工作，我知道如何创建一个自我更新的桌面应用程序。

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

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

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

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

4

5 回答 5

7

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

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

这是无稽之谈。只需在最后进行更新。

于 2010-11-25T08:54:13.883 回答
6

很难给出一个普遍的答案。这取决于上下文：更新的重要性、它是什么类型的应用程序、用户偏好、#users、网络宽度等。这里是一些选项/权衡。

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

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

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

    如果更新对用户来说是透明的，不需要立即重新启动应用程序，那么我建议您在通信带宽允许的情况下尽可能频繁地进行更新（考虑到更新检查频繁但很小 - 以及下载- 不常见但很大）

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

    取决于用户的偏好，也取决于更新的类型：错误修复与功能/UI 更改（用户会困惑地看到外观发生了变化而没有先前的警报）

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

    与上一个问题相同的论点

  • 您应该尝试修补应用程序还是从 Macintosh 风格重新下载整个应用程序？

    如果应用程序很小，请从头开始下载。这将防止为不同补丁之间的不匹配而创建的各种奇怪的错误（“DLL 地狱”）。但是，这可能需要较长的下载时间或对您的网络造成严重影响。

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

    我认为两者

于 2009-12-16T06:42:40.350 回答
2

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

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

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

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

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

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

还有两件事：

  • 即使我不使用您的应用程序，也不要将更新引擎实现为在后台持续运行的进程。我的电脑已经有大约 10 个这样的进程占用资源，这很烦人。
  • 在更新更新引擎本身时，一方面您需要让引擎运行以显示安装进度 UI，但另一方面必须关闭更新过程以避免因 exe 文件被锁定而导致的重新启动。有很多事情，例如从 %TEMP% 运行帮助程序、使用 Windows Installer 重新启动管理器、在启动安装包之前重命名更新程序 exe 文件等。在设计更新引擎时请记住这一点。

    • 于 2009-12-16T08:53:38.493 回答
    1
    • 如果客户端软件已过期，但在尝试与其他版本的软件或数据库本身通信时不会中断，您是否会强制更新？如果是这样，您如何表示这种重大变化？

    询问用户。

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

    询问用户。

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

    询问用户。

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

    询问用户（注意这里的趋势？）。

    • 您应该尝试修补应用程序还是从 Macintosh 风格重新下载整个应用程序？

    通常，如果应用程序具有任何显着大小，则打补丁。

    就“询问用户”的响应而言，这并不意味着每次都提示他们。取而代之的是，让他们选择设置应该提示他们什么以及应该在不可见的情况下完成什么（并且第一次发生给定的事情时，询问他们将来应该做什么，并记住这一点）。这应该不是很困难，并且您从大部分用户群中获得了很多好感，因为很难有固定的设置适合​​使用您的应用程序的每个人的愿望。当有疑问时，更多的选项总比更少的好——尤其是当它们是那种对代码来说相当简单的选项时。

    于 2009-12-16T06:25:16.250 回答