我在 Windows Marketplace for Mobile 和 Windows Mobile 6 上的经验

• 下载源代码 - 553 KB

引言

几个月前，我在 Windows Marketplace for Mobile 注册了。我想创建一个简单的应用程序并通过认证，这样我就可以了解这个过程（并撰写文章！）。目前，我看到了在 Marketplace 中认证失败、通过认证以及提交产品更新的经历。

微软一直在根据用户反馈对 Windows Marketplace for Mobile 的界面、规则和程序进行更改。在我开始撰写本文的过程中，提交应用程序的界面在一个周末经历了多次更改。为了使本文更具相关性，我等到这些更改稳定下来后才完成并发布本文。

本文是什么以及不是什么

本文不是通过认证的指南。微软已经发布了一份指南。本文只是我个人经验、从他人经验中收集的信息以及我的一些想法的集合。如果您认为这可能对您有所帮助，请继续阅读。无论如何，如果您打算向 Windows Marketplace for Mobile 提交应用程序，您都应该访问 http://developer.windowsphone.com 阅读认证过程。开发者仪表板和认证过程随着时间的推移进行了调整，或者我的想法和经验涵盖了通过认证所需了解的一切。

关于代码

本文附带的代码实际上通过了 Marketplace 认证。我编写代码的目的是为了撰写本文，而不是为了赚钱。在几次交谈中，MSMobiles.com 的某人敦促我对应用程序收费而不是免费提供。为了向他证明该应用程序不会出售，我给它定了价。两周后，我出售的副本几乎足以支付注册费用。我制作了一个更新版本的应用程序，并将其推送给付费用户，而原始源代码可在此处供您查阅。不过，本文与代码几乎没有什么关系，我认为代码对文章来说更像是偶然的，而不是支持性的。我之所以包含它，是因为我确信有人会想看看它。

注册

对我来说，注册过程很简单。我住在美国，以个人身份注册。由于我以个人身份注册，我发布的任何内容都必须以我的法定姓名发布。我更喜欢以我的网站名称（j2i.net）发布，但这不是一个选项。除了在线填写注册表格外，我还必须打印一份表格，其中大部分内容是声明我是我所说的那个人，并由公证人签名和盖章。我在我的银行完成了这项工作，因为他们免费为账户持有人公证文件。该文件的影印件以及我的政府签发身份证明的副本已通过电子邮件发送给 GeoTrust。几天后，我接到 GeoTrust 的电话，他们要求我核实我的姓名和其他几项信息。与 GeoTrust 通话两天后，我的账户被启用，我可以访问 Marketplace 仪表板。

应用程序指南和规则

提交指南（PDF 链接）是公开可用的。在等待身份验证期间，我鼓励您熟悉这些指南。我看到很多关于 Marketplace 规则数量的负面评论。虽然规则的数量看起来令人生畏，但当你真正审视这些规则时，它们并没有那么糟糕。根据您的应用程序，您可能会发现其中一些规则不适用于您计划发布到 Marketplace 的应用程序。目前，本文的目录列出了七个要求部分

1. 可靠性
2. 手机优先
3. 有效的内存管理
4. 恶意软件
5. 尊重用户设置
6. 组件 (Widgets)
7. Windows Marketplace 上市标准

我没有发布小部件，所以立刻可以看出文档的小部件部分没有任何适用于我的应用程序的内容。有些规则是针对替代输入法编辑器（例如自定义屏幕键盘）的应用程序。这些规则也不适用于大多数应用程序。为了确定我关心的规则，我需要决定要发布的应用程序的性质。由于我只是为了通过认证过程而创建这个应用程序，所以一个手电筒应用程序就足够了。我决定选择一个功能稍多一点的应用程序；我制作了一个应用程序，可以从 GPS 接收器显示一个人的速度。这个应用程序将使用 .NET 3.5 框架编写，并将在所有屏幕分辨率的 Windows Mobile Professional（带触摸屏的设备）上运行。应用程序可以针对所有 Windows Mobile 6.x 版本，也可以只针对 Windows Mobile 6.5。我看不出像这样的应用程序需要 WM 6.5 特定功能的任何原因，所以我决定针对所有 WM 6.x 版本。（这个应用程序也应该在 Windows Mobile 5 上运行。但我还没有尝试过。）

