沒有原始碼也可以諮詢嗎？

可以諮詢。不過，在沒有原始碼的情況下，能做的事情會受到限制。有時可以從設定、環境、日誌、外部相依、執行檔、安裝程式、通訊內容等線索進行調查。另一方面，功能新增或根本性的修正通常需要原始碼，因此從現狀調查開始比較實際。

包含舊版 VB6、VBA、COM、ActiveX 的應用程式也可以諮詢嗎？

可以諮詢。在這個領域，與其硬把全部一次性替換掉，不如把要保留的部分、要包裝的部分、要替換的部分分開來思考，這點很重要。尤其是業務上仍在運作的資產，一邊評估風險一邊分階段遷移會比較安全。

應該把 Windows 應用程式換成 Web 應用程式嗎？

要看目的。Web 應用程式適合多據點、簡化終端管理、以瀏覽器使用等場景。另一方面，如果有設備整合、本機檔案處理、離線運作、使用既有 DLL 等需求，保留 Windows 應用程式反而比較自然。不一定要把所有東西都 Web 化，把 Windows 端與 Web 端的職責分開設計，也是一種選項。

只委託故障調查也可以嗎？

可以。長時間運作後發生的當機、通訊中斷、記憶體持續增加、只在特定 PC 上出現的故障等問題，與其立刻著手修改，更重要的是先建立能夠追蹤原因的狀態。先整備日誌與傾印檔，縮小重現條件範圍後，再決定修正方針。

需要系統管理員權限的應用程式也可以開發嗎？

可以開發，但一直以系統管理員權限運作的設計，應該謹慎考慮。日常使用的部分以標準使用者權限運作，只把需要的處理獨立出來，會比較安全。安裝、服務註冊、寫入受保護區域、驅動程式、全使用者設定等，會在一開始就先整理好權限設計。

公司內部使用的小型 Windows 應用程式也可以委託開發嗎？

可以。即使是小型應用程式，只要事先考慮到發布、更新、日誌、設定、備份、負責人交接等事項，就能用得更長久、更順手。尤其是像 Excel 作業自動化、CSV 轉換、檔案監控、報表輸出、設備資料收集這類小型業務改善，有時 Windows 應用程式反而更合適。

Windows 應用程式開發委外前的檢查清單

在考慮委外・委託開發 Windows 應用程式時，最先該決定的並不只是「該用什麼技術來開發」。

在實務上，常常會遇到下列這類諮詢。

想改版舊版的 Windows 軟體
無法接手前任負責人做的公司內部應用程式
與設備或量測儀器之間的通訊偶爾會中斷
涉及 32bit / 64bit、COM / ActiveX、VBA 整合
換到 Windows 11 或新電腦後就不能動了
想連同發布、程式碼簽章、自動更新、SmartScreen 警告一起整理
想調查長時間運作後發生的當機或記憶體持續增加問題

也就是說，Windows 應用程式的委外・委託開發並不只是「重新畫一個畫面」的工作。 需要當作一件涵蓋既有資產調查、改版、重建、設備整合、發布、維護、故障調查的工作來思考。

本文將以委託方的視角，整理在委託開發 Windows 應用程式之前該事先掌握的重點。

Windows 應用程式委外・委託開發中常見的諮詢領域

1. 全新業務應用程式開發

將支撐公司內部業務的輸入畫面、搜尋畫面、報表輸出、CSV 整合、檔案整合、外部系統整合等做成 Windows 應用程式的案例。

不選 Web 應用程式而選擇 Windows 應用程式的理由，大致有以下幾點。

想細緻地處理本機電腦上的檔案或資料夾
想與 USB 裝置、量測儀器、PLC、相機等整合
想在離線環境或封閉網路中使用
想活用既有的 Excel、VBA、COM、DLL 資產
想在現場終端上使用鍵盤、條碼讀取器、觸控面板等
需要常駐監控或背景處理

即使是全新開發，只要一開始就先決定好「是否該做成 Windows 應用程式」「Web 應用程式是否也可行」「是否只把一部分留在 Windows 端」，之後需要返工的情況就會減少。

2. 既有 Windows 軟體的改版・維護

委外・委託開發的諮詢中，比起完全全新開發，更常見的是既有軟體的改版・維護。

例如下列這類狀況。

有原始碼，但不知道如何建置
只能用舊版本的 Visual Studio 開啟
停留在 VB6、MFC、WinForms、.NET Framework 的狀態
負責人已離職，沒有人了解規格
因 Windows 更新或電腦更換而導致運作不穩定
客戶或現場要求新增功能

