2026 最新 Windows 桌面应用发布免费签名指南：上架 Microsoft Store，使用 MSIX 分发

很多独立开发者在发布 Windows 桌面软件时，都会遇到同一个问题：应用已经可以运行，但没有代码签名证书，直接发布 EXE 或 MSI 会遇到安全警告；购买证书又是一笔持续成本。如果应用适合通过 Microsoft Store 分发，可以选择一条更轻量的路线：将桌面应用打包为 MSIX，上传到 Partner Center，完成商店认证后由 Microsoft Store 对最终分发包进行签名。

这条路线不代表“任何 Windows 安装包都能免费签名”。它的准确含义是：MSIX 通过 Microsoft Store 分发时，不需要开发者自行购买传统代码签名证书，最终商店包由 Microsoft 的分发信任链处理。

先说结论

问题	结论
没有代码签名证书，能否上架？	可以，优先选择 MSIX + Microsoft Store 路线。
Microsoft Store 会不会重新签名？	会。提交的 MSIX 通过认证后，Store 会对分发包重新签名。
开发者账号是否收费？	Microsoft 当前的新开发者账号注册流程不收注册费，需要账号验证和 Partner Center 审核。
EXE/MSI 是否也能免费签名？	MSIX 和 EXE/MSI 有所区别。传统 EXE/MSI 仍由发布者负责签名。
本地构建出的 MSIX 能不能直接发给普通用户？	不建议。未经过 Store 分发的包可能需要开发者证书、测试证书或额外信任配置。
最终用户需要做什么？	从 Microsoft Store 安装和更新，不需要手动安装开发者证书。

Microsoft 对不同分发路径的说明可以参考：Windows 应用代码签名选项 和 选择 Windows 应用分发路径。

对于想要上架 Microsoft Store 但是又不知道该怎么办的开发者，可以跟随本文的步骤来完成，也可以直接使用我做好的 SKILL：Microsoft Store 上架技能包。

一、为什么选择 Microsoft Store

1. 解决没有证书的问题

如果直接发布 EXE 或 MSI，应用通常需要使用受信任证书颁发机构签发的代码签名证书。证书需要购买、验证身份、配置签名环境，并且还要定期续期。

MSIX + Store 的模型不同：开发者上传符合要求的包，Store 完成认证后负责面向用户的分发签名。对于预算有限的个人开发者，这能避开最早期的一笔证书成本。

2. 安装、卸载和更新更规范

MSIX 包含明确的包身份、版本和清单信息。Store 可以根据这些信息管理安装、更新和卸载，用户不需要自己寻找安装目录，也不容易遗留传统安装器产生的文件和注册表项。

3. 获得更清晰的发布入口

Microsoft Store 可以提供：

• 官方应用页面和搜索入口；
• 统一的安装和更新体验；
• 明确的发行者、隐私和年龄分级信息；
• 版本发布和提交记录；
• 面向用户的商店评价和反馈入口。

4. 需要接受商店约束

Store 路线也有代价：应用需要通过认证，包身份和版本必须符合规则，商店页面需要准备截图、描述、分类和隐私信息，发布节奏也会受认证流程影响，最终还需要经过严格的审核才可以进入商店。

因此，Store 最适合希望获得稳定安装体验、愿意维护发布资料、并且不急于绕过审核的桌面应用。

二、三种发布路线怎么选

路线	是否需要购买传统代码签名证书	用户安装方式	适用情况
MSIX + Microsoft Store	不需要开发者自行购买	从 Store 安装	个人开发者、预算有限、希望规范分发
MSIX + 自建下载页	需要购买受信任证书	下载 MSIX 后安装	有官网、有发布基础设施、需要完全自控
EXE/MSI + 官网直链	需要购买受信任证书	下载并运行安装器	已有安装器体系、需要复杂安装逻辑

我最推荐的低成本起步路径是：

WPF/Win32 应用
    -> 生成 MSIX
    -> 上传 .msixupload
    -> Partner Center 认证
    -> Microsoft Store 分发和签名

需要特别注意：“免费签名”只描述 MSIX 通过 Store 分发这一段，不是说所有发布方式都不需要证书。

三、发布前需要准备什么

1. 可以交付的稳定版本软件

至少应确认以下流程在开发环境中可用：