关于认证过程和规则的几点注意事项：认证测试只针对您计划部署给客户的精确安装进行。论坛中曾有人提出问题，希望认证其应用程序的一个版本，以便在将要发布给客户的版本中进行小幅“调整”。还有一些关于提交测试计划并在发布前完成部分代码的问题。这是不允许的。应用程序必须在提交认证前完成，如果对应用程序进行任何更改，则需要重新认证。另请注意，认证测试不是质量测试。如果您的应用程序在认证期间开始崩溃，那肯定是失败的直接原因，但通过认证并不能保证应用程序不会崩溃。第一个通过认证的代码版本存在一个竞争条件，可能导致它锁定并崩溃，但这种情况非常罕见，以至于在认证测试期间从未发生。我在提交应用程序后才发现它，并且在它通过后，我从未公开发布 1.0 版本，以便在 1.1 版本中纠正这个问题。

满足可靠性规则

可靠性规则可以在规则文档的第 4 页到第 11 页找到。这是文档中最大的一部分（所有规则总共占据了 31 页文档中的 14 页）。可靠性下有 21 条规则。我将全部提及它们，尽管其中一些不适用于我的应用程序。到目前为止，满足这些要求是认证文档中最重要的部分，因此我的大部分时间都花在这里。

1.1 安装包

如果您使用 Visual Studio 创建安装，则无需担心此问题。它只说明您的 _cab_ 必须包含一个 _SETUP.XML_。Visual Studio 将自动完成此操作。

1.2 安装警告消息

如果您曾经在 Windows Phone 上安装过较旧的 Windows Mobile 应用程序，您可能会看到一条错误消息，指出该应用程序是为以前版本的 Windows Mobile 制作的，可能无法在您的手机上正常工作。这可以通过将部署项目上的 OS 版本最大值设置为适当的值来解决（我在 CAB 项目中将其设置为 6.99）。

1.3 开始菜单或开始屏幕上的快捷方式

简而言之，此规则表示您的应用程序必须在“开始”菜单中提供快捷方式。Windows Mobile 6.5 Shell 可以使用 PNG 文件作为应用程序图标。要使您创建的 PNG 文件用作图标，必须进行注册表项。Windows Mobile 6.0/.1 使用我们都习惯的 *.ICO 图标。对于 Windows Mobile 6.5，您的应用程序**必须**使用 PNG 图标。此要求可能存在混淆。早期在 MSDN 论坛中，一些开发人员提到只针对 Windows Mobile 6.0/.1，这样他们就不必担心 PNG 图标。由于 6.0/.1 应用程序也适用于 Windows Mobile 6.5 设备，因此避免使用 PNG 图标似乎是让应用程序交付给客户的最简单途径。这种误解后来得到了澄清。

由于 Windows Mobile 6.0/.1 应用程序也适用于 6.5 设备，因此它们也受 6.5 要求的约束。因此，您的应用程序**必须具有 PNG 图标**才能通过认证。您可以通过几种方式完成此操作。迄今为止，最简单的方法是为您的部署创建一个 90x90 的 PNG 图标，并将条目添加到部署项目注册表编辑器中。您可以在此处查看如何完成此操作的技术细节。最起码，这意味着您将向`HKLM\Security\Shell\StartInfo\Start\<shortcutname.lnk>`添加一个注册表项，其中`<shortcutname.lnk>`应替换为您的快捷方式图标的名称。您需要向此键添加一个名为 Icon 的字符串值，其中包含 PNG 文件的绝对路径。由于您不知道应用程序将安装在哪个文件夹中，因此您无法提前知道绝对路径。但是，您可以在安装文件夹的位置指定`%InstallDir%`，它将在安装时替换为正确的路径。

您仍然需要适用于 Windows Mobile 6.0/.1 目标的 ICO 文件。为了创建 ICO 图标，我使用了 IcoFX，一个免费的图标编辑器。它有一个选项可以从另一个文件导入图像，以及创建不同分辨率的其他图标的选项。

1.4 仅将文件存储在指定目录中

只有共享组件才能安装在 _\Windows_ 目录中。所有其他应用程序文件都应存储在应用程序文件夹中。

1.5 保留 ROM 内文件

