委托开发 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 等。
选择的基准不该是「哪个最简单」，而应该以要向操作系统注册什么、由谁负责更新来决定。详细内容整理在 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 应用程序的咨询中，有时最好不要一开始就决定「要重新开发」。

.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 选型指南。

只用 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 操作系统的限制密切相关。
正因如此，委托开发不只是「开发」，还必须连同「调研」「修复」「保留」「发布」「运维」一起纳入设计。

如果您正为 Windows 应用程序的委托开发、全新开发、现有软件的改造・维护、设备联动、故障排查、发布・更新设计等问题所困扰，欢迎先从梳理目前的状况开始咨询。

咨询 Windows 应用程序开发

相关文章

共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。

常见问题

汇总了咨询这一主题时常见的问题。

没有源代码也可以咨询吗？

可以咨询。不过，在没有源代码的情况下，能做的事情会受到限制。有时可以从配置、环境、日志、外部依赖、可执行文件、安装程序、通信内容等线索进行调查。另一方面，功能新增或根本性的修改通常需要源代码，因此从现状调研开始比较现实。

包含老旧 VB6、VBA、COM、ActiveX 的应用程序也可以咨询吗？

可以咨询。在这个领域，与其硬把全部一次性替换掉，不如把要保留的部分、要封装的部分、要替换的部分分开来考虑，这一点很重要。尤其是业务上仍在运行的资产，一边评估风险一边分阶段迁移会比较安全。

应该把 Windows 应用程序换成 Web 应用程序吗？

要看目的。Web 应用程序适合多据点、简化终端管理、以浏览器使用等场景。另一方面，如果存在设备联动、本地文件处理、离线运行、使用现有 DLL 等需求，保留 Windows 应用程序反而比较自然。不一定要把所有内容都 Web 化，把 Windows 端与 Web 端的职责分开设计，也是一种选择。

只委托故障排查也可以吗？

可以。长时间运行后出现的崩溃、通信中断、内存持续增长、只在特定电脑上出现的故障等问题，与其立刻着手修改，更重要的是先建立能够追踪原因的状态。先整理日志与转储文件，缩小复现条件范围后，再决定修复方案。

需要管理员权限的应用程序也可以开发吗？

可以开发，但一直以管理员权限运行的设计，应该谨慎考虑。日常使用的部分以标准用户权限运行，只把需要的处理独立出来，会比较安全。安装、服务注册、写入受保护区域、驱动程序、全用户设置等，会在一开始就先梳理好权限设计。

公司内部使用的小型 Windows 应用程序也可以委托开发吗？

可以。即使是小型应用程序，只要事先考虑到发布、更新、日志、配置、备份、负责人交接等事项，就能用得更长久、更顺手。尤其是像 Excel 作业自动化、CSV 转换、文件监控、报表输出、设备数据采集这类小型业务改进，有时 Windows 应用程序反而更合适。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司 代表

以 Windows 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。