每一个Windows Phone开发者都比较清楚，向微软的Windows Phone应用商店提交审核时，开发者被要求在提交过程中，微软要对其程序进行验证。该过程包括检查元数据和验证上传的XAP文件。程序集和数据文件必须打包成XAP文件包。Visual Studio 2010 Express for Windows Phone 可以生成必要的XAP包和清单文件。
XAP软件包提交注意事项
XAP包文件的最大大小为225MB。也就是说，你不要试图开发超过225MB以上的大应用。例如大型的3D游戏，将超大容量的视频等内容打包等。
XAP包必须包含以下内容：
1. 一个名为 WMAppManifest.xml 的有效 Windows Phone 应用程序清单文件。
2. WMAppManifest.xml 文件中的 <Title> 元素必须包含应用程序标题。<Title> 元素不得为空。在提交过程的步骤 2 中输入 Windows Phone 商城 的“应用程序标题”和显示在该手机上的标题必须相同。
3. 一个名为 AppManifest.xml 的有效 .NET 应用程序清单文件。
4.AppManifest.xml 文件中指定的程序集文件。
如果你希望显示在手机“应用”列表上的手机应用小磁贴。游戏必须使用手机应用大磁贴替换手机应用小磁贴。手机应用小磁贴必须为 62 x 62 像素的 PNG 文件。
要在用户将应用程序固定到手机“开始”屏幕体验上的快速启动区域时显示的手机应用大磁贴。手机应用大磁贴必须为 173 x 173 像素的 PNG 文件。
#p#
应用程序代码验证
WP开发者要想顺利提交应用，必须使用Windows Phone应用程序平台 上应用程序目标操作系统版本支持的规定API开发应用程序。
应用程序不得通过 PInvoke 或 COM 互操作调用本机代码。如果调用，则认证过程会失败。
应用程序必须使用发布配置而不是调试进行编译。应用程序不得包含调试符号或输出。
应用程序不得重新分发 Windows Phone 程序集。但是可以重新分发全景图、数据透视图和地图程序集。
在使用 System.Windows.Controls 命名空间中的任何方法时，应用程序不得调用 Microsoft.Xna.Framework.Game 程序集或 Microsoft.Xna.Framework.Graphics 程序集中的任何API。
#p#
各种应用截图提交注意事项
1.Windows Phone商城图解
对于每个应用程序，必须提交一个图标以将你的应用程序显示在 Windows Phone 商城 目录中。此图标必须密切匹配 XAP 包中提供的图标。当用户在购买前浏览手机上的应用程序目录时，会看到此图标。
切记：不要将透明 PNG 图像文件用于以下手机应用程序图标。
◆手机应用小磁贴图标（必选），用于手机 Windows Phone 商城，大小为 99 x 99 像素。
◆手机应用大磁贴图标（可选），用于手机 Windows Phone 商城，大小为 173 x 173 像素。
◆PC应用大磁贴图标（必选），用于手机 Windows Phone 商城，大小为 200 x 200 像素。
◆背景照片（可选），用于背景全景图，大小为 1000 x 800 像素。
2.应用程序屏幕截图
对于每个应用程序，必须提供至少一个或最多八个屏幕截图。用户在购买之前，会在目录的详细信息页面中看到这些屏幕截图。
屏幕截图必须只包含应用程序图形，不得包含任何模拟器镶边、帧速率计数器或调试信息。不能以图形方式增强屏幕截图，但添加由微软指定和预先批准的信息性覆盖内容除外。
3.应用程序磁贴图像
手机应用大磁贴和小磁贴图像必须代表应用程序。
#p#
微软的应用程序策略
为了保护Windows Phone商城服务和服务的用户，也为了满足手机运营商的要求，微软已为Windows Phone商城中提供分发的应用程序建立了一些策略和条款，并且特别指明：微软保留根据需要更新这些策略的权利。（你懂的）作为WP应用开发者这些条款都是需要在开发之前就牢记在心的。
1.当从Windows Phone商城中获取时，应用程序必须功能完善（除了下面允许的其他数据以外）。除非与用户预先存在帐单关系，否则应用程序可不得要求用户提供支付信息（在该应用程序体验内）来激活、解锁或延长应用程序使用期。
2.应用程序不得出售、链接到或推销手机语音计划。
3.应用程序不得危害Windows Phone手机或Windows Phone 商城的安全或功能。
4.如果应用程序包含或显示广告，则该广告必须遵守微软广告创意接受政策指南，并且该应用程序除了显示广告之外，还必须具有鲜明的、实质性的、合法的内容和目的。
5.如果应用程序需要下载其他大型数据包（例如，大于50MB的地图）才能使该应用程序按上述方式运行，则该应用程序描述必须显示该数据包的近似大小以及可能收取的额外费用，具体取决于用于获取数据的连接。
6.如果应用程序允许聊天、收发即时消息或进行其他面对面的通信，而且允许用户从移动设备中设置或创建自己的帐户或 ID，则该应用程序必须包含一个机制，用来验证创建帐户或ID的用户至少有13岁。
7.以下要求适用于接收用户移动设备的位置的应用程序：
（1）应用程序必须使用微软定位服务API确定位置。
（2）应用程序的隐私策略必须通知用户如何使用和显示定位服务API中的位置数据，以及用户对位置数据使用和共享的控制。位置数据可以由应用程序承载，或直接与应用程序相链接。
（3）应用程序必须提供应用程序内设置，允许用户启用或禁用对定位服务API中位置的访问和使用。
（4）如果应用程序将从定位服务API获取的可用位置数据发布到其他服务或透露给其他人员（包括广告网络），则应用程序必须实现一种方法来获得选择性同意。要“实现一种获得‘选择性’同意的方法”，该应用程序必须：
(a) 首先介绍使用或共享位置信息的方式；
(b) 在按上述方式发布位置信息之前，先获取用户的明确权限；
(c) 提供一个机制，通过该机制用户可以稍后不再发布位置信息。应用程序必须定期提醒用户或提供可视指示器，表明位置数据已被发送到任何其他服务或个人。
（5）应用程序不得覆盖、回避或禁止任何与定位服务 API 相关的 Microsoft Toast 通知或提示。
（6）应用程序不得覆盖或回避用户在移动设备上禁用定位服务的选项。
（7）必须仅在交付应用程序向用户提供的位置感知功能时，应用程序才请求位置并保留和使用来自位置服务 API 的位置数据。
（8）应用程序必须采取措施，阻止未经授权的访问、使用或泄露从定位服务 API 中接收的位置数据。
8.如果应用程序与第三方（例如其他服务或个人）共享用户的个人信息（包括，但不限于联系人、照片、电话号码、短信、浏览历史记录或合并了用户信息的唯一手机或用户 ID），则该应用程序必须实现一种方法以获取“选择性”同意。要“实现一种获得‘选择性’同意的方法”，该应用程序必须：
提供隐私策略，其中至少必须描述将如何使用或共享个人信息；在按上述方式共享信息之前，请先获取用户的明确权限；以及提供一个机制，通过该机制用户可以稍后不再共享信息。
9.如果应用程序使用微软推送通知服务，则应用程序和微软推送通知服务的使用必须遵守以下要求：
（1）应用程序必须首先介绍要提供的通知并获取用户的明确许可（选择性获取），而且必须提供一个机制，通过该机制用户可以不接收推送通知。使用微软推送通知服务提供的所有通知必须与提供给用户的介绍保持一致，并且必须遵守所有适用的应用程序策略、内容策略和特定应用程序类型的其他要求。
（2）该应用程序及其使用微软推送通知服务不得过度使用微软推送通知服务的网络容量或带宽，否则过多的推送通知会加重 Windows Phone 或其他微软设备或服务的负担（由微软经过合理的考虑决定），而且不得损害或干扰任何微软网络或服务器或任何连接到微软推送通知服务的第三方服务器或网络。
（3）微软推送通知服务不得用于发送包含重要任务的通知，否则可能会影响性命攸关的事情，包括但不仅限于与医疗设备或条件相关的重要通知。微软特别声明不会对使用微软推送通知服务或提供微软推送通知服务通知将不会被中断、不会出现错误或保证实时出现提供任何保证。
10.应用程序必须具有独特、实用且合法的内容和用途。应用程序必须提供相关功能，而不是用来启动网页。
#p#
特定应用程序类型的其他审核要求
除却严格的提交格式和API函数之外，微软对于WP应用中一些较为特别的功能，还有一些追加的要求。这些也是开发者应该注意和遵循的。
一、位置感知应用程序
用户可以从“系统设置”页面关闭手机上的定位服务。在手机上的定位服务关闭时，位置感知应用程序必须仍然保持响应能力。
建议：显示用户友好消息以指示位置数据不可用。
二、推送通知应用程序
微软推送通知服务会提供一个灵活持久的专用通道，用于将通知从 Web 服务推送到移动设备。但在 UI 或“设置”菜单中，该应用程序必须向用户提供单独禁用 Toast 通知的功能。你的应用程序第一次使用 BindToShellToast()()()() 方法时，该应用程序必须要求用户提供显式权限才能接收 Toast 通知。
建议：使用“允许 Toast 通知”作为此设置的文本标签。只需要在第一次使用 BindToShellToast 方法时要求用户提供权限即可。不需要再次要求用户提供权限。例如，如果每次加载应用程序时该应用程序都要调用 BindToShellToast，则只需在第一次启动该应用程序时提示用户即可。
三、在锁定屏幕下运行的应用程序
通过设置 ApplicationIdleDetectionMode 属性，前台中的应用程序就能够在锁定手机屏幕的情况下继续运行。当应用程序在锁定屏幕下运行时，消耗的电量可能不受用户控制，并且可能会无意中增加自身的数据费用。因此，必须最大限度地降低你的应用程序在锁定屏幕下运行时的用电量。（微软对于耗电大的应用，会把关很严格。）
应用程序在锁定条件下运行时，微软强烈建议你使用以下新功能，而不是设置 ApplicationIdleDetectionMode 属性。
对于锁屏状态下微软要求：
当通知锁定屏幕时，在锁定屏幕下运行的所有应用程序均必须停止全部 UI 更新、活动定时器及其他不重要的处理工作。
应用程序在锁定屏幕下播放音频时，手机电池的最短使用时间必须大于六小时。
如果手机锁定时应用程序未播放音频，则手机屏幕锁定时该应用程序必须仍然保持空闲。
应用程序在锁定屏幕下运行时，手机电池的最短使用时间必须大于 120 小时。
四、“音乐 + 视频”中心应用程序
“音乐 + 视频”中心的应用程序在手机上提供综合音乐和视频体验，这也是它的主要功能。当应用程序调用 MediaHistory 或 MediaHistoryItem 类时，如果手机上已安装该应用程序，则会视为“音乐 + 视频”中心应用程序并将显示在“附加程序”列表中（在 Windows Phone OS 7.0 中称为“字幕”列表）。提交过程会检测该应用程序是否使用这些类，并自动将中心类型更新到 Windows Phone 应用程序清单文件中的“音乐 + 视频”。
微软的要求：
应用程序功能必须与视频和/或音乐媒体播放相关。
当用户点按的磁贴与“音乐 + 视频”中心的“历史记录”或“正在播放”列表中的应用程序相关联时，该应用程序必须 (a) 启动该磁贴中标识的内容的播放体验，或者 (b) 启动提供先前播放的媒体内容相关信息的视图并允许用户继续播放。当用户在“音乐 + 视频”中心的“历史记录”、“正在播放”或新列表中点按内容磁贴时，该应用程序不得启动主登录页面或默认登录页面。
当应用程序播放媒体时，该应用程序必须更新“音乐 + 视频”中心的“历史记录”列表。
当媒体被添加到手机或用户在应用程序中创建“对象”时（例如，创建收音机电台、创建音乐标记），该应用程序必须更新“音乐 + 视频”中心的“新建”列表。
当媒体与容器相关联时，“音乐 + 视频”中心的“新建”列表和“历史记录”列表中的中心磁贴必须表示一个有效的容器（例如相册、艺术家、播放列表、收音机电台，而不是各个媒体项目）。
“音乐 + 视频”中心的中心磁贴不得包含广告、媒体源或其他未经请求的内容。
五、播放媒体的非“音乐 + 视频”中心应用程序
应用程序运行时可以在后台播放媒体，即使在其主要功能与音乐或视频不相关的情况下也是如此。微软对播放音乐、音频或声音效果的应用程序提出了以下要求：
在程序的初始启动时，如果应用程序启动时用户已在手机上播放音乐，则该应用程序不得通过调用 Microsoft.Xna.Framework.Media.MediaPlayer 类暂停、继续或停止手机 MediaQueue 中播放的音乐。如果应用程序播放自带的背景音乐或调整背景音乐的音量，则必须征得用户同意才能停止播放/调整背景音乐（例如消息对话框或设置菜单）。此提示必须在每次启动应用程序时出现，除非已为用户提供选择设置并且用户已采用此设置进行选择。
可配置的功能方面，如果应用程序播放背景音乐，则该应用程序必须向用户提供背景音乐和背景音乐音量的可配置设置。
在播放时，应用程序无需征得用户同意即可中断手机上当前正在播放的音乐，以播放非交互式的全动态视频或非交互式的音频段（例如影片剪輯或媒体剪辑）。关闭应用程序后，该应用程序必须继续播放先前播放的音乐。
特效方面，SoundEffect 类不得用于在应用程序中播放连续的背景音乐曲目。
#p#
心得总结
微软为开发者制定了许多严格的条款，作为WP应用平台的开发者，对这些内容一定要有深刻的了解，而微软设下的这道“门”也必有其道理。
我一直认为门是用来打开的，所以才会装了合叶和把手。你设置了阻碍，而其他人必定会设法跨越。人类就是这样好奇未知，而忽视显而易见的真知本性。因此，门的存在是有其必然的道理。
微软正在高压打击的方面一定不要去尝试跨越。另一方面，这些严苛的条款对于最终的用户是好的。我们可以明显看到，微软在尽力保障用户的电池续航时间，在严格的保护用户敏感的隐私。同时微软也在极力的保证其Metro UI的设计理念能够深入的贯彻到每一个应用中。总之，上述的这些条款都是微软该作的，也是不得不作的。最后预祝各位开发者的应用提交流程一帆风顺。
【编辑推荐】