不要覆盖设备 ROM 映像中的任何文件。这可能也是一个很好的时机，指出微软在发布自己的应用程序时不受相同的限制。如果您安装了 Office 2010 Beta，设备 ROM 中的 GDI+ DLL 将被更新的 GDI+ DLL 覆盖（影子）。如果您编写了任何 GDI+ Windows Mobile 应用程序，安装 Office 2010 Beta 可能会破坏它们（注意：虽然 GDI+ 的子集存在于 Windows Mobile 应用程序中，但 GDI+ 从未在 Windows Mobile 上受支持，因此无法保证它会在 Windows Mobile 设备上可用）。

1.6 应用程序名称长度

您的应用程序名称必须少于 70 个字符。即使这不是一条规则，我也看不到有多少人会跨越这个界限。

1.7 干净安装和卸载

您的应用程序应无错误地安装和卸载。

1.8 清理数据

在安装或首次运行时创建的文件应被删除。用户使用您的应用程序创建的应用程序文件可以保留（例如：如果您制作了一个文字处理应用程序，文档文件可以保留）。您也可以保留应用程序的文件夹结构。在我在 Marketplace 中提供的第一个应用程序版本中，我故意保留了一个设置文件，以便用户重新安装应用程序时其设置能够保留。因此，应用程序卸载后，应用程序的文件夹也继续存在（因为它包含设置文件）。允许保留的文件类型包括

• 与应用程序相关的用户数据
• 同一发布商的应用程序共享的文件
• 操作系统所需的文件

1.9 安装在 RAM 中，不要这样做！

我甚至不知道如何将文件放在 RAM 文件系统中。老实说，我没有为此担心。如果有人能解释，请告诉我。

1.10 主屏幕文件

不适用。

1.11 GAPI 在 WM 6.5 上

不适用。

1.12 GAPI 在 WM 6.1 上

不适用

1.13 多设备支持

您的应用程序必须能够在满足您所传达规格的多台设备上运行。为了兼容性，您选择支持的分辨率和所需的硬件。从在 Marketplace 论坛中协助他人来看，我认为这是另一个潜在的混淆点。为了传达硬件要求，有一个带有复选框的表单，允许您选择目标设备中必须存在的硬件。如果用户的设备不具备您在此处勾选的所有功能，那么您的应用程序将不会在 Marketplace 中对用户可见。我看到开发人员勾选了键盘要求，却没有意识到此要求意味着用户的设备必须具有物理键盘。我还知道另一个应用程序可以有无 GPS 都能工作。但开发人员勾选了 GPS 要求，使该应用程序仅适用于手机中带有 GPS 接收器的用户。如果您在此部分犯了错误，并且在提交应用程序进行认证之前没有更新它，那么在提交应用程序更新之前无法更改它。

除了硬件要求，还必须选择兼容的屏幕分辨率。与硬件要求一样，如果用户的设备不符合您选择的屏幕要求，当用户浏览 Marketplace 时，应用程序将不会在 Marketplace 中向用户显示。有些分辨率仅适用于 Windows Mobile Standard 设备（无触摸屏设备）和 Windows Mobile Professional 设备（有触摸屏设备），而大多数分辨率在两者上都可用。我选择了所有适用于 Windows Mobile Professional 设备的屏幕分辨率。由于应用程序中 UI 的缩放方式，它将在所有这些分辨率下工作。

1.14 单应用程序实例

您的应用程序一次只能运行一个实例。大部分代码由 .NET 框架自动处理。如果您快速连续多次启动应用程序，可能会创建多个实例，但我并不担心有人会这样做。测试人员也不担心。所以，我不需要为此要求做任何事情。

1.15 从省电模式恢复

如果设备进入待机状态并恢复，您的应用程序不应因此崩溃。我不需要为此做任何事情。我见过出现待机恢复问题的应用程序是那些依赖外部硬件（例如：蓝牙连接或通信端口）的应用程序。进入待机状态可能会关闭与这些外部设备关联的连接和文件句柄；未设计用于处理此情况的应用程序可能会崩溃。如果您的应用程序通过 Wi-Fi 连接进行通信，进入待机状态可能会关闭 Wi-Fi 适配器，并且在设备从待机状态恢复时，Wi-Fi 适配器重新启动可能会有延迟——这是另一个可能导致未准备好的应用程序出现问题的情况。

1.16 任务管理器

