说实话, 很久以前玩QT的时候, 就了解到自己开发的应用程序, 想要符合windows的验证规范, 就必须购买 ea 证书进行代码签名, 而ea证书的价格不是我个人可以承担的。管理代码签名证书

直到某天想要把自己的小制作上传到微软的应用商店, 才发现如果你要上架的应用包是 msi/exe, 也是绕不开 ea 证书(是比ca证书更严格的签名, 实际上ca就可以)的代码签名的, 即使购买了微软的开发者帐号, 签名仍需自己额外找 ca机构花钱购买, 不签名就不让上架, 这是微软对此类安装包上架亘古不变的要求点击查看相关要求, 但若是购买证书进行签名, 则感觉不太值得, 毕竟太贵了(一个开发者帐号我都嫌贵, 更何况这种上千的证书年费)。但令我放弃的不只有证书年费, 还有更离谱的 自托管式的分发要求, 就是说负责下载应用程序的url链接需要开发者来提供, 而且我github的release页面中的下载链接, 虽然被我成功用于官网的下载按钮, 但却无法用于微软商店, 会因为重定向原因无法通过微软商店审核(因为github会为每个下载都重定向一个专门的临时url)。 也就是说, 我必须购买第三方的托管服务或是对象存储或是专门提供一个相关的服务器, 而不管那种方案, 尽管前期成本很低甚至免费, 但逐渐发展的过程中, 是有可能在应用火爆或是被恶意刷量的情况下, 使我付出或者说亏损超大一笔钱的, 我这种穷人承担不起这个风险。

因此, 我放弃了上架微软商店的想法, 转向了steam平台, 并花费99美金的槽位费购买了一个位置(相比于昂贵的证书年费和按量收取的服务器或对象存储费用, 我还是勉强能够接受这种一次性支出的)。但毕竟自己太穷, 想着先验证需求在来使用此槽位费, 于是又把目光暂时切回了微软的开发者帐号(毕竟116的永久费用相比于槽位费还是便宜的多的)。

此时, 贫穷的我注意到了Microsoft合作伙伴中心中如下图所示的提示:

然后, 我研究了微软官网中与msix相关的部分, 并重新审视了electron的打包工具, 发现其中存在与msix格式重叠的部分, 即Appx格式, 这也是electron官网在上架微软应用商店的文档中所推荐的格式, 其中还介绍了不少Appx格式的缺点, 以及electron在打包此格式的过程中, 为何不受这些缺点的影响。

当然, 由于我对electron的打包工具的认知中, 不太喜欢Electron Packager以及官网的Electron Forge, 而是更倾向于使用文档简单详细且强大的Electron Builder, 我甚至在Electron Builder的文档中再次确认了Appx的可行性。

同时, 我也注意到无论哪种electron打包工具, 都不支持msix后缀的打包格式, 此结论也在其它开源项目中暂时得到了佐证Electron 的好像打不了 msix 包,而这个项目的微软商店版用的就是Appx的安装包。

也可从Electron Builder项目的issues中得知, msix包暂时不受支持。

因此, 既然我可以通过Appx格式来借用微软商店的签名来避免资金问题, 那么我的应用就优先上架微软应用商店, 若是反响还不错, 再进一步消费之前购买的槽位来上架steam。

目前我还没有实施, 因为有以下几点疑问:

  1. electron官网中推荐的用于打包Appx的工具electron-windows-store, 和Electron Builder中的Appx的打包方式是否是一回事, 如果不是的话, 哪个效果更好?

    在网上搜索过后, 发现并不能很好的对比它们, 以至于我对其的认知仍然模糊

    • electron-windows-store似乎是微软官方推断的项目,根据gpt4o的回答, 其对比Electron Builder而言在appx格式的优化上应该更好。并且SiYuan这个项目也是使用的它来进行的appx的打包。(我自己也更倾向于使用electron-windows-store)
    • Electron Builder的优点就是配置方便, 只需增加一个appx字段即可。不过其似乎存在一些小问题。比如在有证书的项目中, 若进行代码签名, 它无法隔离nsis和appx的打包签名,会使得其中之一不可用(Appx貌似一般不使用ea证书进行签名)。此外, Motrix项目就直接使用了Electron Builder的打包, 并且其也在应用商店有出现(其证书的签名公钥似乎也写在了配置中, 但似乎与微软商店的发布者名称不是一个, 不过这里还是认为其微软商店上架版本就是此版本)(我将其release界面的appx下载下来后尝试安装,发现其是未知开发者, 可能是其公钥过期了吧, 毕竟此项目已经2年没有commit了)。

      不论哪种, 似乎都需要在build目录下建立Appx目录, 并将所需图标给放置在此目录中。
      Electron Builder的方式似乎更为简便, 但我不确定sdk是否可以打进去, 或者说此部分仍需摸索。

      electron-windows-store的话, 可以参考下SiYuan项目的相关配置, 可以为sdk的构建操作节省点力气。
      总之, 我更倾向于使用electron-windows-store。(毕竟appx在未知开发者状态下是不允许安装的, 因此将其集成在Electron Builder的打包流程中也是毫无意义的。倒不如使用electron-windows-store在每次发布后独立的打包appx并发布到微软应用商店(微软应用商店会为其赋予签名证书的))

      虽然我倾向于使用electron-windows-store, 但最终我使用了electron-builder成功上架。

  2. electron官网中推荐的Electron Forge, 到底有没有可能在未来超过Electron Builder?

    这个先附上electron-forge官网对两者的对比

    为防止链接失效, 附上对比截图

    总之, 它们似乎都解决了Electron Packager不包括的创建安装程序或自动更新等功能。但目前看来, 似乎我正在使用的Electron Builder仍处于上风, 只是我个人仍是这么感觉的。因此, 我也仍会继续使用Electron Builder而不是官网推荐的Electron Forge。(但对应Appx格式的打包, 我会在考察后决定使用Electron Builder还是官网推荐的electron-windows-store)

    目前可由Electron Forge的官网得知, 其打包Appx时, 依赖的是electron-windows-store。相关内容点击查看

  3. uwp或appx上架微软商店的大致流程?

    一般情况下, 完全按照官网的提示即可完成上架流程, 但网上也不乏有很多类似的文章教程, 可以用来参考, 如这篇博文中就介绍了相关的大致流程, 但具体应用具体分析, 这些文章仅能起到参考的作用, 自己的上传流程最好是自己做主。