• 应用可以启动和退出；
• 主流程可以完成，不会因为缺少开发机路径而失败；
• 窗口拖动、Tab 切换、最小化、最大化、关闭等交互正常；
• 应用重启后不会因为残留状态进入错误状态；
• 没有把调试目录、开发者机器路径或测试账号写进运行逻辑；
• 崩溃时不会弹出明显的调试窗口或开发者错误信息。

Store 认证不是替代测试。它主要检查包、权限、安装和应用行为是否符合发布要求。

2. 一个 Partner Center 开发者账号

注册入口是 Microsoft Partner Center。Microsoft 当前的开发者账号说明见：创建开发者账号。

准备时应注意：

• 选择个人账号或公司账号时要慎重，账号类型通常不能直接切换；
• 需要使用可以完成身份验证的 Microsoft 账号；
• 发布者显示名称会出现在商店页面；
• 账号注册不等于应用自动通过审核，应用仍需单独提交认证。

3. 一个唯一且稳定的包身份

MSIX 身份由包名、发布者和版本共同参与确定。身份一旦用于 Store 应用，就不应该在后续版本中随意修改。

不要把下面几类值混在一起：

• Identity Name：包身份名称；
• Publisher：发布者标识；
• PublisherDisplayName：用户可见的发布者名称；
• PFN：Package Family Name，由包身份计算得出；
• Store ID：Store 中的应用标识。

4. 商店图标和截图

至少要准备：

• 应用图标的多种尺寸；
• 商店列表图标；
• 桌面应用截图；
• 应用名称和一句话描述；
• 详细描述；
• 分类、功能和年龄分级信息。

Microsoft 的要求是每个适用设备系列至少准备一张截图，桌面设备最多可以上传 10 张。实际发布建议准备 4 张以上，覆盖主界面、核心功能和典型使用场景。参考：截图和应用图片。

5. 隐私和审核说明

即使应用不联网，也要把这一点写清楚。建议准备一份内部审核说明，包含：

• 应用解决什么问题；
• 用户如何完成核心操作；
• 是否收集、上传或共享数据；
• 是否需要登录、广告、付款或订阅；
• 为什么需要声明的权限；
• 审核人员如何在几分钟内验证主要功能；
• 日志保存在哪里，是否包含个人信息。

审核人员不应该依靠猜测来测试应用。给出简短、可重复的测试步骤，往往比写一篇很长的产品介绍更有帮助。

四、成本到底是多少

项目	MSIX + Store 路线	EXE/MSI 官网直发
开发者账号注册费	不收注册费	视发布平台而定
传统代码签名证书	不需要开发者购买	需要
应用开发和测试	需要	需要
图标、截图和文案	需要	可选但建议准备
商店审核	需要	不需要
网站、服务器和下载带宽	可选	通常需要
后续维护	版本提交、审核、用户反馈	证书续期、安装器维护、下载服务

所以更准确的预算结论是：在没有购买证书的前提下，个人开发者可以用较低的现金成本完成 Store 上架，但仍需要承担开发、测试、素材、维护和时间成本。

五、以“窗口聚合”为例确定包身份

本项目产品名为“窗口聚合”，Store 相关身份如下：

字段	值
产品名称	窗口聚合
Package/Identity/Name	51628CBE.509183AB00F26
Package/Identity/Publisher	CN=10934E18-0ADF-4650-94FB-E90F5D295786
PublisherDisplayName	刘冲
Package Family Name	51628CBE.509183AB00F26_q7jd2hd009eyg
Store ID	9PK430RR7XT5

这些值的使用原则是：

1. 包身份以 Partner Center 分配和确认的值为准；
2. 后续版本保持 Name 和 Publisher 不变；
3. 只通过版本号区分更新，不要为了“重新打包”而重新生成身份；
4. PFN 和 Package SID 主要用于系统识别，不要手动把它们当成 Identity Name；
5. Store ID 用于商店页面、发布记录和后续运营，不要替代包身份。

当前项目的配置文件是 StorePackage/Package.config.json，核心内容如下：

{
  "identityName": "51628CBE.509183AB00F26",
  "publisher": "CN=10934E18-0ADF-4650-94FB-E90F5D295786",
  "publisherDisplayName": "刘冲",
  "displayName": "窗口聚合",
  "description": "将同一软件的不同进程窗口聚合到一个带 Tab 的窗口中运行",
  "version": "0.1.1.0",
  "appId": "WindowCollector"
}

六、如何生成 MSIX 包

我是编写了几个 powershell 脚本进行打包，脚本实现了以下共嗯那个：