应用程序运行时必须显示在任务管理器中（注意：如果您的应用程序在标题栏中没有标题，它将不会显示在任务管理器中）。我知道有一个开发人员因此而未通过认证，因为他使他的应用程序一失去焦点就终止。对测试人员来说，这似乎是一个不会显示在任务管理器中的应用程序。

1.17 Hopper 测试

Hopper 测试是应用程序的压力测试。它会生成随机的按键和屏幕点击。您的应用程序必须能够在 Hopper 应用程序的测试中存活 2 小时而不会崩溃。您可以在此处找到 Hopper 的下载。虽然这是认证的一部分，但它不是 QA 测试。通过 Hopper 的应用程序仍然可能存在导致崩溃的代码路径。

1.18 不要禁用错误报告

您的应用程序不应禁用 Windows 错误报告。

1.19 优雅关闭

应用程序必须能够在不崩溃的情况下关闭。关闭可能是由用户发起，也可能是由内存不足条件导致应用程序关闭。我第一次尝试应用程序认证时因此失败了。虽然用户关闭应用程序时没有问题，但如果应用程序被任务管理器终止（测试人员模拟 Shell 终止应用程序的方法），应用程序的工作线程没有被终止并继续运行。当它尝试将调用调度到 UI（与主线程一起被终止）时，它会崩溃。为了解决这个问题，我只需要在主窗体的 `Closing` 事件中终止工作线程。

1.20 等待光标支持

如果应用程序忙于执行某些操作的时间足够长，以至于 UI 看起来无响应或被锁定，则必须显示等待光标。对于此应用程序，我对此并不担心。

1.21 使用 MFC 的应用程序必须静态链接到 MFC 运行时

同样，由于这是一个 .NET 应用程序，因此不适用。

其他规则

认证指南中还有一些其他规则。总而言之，应用程序不应干扰手机接听电话的能力。软件不应是恶意的。软件不应更改系统设置/偏好设置。而且，软件必须在打开数据连接之前通知用户。

将应用程序上传到 Marketplace

请注意，还有一个上传过程的视频可供查看。

您可以在开始编写应用程序之前开始填写提交表格。在将应用程序上传到 Marketplace 之前，您需要准备一些东西：

• 应用程序的 CAB 文件
• 4 个图标，用于在 Marketplace 中表示您的应用程序
• 1 到 6 张您的应用程序截图
• 用于在手机上浏览的用户看到的应用程序的简短描述（限制：500 个字符）
• 用于在计算机上浏览的用户看到的应用程序的详细描述（限制：2000 个字符；可以与简短描述相同）
• 3 到 5 个要突出显示的应用程序功能
• 您的应用程序所需的任何豁免
• 提供支持电子邮件地址，可能还需要支持页面或电话号码
• 了解您的应用程序的硬件和屏幕分辨率要求
• 为您的应用程序设定一个或多个货币的价格
• 为您的应用程序想好一个类别

收集完这些信息后，登录到 http://developer.windowsphone.com 的开发者仪表板，然后选择“添加产品”按钮。系统会提示您指定是添加小部件还是应用程序。我选择了应用程序，然后进入一个表格，可以在其中选择应用程序的名称、它支持的 Windows Mobile 版本以及应用程序的版本号。

对于次版本号，*始终*选择 0 作为初始版本。您可以免费将应用程序更新到版本 x.9。如果您从版本 x.7 开始，那么您只能再进行两次更新，然后就会消耗一个提交额度。这样做的后果是应用程序的内部版本号可能最终与 Marketplace 中声明的版本不同步。**如果**您只通过 Marketplace 分发，那么您应该能够轻松保持这些数字同步。如果您在应用程序中显示应用程序的版本号，您可能需要添加代码以从程序集元数据中提取版本号，以减少您必须更新版本号的地方。

提交过程中的下一个表格是填写产品描述和功能。在这里，您可以输入应用程序的简短和详细描述，以及输入您要突出显示的应用程序的三个到五个功能。

在提交过程的第 3 步，您将能够上传您的应用程序二进制文件并提供支持信息。在同一页面上，如果您的应用程序安装需要提升的权限，您可以在此处选择“特权模式数字签名”。对于我的应用程序，我能够将此设置保留为默认的“正常模式数字签名”。

