Office 2010 应用程序兼容性指南

 

适用于: Office 2010

上一次修改主题: 2017-01-17

针对 Microsoft Office 2010 部署的应用程序兼容性测试和修正过程可确定兼容性问题,并帮助您制定解决这些问题的计划。此类信息主要对将评估和缓解应用程序兼容性问题的 IT 专业人员有用。要升级 Office 应用程序的开发人员也可能发现此类信息有用。完成本文中介绍的过程后,管理员和开发人员将可以更好地了解哪些加载项和应用程序与 Office 交互,以及如何将它们迁移到 Office 2010。

本文不介绍文档兼容性、转换或迁移。有关如何转换旧版 Office 文件和使用兼容模式的信息,请参阅Office 2010 的文档兼容性

本文内容:

  • Office 2010 中的应用程序兼容性简介

  • 应用程序兼容性评估和修正过程

  • 规划兼容性测试

  • 评估环境

  • 测试和修正兼容性问题

Office 2010 中的应用程序兼容性简介

自从 Office 产品首次推出以来,开发人员和专家用户就一直在编写代码来扩展 Office。随着 Office 的逐渐发展(功能变更、功能删除和文件格式更改),较旧的加载项和自定义项在用于 Office 2010 时可能无法正常工作的可能性也在不断变化。因此,对于拥有十年前或更早的 Office 文件的组织来说,应用程序兼容性这个话题很具挑战性也就毫不奇怪了。

Office 2010 具有许多产品改进功能以及可能影响与现有文件、宏、加载项和 Microsoft Visual Studio 解决方案的兼容性的其他变更。下面的列表描述了其中一些变更。

  • 已删除的功能   依赖已从 Office 2010 删除的功能(及其相应对象模型)的加载项和应用程序会中断。

  • 功能变更   更新的功能及其对象模型可能导致加载项和应用程序无法按预期运行。有时这些变更显而易见,而有时只在全面测试之后才会发现。

  • 64 位不兼容性   Office 2010 同时具有 32 位和 64 位版本。64 位版本是为需要更多内存容量来处理复杂的 Microsoft Excel 电子表格或 Microsoft Project 文件的用户设计的。如果您计划部署 64 位版本的 Office,则必须考虑创建的用于在 32 位客户端计算机上运行的 ActiveX 控件、加载项和 Microsoft Visual Basic for Applications (VBA) 解决方案可能无法用于 64 位版本的 Office 2010。

提供了几种工具和解决方案来评估和修正与 Office 2010 的应用程序兼容性问题。对于 IT 管理员,新的 Office 环境评估工具 (OEAT) 可帮助识别与 Office 交互的加载项和应用程序。开发人员可以通过使用新的 Microsoft Office 2010 代码兼容性检查器工具查明 VBA 项目或 Visual Studio 代码中的潜在不兼容代码来执行其他测试。在无法修复应用程序的情况下,管理员可以使用远程桌面服务(终端服务)、并行安装和新的 Microsoft Application Virtualization (App-V) 等解决方案来同时维护以前的兼容 Office 环境和 Office 2010。

以下各节简单介绍了 Office 2010 应用程序兼容性评估工具。

Office 环境评估工具 (OEAT)   OEAT 是 Office 2010 的用于识别用户计算机上安装的加载项的新扫描工具。OEAT 收集并报告 Microsoft Office 97、Microsoft Office 2000、Microsoft Office XP、Microsoft Office 2003 和 2007 Microsoft Office system 的加载项信息。OEAT 还将发现的第三方加载项列表与独立软件供应商 (ISV) 应用程序兼容性可见性计划跟踪的兼容加载项列表进行比较。