1. 检查发布构建所需的工具和文件；
2. 生成应用图标和商店素材；
3. 构建 win-x64 发布版本；
4. 根据 Package.config.json 生成 MSIX 清单；
5. 生成 MSIX 包；
6. 生成上传用的 .msixupload 文件；
7. 输出 SHA-256 校验值，便于留档和核对。

构建成功后，重点查看：

artifacts\store\win-x64\WindowCollector-win-x64.msix
artifacts\store\win-x64\WindowCollector-win-x64.msixupload
artifacts\store\win-x64\WindowCollector-win-x64.msixupload.sha256

Microsoft 建议上传 .msixupload 或 .appxupload 文件，而不是把多个架构包随意压缩成普通 ZIP。参考：上传 MSIX 包。

版本号规则

每一次提交更新都要增加版本号，例如：

0.1.1.0 -> 0.1.2.0
0.1.2.0 -> 0.2.0.0

一定要注意：已经提交过的版本不能原样重复上传。版本号、清单身份和发布目标不一致。

七、在 Partner Center 创建并提交应用

第 1 步：注册开发者账号

进入 Partner Center，完成个人或公司账号注册、邮箱验证和身份验证。注册完成后进入应用管理页面。

第 2 步：保留应用名称

创建新应用后，先保留“窗口聚合”这个名称。名称保留成功后，Partner Center 会给出应用对应的 Store 身份信息。

这一步应在最终打包前完成，因为包清单中的身份必须和 Store 侧身份匹配。

第 3 步：填写应用可用性

配置：

• 发布市场和地区；
• 发布日期；
• 是否允许发现；
• 是否需要年龄限制；
• 是否提供免费安装。

如果应用当前没有付费、订阅或内购，不要为了“以后可能收费”提前勾选相关能力。页面信息应与真实产品行为一致。

第 4 步：填写应用属性

根据实际功能选择：

• 主分类和次分类；
• 支持的设备类型；
• 适合的年龄范围；
• 应用功能描述；
• 隐私政策地址；
• 支持联系信息。

隐私政策不应该只写“我们不收集信息”就结束，还应说明应用是否在本地保存配置、日志或崩溃信息，以及这些内容是否离开用户设备。

第 5 步：上传应用包

进入包管理或 Packages 页面，上传：

WindowCollector-win-x64.msixupload

上传后检查 Partner Center 识别出的：

• 包身份；
• 发布者；
• 版本号；
• 支持架构；
• 应用入口；
• 清单权限。

如果识别出的身份不是“窗口聚合”的 Store 身份，不要继续提交，先回到配置文件和打包脚本排查。

第 6 步：填写必须的数据

建议至少准备以下内容：

• 应用名称：取一个合适的名字；
• 简短描述：用一句话说明核心价值；
• 详细描述：说明应用适合谁、怎么工作、有哪些限制；
• 4 张以上桌面截图；
• 应用图标和宣传图；
• 支持邮箱或支持页面；
• 隐私政策链接。

详细描述不要堆砌“最快、最好、第一”等无法证明的宣传语。用用户可以验证的功能描述更稳妥，例如“将同一软件的多个窗口收纳到一个带 Tab 的窗口中”。

第 7 步：提交认证

提交前在 Partner Center 做一次完整检查，然后提交认证。Microsoft 的提交流程说明见：创建 MSIX 应用提交。

提交后可能经历：

1. 包和页面资料检查；
2. 自动化测试；
3. 人工审核；
4. 认证通过并发布；
5. 用户可以从 Store 搜索或通过页面安装。

认证时间会受应用类型、资料完整度和平台状态影响，不建议把首次上架安排在必须当天发布的节点。

八、应该如何写审核说明

以“窗口聚合”为例子，本项目是一个本地 Win32 窗口管理工具，审核人员需要知道它为什么申请桌面能力，以及如何验证它的核心功能。我写的说明如下：

窗口聚合用于将同一软件的多个进程窗口收纳到一个带 Tab 的窗口中。

应用不要求用户登录，不上传用户数据，不包含广告、内购和订阅。
应用不安装驱动、系统服务或后台常驻组件。

应用使用 runFullTrust，是因为它需要调用 Windows Win32 API 来枚举窗口、调整窗口样式、重新设置父窗口、切换焦点和恢复窗口。
应用不声明 allowElevation，不会自动请求管理员权限。