在這種情況下，與其立刻重新開發，更應該先盤點現狀。

支撐的是什麼業務
哪些功能是必要的
在什麼環境下運作
依賴哪些外部設備・DLL・資料庫・共用資料夾
是否留有日誌或錯誤資訊
是否留有原始碼、建置步驟、安裝程式、設定檔

既有軟體本身「還能運作」這件事就是一種價值。
正因如此，委託開發不只是「全部丟掉重新開發」，保留・包裝・替換這種分階段的思考方式非常重要。

如果涉及 COM / ActiveX / OCX，可以先透過 COM/ActiveX/OCX 差異完整解說掌握用語，再用 ActiveX/OCX 保留・包裝・替換判斷表這類觀點來思考遷移方針，會更容易推進。

3. 設備整合・外部設備整合應用程式

在製造業、檢驗、量測、醫療周邊、研究用途等領域，Windows 應用程式有時會與外部設備連接。

代表性的整合對象如下。

序列通訊裝置
USB 裝置
工業用相機
PLC
量測儀器
條碼讀取器
共用資料夾或 NAS
既有的原生 DLL
廠商提供的 SDK

在這個領域，不只是要做出畫面，還必須設計通訊中斷的方式、重新連線、逾時、日誌、原始資料儲存、狀態顯示等。

尤其序列通訊在接收單位、逾時、重新連線、UI 凍結等方面容易出問題，因此從一開始就掌握序列通訊應用程式開發的陷阱這類觀點會比較安全。

此外，外部設備的狀態有時光靠「已連線」「未連線」並不足夠。
把設備的存在、回應、功能就緒、資料新鮮度、組態一致性等分開思考，就能做出在現場不容易被誤解的畫面。詳細內容可參考外部設備狀態顯示設計。

4. 故障調查・原因分析

在 Windows 應用程式的委託開發中，有時需要先進行故障調查，而不是先新增功能。

常見的諮詢如下。

一天只會當機幾次
長時間運作後記憶體持續增加
只有特定的電腦不能動
與設備的通訊會中斷幾秒鐘
檔案整合時會發生漏收
不知道重現步驟
日誌太少，無法追蹤原因

這類問題光靠瀏覽程式碼是無法解決的。
必須先設計觀測點，收集日誌、當機傾印檔、通訊日誌、事件日誌、記憶體使用量、控制代碼數等資訊。

在當機調查方面，Windows 應用程式當機時的日誌輸出方法與當機傾印檔收集入門〖WER/ProcDump/WinDbg〗這類方法，關鍵在於如何保留當機瞬間的證據。

在記憶體持續增加的問題上，需要區分究竟只是單純等待 GC，還是真正的記憶體洩漏。
對於 .NET 應用程式，可以參考在 .NET 中區分 GC 等待與記憶體洩漏，依照觀察、比較、證明的步驟來進行。

5. 發布・簽章・自動更新

Windows 應用程式完成之後，常常會卡在「該如何發布」這個問題上。

是否要做安裝程式
是否放著就能直接執行
標準使用者是否能安裝
是否需要系統管理員權限
是否透過公司內部檔案共用來發布
是否要讓使用者從網路下載
是否要自動更新
該如何處理程式碼簽章憑證
該如何說明並應對 SmartScreen 警告

發布方式包含 MSI、MSIX、ClickOnce、xcopy、自訂 updater 等。
選擇的基準不該是「哪個最簡單」，而該以要向 OS 註冊什麼、由誰負責更新來決定。詳細內容整理在 Windows 應用程式發布方式選擇指南。

如果是公司內部使用的 .NET Windows 應用程式，想發布給標準使用者並輕鬆做到自動更新，可以參考 ClickOnce 入門：發布・更新・選擇基準。

另一方面，若透過網路發布或對外發布，就會遇到 SmartScreen 警告與程式碼簽章的問題。
關於為什麼會顯示「Windows 已保護你的電腦」，整理在 Windows 為什麼會顯示「Windows 已保護你的電腦」一文中。

委託開發 Windows 應用程式前想整理的 5 件事

1. 什麼是不希望停止的

最先該整理的不是功能清單，而是「一旦停止會造成困擾的業務」。

接單處理停止
檢驗線停止
無法輸出報表
與設備的通訊中斷
現場人員被迫回到手動作業
稽核或紀錄無法留存

委託開發不只是要做出畫面或功能，讓業務不中斷也是設計的一部分。
掌握了這個優先順序，就能更容易判斷該開發的功能、可以延後的功能，以及該優先調查的故障。

2. 目前的應用程式與周邊環境