appx安装包如何在本地安装, 以进行上架前的测试?

首先, appx的格式就是为微软商店准备的, 因此微软合作伙伴中心会给到我们 Publisher: 'CN=54940991-8DDB-4049-B299-2C3D65A6BBCC', 它是微软合作伙伴中心为你的应用生成的发布者标识符（Publisher ID）。这个标识符通常用于在将应用上传到微软商店时，由微软商店自动对应用进行签名。

然而，若是希望在本地实现签名，而不是依赖微软商店的自动签名流程, 则需要保证构建配置中的Publisher字段和证书的 Subject 是一致的。

因为要发布应用商店, 因此构建流程中的Publisher字段必须使用合作伙伴中心提供的 Publisher ID。因此, 我们生成本地证书时需要保证Subject与其一致。(如果不发布应用商店或者喜欢多套构建流程, 则请随意)

1. 理解合作伙伴中心提供的 Publisher ID

  • 合作伙伴中心提供的 Publisher ID 是一个唯一的标识符，用于将应用与你的开发者账户关联。
  • 这个 Publisher ID 通常用于微软商店的自动签名流程，而不是本地签名。

2. 本地签名的限制

  • 如果你希望在本地对应用进行签名，需要使用一个有效的代码签名证书，并且该证书的 Subject 必须与合作伙伴中心提供的 Publisher ID 完全匹配。
  • 合作伙伴中心提供的 Publisher ID 通常无法直接用于本地签名，因为它不是一个完整的证书，而是一个标识符。

3. 解决方案：生成本地测试证书

如果你需要在本地测试应用，可以生成一个自签名证书，并将其 Subject 设置为与合作伙伴中心提供的 Publisher ID 匹配。

步骤：

  • 打开 PowerShell（以管理员身份运行）。

  • 运行以下命令生成自签名证书：

    1
    New-SelfSignedCertificate -Type Custom -Subject "CN=54940991-8DDB-4049-B299-2C3D65A6BBCC" -KeyUsage DigitalSignature -FriendlyName "AppxTestCert" -CertStoreLocation "Cert:\LocalMachine\My"

    注意：将 Subject 替换为你的 Publisher ID。

  • 可以使用这个命令查看证书。

    1
    Get-ChildItem -Path Cert:\LocalMachine\My

  • 导出证书为 .pfx 文件：

    1. 打开“证书管理器”（certlm.msc）。
    2. 导航到： 个人 -> 证书
    3. 右键点击“证书”，选择“所有任务” -> “导出”。
    4. 记得选择”是,导出私钥”, 以导出.pfx格式。(用于后续给SignTool签名时使用)(顺便提一下, 我一般喜欢使用sha256)
    5. 选择导出路径时, 建议导出至/c/Windows/system32。(因为PowerShell打开时的默认路径是这个, 方便我们指定pfx证书的路径。)

  • 使用 SignTool 对 .appx 文件进行签名：

    1
    signtool sign /fd SHA256 /a /f ".\AppxTestCert.pfx" /p "这里写你在导出证书时设置的密码" "D:\safe\KeyTone\frontend\dist\electron\Packaged\KeyTone-0.3.4-win-x64.appx"

    注意：确保证书的 Subject 与合作伙伴中心提供的 Publisher ID 完全匹配, 否则会造成签名失败。

4. 将证书导入受信任的根证书颁发机构

为了让系统信任你的自签名证书，需要将其导入到“受信任的根证书颁发机构”存储中。

步骤：

  1. 打开“证书管理器”（certlm.msc）。
  2. 导航到： 受信任的根证书颁发机构 -> 证书
  3. 右键点击“证书”，选择“所有任务” -> “导入”。
  4. 选择你生成的 .pfx 文件，完成导入。

当然, 如果在导出证书时选择”不,不要导出私钥”, 则会生成.cer的证书, 此证书也可以用于导入受信任的根证书颁发机构, 但不可用于使用 SignTool 对 .appx 文件进行签名, 因为签名时私钥是必须的, 也就是说必须是.pfx格式的文件。

5. 安装你的Appx包

不出意外的话, 你的系统现在已经可以安装这个自签名的Appx包了, 开始测试你的应用吧, 以在发布新版本及上传到应用商店前, 做最后的测试工作。

6. 上传到微软商店时的签名

当你将应用上传到微软商店时，合作伙伴中心会自动使用其内部的证书对应用进行签名。因此, 请不要上传在本地签名过的appx包, 而是上传原始生成的包交由微软来签名。

7. 注意事项

  • 本地签名的证书仅适用于开发和测试，不能用于正式发布。
  • 如果你需要正式发布应用，必须通过合作伙伴中心上传应用，由微软商店进行签名。

总结

  • 合作伙伴中心提供的 Publisher ID 主要用于微软商店的自动签名流程，无法直接用于本地签名。
  • 你可以在本地生成一个自签名证书，并将其 Subject 设置为与 Publisher ID 匹配，以进行本地测试。
  • 正式发布时，必须通过合作伙伴中心上传原始未签名的应用安装包，由微软商店进行签名。(千万不要上传本地签名过后的测试用的应用安装包)