测试步骤：
1. 启动应用。
2. 打开两个或多个普通权限运行的记事本窗口。
3. 使用应用扫描并选择目标窗口。
4. 将窗口收纳到主窗口中，确认 Tab 可以切换。
5. 在收纳后的窗口中输入文本，确认输入和焦点正常。
6. 释放窗口，确认原窗口可以恢复。
7. 关闭应用并重新启动，确认应用可以正常运行。

权限说明必须和真实代码一致。不要为了通过审核而隐藏应用的行为，也不要在说明里承诺代码实际没有提供的功能。

九、最常见的失败原因

现象	常见原因	处理方式
本地双击 MSIX 安装失败	包没有受本机信任的签名，或系统策略不允许	本地验证使用开发者证书/测试环境；最终用户从 Store 安装。
Partner Center 拒绝上传	包身份、发布者或版本不匹配	对照保留的 Store 身份检查配置文件和清单。
重复版本无法提交	版本号没有递增	修改四段版本号后重新构建。
应用装上了但无法启动	入口、运行时依赖或架构不匹配	在干净环境启动，检查发布目录和包清单。
商店页面缺少素材	图标、截图、描述或隐私信息不完整	完成 Store listing，不要只上传包。
审核人员无法操作核心功能	没有提供测试账号或测试步骤	在审核备注中给出最短可复现步骤。
需要管理员权限的目标窗口无法收纳	Windows UIPI 限制跨权限窗口操作	明确提示用户，当前版本不自动提权。
更新后出现旧配置或旧包残留	应用数据迁移和版本策略未设计	提交前定义配置位置、兼容策略和卸载行为。

十、常见问题

Q1：Store 免费签名，是否意味着完全零成本？

不是。它主要省掉了开发者自行购买传统代码签名证书的成本。开发、测试、图标、截图、隐私政策、维护和审核时间仍然需要投入。

Q2：可以只把 EXE 上传到 Store，让 Microsoft 帮我签名吗？

不行。Store 对 Win32 应用确实有多种发布方式，但“自动签名”只针对 MSIX 分发路径。传统 EXE/MSI 分发还是需要开发者自行处理。

Q3：本地构建的 MSIX 可以直接放到网盘吗？

技术上可以作为测试包分享，但不适合作为普通用户的正式安装包。一般情况下，系统默认是不允许开发测试包。

Q4：每次更新都要重新申请包身份吗？

不需要。保持同一 Identity Name 和 Publisher，递增版本号，生成新的包并提交更新即可。

Q5：为什么上传 .msixupload，而不是直接上传 .msix？

.msixupload 是 Microsoft 为应用提交提供的推荐上传格式，适合把应用包作为提交工件交给 Partner Center 处理。具体支持格式和当前规则以 上传 MSIX 包 为准。

Q6：Store 上架后还需要保留官网吗？

建议保留。Store 可以承担主要安装入口，但官网仍然适合放置使用文档、更新日志、隐私政策、问题反馈和旧版本说明。

十一、发布前最终检查清单

账号和身份

• Partner Center 开发者账号已注册并完成验证；
• 应用名称正常使用；
• Identity Name 和 Publisher 与 Store 记录一致；
• 发布者显示名称正确；
• Store ID 已记录。

包和版本

• MSIX 清单中的应用名称正确；
• 版本号为新版本且未重复提交；
• runFullTrust 等权限和实际功能一致；
• 未声明不必要的权限；
• 已生成 .msix 和 .msixupload；
• 已保存 SHA-256 校验值。

商店页面

• 简短描述和详细描述已完成；
• 至少上传一张合格截图，最好准备 4 张以上；
• 图标和素材尺寸符合要求；
• 分类和年龄分级已完成；
• 隐私政策和支持信息可访问；
• 页面文字与实际功能一致。

审核和质量

• 已提供审核测试步骤；
• 已说明是否联网、登录、广告、付款和数据收集；
• 已在干净环境测试安装、启动、更新和卸载；
• 已测试普通权限和管理员权限窗口；
• 已确认应用关闭后不会遗留异常窗口或后台进程。

结语

对于没有预算购买代码签名证书的 Windows 独立开发者，MSIX + Microsoft Store 是一条现实、规范且可持续的发布路线：开发者负责把应用做成合格的 MSIX，Microsoft Store 负责认证、分发和面向用户的签名信任。

如果你想要实现免费签名，马上就上架商店试试，立即体验 Microsoft Store 上架技能包。