若要下载 OEAT,请参阅 Office 2010 工具:Office 环境评估工具(该链接可能指向英文页面) (https://go.microsoft.com/fwlink/?linkid=171092\&clcid=0x804)(该链接可能指向英文页面)。

ISV 应用程序兼容性可见性计划   此新计划跟踪保证其产品与 Office 2010 兼容的独立软件供应商 (ISV)。ISV 通过特殊的 ISV 门户提交有关其产品的信息,并且 Microsoft 将此列表发布到 Microsoft Office 2010 的兼容性资源中心 (https://go.microsoft.com/fwlink/?linkid=186766\&clcid=0x804)。OEAT 还使用此列表在摘要报告中突出显示已知的兼容加载项。

若要查看参加此计划的 ISV 的最新列表,请参阅 Microsoft Office 2010 的兼容性 (https://go.microsoft.com/fwlink/?linkid=186766\&clcid=0x804)。

Microsoft Office 2010 代码兼容性检查器 (OCCI)   Microsoft Office 2010 代码兼容性检查器将对 Office 2010 不兼容的对象模型 API 调用的现有 VBA、Visual Basic .NET 和 C# 源代码进行比较。该工具与 Microsoft Visual Basic for Applications 7.0 (VBA 7) 和 Microsoft Visual Studio 2008 或 Microsoft Visual Studio 2010 集成,并且包括基本扫描程序。当检查器工具找到与 Office 2010 不兼容的代码时,该工具会为代码添加注释以供开发人员参考和以后修复。检查器工具还扫描代码中由 ActiveX 控件使用的 Declare 语句和对 DLL 的引用,需要更新这些控件才能与 64 位 Office 2010 兼容。

若要下载 OCCI,请参阅 Office 2010 工具:兼容性检查器(该链接可能指向英文页面) (https://go.microsoft.com/fwlink/?linkid=181874\&clcid=0x804)(该链接可能指向英文页面)。

下表描述了许多组织都会遇到的基于 Office 的自定义项的种类以及用于评估每种自定义项的工具。因为其中一些自定义项通用于早期版本的 Office,所以指向其他信息的链接通常指向 Office 2003 及更早版本的开发人员文档。

自定义项的类型 说明 评估工具

自动化加载项(.xll 或 .wll)

自动化加载项使开发人员能够将现有 Office 2010 应用程序的功能合并到自定义应用程序中。Office 自动化加载项的一个示例是将客户的帐单数据写入 Microsoft Excel 工作表中的 CRM 应用程序。

有关自动化加载项的详细信息,请参阅 Excel COM 加载项和自动化加载项 (https://go.microsoft.com/fwlink/?linkid=186622&clcid=0x804)。

OEAT

COM 加载项 (Windows .dll)

COM 加载项是作为 Microsoft Office 2000 的一部分引入的,使开发人员能够使用自己选择的编程语言和环境来创建基于 Office 的解决方案。编写了 COM 加载项后,它将编译为一个 .dll 文件。该 .dll 文件可由一个或多个 Office 应用程序加载,并可与 Office 对象模型交互。

有关 COM 加载项的详细信息,请参阅什么是 COM 加载项?(该链接可能指向英文页面) (https://go.microsoft.com/fwlink/?linkid=186623&clcid=0x804)(该链接可能指向英文页面)。

OEAT

Office 97–2003 格式的 VBA 加载项(.dot, .wll, .xla, .xll, .ppa)

Office 2007–2010 格式的 VBA 加载项(.dotm, .xlam, .ppam)

VBA 模板加载项是通过使用 Microsoft Visual Basic for Applications (VBA) 创建的。

有关 VBA 加载项的详细信息,请参阅 Office 2010 中的 VBA 入门 (https://go.microsoft.com/fwlink/?linkid=186624&clcid=0x804)。有关 Microsoft Word 模板与加载项之间的区别的说明,请参阅 Word 文档模板与 Word 加载项(全局模板)(该链接可能指向英文页面) (https://go.microsoft.com/fwlink/?linkid=186625&clcid=0x804)(该链接可能指向英文页面)。

OEAT 和 OCCI

Office 2007–2010 格式的启用 VBA 宏的文件(.docm, .xlsm, .pptm)

这些文件包含 VBA 宏代码但未保存为加载项。

OEAT 将检测存储在 Startup 文件夹中或作为全局模板加载的启用宏的 Word 和 Excel 文件。OEAT 不会发现存储在其他位置的启用宏的文件,OEAT 也不会发现位于任何位置的启用宏的 PowerPoint 文件。

有关启用宏的文件的详细信息,请参阅 Office 2010 中支持的文件格式

OEAT 和 OCCI

使用 Visual Studio 创建的 Office 加载项

通过使用 Visual Studio 创建的 Office 加载项,组织能够自定义 Office 应用程序以添加业务流程所需的特定功能。

Visual Studio 支持两种可能在贵组织中使用的解决方案:

  • 文档级自定义项   这些自定义项包括一个与 Microsoft Word 或 Microsoft Excel 中的单个文档、工作簿或模板相关的程序集。文档级自定义项中的功能只在相关文档打开时可用。这些自定义项无法进行应用程序范围的更改,例如在任何文档打开时显示新菜单项或功能区选项卡。

  • 应用程序级加载项   这些加载项包括一个与 Office 应用程序相关的程序集。该加载项可调用对象模型来自动化和扩展应用程序,并且它可以使用 Microsoft .NET Framework 中的任意类。

OEAT 只可用于检测应用程序级加载项。

有关使用 Visual Studio 创建的 Office 加载项的详细信息,请参阅 Office 解决方案开发概述(该链接可能指向英文页面) (https://go.microsoft.com/fwlink/?linkid=188380&clcid=0x804)(该链接可能指向英文页面)。

OEAT 和 OCCI

应用程序兼容性评估和修正过程

下图显示了应用程序兼容性评估和修正过程的摘要。此图中定义的每个任务在本文中均具有对应的章节。

应用程序兼容性流程

备注

本指南不介绍文档兼容性、转换或迁移。有关如何转换旧版 Office 文件和使用兼容模式的信息,请参阅Office 2010 的文档兼容性

规划兼容性测试

规划加载项和应用程序的评估、修正和试用是应用程序兼容性测试的总体过程中很重要的第一步。虽然您可能很想依赖以前的 2007 Office system 兼容性测试结果,但我们建议不要这样做,这只会延迟成功部署。

规划评估

以下各节介绍了将帮助您准备评估组织中的加载项和应用程序的规划任务。

为评估文档和结果创建中央存储库

为帮助管理评估和修正过程,我们建议您构建一个已发现的应用程序及其状态的中央存储库。Microsoft SharePoint Server 2010 之类的解决方案可帮助保持所有项目成员最新并保持项目本身正常运转。

确定利益干系人

利益干系人是审批资源并将资源分配给项目的人或组。通过在早期的规划过程中确定利益干系人,应用程序兼容性项目工作组可以将项目可交付结果传送给具有既定兴趣的人并进行验证。

下表描述了应用程序兼容性项目中的典型利益干系人角色。

角色 责任

应用程序所有者

确保通过使用以前的 Office 版本完成的业务流程在升级后仍是连续的。

项目赞助商

促进组织内 Office 升级的成功和正面宣传。

为项目参与者分配角色

下表描述了必须在应用程序兼容性项目中填补的可能角色及其各自的责任。

角色 责任

项目经理

确保项目的总体流程,并管理总体资源、指标和风险。

兼容性验证测试人员

按照测试计划测试 Office 组件中是否存在任何潜在不兼容问题,包括文件格式、宏、加载项或 Office 自动化。

OEAT 操作员

了解并执行 OEAT 的安装和配置。

修正负责人

执行用于解决有关 Office 自定义项的兼容性问题的操作。

回归测试人员

确保对 Office 对象执行的修正成功。此角色通常由修正负责人担当。

用户验收测试人员

受影响业务部门的代表,用于确定应用程序修正成功并且它没有干涉其他自定义项或操作。这决不应是执行修正或回归测试的人。

业务分析师或所有者

拥有对业务部门很重要的应用程序和加载项的代码和文档。

部署组负责人

负责并跟踪完整技术过程的适时性。可能委派一些报告或管理活动。

应用程序打包组

负责 Office 2010 安装包。

客户端(桌面)工作组

负责通过组织的配置管理工具(例如 System Center Configuration Manager (SCCM))进行的 Office 2010 包的部署。

服务台

为测试人员提供 Office 的功能支持,并在迁移完成后,为用户提供此支持。

确定并访问业务部门

评估规划的下一步是确定部门或业务部门分组并访问其代表以了解当前的这组加载项如何满足其业务需求。了解每个加载项的重要性、目的、创建原因、用途和创建者对做出有关如何修正加载项和更正已发现问题的明智决策都很重要。

Office 应用程序的一些加载项可能并不是在组织中正式创建的。因此,您可能需要进行一些调查工作来跟踪所有者和原始源代码(如果仍存在)。

您可以使用下表作为访问调查表的模板。

应用程序信息

业务部门

应用程序名称

应用程序联系人/所有者

应用程序 ID

版本

优先级

Office 2010 兼容性状态(如果知道)(通过、未通过)

兼容性问题描述(如果有)

用户数量

应用程序使用的 Office 版本(XP、2003、2007、2010 等等)

描述用法种类(例如,导出 Office 文档、Office 应用程序加载项等等)

应用程序使用的 Office 套件组件

Word

Excel

Access

PowerPoint

其他

此应用程序是否使用复杂的 Office 对象(例如图表、数据透视表或绘图)?

它是否是数据输入或前端应用程序?如果是,请提供详细信息。

应用程序支持哪些语言?

确定要扫描的客户端计算机

确定了需要扫描其客户端计算机的不同业务部门后,可以为每个业务部门启动确定客户端计算机的统计相关样本的过程。并非组织中的每个客户端计算机都需要扫描。不过,在一些情况下(具体取决于组织规模),扫描整个环境或者整个组或组织单位 (OU) 可能比描述要参与的各个客户端计算机的限制性更小(或更容易)。仅仅 20% 的统计相关样本可提供足够的信息来成功评估和修正您的 Office 2010 环境中的兼容性问题。

重要

运行 OEAT 的所有客户端计算机都必须安装 Microsoft .NET Framework 2.0 或更高版本。有关 OEAT 要求的详细信息,请参阅 用于 Office 2010 的 Office 环境评估工具 (OEAT) 用户手册

如果贵组织缺乏最新的客户端清单,请考虑运行 Microsoft Assessment and Planning (MAP) Toolkit 来生成客户端清单并评估 Office 2010 准备情况。通过此清单,您可以与业务组负责人合作来选择一部分客户端计算机以使用 OEAT 进行评估。有关 MAP Toolkit 的详细信息,请参阅 Microsoft Assessment and Planning Toolkit (https://go.microsoft.com/fwlink/?linkid=149448\&clcid=0x804)。

规划修正

以下各节将帮助您确定用于分类和修正不兼容应用程序的基准标准。在规划过程的早期达成协议将帮助您避免在获得评估和测试结果后出现分歧或其他延迟。

确定将如何分类应用程序并确定其优先级

企业开发、部署并维护各种基于 Office 的应用程序和加载项,所有这些都可能对组织具有显著不同的价值。因此,基于应用程序对业务的价值将应用程序组织到类或层很重要。一种简单的方法是将应用程序分类为是否为任务关键型。应考虑的其他分类如下所示:

  • 内部应用程序和第三方应用程序

  • 部门应用程序

  • 非托管解决方案,例如最终用户创建的模板、加载项和宏

  • 应用程序的用户数量

  • 由主管人员使用应用程序

  • 应用程序的预期生存期

下表描述了组织可能如何对不同种类的 Office 自定义项进行分类和确定其优先级。

自定义项 任务关键型 非任务关键型

自动化加载项

主动 OEAT 扫描、测试和修正

应对用户发现

COM 加载项

主动 OEAT 扫描、测试和修正

应对用户发现

VBA 加载项

主动 OEAT 和 OCCI 扫描、测试和修正

应对用户发现

为进一步帮助确定任务关键型应用程序的优先级,可以将它们分类为层 1、层 2 或层 3。每个层的示例分类指南如下所示:

  • 层 1:任务关键型   任务关键型应用程序失败会损害组织的业务连续性或收入。主管人员使用的任何应用程序应视为任务关键型,而不管用户数量是多少或应用程序的业务优先级是什么。此层还包括超过 10% 的组织用户使用的应用程序。

  • 层 2:业务关键型   这些应用程序是业务关键型应用程序或由 10% 甚至更多组织用户使用。此层还可以包括由 1% 至 10% 的组织用户使用的应用程序,并可以是任何业务优先级。这些不是任务关键型应用程序或影响收入的应用程序。不过,它们可通过影响工作效率来间接增加费用或减少收入。

  • 层 3:业务应用程序   这些应用程序不是任务关键型应用程序,受其影响的组织员工少则 10 名,最多可达 1%。它们通常是可帮助执行小型任务并对业务影响较低的工具。

确定修正策略

定义应用程序分类标准后,应确定潜在修正策略。虽然实际的修正工作很难规划,但是您可以确定可指导解决每种自定义项的问题的一般策略。下表提供了基于应用程序种类及其预期生存期建议的修正策略。

类型 潜在策略

生存期有限的内部应用程序

停用应用程序并找到新过程。

生存期较长的内部应用程序

重写或修改代码以符合新对象模型。

生存期有限的第三方应用程序

停用应用程序并找到新过程。

生存期较长的第三方应用程序

与供应商联系以获取更新或更换。

应用程序不工作

使用新目录结构重新安装应用程序,或为应用程序创建虚拟环境。

在修正应用程序时,您可能发现它们的优先级在初始评估后发生更改。您应为修正评估设置严格的过程以便只允许应用程序在层中上移(但不能下移)。有关 Microsoft IT 如何分类应用程序并确定其优先级的信息,请参阅在 Microsoft 内部部署 2007 Office system(该链接可能指向英文页面) (https://go.microsoft.com/fwlink/?linkid=178278\&clcid=0x804)(该链接可能指向英文页面)。

Microsoft 还在 TechNet 上提供了有关在迁移 Office 自定义项时出现的已知问题的说明性信息。有关详细信息,请参阅 Office 2010 中的产品和功能更改。Microsoft 合作伙伴还提供了可帮助执行修正过程的工具。

规划试用

项目工作组必须考虑将如何试用加载项和应用程序。具体来说,工作组应确定以下各项:

  • 哪些用户将参与试用。

  • 试用中的用户将如何报告问题。

  • 支持人员是否将帮助试用,如果是,将如何培训他们。

  • 试用的开始时间。例如,一些组织在规划过程的早期阶段开始试用测试,以便随着过程的推进获得早期反馈。

以下资源可用来帮助您规划试用。这些资源并不特定于 Office 2010 兼容性测试。不过,这些资源中介绍的许多原则仍适用。

评估环境

在评估阶段,通过对一部分与统计相关的客户端计算机运行 OEAT,收集加载项和应用程序的清单。在分析完结果并确定应用程序优先级后,就可以进入测试和修正阶段了。

运行 OEAT

OEAT 可从网络共享运行或分发给用户。OEAT 扫描客户端计算机,然后将扫描结果保存到指定位置,通常为网络共享。扫描完成后,您可以使用 OEAT 将结果编译到 Microsoft Excel 电子表格中以便在修正过程中使用。

根据您的环境,可以采用以下方式之一部署 OEAT:

  • Active Directory 环境   使用 Active Directory 登录脚本部署 OEAT。在用户登录时,会自动执行 OEAT,并将结果保存到指定位置。

  • 托管环境   使用管理解决方案(例如 Systems Management Server (SMS) 或 System Center Configuration Manager (SCCM))部署 OEAT。

  • 非托管或非集中 IT 环境   为 OEAT 创建共享并为用户提供有关如何手动运行扫描的说明。

有关如何部署和使用 OEAT 的信息,请参阅用于 Office 2010 的 Office 环境评估工具 (OEAT) 用户手册。若要下载 OEAT,请参阅 Office 2010 工具:Office 环境评估工具(该链接可能指向英文页面) (https://go.microsoft.com/fwlink/?linkid=171092\&clcid=0x804)(该链接可能指向英文页面)。

查看 OEAT 结果

在客户端计算机扫描完成后,使用 OEAT 中的“Compile results”选项创建一个汇总了已扫描的所有客户端计算机结果的电子表格。该电子表格包含多个工作表,其中包括:

  • SummaryReport   此工作表包含的摘要信息有助于确定已扫描客户端计算机是否为 Office 2010 做好准备。此工作表包括有关平均可用空间、处理器、计算机制造商、Windows 安装(包括 Service Pack 级别)和 Office 安装的数据。从配置管理角度看,生成的数据可能很重要,原因是客户端计算机可能没有运行预期的 Office 或 Windows 版本。

  • MicrosoftOfficeAddins   此工作表包含 Office 附带的所有加载项的列表。

  • AddinsNotShippedWithOffice   此工作表包含 Office 未附带的所有加载项的列表。您的许多评估和规划都将来自此报告。您可以按应用程序排序列表、查看上次的访问或修改日期以及查看在其上检测到加载项的客户端计算机的数量。您还可以比较相同加载项的版本号以确定其中一部分客户端计算机是否已过时,这将指示组织中的配置管理过程是否存在问题。

AddinsNotShippedWithOffice 工作表上,从“Compatibility”列开始查看每个加载项的兼容性状态。OEAT 通过将已发现的加载项与 ISV 兼容性计划所跟踪的兼容加载项列表相比较,来为此列生成数据。可能的兼容性状态结果如下所示:

  • UNKNOWN   加载项当前未在与 Office 2010 兼容的加载项的 Microsoft 供应商列表中。因此,此加载项的状态为未知。请注意,在向 OEAT 提供了新供应商数据时,此状态可能发生更改。每次编译电子表格时,都可以选择下载新供应商数据。

  • PARTIAL MATCH   OEAT 在以下两种情况下报告此状态:OEAT 仅为供应商名称找到了匹配项。或者,OEAT 为供应商名称和产品名称找到了匹配项,但版本号不匹配。使用 URL 列中提供的链接来检查供应商提供的兼容加载项的供应商列表。

  • EXACT MATCH   在供应商名称匹配,产品名称匹配,并且加载项的版本号等于或大于供应商报告的版本时,显示此状态。

重要

如果您在 OEAT 的最终版本中出现提示时选择不下载兼容性数据,或使用的是 OEAT 的 Beta 版本,则不会显示 Compatibility 列。可以从 Microsoft 下载中心(该链接可能指向英文页面)下载 OEAT 的最终版本。

完成修正规划

此时,您已准备好使 OEAT 结果与在规划阶段确定的优先级标准相关联。在为此工作设置计划时,确保您额外留出了时间来调查在业务部门访问期间未识别的加载项并确定其优先级。若要了解 VBA 加载项和 Visual Studio 加载项的不兼容范围,开发工作组可以在此阶段运行 OCCI 以了解将需要更改多少基础代码。

测试和修正兼容性问题

在此阶段,您和您的开发工作组将开始测试任务关键型加载项和应用程序以及其他高优先级加载项和应用程序,以查找与 Office 2010 的特定兼容性问题。找出不兼容问题后,开发工作组将开始根据您在规划阶段所做的工作修正不兼容的加载项和应用程序。

在修正多个应用程序和加载项时,不能假定这些修正会一起运行。您必须同时测试所有修正,然后在实际方案中试用这些修正。在验证修正、稳定 Office 2010 的总体部署以及最终创建更成功的迁移时,每一步都很重要。

测试加载项和应用程序

以下流程图为测试不同种类的应用程序以识别与 Office 2010 的不兼容问题的开发人员提供一般指南。有关其他指南,请参阅以下资源:

一般应用程序测试

以下流程图概述了应用程序测试。本节中的后续流程图介绍特定种类的 Office 应用程序(例如加载项、宏和脚本以及 Office 自动化测试)的测试过程。

应用程序测试流程图

Office 加载项测试

Office 加载项测试流程图

宏和脚本测试

宏测试流程图

Office 自动化测试

Office 自动测试流程图

运行 Office 代码兼容性检查器工具

作为总体测试过程的一部分,开发人员可以运行 OCCI 工具来扫描对对象模型成员的已知更改或弃用。OCCI 还扫描 ActiveX 控件所用的 VBA Declare 语句和对 DLL 的引用,需要更新这些控件才能与 64 位 Office 2010 兼容。在该工具遇到潜在兼容性问题时,它会在代码中添加注释以使开发人员注意此问题。

每次检查器扫描完成后,都会提供在项目中找到的内容的摘要和详细报告。扫描的项目包括:

  • 更改   标记对对象模型成员的任何语法更改。OCCI 检测自从 Office 97 以来更改的任何对象模型成员的用法。

  • 弃用   标记弃用的对象模型成员的任何用法。OCCI 检测自从 Office 97 以来弃用的任何对象模型成员的用法。

有关如何使用 OCCI 的详细信息,请参阅 Microsoft Office 代码兼容性检查器用户指南。有关应用程序特定的开发资源,例如有关自 Office 早期版本以来发生更改的对象模型的详细信息,请参阅 Microsoft Office 2010 (https://go.microsoft.com/fwlink/?linkid=206197\&clcid=0x804)。

修正加载项和应用程序

更正具有与 Office 2010 的兼容性问题的应用程序或加载项的方法有多种。以下各节简单介绍了修正选项。

从供应商获取更新

OEAT 报告提供了指向已知兼容的加载项的链接。不过,某些应用程序可能不在此列表上。在这种情况下,您必须直接与供应商联系。如果不会及时为您的迁移提供更新的加载项,或加载项不会更新(或供应商不再运营),请准备开发临时解决方法。如果没有提供临时解决方法,请考虑虚拟化或并行安装。

更新内部应用程序

如果您拥有源代码并了解加载项或应用程序的运行方式,或者您拥有文档且原始开发工作组仍在工作或可咨询,则您具有更新内部应用程序的理想情形。使用 OCCI 可大大简化更新内部应用程序的过程,OCCI 可识别源代码中的不兼容功能。开发工作组仍将需要自己执行所需的修复。不过,通过使用 OCCI,他们可以更加轻松地找到不兼容的代码。

备注

如果用于编写内部应用程序的平台非常陈旧(例如 Visual Basic 6 或更早版本),我们建议您考虑使用 .NET Framework 完全重写该工具。

以下指南对需要更新内部应用程序的开发人员有用。

使用 Visual Studio 创建的加载项

创建了 Office 2010 的运行时组件,以便 Microsoft Visual Studio Tools for Applications (VSTA) 和 Visual Studio 2008 .NET 加载项、文档解决方案和电子表格解决方案将全部运行在 64 位 Office 2010 上。这些运行时组件随 Office 2010 一起安装。因此,管理员无需为此运行时执行单独安装。不过,需要考虑一些其他事项。

在 Visual Studio 项目中,当使用“任何 CPU”选项时,C# 或 Visual Basic 代码可编译为 Microsoft 中间语言 (MSIL)。在运行时,MSIL 实时 (JIT) 编译到正确的芯片集:AMD 或 Intel 32 位或 64 位。不过,此技术不适用于 .NET Framework 1.0 和 1.1 版。这些版本没有启用此 64 位转换。

即使兼容的 .NET Framework 2.0 代码也必须进行检查,因为代码中对进程调用 (p/invoke) 的任何调用都是本机的(处理器体系结构特定的)。如果尝试使用 p/invoke 调用本机 API 方法,则在 64 位 Office 2010 上正确运行的 VSTO 解决方案会出现问题。

如果代码有意调用没有与对应 Win64 API 的签名完全相同的签名(方法名、参数列表和 DLL 名称)的 Win32 API,则也会出现问题。对任何解决方案都是如此,不管它是 Office 解决方案还是基于 Windows 的解决方案。

有关如何为 64 位 Office 2010 创作解决方案的详细信息,请参阅 MSDN 技术库中的 Visual Studio 2005 的 64 位应用程序 (https://go.microsoft.com/fwlink/?linkid=178279\&clcid=0x804) 和 Visual Studio 2010 的 64 位应用程序(该链接可能指向英文页面) (https://go.microsoft.com/fwlink/?linkid=152431\&clcid=0x804)(该链接可能指向英文页面)。

VBA 解决方案和宏

只要使用 Visual Basic for Applications (VBA) 创建的解决方案和宏与 Office 2010 对象模型连接,它们就会运行。不过,某些调用可能已弃用,无法再正常运行。如果 VBA 代码使用 Windows API 调用,则这些调用很可能调用 32 位 DLL。一个简单的修复是更新代码以便 Declare 语句使用 PtrSafe 关键字。OCCI 可用于识别这些 Declare 语句。有关 VBA 64 位兼容性的详细信息,请参阅 32 位和 64 位版本的 Office 2010 之间的兼容性(该链接可能指向英文页面) (https://go.microsoft.com/fwlink/?linkid=186639\&clcid=0x804)(该链接可能指向英文页面)。

ActiveX 控件

64 位 Office 2010 不支持属于本机 32 位控件的 ActiveX 控件(它们很可能是与 2007 Office system 及以前的 Office 版本兼容的任何控件)。对其中任何控件的修正将需要重新编译(如果提供有源代码),询问或等待供应商更新或使用虚拟化方法。另外,有关 VBA 64 位兼容性的详细信息,请参阅 32 位和 64 位版本的 Office 2010 之间的兼容性(该链接可能指向英文页面) (https://go.microsoft.com/fwlink/?linkid=186639\&clcid=0x804)(该链接可能指向英文页面)。

Outlook 应用程序

Outlook 2010 会对加载项强制实施新的快速关闭进程。新的关闭进程可防止加载项通过在用户退出 Outlook 后继续占用资源而导致长时间延迟。虽然此更改可能会对某些现有加载项产生不利影响,但加载项供应商和 IT 管理员可以通过强制 Outlook 恢复为标准的加载项关闭进程来消除这些影响。有关新的关闭进程的详细信息,请参阅 Outlook 2010 中有关关闭的更改 (https://go.microsoft.com/fwlink/?linkid=203255\&clcid=0x804)。

Outlook 2010 中不会加载 Exchange 客户端扩展 (ECE)。有些第三方应用程序(例如存档或安全解决方案)使用 ECE,并且必须针对 Outlook 2010 进行更新。有关详细信息,请参阅宣布弃用 Exchange 客户端扩展(该链接可能指向英文页面) (https://go.microsoft.com/fwlink/?linkid=203888\&clcid=0x804)(该链接可能指向英文页面)。

如果要安装 64 位 Outlook 2010,则必须将 Outlook 的 32 位 MAPI 应用程序、加载项和宏更新为 64 位。有关详细信息,请参阅 64 位 Office 2010 版本在 32 位和 64 位平台上构建 MAPI 应用程序(该链接可能指向英文页面) (https://go.microsoft.com/fwlink/?linkid=203889\&clcid=0x804)(该链接可能指向英文页面) 以及 开发针对 32 位和 64 位系统的 Outlook 2010 解决方案(该链接可能指向英文页面) (https://go.microsoft.com/fwlink/?linkid=208699\&clcid=0x804)(该链接可能指向英文页面)。

使用并行安装或虚拟化

当没有可行的重新编码或重写解决方案时,还有其他选项可帮助您找到兼容性问题的解决方案。

  • 如果您在等待可能在部署日期之后的某个日期提供的加载项的供应商更新,可以选择与 Office 2010 并行安装 Office 2003 或更早版本(或仅等待供应商更新的特定应用程序,例如 Office Excel 2003)。

    备注

    如果要移到 64 位版本的 Office 2010,则无法同时安装 2007 Office system(或更早版本)的并行安装。所有以前的版本仅具有 32 位版本。

  • 如果您运行的是 Windows 7,则可以在 Windows XP 兼容模式下安装 Office 2003(或更早版本)的并行安装,或者您使用的是较旧版本的 Office,则可以在虚拟计算环境中安装它。

  • 使用 App-V(以前称为 SoftGrid)。有关 App-V 的详细信息,请参阅 Microsoft Application Virtualization 4.6(该链接可能指向英文页面) (https://go.microsoft.com/fwlink/?linkid=143973\&clcid=0x804)(该链接可能指向英文页面)。

  • 使用 Windows 终端服务并执行以下两个选项之一:

试用修正后的加载项和应用程序

进行试用是部署 Office 2010 之前的最后一个重要步骤。试用是修正后的选项的最终试验场,它应是项目工作组的角色的一部分,以便在试用 Office 2010 以捕获并更正出现的任何问题的整个过程中都保持参与状态。在试用期间,发布管理工作组监控受控环境,用户将在其中使用新功能(包括与 Office 2010 交互的修正后的应用程序和加载项)来执行他们的典型业务任务。这样可以证明修正是否按预期运行以及是否满足了组织的业务要求。

在试用中报告了问题时,应采取迭代方法来修正发现的问题,设计新测试用例,执行测试,然后将更新后的应用程序部署回试用中以进行其他检查。应特别关注这些选项的运行情况、用户反馈以及限制修正后的加载项或应用程序的范围或功能的任何问题。

有关如何稳定和试用应用程序的详细信息,请参阅 TechNet 技术库中的 Microsoft Operations Framework 4.0 中的稳定服务管理功能(该链接可能指向英文页面) (https://go.microsoft.com/fwlink/?linkid=115624\&clcid=0x804)(该链接可能指向英文页面)。