在既有應用程式的改版・維護中，不只確認應用程式本身，還要確認周邊環境。

想事先掌握的資訊如下。

應用程式名稱、用途、使用部門
使用人數、使用台數
Windows 版本
32bit / 64bit
.NET Framework / .NET 版本
Visual Studio 版本
資料庫、共用資料夾、外部 API
整合的設備、DLL、SDK
安裝步驟
設定檔的位置
日誌的位置
是否有原始碼
是否有建置步驟
前任負責人是否留有資料

這些資訊越齊全，估價與調查的精確度就越高。
反之，若資訊不足，把第一階段獨立切出來做「現狀調查」會比較安全。

3. 全新開發・改版・重建，該選哪一個

在 Windows 應用程式的諮詢中，有時最好不要一開始就決定「要重新開發」。

方針	適合的狀態	注意事項
既有改版	有原始碼，主要功能仍在運作	會受到舊設計的限制
包裝・延壽	想繼續使用 COM、ActiveX、DLL 等既有元件	邊界設計與運用規則很重要
分階段遷移	想在不停止業務的情況下遷移到新環境	需要新舊並行運作與資料一致性
全面重建	規格能夠整理清楚，現行限制很大	規格遺漏與切換風險很大
僅故障調查	想先了解原因	需要整備日誌與重現環境

.NET Framework 應用程式是否要繼續使用，或是要遷移到 .NET，取決於應用程式的種類、相依函式庫、COM 整合、發布方式。
遷移前的確認項目，可以參考 .NET Framework→.NET 遷移前檢查清單，先盤點清楚會比較容易判斷。

4. 發布・更新・權限

在 Windows 應用程式上，有時會卡在發布而不是開發本身。

特別想確認的項目如下。

是否以標準使用者身分使用
是否有需要系統管理員權限的處理
是要安裝給全體使用者，還是以使用者為單位就足夠
只在公司內部使用，還是也要對外發布
是否需要自動更新
是否有離線終端
是否需要程式碼簽章
是否需要對 Microsoft Defender SmartScreen 做出說明
是否有 Intune、GPO、App Control 等管理原則

把需要系統管理員權限的處理與不需要的處理分開，可以提升日常使用的安全性與運用性。
權限的界線可以用 Windows 系統管理員特權的需要/不需要界線這類觀點來確認。

5. 是否容易維護

委託開發重要的不只是交付當下能夠運作。
更希望的是，數年後即使換了不同的負責人，也能夠調查・改版・重新發布。

容易維護的 Windows 應用程式，具有下列特徵。

留有建置步驟
能了解相依函式庫與版本
能了解設定檔的位置與意義
日誌輸出的粒度足以用於調查
當機時能留下證據
有發布步驟與復原步驟
原始碼的職責有清楚劃分
需要系統管理員權限的處理有限定範圍
機密資訊不是以純文字儲存

上線前最基本的資安確認，可以參考 Windows 應用程式資安檢查清單，從權限、簽章、機密資訊、通訊、輸入、DLL、日誌等角度來確認。

若需要把密碼或 token 儲存在設定檔中，應避免以純文字儲存，並利用 Windows 的機制來保護，這方面的設計很重要。詳細內容可參考安全儲存設定檔機密資訊的方法。

Windows 應用程式技術選型上常見的判斷

WinForms、WPF、WinUI 該選哪一個

在 Windows 應用程式的全新開發中，該使用 WinForms、WPF、WinUI 哪一種，是常見的討論點。

大致比較如下。

技術	適合的情境
WinForms	公司內部業務應用程式、輸入畫面、與既有資產的相容性、短期開發
WPF	複雜畫面、資料繫結、長期維護、業務應用程式的精細打造
WinUI	以 Windows 11 為前提、現代化 UI、與 Microsoft Store / MSIX 等的相容性

不過，新技術不代表永遠是正解。
必須連同既有團隊的經驗、維護期間、發布方式、畫面需求、周邊函式庫一併納入考量再選擇。

詳細內容整理成判斷表，收錄在 WinForms/WPF/WinUI 選型指南。

只用 C# / .NET 是否足夠，還是需要 C++ 或原生 DLL

多數業務應用程式用 C# / .NET 就足以開發完成。
不過，以下這些情況有時會需要考慮 C++、原生 DLL、P/Invoke、C++/CLI、COM 等。

廠商 SDK 是針對 C/C++
需要呼叫既有 DLL
有高速影像處理或裝置控制需求
需要使用既有的 COM 資產
需要跨越 32bit / 64bit 的界線

