Noamwa做.NET桌面应用开发，只要产品不是只在自己电脑上跑，自动更新就是个绕不开的坎。我维护过好几个客户端项目，最难受的阶段不是写业务功能，而是每次发新版都要在群里喊“请大家手动覆盖安装一下”，然后被各种问题追着跑：有人没权限替换文件，有人旧进程没退出导致安装失败，还有人连不上共享目录。这些事单看都不复杂，但叠加在一两百台机器上，就是场灾难。所以后来我把“自动更新”正式当成一项工程来做，这篇就把我用过的、研究过的几类 .NET 桌面程序更新方案一次性梳理完，并讲清楚每种方案背后的取舍和适用场景。
在聊具体技术之前，先说清楚一个观点：自动更新不仅仅是给程序加一个“下载新版并覆盖”的功能，它实际上是一套“从服务端到客户端”的发布流程。你只有把更新当作一个完整的发布系统来设计，才能避开后面要踩的坑。下面我从为什么手动更新容易出问题讲起，再到现成框架、自研设计、发布灰度，把整条链路走一遍。
1. 手动发安装包的日子，先让我看清了问题出在哪
1.1 三个最典型的翻车现场
先说一个最经典的场景：有用户反馈程序报“找不到 xxx.dll”，我一查，发现他原来的安装目录里根本没有我新版依赖的那个文件。原因很简单，我更新包里的 dll 列表是新的，但用户在共享目录里拖过去覆盖的时候，系统的文件占用、杀毒软件拦截等任何一个环节出问题，都会导致旧文件残留、新文件缺失，最终得到一个“既不是旧版也不是新版”的混合目录。
第二个场景是文件被占用。Windows 下如果一个程序进程还在运行，它的 exe 和 dll 默认会被锁定，普通复制操作直接报“文件正在被另一进程使用”。用户如果开着程序、点完下载后没关主程序，就执行覆盖安装，大概率会失败。
第三个场景和权限有关。如果应用装在 C:\Program Files 目录，普通用户没有写权限。很多内部系统为了图省事，直接让用户右键“管理员身份运行”安装包，UAC 弹窗又是阻碍，稍微不懂电脑的同事就会卡在那里。
这些表面上是操作问题，本质上暴露了一个事实：手动分发模式没有任何“可验证性”和“可靠性”。你无法确认用户最后跑起来的到底是哪个版本的哪个文件。
1.2 自动更新的本质：可靠送达、安全替换、失败恢复
把上面的问题抽象一下，桌面端自动更新要解决的核心问题就三条。
第一，可靠送达。新版文件要从某个服务器或共享源下载到本地，网络中断、下载到一半、源地址变更等情况都要处理好。第二，安全替换。全新版本的文件不能“散装”覆盖旧目录，因为覆盖过程中可能崩溃，一旦中途失败，程序既不是旧版也不是新版，后续再跑就可能报错。第三，失败恢复。更新后如果新版本启动不了，用户不应该被困在一个“死掉的新版本”里，系统要能回滚到旧版本。
理解这三条，很多配置和设计就有了方向。比如选择辅助进程更新而不是在主程序里直接覆盖，是为了“安全替换”；每次下载后做哈希校验，是为了“可靠送达”；保留上一版本的备份，是为了“失败恢复”。
1.3 一次理想更新流程应该长什么样
我后来做更新功能，总会把流程画成一条固定链路：客户端启动或点击“检查更新”时，先向服务器请求更新清单，把自己的当前版本号发过去；服务器返回“有哪些文件需要下载、每个文件的下载地址和哈希值”；客户端下载到临时目录，逐文件校验；校验通过后退出主程序；启动一个独立的更新辅助进程，由辅助进程完成“备份旧版 -> 替换文件 -> 启动新版本”；新版启动成功后反馈结果，启动失败则触发回滚。
这套流程每个环节后面都会展开讲。先记住一个关键点：更新动作最好由“独立的辅助程序”完成，而不是让正在运行的主程序自己覆盖自己的 exe，因为 Windows 对正在运行的文件有独占锁，自己替换自己几乎一定会失败。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 不想从零造轮子，可以先看看这四类现成框架
如果你不是想研究底层原理，而是希望项目尽快用上自动更新，最简单的做法是选一个成熟框架。现在我常用的、实践验证过的主流派别有 ClickOnce、Squirrel.Windows / Clowd.Squirrel、Velopack 和 MSIX 应用打包，各有各的脾气。
2.1 ClickOnce：微软自家老牌方案，适合不太复杂的小工具
很多老 .NET 项目最先接触的就是 ClickOnce。它在 Visual Studio 里直接“发布”就能生成部署包，客户端启动时会检查服务器上的清单文件，如果版本号变更就自动下载并安装。代码里也可以用 ApplicationDeployment 的 API 实现更新检查。
它的优点是接入成本极低，不需要你写服务端接口，不需要自己处理证书签名，微软把整个链路都包了。比较适合内部小工具、低频使用且功能不复杂的桌面程序。但它有比较明显的边界：一是部署路径基本在用户目录下，你没法直接把程序装到 Program Files 那种需要管理员权限的位置；二是很多定制化行为受限，比如自定义更新界面、强制更新到指定版本、处理更新前的数据库脚本等，用 ClickOnce 就很难做得顺手；三是它对 .NET 桌面应用的支持体验在不同框架版本上有差异，老项目还好，新项目要仔细评估。
2.2 Squirrel.Windows 与 Clowd.Squirrel：把更新流程做得像“安装器”一样
Squirrel.Windows 的思路和普通“下载文件覆盖”不同，它把应用打包成一个安装器，安装器能做桌面快捷方式、开机启动项等操作。更新时依靠一个名为 Update.exe 的程序，它会先关掉主进程，再从 NuGet 包或远程源拉取新版本，最后用类似“原子替换”的方式切换目录。
Squirrel 本身已经有一段时间没有大版本维护，社区里后来有 Clowd.Squirrel 这个 fork，修复了不少现代 .NET 支持的问题，也在持续迭代。如果你的项目想省去自己写辅助更新器的麻烦，Squirrel 风格的框架是很好的选择。但要注意，它默认会把应用放到 %LocalAppData%\应用名\ 下，文件路径不是传统的 Program Files，这个细节对内网环境里某些按路径配置白名单的工具可能会有影响。
2.3 Velopack：Squirrel 的现代替代品
Velopack 可以理解成 Squirrel 思路的现代化重做版。它支持 .NET 6+，在 Windows、macOS 和 Linux 上都能用，发布时可生成安装器和更新包，也支持增量更新和安装前/安装后的脚本钩子。对于现在做跨平台 .NET 桌面应用（比如 Avalonia、MAUI 项目）的开发者，Velopack 是比较省心的选择。
它的工作方式对开发者友好：发布时用命令行把应用打包成一个目录，并把版本号写进更新清单；客户端引入 NuGet 包后调用 UpdateManager 即可检查更新。比较遗憾的一点是文档和案例相比老牌框架还偏少，你遇到特别冷门的问题时，可查的资料没有大型框架那么多。
2.4 MSIX：作为官方新势力，适合新项目配合商店分发
MSIX 打包是微软推的现代应用安装格式，它自带更新机制。如果你的应用通过 Microsoft Store 或自己搭建的 App Installer 分发，系统会负责下载和安装新版，而且文件隔离和干净卸载这些都很成熟。
但 MSIX 也有它的“傲慢”：第一，它不是一台老机器上随意跑起来就能更新的方案，对系统版本、打包工具链都有要求；第二，程序运行在虚拟化的应用容器里，部分需要管理员权限或要写安装目录周边内容的原生模块可能不受支持。所以 MSIX 更适合以 Win11/Win10 为目标、走商店场景的新项目。你如果还有一批 Win7 用户，基本可以直接放弃这条路。
可以简单用一张表总结它们的区别。
| 方案 | 是否需要自建更新服务 | 更新时能否处理“主程序运行中”状态 | 适合场景 | 主要限制 |
|---|---|---|---|---|
| ClickOnce | 不需要，能用静态文件服务器 | 由系统接管，总体可靠 | 简单小工具、内部工具 | 定制能力弱，依赖 .NET 部署环境 |
| Squirrel/Clowd.Squirrel | 需要，自己放更新源 | 可以，Update.exe 负责切换 | 常规 Windows 桌面应用 | 老库维护状态需注意，fork 生态更推荐 |
| Velopack | 需要 | 可以，内置更新器进程 | 跨平台、现代 .NET 桌面应用 | 资料较少，要理解发布工具链 |
| MSIX | 需要，或者走商店 | 可以，系统级更新 | 新系统、商店分发 | 老系统兼容性差，个性化受限 |
一句话建议：如果你要处理的生产环境里有大量老系统、内网服务器或自动运维脚本，我更推荐把更新逻辑自己控制起来，或者选 Velopack 这类可以自定义更新源地址的框架。
3. 自己写更新器时，我是怎么处理文件替换和失败恢复的
我一开始也天真地以为“写更新器”就是把服务器上的文件下载到本地然后复制过去。直到测试环境出现“程序崩溃，目录里文件缺了一半”的情况，我才下定决心把更新器做成独立进程，并且把每一次替换都当作一次正式上线来做。
3.1 更新清单不要只存版本号，要带上文件级信息
服务端返回的更新清单，很多初级做法是返回一个 version 就完事，客户端发现版本号不一致后就把整个安装包下载下来解压替换。这没问题，但容易忽略一个问题：你到底改了几个文件？是全量替换还是部分替换？如果下载过程网络中断，残留下一个损坏包，你还需要额外的检查才能发现。
我建议更新清单至少包含版本号、文件下载地址、哈希值、文件大小、最低支持升级的版本和更新说明。一个典型的 JSON 是这样：
json复制{
"version": "2.0.1",
"releaseNotes": "修复打印模块崩溃，优化大文件打开速度",
"minUpgradeableFrom": "1.5.0",
"files": [
{
"path": "MyApp.exe",
"url": "https://download.example.com/updates/2.0.1/MyApp.exe",
"sha256": "9f6d8c7b3e5a0b6fdc0c1d7ab7c8d9e0f1a2b3c4d5e6f708192a3b4c5d6e7f80",
"size": 1843200
},
{
"path": "MyApp.dll",
"url": "https://download.example.com/updates/2.0.1/MyApp.dll",
"sha256": "c3a1b4e7a1f2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8",
"size": 573440
}
]
}
path 字段最好使用相对应用根目录的路径。最好不要写死一个 ZIP 下载地址而不做任何校验，因为服务器上文件损坏或被人篡改时，客户端会把一个坏版本装到用户机器上，那种场景我真实碰到过一次：运维同步更新文件不完整，结果客户端们集体拉到残缺包，当晚客服群就炸了。
3.2 版本比较：网络版 Version 比较不是字符串比较
很多人在判断是否更新时，会把服务器返回的版本号和本地 Application.ProductVersion 直接做字符串比较。字符串比较在“10.0.1”和“9.5.1”这种场景下会错得离谱，因为按字典序 "10" 小于 "9"。正确做法是解析成 Version 类型再比大小：
csharp复制var local = new Version(Application.ProductVersion);
var remote = new Version(updateManifest.Version);
if (remote > local)
{
// 有可用更新
}
对于多数 .NET 桌面应用，四位版本号就够了，Version 类型能直接覆盖主版本、次版本、构建号和修订号。如果将来真要处理复杂前缀或预发布标记，可以再单独设计解析逻辑。
最终比较逻辑建议这样：先确认本地版本不低于 minUpgradeableFrom，再判断远程版本是否大于当前版本。如果本地版本已经低于最低可升级版本，说明用户跳过了过多版本，此时应当提示“只能重新安装完整安装包”，防止跨版本升级时文件缺失。
3.3 目录结构设计：不要把所有文件都映射到当前进程目录
很多人写更新器会在主程序目录里再放一个“Updater.exe”，然后让主程序退出后重新启动它去覆盖文件。但这有个天然问题：如果主程序在 C 盘 Program Files 下，普通用户连更新器都启动不了，又何谈覆盖？
比较好的方式是，用一个位于用户可写目录下的更新器程序来做替换动作。比如把应用装在 %LocalAppData%\Programs\MyApp，更新器放在同层的 MyAppUpdater 目录下，和主程序的应用目录兄弟关系。更新器进程和主进程不是同一个目录，不会相互持有文件锁；它启动后先等待主进程完全退出，再把旧的应用目录重命名为带时间戳的备份目录，接着把下载好的新版本目录改名成正式应用目录。
这里有个很容易忽略的点：整个安装目录被重命名或替换时，主程序自身的可执行文件没有“被部分覆盖”的过程，要么是完整的旧目录，要么是完整的新目录，这能最大程度避免“新老文件混在一起”的脏状态。
3.4 一个完整的更新辅助进程流程
我自己在项目里使用更新器时，整个流程大概是这样的：
- 主程序下载完新版文件到临时目录
%LocalAppData%\MyApp\UpdateCache\2.0.1。 - 主程序校验每个文件哈希，如果校验失败就清理临时目录并下载成功后退回一次，仍然失败就跳过本次更新。
- 主程序启动
MyAppUpdater.exe，传入三个参数：当前应用目录、新版本文件目录、备份目录路径。 - 更新器等待主程序进程退出。
- 更新器把当前应用目录重命名为
MyApp_backup_20250318_102030。 - 更新器把新版本文件目录重命名为正式应用目录。
- 更新器从正式应用目录启动主程序，并传入一个类似
--upgrade-from-backup的参数。 - 主程序启动后向更新器进程发送一个“启动成功”的命名管道或文件标记；如果在一定时间内没收到标记，更新器把正式目录删除，把备份目录改回来，再启动旧版。
如果你是在 .NET 里直接调辅助更新器，类似这样：
csharp复制var psi = new ProcessStartInfo
{
FileName = Path.Combine(updaterDir, "MyAppUpdater.exe"),
WorkingDirectory = updaterDir,
UseShellExecute = false
};
psi.ArgumentList.Add(targetAppDir);
psi.ArgumentList.Add(downloadedDir);
psi.ArgumentList.Add(backupDir);
Process.Start(psi);
核心思路是“先整体切目录，再启动验证”。这比把文件一个个覆盖进旧目录要安全得多，从物理上避免了旧 exe 和新 dll 混用的问题。
4. 更新器上线后，签名、权限和杀毒软件全是隐形坑
很多项目做完更新器，测试机一切正常，发到真实用户那里就开始出幺蛾子。我总结下来，绝大部分问题集中在代码签名、权限配置和杀毒软件拦截这三个领域。
4.1 没有代码签名，更新包很可能过不了 SmartScreen
Windows 对从网络下载的程序默认会叠加 Mark of the Web 标记，再从非商店渠道执行 exe 时经常弹出 SmartScreen 蓝色警告。如果你的更新器没有代码签名，用户第一次运行就会被警告吓住，甚至被杀毒软件直接隔离。
正规的桌面软件项目，最好在发布主程序和更新器时都签上 Authenticode 数字证书。购买商业证书虽然要花钱，但这对企业用户尤其重要，因为很多安全策略软件只信任有签名的可执行文件。如果你在一个域环境中，也可以给内部分发根证书，但要维护好证书信任链，否则比不签还麻烦。
4.2 Program Files 和用户目录，决定了更新器要不要提权
Windows 下，应用装在 C:\Program Files\ 时，普通用户没有写入权限，更新器想复制文件进去就必须要提升到管理员权限。提权不是不可以，但会在用户侧弹 UAC 框，很多内部软件的使用者根本不敢点“是”，UAC 是企业软件交付中非常大的隐形摩擦成本。
这也是 Squirrel、Velopack 等框架默认把应用安装到 %LocalAppData%\Programs\ 的原因之一。用户目录下的文件操作不需要提权，更新器和主程序都运行在普通用户权限下，更新过程的连续性和可靠性会高很多。如果你还在用 C:\Program Files 作为安装目录，建议考虑迁移到用户级安装目录；如果产品必须装到 Program Files（比如有驱动或服务组件），那更新器就必须包含服务提权逻辑，并在更新前主动提示用户确认 UAC。
4.3 杀毒软件误报和“文件名后缀”陷阱
实际上传更新包和更新器上线后，最容易冤枉人的是杀毒软件的实时监控。一个非常常见的情况是：更新器每次编译生成的最终 exe 哈希都不一样，杀毒软件报毒不一定是因为真的毒，而是你的程序行为（退出主进程、覆盖系统目录文件、解密下载的包等）太像恶意软件了。
降低误报的办法有几个：一是给更新器固定签名，让可信发布者一致；二是不要给更新的临时文件起像 payload.exe 或 update.tmp 这种可疑名字，实际部署时用带版本号的目录名；三是在正式发布前把样本提交给主流杀毒厂商的白名单流程。杀毒软件决策普遍会参考“文件信誉”，新编译出的文件信誉低，容易报警，但同一个带签名的版本持续分发一段时间后，误报率会明显下降。
4.4 把更新日志留好，排查问题就成功了一半
这句话可能不够“技术范”，但每次线上出问题时，帮我最快定位原因的永远是客户端日志。更新器日志至少要记录：本地版本号、目标版本号、下载清单的获取时间、每个文件下载的字节数、哈希校验结果、备份目录路径、替换操作开始/结束时间、新程序启动标识、最终成功或失败状态。
日志路径建议独立出来，比如 %LocalAppData%\MyApp\Logs\UpdaterLog-20250318.log。不要只写到安装目录下，一方面安装目录用户可能没有写权限，另一方面新版替换时旧日志容易被顺带清除，导致失败后什么都查不到。
5. 更新推送不是“有新版就全量发”，灰度与回滚必须提前设计
我刚开始推更新时，只要本地测试过了就直接把版本放给所有用户，结果经常是“小范围完美，全量后出事故”。后来才意识到服务器端太简单了，缺少灰度开关和强制版本判断的字段。
5.1 用服务器清单控制灰度范围
更新接口不要只返回“最新版本号和一个下载地址”，最好让它能判断哪些客户端可以被升级。更有效的方法是：更新清单里带一个 applicableVersionRanges 或白名单列表，服务器发布新版时只将少数机器码或渠道号加进“可更新白名单”。
例如我可以按“用户 ID 后三位 % 100”来做灰度的档位，然后服务端下发包含 allowUpdate: true/false 的响应。初期让 5% 的用户可以看到更新，跑几天没问题后，再把 allowUpdate 的比例调到更大的范围。客户端的下载链接仍然都是同一个，但是否提示升级交给服务端控制。
这里要特别注意：灰度不单是“是否提示”的区别，还应当配合日志统计“更新成功率”。如果某个版本在灰度阶段更新成功率就异常低，说明替换流程或文件依赖可能有问题，在全量发布前需要先揪出来。
5.2 强制更新、可选更新和“跳过这次”怎么共存
更新界面至少有两个模式：可选更新，用户点“稍后”之后还能继续用旧版本；强制更新，程序必须升上去，否则不让继续用。
要做到强制更新，需要在更新清单里返回 minimumAllowedVersion。比如当前最新版本是 3.0.0，但服务端认为低于 2.5.0 的版本不允许继续连接服务器，因为旧版本有严重安全漏洞或数据兼容性风险。客户端收到后，如果本地版本低于 2.5.0，界面就不显示“跳过”按钮，只能点击更新。这里的判定逻辑建议放到服务端配置里，而不是写死在客户端代码里，这样出现问题后不用发新版去调整。
很多桌面应用没有处理“跨大版本”场景。比如用户用着 1.0.0，但当前已是 3.0.0，如果你只让它往 3.0.0 升，可能因为数据库结构差异或配置文件格式差异导致升级失败。处理手段是服务端维护“可升级的路径”：确实不能直接跨版本时，可以先让客户端升到 2.5.0，再升到 3.0.0，或者直接引导用户下载完整安装包重新安装。路径表这东西虽然丑，但在真实运维中非常实用。
5.3 大规模故障时的回滚开关
每个推版本的人最怕的事就是“全量后三分钟，客服已经开始收到报错截图”。实际上只要客户端更新流程里有备份目录，回滚是可能的。你需要在服务器侧准备一个“回滚发布”的开关：把服务端最新版本重新指向上一个稳定版本，这样还没更新的用户会继续停留在稳定版；已经更新到新版的用户，则要有一个“检测到本地版本高于远程最新可接受版本”的逻辑，参照备份目录回滚。如果旧版本对数据库的兼容性保持正常，这条路径是可行的。
回滚最容易出的问题是数据文件降级：新版改了本地的 Settings.xml 或 SQLite 数据库，老版本再启动时可能读不了新格式。因此“自动回滚”不能无脑执行，至少应保留一份“旧版是否兼容当前数据文件”的判断标记。真遇到数据格式不兼容，只能走客服辅助流程或数据导出修复，回滚开关解决不了所有问题。
6. 不同团队怎么选型，我自己最终的实践组合是什么
经过这些尝试，我对自动更新框架选型有了比较明确的判断。如果你是个人开发者或团队较小，工具也只是内部几十人用，建议先用 ClickOnce 或 Velopack 跑通，没必要一上来就写辅助更新器。如果你们像我们一样，需要管理大量内部员工电脑，且允许使用域名和证书，那我更推荐自研一个“更新接口 + 更新辅助进程”的基础设施，因为这种环境下你经常要实现内网源、指定渠道、定时更新、阻止旧版本访问服务器等定制逻辑，现成框架不一定都方便适配。
我自己现在最常用的组合是：安装目录放用户目录下，使用 Velopack 打安装包和更新包，服务器端保存每个版本的版本清单和全量文件。辅以自己写的一个四五百行的更新检查模块来控制灰度比例。这样既有框架处理安装、替换等脏活，又有服务端自定义策略的能力。
最后特别提醒几个看起来很小但经常救命的细节：
第一，不要假定所有用户都会点击“检查更新”。主程序启动后建议静默检查一次更新，发现新版本后在右下角弹一个可关闭的提示，不要强制打断用户操作。
第二，更新包的下载请求一定要加超时和重试。某些内网环境下载一个 200MB 的包，网络抖动会导致整次更新失败；下载模块至少要有断点续传或失败重试机制，并且在下载过程中随时可以暂停。
第三，不要在安装目录里存放用户产生的数据。用户文档、配置文件、数据库等应统一放 %AppData% 或专门的文档目录，否则版本替换时你就会很纠结：到底保留哪些文件？保留目录会导致新老数据混在一起，删除目录又会导致用户数据丢失。
第四，更新器本身要尽量减少“需要它自己更新”的频率。如果更新器代码也要频繁改，那每次更新器自身变化都会带来新的信任问题，一旦更新器启动失败，客户端彻底失去远程升级能力。所以更新器逻辑要写得保守，接口稳定，文件依赖少。
我在实际项目中踩过的最深的一个坑：更新流程本身没问题，但因为主程序没有在更新前通知用户保存正在编辑的数据，强制重启时把用户的未保存内容给丢了，结果投诉比更新故障还多。更新即将发生前一定要先广播事件让业务层执行善后处理，必要时给用户一个“延迟5分钟重启”的选项。自动更新说到底不只是文件替换，还包括对用户工作状态的尊重。