在提交过程的第 4 步，您将上传您的产品艺术品。这总是包括 4 个 PNG 图标和至少一个应用程序屏幕截图。以前，这是一个很容易导致认证失败的地方。如果您上传了错误大小的图像，您基本上会浪费一次认证尝试（价值 99 美元）。现在，此页面将验证您上传的图标的大小，如果它们不正确，将阻止您继续操作。您上传的四个图标必须具有 45x45、64x64、36x36 和 60x60 的尺寸。我将这些图像用作程序在“开始”菜单中的图标，但没有任何规定要求这些图像必须相同。屏幕截图也有尺寸限制。我的所有屏幕截图都是 240x320。它们也可以是 315x420。

提交过程的第 5 步是指定应用程序的要求。我之前讨论过这些要求。我没有提到的一点是，您可以在此处指定应用程序所需的 .NET 框架版本。如果用户的设备上没有所需的版本，Marketplace 将负责安装它。当然，如果您的应用程序是用本机代码编写的，那么您可以指定不需要 .NET 框架。

提交过程的第 6 步是为您的应用程序指定类别和价格。您输入的价格信息将影响应用程序对其他国家/地区客户的可见性。如果您只想让应用程序对您上传应用程序的市场内的客户可用，您只需为该区域选择一个价格。如果来自其他区域的用户浏览您已上传应用程序的目录，如果未指定其区域的价格，则应用程序将不会显示。

输入所有信息后，您可以提交您的应用程序进行认证。一旦您提交了应用程序，它就不再由您控制。如果没有使用提交额度，就无法取消该过程。因此，在单击此按钮之前，请确保您已真正准备好发布应用程序进行测试。如果您提交了应用程序，然后几分钟后发现提交了错误的版本或需要更改某些内容，您将无能为力。您可以请求不测试您的应用程序，但这不会阻止您失去认证尝试额度。因此，如果您提交后发现需要更改某些内容，最好让它完成认证测试，以便您获得有关其他可能不符合规定的反馈。

认证过程的时间可能有所不同。我已将此应用程序通过认证 4 次（一次失败尝试和三次通过尝试）。平均而言，通过认证大约需要 5 天。最长需要 10 天。当应用程序认证过程完成，通过或失败时，会发送一封电子邮件通知应用程序状态已更改。

登录到开发者仪表板后，将显示应用程序的状态。如果应用程序通过认证，它在仪表板中的状态将是“准备发布”。一旦应用程序达到此状态，您可以通过选择“提交到目录”使其可见。提交应用程序到目录后，用户将在几分钟到 12 小时内看到它。

我当时正在将我的应用程序提交到多个 Marketplace。我等到应用程序通过认证后，然后转到开发者仪表板的产品选项卡并找到了我的应用程序。应用程序行项目右侧的设置图标有一个选项可以提交到其他 Marketplace。选择此选项会导致 CAB 和应用程序要求自动复制。不幸的是，它不会导致产品描述或屏幕截图复制过来，因此需要再次上传这些。我发现将已通过认证的应用程序提交到另一个市场比提交新应用程序进行认证要快。平均而言，应用程序需要大约 5 到 6 个工作日才能通过新市场的认证。

一旦应用程序的销售量达到 200 美元的支付门槛，我在仪表板中收到一条通知，看起来很像错误。错误是“银行数据待验证”。乍一看，这个错误让我感到震惊。

当我查看错误的详细信息时，事情变得更有意义了。此错误的详细信息如下：

Your banking information has been received, but we have not attempted to deposit royalty 
funds in your account. Once we are able to successfully fund your account, 
this message will no longer appear.

换句话说，对您提供给微软的银行账户信息的最终验证形式是资金是否可以成功存入该账户。一旦我成功收到第一笔付款，我就不会再看到这个错误了。

报告

开发者仪表板中提供两种类型的报告：履行报告和版税报告。要生成报告，您需要填写一个表单，询问基本参数，例如您是希望报告基于单个市场还是您拥有产品的所有市场，或者选择报告是基于过去七天、本月至今、30 天还是 90 天。当您选择所有参数并请求报告时，您将收到一条通知，告知您正在生成报告。当报告生成完成时，您会收到一封电子邮件通知。到目前为止，报告生成时间并不长。请求报告后，我能够转到仪表板的另一个区域，然后返回查看我的报告正在等待。报告是 XML 格式，可以直接在 Microsoft Excel 中打开。