在這類專案中，不只是畫面端的開發便利性，還必須整理程序界線、記憶體所有權、例外處理、執行緒、位元數（bitness）。

該用 Windows 應用程式還是 Web 應用程式

也有「想把舊版 Windows 應用程式 Web 化」的諮詢。
Web 化有時很合適，但不代表把一切都做成 Web 就好。

Windows 應用程式適合的情境，例如以下這些。

直接與設備或本機裝置連接
在離線環境下使用
處理大型本機檔案
使用既有的 COM / DLL / VBA 資產
現場終端需要快速操作
需要常駐監控或背景處理

另一方面，若想在多個據點參考同一份資料、只想透過瀏覽器使用、想減少終端管理負擔，Web 化或雲端化有時會更合適。

在實務上，並非一次性把所有東西都 Web 化，也可以只保留需要 Windows 應用程式的部分，把資料管理或檢視的部分交給 Web 端這種架構。

委託開發的進行方式

Windows 應用程式的委外・委託開發，依下列方式進行會比較安全。

1. 現狀掌握

首先整理對象業務、使用環境、既有應用程式、外部設備、發布方法、目前遇到的困擾症狀。

若有既有應用程式，要確認原始碼、建置環境、設定檔、日誌、安裝程式、相關資料。

2. 觀測點設計

若存在故障或不穩定的情況，在立刻著手修正之前，先讓自己能夠追蹤原因。

新增日誌
取得當機傾印檔
保留通訊日誌
記錄記憶體或控制代碼數量
保留操作紀錄
保存異常發生時的螢幕截圖或狀態

問題越難重現，觀測點設計的效果就越明顯。

3. 方針決定

在了解現狀之後，決定改版、延壽、分階段遷移、全面重建、僅故障調查等方針。

在這個階段，也一併決定技術選型、發布方法、更新方法、維護範圍。

4. 實作・測試

在實作時，把畫面、業務邏輯、外部設備整合、檔案整合、錯誤處理、日誌、設定、發布分開來開發。

測試時，不只要確認正常情境，也要確認異常情境。

設備未連線
通訊中途中斷
檔案被鎖定
權限不足
網路不穩定
設定損壞
更新失敗
應用程式異常終止

5. 發布・遷移

完成後，要整理好發布步驟、更新步驟、還原步驟、初始設定、給使用者的說明。

若是從既有應用程式遷移，也要把新舊並行運作、回退、資料遷移、使用者教育納入計畫。

6. 維護・改善

交付後，要一邊觀察日誌與詢問內容，一邊改善成符合實際運用的形式。

Windows 應用程式會受到作業系統更新、電腦更換、周邊設備變更、資安政策變更的影響。
正因如此，以維護為前提的設計與文件化不可或缺。

估價前準備好會更順利的資訊

在諮詢階段，不需要所有資訊都齊全。
不過，有以下資訊的話，會讓討論進行得更快。

應用程式的目的
目前遇到的困擾
使用人數・使用台數
Windows 版本
是否有既有應用程式
是否有原始碼
開發語言或框架
整合的設備・資料庫・檔案・API
錯誤畫面或日誌
重現步驟
希望的交付期限
絕對不希望停止的業務
是公司內部發布還是對外發布
是否也需要維護

即使有不清楚的項目也沒有問題。
把哪些已經清楚、哪些還不清楚的部分弄明白，正是委託開發最初該做的工作。

結語

在委託開發 Windows 應用程式時，如果只是簡單傳達「想請你們開發一個應用程式」，需要的範圍就會變得不容易看清楚。

委託前想先掌握的重點，有以下這 7 點。

是全新開發、既有改版，還是重建
什麼業務不希望停止
是否有既有資產、外部設備、DLL、COM、ActiveX
WinForms、WPF、WinUI、.NET 遷移等技術選型
該如何處理發布、簽章、自動更新、系統管理員權限
日誌、當機傾印檔、記憶體、通訊等的調查設計
交付後該如何留下能夠維護的狀態

Windows 應用程式與現場的業務、設備、檔案、周邊裝置、Windows OS 的限制密切相關。
正因如此，委外・委託開發不只是「開發」，還必須連同「調查」「修正」「保留」「發布」「運用」一起納入設計。

如果您正為 Windows 應用程式的委外・委託開發、全新開發、既有軟體的改版・維護、設備整合、故障調查、發布・更新設計等問題所困擾，歡迎先從整理目前的狀況開始諮詢。

諮詢 Windows 應用程式開發

共用相同標籤的最新文章。能以相近的主題延伸理解。

與本主題相關的服務

本文連結到以下服務頁面，歡迎從最接近的入口查看。