更新紀錄(僅初版,2026年03月20日 發布)
- 初次發布
引用本文(DOI: 10.5281/zenodo.21616340)
本文保存於 Zenodo。以下同時提供一律指向最新版本的 DOI，以及固定於您正在閱讀版本的 DOI。
小村 豪(2026)。〈Windows 應用發布方式怎麼選 - MSI / MSIX / ClickOnce / xcopy / 自訂 updater 的判斷表〉。小村軟體有限公司。https://doi.org/10.5281/zenodo.21616340 https://staging.comcomponent.com/zh-TW/blog/2026/03/20/000-windows-app-deployment-msi-msix-clickonce-xcopy-custom-updater/
- DOI(最新版本)
- 10.5281/zenodo.21616340
- DOI(此版本)
- 10.5281/zenodo.21616341
選 Windows 應用的發布方式時，話題常常從「哪一個比較新」「哪一個比較簡單」開始。
但真正在實務上起作用的，是另一套軸線。
- 想以使用者為單位安裝，還是以整台機器為單位安裝
- 更新要不要交給發布平台，還是自己掌握
- 是否涉及服務／驅動／shell extension／COM 註冊這類 OS 整合
- 是否需要撐得住封閉網路／離線／USB 發布
- 要不要 package identity，或想以純 Win32 不受限（unrestricted）的方式跑
發布方式的選擇，不是 installer 格式的偏好，而是 要動到 OS 多深 與 更新責任由誰扛 的選擇。
1. 先下結論
用比較粗、但實務好用的說法：
- 要裝到整台機器、有服務或 COM 註冊、有前置相依要裝：從 MSI 起算
- 以 Windows 10/11 為前提、需要 clean install / clean uninstall、更新頻繁、想要 package identity：MSIX 有力
- 想把 .NET 公司內部桌面應用以使用者單位輕鬆派發並自動更新：ClickOnce 至今仍相當強
- 優先「放著就能跑的工具、封閉網路、USB 發布、不需系統管理員權限」：xcopy 最直接
- 想自己掌握更新 UX、頻道、分段發布、telemetry、復原策略：自訂 updater
- 需要驅動：一開始不要以 MSIX 為中心比較安全
- 需要 Explorer 的 in-process shell extension：MSIX 不適合
總之，大致如下：
- 向 OS 註冊很濃 → 偏向 MSI
- 想拿到 package identity 與 modern packaging → MSIX
- 想要 per-user 的簡易發布與內建更新 → ClickOnce
- 「放著就能跑」是第一優先 → xcopy
- 有決心自己設計並營運更新平台 → 自訂 updater
2. 這 5 個不在同一個擂台上
這點很重要。
MSI / MSIX / ClickOnce / xcopy 主要談的是 怎麼裝。
自訂 updater 主要談的是 更新責任由誰扛。
所以實務上把這件事拆成兩層會比較好整理。
| 層 | 主要候選 | 要決定什麼 |
|---|---|---|
| 初次導入 | MSI / MSIX / ClickOnce / xcopy | 放到哪、要註冊什麼、權限、解除安裝 |
| 持續更新 | MSIX App Installer / ClickOnce / 手動替換 / 自訂 updater | 更新確認、發布來源、簽章驗證、rollback、頻道、UI |
所以 自訂 updater 不是第一個選項，而是現有發布方式滿足不了更新需求時再追加的選項，這樣比較穩。
3. 一張判斷表
先放最實用的判斷表。
| 情境 | 優先選 | 理由 |
|---|---|---|
| 全使用者導入，有服務、COM 註冊、machine-wide 設定 | MSI | 上 Windows Installer 的擂台比較少出事 |
| 以 Windows 10/11 為前提，要 clean install / uninstall、更新頻繁、要 package identity | MSIX | 容易靠進 modern packaging 與 update 模型 |
| 想把 .NET 公司內部業務應用以 per-user 輕鬆派發 | ClickOnce | 內建的更新模型好用 |
| 放著就能跑的工具、封閉網路、USB、不需系統管理員 | xcopy | 盡量不引入 install 的觀念 |
| 商用產品，想自己掌握更新 UX 與頻道 | 自訂 updater | 比內建更新自由度高 |
| 需要驅動 | 偏 MSI 或專用 installer | driver package 另一回事，MSIX 不合適 |
| 需要 in-process shell extension | 偏 MSI 或專用 installer | shell extension 與 MSIX 相性不佳 |
這張表最重要的一點是：「有更新需求」這一條單獨不足以跳到自訂 updater。
4. 觀點別比較
| 觀點 | MSI | MSIX | ClickOnce | xcopy | 自訂 updater |
|---|---|---|---|---|---|
| per-user 導入容易度 | ○ | ○ | ◎ | ◎ | ○ |
| per-machine 導入容易度 | ◎ | ○ | △ | × | ○ |
| 內建更新 | △ | ◎ | ◎ | × | ◎ |
| package identity | × | ◎ | × | × | × |
| 與服務的相性 | ◎ | △ | × | × | ○ |
| 與驅動的相性 | △ | × | × | × | ○ |
| 與 shell extension 的相性 | ◎ | × | × | × | ○ |
| 封閉網路／離線發布 | ◎ | ○ | ○ | ◎ | ◎ |
| 實作／營運成本 | ○ | ○ | ◎ | ◎ | × |
| 更新 UX 自由度 | △ | ○ | △ | × | ◎ |
看這張表時要問的不是 哪個最強，而是 哪個摩擦最少。
5. 各自適合什麼樣的案子
5.1 MSI
MSI 是 要把 Windows 傳統桌面應用端端正正地做 install / uninstall / repair 時的基準點。
特別適合：
- 全使用者導入的業務應用
- 含 Windows 服務的應用
- 涉及 COM 註冊、file association、machine-wide 設定的應用
- 已有 installer 營運經驗的產品
MSI 的強項在於 能用 Windows 的慣例表達「這個應用怎麼裝到 OS」。
弱點也清楚：
- authoring 其實不好寫
- upgrade／patch 設計粗糙就後患無窮
- custom action 越多越容易壞
- 對高頻更新的產品，更新 UX 容易偏重
5.2 MSIX
MSIX 是 想取得 modern packaging 與 clean update／uninstall 的選擇。想用到需要 package identity 的 Windows 功能時，意義更大。
特別適合：
- 可以以 Windows 10/11 為前提的桌面應用
- 更新頻率偏高的業務應用
- 想用到 package identity 相關 Windows 功能的應用
- 偏向 Intune 或 App Installer 的案子
MSIX 的強項在於 更新與解除安裝的乾淨。
但不是什麼都能裝，下面這些要先確認：
- in-process shell extension
- driver
- 需要 unrestricted 的舊式 Win32 前提
- 不想背負 package identity 的結構
5.3 ClickOnce
ClickOnce 在 想以 per-user、快速、含更新的方式派發 .NET 公司內部桌面應用 上至今仍相當強。
適合：
- 公司內部業務應用
- 以標準使用者權限導入
- 以使用者為單位派發就足夠
- 更新 UX 不需要做得很精緻
相對地，若產品需要深入 OS，或期待 installer 來綁多個前置相依，就不適合。
5.4 xcopy
xcopy 是 deploy 而不是 install。沒有登錄註冊、沒有修復功能、沒有 package identity。但若「放著就能跑」，它幾乎是最簡單的。
特別適合：
- 診斷工具
- 設備設定工具
- 日誌收集工具
- 以 USB 送到現場的小工具
- 想讓多版本 side-by-side 共存的情境
xcopy 的強項是 失敗模式清楚。整個資料夾替換，要退回就退回舊版本，營運上很好管理。
當然下面這些會弱：
- Start menu／ARP／repair
- file association／service／shell extension／driver
- 內建更新
5.5 自訂 updater
自訂 updater 比起 選擇自由度，更像是 選擇責任。
適合：
- 更新頻率高
- 想要 stable／beta／preview 等頻道
- 想控制分段發布或 rollout 百分比
- 想精細控制背景下載、通知、維護時段
- 想自己掌握更新 telemetry 或 crash recovery
強項大，但要付的代價也大：
- 簽章驗證
- 發布 manifest
- retry／resume
- proxy／firewall／封閉網路對應
- rollback
- 壞掉的更新的復原
- updater 本身的更新
也就是 不是自由度變大，而是責任變重。
6. 容易糾結的幾個重點
6.1 是否需要 package identity
若你要用的是以 package identity 為前提的 Windows 功能，MSIX 的價值就一口氣上來。
反之：
- 想要不受限的 file system access
- 想要不受限的 registry access
- 想保留 elevation／process model 的自由
- 想留住原本的舊式 Win32 假設
這種情況下偏 unpackaged 的方式才自然。
6.2 是否涉及服務／驅動／shell extension
這三個會大幅拉高發布方式的複雜度。
- driver：MSIX 不合
- in-process shell extension：MSIX 不合
- Windows 服務：MSI 很自然；MSIX 有條件納入比較
與 OS 深度耦合的要素越多，主題越不是「外觀簡單的發布」，而是 能否正確地導入、更新、移除。
6.3 per-user 還是 per-machine
這一點模糊往前推，之後一定會吵：
- 偏 per-user
- ClickOnce
- xcopy
- 部分的 MSIX
- 偏 per-machine
- MSI
- 條件合的話 MSIX
「想不需要系統管理員權限安裝」和「全使用者都從同一個位置使用」不是同一件事。
6.4 更新頻率與營運責任
依更新頻率的感覺大致是：
- 每季到每月更新：MSI 就足以應付
- 每月到每週更新：MSIX／ClickOnce 會輕鬆許多
- 每週到每日更新：自訂 updater 開始有檢討的理由
- 手動更新即可／由部署端控制：xcopy 也行
發布方式既是 技術選型，也是 營運設計。
6.5 封閉網路／離線發布
在封閉網路裡，簡單 常常勝過漂亮的自動更新：
- xcopy 很強
- MSI 也很強
- ClickOnce 可以走 file share 或 removable media
- MSIX 只要 App Installer 用法對，也能跑
但在封閉網路裡要頻繁更新，就得決定「誰、把新版放到哪、舊版怎麼處理」，光選方式不決定營運，很快就會壞掉。
7. 猶豫時最後看的 6 個問題
- 這個應用 current user 就夠，還是要 machine-wide 安裝
- 有沒有 service／driver／shell extension／COM 註冊
- 是否會用到需要 package identity 的 Windows 功能
- 是否只以標準使用者權限導入
- 更新頻率是每月、每週，還是更高
- 目標環境是不是封閉網路、OS 版本是否齊一
這 6 題回答完，大致會落到：
- 2 為「是」 → 先從 MSI 側看
- 3 為「是」 → 優先看 MSIX
- 1 是 current user，4 為「是」，且是 .NET desktop app → ClickOnce 很有力
- 4 為「是」，2 為「否」，且營運允許放著就好 → xcopy 很有力
- 5 很高，且把更新 UX 視為產品價值 → 把自訂 updater 納入比較
8. 總結
Windows 應用發布方式大致可以收斂成一句話：
初次導入怎麼成立，和
持續更新由誰扛，這兩件事要分開決定。
在此之上，粗略的實務判斷是：
- MSI：深入 OS 的傳統 desktop app
- MSIX：想拿 package identity 與 modern packaging／update 的 app
- ClickOnce：per-user 的 .NET 業務應用，想輕鬆派發與更新
- xcopy：放著就好、自成一體的工具
- 自訂 updater：有覺悟要自己設計並營運更新這件事的產品
最重要的是：
- 有 driver／shell extension／service 時，發布方式的選擇不是最後的外觀，而是從 OS 整合方式決定
- 需要 package identity 時，MSIX 的意義就大
- 自訂 updater 是壓箱底的選項，不是第一選項
- 在 封閉網路，簡單往往比聰明更重要
若還在猶豫，先把 per-user 或 per-machine、要向 OS 註冊什麼、更新頻率多高 這三件事固定下來，討論就能明顯往前推進。
9. 參考資料
- Microsoft Learn, Windows Installer
- Microsoft Learn, What is MSIX?
- Microsoft Learn, Packaging overview for Windows apps
- Microsoft Learn, MSIX features and supported platforms
- Microsoft Learn, App Installer file overview
- Microsoft Learn, Prepare to package a desktop application
- Microsoft Learn, Know your installer
- Microsoft Learn, Convert an installer that includes services
- Microsoft Learn, ClickOnce deployment and security
- Microsoft Learn, Manage updates for a ClickOnce application
- Microsoft Learn, Choosing a ClickOnce deployment strategy
- Microsoft Learn, ClickOnce cache overview
- Microsoft Learn, Windows App SDK deployment guide for self-contained apps
相關文章
共用相同標籤的最新文章。能以相近的主題延伸理解。
Windows 為什麼會出現「Windows 已保護您的電腦」
從程式碼簽章、EV/OV 憑證、Azure Artifact Signing、MSIX、Microsoft Store、ClickOnce、內部發佈到 App Control，以實務角度整理 Windows 應用程式發佈時出現 SmartScreen 警告的原因。
自動更新功能的安全性基本 - 糟糕的模式與最佳實踐
把自動更新當成信任的發佈而非檔案傳輸來重新整理，從只靠 HTTPS 不夠的理由、signed metadata 與用戶端驗證、簽章金鑰的運營分離、staging 與 fail-closed、rollback 與 freeze 的對策，到 Windows 上 MSIX 與 C...
委外・委託開發 Windows 應用程式前該整理的事項
在委外・委託開發 Windows 應用程式之前，整理既有軟體改版、設備整合、COM/ActiveX、發布與更新、維護等應留意的重點。
ClickOnce 是什麼 - 以實務視角整理機制、更新、適合場面・不適合場面
本文以實務視角整理 ClickOnce 是什麼，從 manifest、快取、更新、簽章的構造，到適合公司內部 .NET 桌面業務應用程式的案件與不適合 machine-wide 或 service、driver 等深度 OS 整合的案件，幫助讀者判斷是否採用並掌握 depl...
Windows 什麼時候需要系統管理員權限 - UAC、保護區、設計上的分辨方式
從邊界與儲存位置的角度，整理 Windows 何時真正需要系統管理員權限：UAC、保護區、HKLM、服務、驅動、防火牆。同時說明 per-user 與 per-machine 的差異，以及把管理員處理切成獨立 EXE、服務或工作的設計取捨，幫讀者判斷該不該提權。
相關主題
與本文相近的主題頁面。以本文為起點，可進一步連到相關服務與其他文章。
Windows 技術主題
彙整 KomuraSoft LLC 關於 Windows 開發、故障調查與既有資產活用文章的主題中心。
與本主題相關的服務
本文連結到以下服務頁面，歡迎從最接近的入口查看。
Windows 應用程式開發
支援包含常駐處理、設備連動、運作日誌與可維護結構的 Windows 桌面應用程式。
Windows 軟體維護 & 現代化
支援既有 Windows 軟體的階段性升級、功能追加、64 位元就緒以及可維護性的重構。
常見問題
整理諮詢這個主題時常見的問題。
- MSI、MSIX、ClickOnce、xcopy 該怎麼選？
- 選擇的軸線不是哪個比較新，而是與 OS 的耦合深度和更新責任由誰扛。要裝到整台機器、有服務或 COM 註冊、有前置相依要裝就從 MSI 起算；以 Windows 10/11 為前提、需要 clean install/uninstall、更新頻繁、想要 package identity 就看 MSIX；想把 .NET 公司內部桌面應用以使用者單位輕鬆派發並自動更新則 ClickOnce 至今仍相當強；「放著就能跑、封閉網路、USB 發布、不需系統管理員權限」是第一優先就選 xcopy。
- 什麼時候該考慮自訂 updater？
- 自訂 updater 不是第一選項，而是現有發布方式滿足不了更新需求時再追加的選項。適合更新頻率高、想要 stable/beta/preview 等頻道、想控制分段發布或 rollout 百分比、想掌握更新 telemetry 的商用產品。代價是簽章驗證、發布 manifest、retry/resume、rollback、updater 本身的更新都要自己扛，不是自由度變大，而是責任變重。
- 有 Windows 服務或驅動的應用該用哪種方式發布？
- 需要驅動時，一開始不要以 MSIX 為中心比較安全，driver package 是另一回事，偏向 MSI 或專用 installer。需要 Explorer 的 in-process shell extension 時 MSIX 也不適合。含 Windows 服務的應用用 MSI 很自然，MSIX 則要有條件納入比較。與 OS 深度耦合的要素越多，主題越不是外觀簡單的發布，而是能否正確地導入、更新、移除。
- 封閉網路或離線環境的發布該注意什麼？
- 在封閉網路裡，簡單常常勝過漂亮的自動更新：xcopy 很強、MSI 也很強，ClickOnce 可以走 file share 或 removable media，MSIX 只要 App Installer 用法對也能跑。但要在封閉網路頻繁更新，就得先決定誰、把新版放到哪、舊版怎麼處理，光選發布方式而不決定營運，很快就會壞掉。