履行报告对于了解有多少人下载了您的应用程序以及何时下载很有用。版税报告包含您收到的付款信息。虽然我符合首次付款的资格，但我尚未收到付款，因此此报告对我来说是空白的（收到后，我计划更新本文以包含其中包含的信息类型）。

请求支持

仪表板的第一页有一个“联系支持”链接，可以打开一个提交支持请求的表单。我只提交了一个支持请求，并在同一天晚些时候收到了回复。根据我在 Marketplace 早期阶段在 MSDN 论坛中阅读到的其他开发人员的消息，支持链接并不是那么可靠。

对于一般性问题，我建议在MSDN Marketplace 开发者论坛中发布问题（不要错误地发布到用户论坛）。当您发布问题时，如果它是一个已提交并获得批准的应用程序，您需要包含您的应用程序名称、您遇到问题的市场以及应用程序的产品 ID（当您在仪表板中查看应用程序信息时，产品 ID 显示在页面底部）。当有人发布一个诸如“我在 Marketplace 中找不到我的应用程序，它在哪里？”的问题时，任何人都会难以提供帮助，并且总是会导致请求更多信息。一个包含所有所需信息的问题可以这样措辞：“我在 en-US Marketplace 中找不到我的应用程序 SpeedTracker。我的应用程序的产品 ID 是 9038f34f-2cda-4a3e-9bbb-81978b88a6bb。”如果您在 Marketplace 论坛线程中提出问题并决定将问题升级为支持请求，请记住在您的支持请求中引用该线程的链接。

用户评价和支持

我活跃于微软支持论坛，从阅读 Marketplace 的用户论坛和开发者论坛来看，用户之间似乎存在一套普遍的行为模式。对应用程序不满意的用户往往比对应用程序满意的用户更有可能对应用程序进行评分。此外，遇到应用程序问题的用户似乎并不知道应用程序开发者提供了支持信息。我遇到过许多用户在使用应用程序时遇到问题，他们的反应是要么在用户论坛中提问（在这种情况下，我尝试将用户引导回应用程序发布者），要么只是给应用程序差评然后离开。我对此没有经过测试的解决方案，但看到这种行为让我思考，如果提高应用程序内支持信息的可见性，是否会促使用户在给应用程序差评之前与应用程序发布者互动。

应用程序可用性问题

关于 Marketplace，我仍然有一个问题。当一个应用程序不再可用时会发生什么？没有官方认可的方式让用户获得 CAB 文件来重新安装应用程序。相反，如果用户需要重新安装应用程序，他们可以通过 Marketplace 客户端重新下载。但是，如果应用程序实际上从 Marketplace 中删除会发生什么？应用程序删除可能有很多原因。独立软件供应商/开发者可以决定删除应用程序。如果开发者/独立软件供应商每年不续订他们的 Marketplace 帐户，那么他们的应用程序将自动删除。此外，如果应用程序进行了更新，并且该更新的要求与应用程序的先前版本不同，那可能会使应用程序不兼容，从而对一些以前的购买者不可用。我未能找到这些问题的明确答案，但我确实找到了发生此类情况的实例。

Marketplace 何时在我的地区可用

每隔一段时间，就会有用户或开发者发布问题，询问 Windows Marketplace for Mobile 何时在他们的地区可用。开发者还会问，既然 Marketplace 在他们的地区尚未可用，他们是否可以在其他地区注册销售应用程序（例如：一名来自以色列的开发者想注册在美国销售）。对于这些问题，微软员工最常见的回复是，微软正在寻求扩大地理覆盖范围，届时将提供更多信息。扩大 Marketplace 覆盖范围的计划似乎没有公开披露。到目前为止，似乎一个人是否有资格注册销售或购买应用程序取决于他们的地区是否支持 Marketplace。如果 Marketplace 在您的地区不可用于购买应用程序，那么您也无法在您的地区或任何其他地区注册销售。

问题？

我已重点介绍了我的想法和经验。如果您希望我扩展任何方面，请在评论区提出问题，我将尽力回答。如果您对 Marketplace 有一般性问题，最好的提问地点是Microsoft Windows Marketplace for Mobile 开发者论坛。

历史

• 2010 年 3 月 21 日 - 初次发布。