Compartir a través de

  • Artículo

Guía de compatibilidad de aplicaciones de Office 2010

 

Se aplica a: Office 2010

Última modificación del tema: 2017-01-17

El proceso de comprobación y corrección de la compatibilidad de aplicaciones para las implementaciones de Microsoft Office 2010 identifica los problemas de compatibilidad y le ayuda a desarrollar planes para solucionarlos. Esta información es útil principalmente para los profesionales de TI que evalúan y corrigen los problemas de compatibilidad de aplicaciones. Los programadores que actualizan las aplicaciones de Office también pueden encontrar útil esta información. Una vez completado el proceso descrito en este artículo, los administradores y programadores comprenderán mejor los complementos y las aplicaciones que interactúan con Office y la forma de migrarlos a Office 2010.

En este artículo no se trata la compatibilidad, la conversión ni la migración de documentos. Para obtener información acerca de cómo convertir archivos de Office heredados y cómo usar el modo de compatibilidad, vea Compatibilidad de documentos de Office 2010.

En este artículo:

  • Introducción a la compatibilidad de aplicaciones en Office 2010

  • Proceso de evaluación y corrección de la compatibilidad de aplicaciones

  • Planeación de la comprobación de compatibilidad

  • Evaluación del entorno

  • Comprobación y corrección de los problemas de compatibilidad

Introducción a la compatibilidad de aplicaciones en Office 2010

Los programadores y los usuarios expertos han estado escribiendo código para ampliar Office desde la introducción de los primeros productos de Office. Del mismo modo que Office ha evolucionado con cambios en las características, eliminación de características y cambios en los formatos de archivo, también ha aumentado la probabilidad de que las personalizaciones y los complementos más antiguos no funcionen correctamente cuando se usan con Office 2010. No es sorprendente que el tema de la compatibilidad de aplicaciones suponga un desafío para las organizaciones que tienen archivos de Office con una década o más de antigüedad.

Office 2010 incluye muchas mejoras en los productos y otros cambios que pueden afectar a la compatibilidad con los archivos, las macros, los complementos y las soluciones de Microsoft Visual Studio existentes. En la siguiente lista se describen algunos de esos cambios.

  • Características que se han quitado   Es posible que se produzcan errores en los complementos y las aplicaciones que dependen de características (y de sus modelos de objetos correspondientes) que se han quitado de Office 2010.

  • Cambios en las características Las características actualizadas y sus modelos de objetos pueden provocar que los complementos y las aplicaciones no funcionen de acuerdo a lo esperado. Algunas veces, estos cambios son obvios, mientras que otras, solo se descubren mediante una rigurosa comprobación.

  • Incompatibilidades de 64 bitsOffice 2010 se encuentra disponible en versiones de 32 y 64 bits. La versión de 64 bits está diseñada para los usuarios que necesitan más capacidad de memoria al trabajar con hojas de cálculo de Microsoft Excel o archivos de Microsoft Project complejos. Si planea implementar la versión de 64 bits de Office, debe tener en cuenta que los controles ActiveX, los complementos y las soluciones de Microsoft Visual Basic para Aplicaciones (VBA) creadas para trabajar en equipos cliente de 32 bits pueden no funcionar con las versiones de 64 bits de Office 2010.

Existen varias herramientas y soluciones para evaluar y corregir los problemas de compatibilidad de aplicaciones con Office 2010. Para los administradores de TI, la nueva herramienta de evaluación del entorno de Office (OEAT) puede ayudar a identificar los complementos y las aplicaciones que interactúan con Office. Los programadores pueden realizar comprobaciones adicionales mediante la nueva herramienta Inspector de compatibilidad de códigos de Microsoft Office 2010 para identificar códigos potencialmente incompatibles dentro de proyectos de VBA o códigos de Visual Studio. En los casos donde las aplicaciones no se pueden corregir, los administradores pueden usar soluciones como los servicios de escritorio remoto (Terminal Services), las instalaciones paralelas y la nueva plataforma Microsoft Application Virtualization (App-V) para mantener el entorno compatible anterior de Office junto con Office 2010.

En las siguientes secciones se describen brevemente las herramientas de evaluación de compatibilidad de aplicaciones de Office 2010.

Herramienta de evaluación del entorno de Office (OEAT) OEAT es una nueva herramienta de análisis de Office 2010 que identifica los complementos instalados en los equipos de los usuarios. OEAT recopila y transmite información acerca de complementos para Microsoft Office 97, Microsoft Office 2000, Microsoft Office XP, Microsoft Office 2003 y 2007 Microsoft Office system. OEAT también compara la lista de los complementos descubiertos de otros fabricantes con una lista de complementos compatibles que registra el Programa de visibilidad de compatibilidad de aplicaciones de los fabricantes independientes de software (ISV).

Para descargar OEAT, vea el tema sobre la herramienta de evaluación del entorno de Office (Office Environment Assessment Tool, OEAT) de Office 2010 (https://go.microsoft.com/fwlink/?linkid=171092\&clcid=0xC0A).

Programa de visibilidad de compatibilidad de aplicaciones de ISV Este nuevo programa realiza un seguimiento de los fabricantes independientes de software (ISV) que aseguran que sus productos son compatibles con Office 2010. Los ISV envían información acerca de sus productos a través de un portal de ISV especial y Microsoft publica esta lista en el tema sobre compatibilidad para el centro de recursos de Microsoft Office 2010 (https://go.microsoft.com/fwlink/?linkid=186766\&clcid=0xC0A). OEAT también usa esta lista para resaltar los complementos compatibles conocidos en el informe de resumen.

Para ver la lista actual de ISV que participan en este programa, vea el tema sobre la compatibilidad para Microsoft Office 2010 (https://go.microsoft.com/fwlink/?linkid=186766\&clcid=0xC0A).

Inspector de compatibilidad de códigos de Microsoft Office 2010 (OCCI) El Inspector de compatibilidad de códigos de Microsoft Office 2010 compara los códigos fuente de VBA, Visual Basic .NET y C# existentes para las llamadas API al modelo de objetos que no son compatibles con Office 2010. La herramienta se integra tanto con Microsoft Visual Basic para Aplicaciones 7.0 (VBA 7) como con Microsoft Visual Studio 2008 o Microsoft Visual Studio 2010 e incluye un detector básico. Cuando un inspector encuentra código que no es compatible con Office 2010, la herramienta agrega un comentario al código para que el programador lo use como referencia y corrija más tarde. El inspector también examina el código de las instrucciones Declare y las referencias a las DLL que usan los controles ActiveX que deben actualizarse para ser compatibles con la versión de Office 2010 de 64 bits.

Para descargar OCCI, vea el tema sobre la herramienta de Office 2010: inspector de compatibilidad (https://go.microsoft.com/fwlink/?linkid=181874\&clcid=0xC0A).

En la siguiente tabla se describen los tipos de personalizaciones basadas en Office que muchas organizaciones suelen encontrar y la herramienta que se usa para evaluar cada personalización. Como algunas de estas personalizaciones eran comunes en las versiones anteriores de Office, los vínculos para obtener información adicional suelen conducir a la documentación para programadores de Office 2003 y versiones anteriores.

Tipo de personalización Descripción Herramienta de evaluación

Complementos de automatización (.xll o .wll)

Los complementos de automatización permiten a los programadores incorporar una funcionalidad de una aplicación existente de Office 2010 a las aplicaciones personalizadas. Un ejemplo de un complemento de automatización de Office es una aplicación de CRM que escribe los datos de facturación del cliente en una hoja de cálculo de Microsoft Excel.

Para obtener más información acerca de los complementos de automatización, vea el tema sobre los complementos de automatización y los complementos COM de Excel (https://go.microsoft.com/fwlink/?linkid=186622&clcid=0xC0A).

OEAT

Complemento COM (archivo .dll de Windows)

Introducidos como parte de Microsoft Office 2000, los complementos COM permiten a los programadores usar el lenguaje de programación y el entorno que deseen para crear soluciones basadas en Office. Una vez que se escribe un complemento COM, se compila como un archivo .dll. El archivo .dll puede cargarse en una o varias aplicaciones de Office y puede interactuar con los modelos de objetos de Office.

Para obtener más información acerca de los complementos COM, vea el tema en el que se explica qué es un complemento COM (https://go.microsoft.com/fwlink/?linkid=186623&clcid=0xC0A).

OEAT

Complementos de VBA con formato Office 97–2003 (.dot, .wll, .xla, .xll, .ppa)

Complementos de VBA con formato Office 2007–2010 (.dotm, .xlam, .ppam)

Los complementos de plantilla de VBA se crean mediante Microsoft Visual Basic para Aplicaciones (VBA).

Para obtener más información acerca de los complementos de VBA, vea la introducción a VBA en Office 2010 (https://go.microsoft.com/fwlink/?linkid=186624&clcid=0xC0A). Para obtener una explicación más clara acerca de las diferencias entre las plantillas y los complementos de Microsoft Word, vea el tema sobre las plantillas de documento de Word frente a los complementos de Word (plantillas globales) (https://go.microsoft.com/fwlink/?linkid=186625&clcid=0xC0A).

OEAT y OCCI

Archivos habilitados para macros de VBA con formato Office 2007–2010 (.docm, .xlsm, .pptm)

Estos archivos contienen código de macro de VBA pero no se guardan como complementos.

OEAT detecta los archivos habilitados para macros de Word y Excel que se almacenan en la carpeta Inicio o que se cargan como plantillas globales. OEAT no descubre los archivos habilitados para macros que se almacenan en otras ubicaciones ni descubre los archivos habilitados para macros de PowerPoint independientemente de su ubicación.

Para obtener más información acerca de los archivos habilitados para macros, vea Formatos de archivo compatibles con Office 2010.

OEAT y OCCI

Complementos de Office creados con Visual Studio

Los complementos de Office creados con Visual Studio permiten a las organizaciones personalizar las aplicaciones de Office para agregar características específicas que se necesitan en los procesos de negocio.

Visual Studio admite dos tipos de soluciones que pueden usarse en una organización:

  • Personalizaciones en el nivel de documentos Estas personalizaciones se componen de un ensamblado asociado a un solo documento, libro o plantilla de Microsoft Word o Microsoft Excel. Las características de las personalizaciones en el nivel de documentos solo están disponibles al abrir el documento asociado. Estas personalizaciones no pueden aplicar cambios en toda la aplicación como, por ejemplo, mostrar un nuevo elemento de menú o una nueva ficha en la cinta de opciones al abrir cualquier documento.

  • Complementos en el nivel de aplicaciones Estos complementos se componen de un ensamblado asociado con una aplicación de Office. El complemento puede llamar al modelo de objetos para automatizar y ampliar la aplicación, y puede usar cualquiera de las clases de Microsoft .NET Framework.

OEAT puede usarse para detectar únicamente los complementos en el nivel de aplicaciones.

Para obtener más información acerca de los complementos de Office creados con Visual Studio, vea la información general sobre el desarrollo de soluciones en Office (https://go.microsoft.com/fwlink/?linkid=188380&clcid=0xC0A).

OEAT y OCCI

Proceso de evaluación y corrección de la compatibilidad de aplicaciones

En la siguiente ilustración se muestra un resumen del proceso de evaluación y corrección de la compatibilidad de aplicaciones. Cada tarea que se define en esta ilustración tiene una sección correspondiente en este artículo.

Proceso de compatibilidad de aplicaciones

Nota

En esta guía no se trata la compatibilidad, la conversión ni la migración de documentos. Para obtener información acerca de cómo convertir archivos de Office heredados y cómo usar el modo de compatibilidad, vea Compatibilidad de documentos de Office 2010.

Planeación de la comprobación de compatibilidad

Planear la evaluación, la corrección y las pruebas piloto de las aplicaciones y los complementos es un importante primer paso en el proceso general de comprobación de la compatibilidad de aplicaciones. Aunque basarse en los resultados anteriores de la comprobación de compatibilidad de 2007 Office System puede resultar tentador, esta no es una opción recomendable ya que solo retrasa la correcta realización de una implementación.

Planeación de la evaluación

En las siguientes secciones se describen las tareas de planeación que permiten prepararse para evaluar los complementos y las aplicaciones de una organización.

Creación de un repositorio central para los resultados y la documentación de la evaluación

Para ayudar a administrar el proceso de evaluación y corrección, se recomienda crear un repositorio central para las aplicaciones descubiertas y su estado. Una solución como Microsoft SharePoint Server 2010 puede ayudar a mantener a todos los miembros del proyecto actualizados y al proyecto en el camino previsto.

Identificación de las partes interesadas

Las partes interesadas son las personas o los grupos responsables de aprobar y asignar recursos al proyecto. Al identificar las partes interesadas en las primeras fases del proceso de planeación, el equipo de proyecto de compatibilidad de aplicaciones puede comunicarse y validar las entregas del proyecto con las partes que tienen un interés personal.

En la siguiente tabla se describen los roles típicos de las partes interesadas en un proyecto de compatibilidad de aplicaciones.

Rol Responsabilidad

Propietario de la aplicación

Garantiza que el proceso de negocio ejecutado mediante la versión anterior de Office continúe sin interrupciones después de la actualización.

Patrocinador del proyecto

Promueve la correcta realización de la actualización de Office y la publicidad positiva dentro de la organización.

Asignación de roles para los participantes del proyecto

En la siguiente tabla se describen los posibles roles y las correspondientes responsabilidades que deben ocuparse en un proyecto de compatibilidad de aplicaciones.

Rol Responsabilidad

Jefe de proyecto

Garantiza el flujo general del proyecto y administra los recursos, la métrica y los riesgos generales.

Ingeniero de pruebas de validación de la compatibilidad

Sigue el plan de comprobación y prueba los componentes de Office para detectar posibles problemas de incompatibilidad, entre los que se incluye el formato de archivo, las macros, los complementos o la automatización de Office.

Operador de OEAT

Comprende y ejecuta la instalación y la configuración de OEAT.

Responsable de corrección

Ejecuta las acciones que resuelven los problemas de compatibilidad en las personalizaciones de Office.

Ingeniero de pruebas de regresión

Garantiza la correcta ejecución de las correcciones en un objeto de Office. Este rol suele pertenecer al responsable de corrección.

Ingeniero de pruebas de aceptación de usuario

Representa a una unidad de negocio afectada que determina si la corrección de una aplicación se realizó correctamente y no interfiere con otras personalizaciones o acciones. Nunca debe ser la persona que ejecuta las pruebas de regresión o corrección.

Propietario o analista de negocios

Posee el código y la documentación de las aplicaciones y los complementos esenciales para la unidad de negocio.

Jefe de grupo de implementación

Es propietario de todo el proceso técnico y realiza un seguimiento de la puntualidad del proceso. Puede delegar algunas actividades de generación de informes o administración.

Grupo de paquetes de la aplicación

Es propietario del paquete de instalación de Office 2010.

Equipo cliente (escritorio)

Es el propietario de la implementación del paquete de Office 2010 a través de una herramienta de administración de configuración de la organización, como System Center Configuration Manager (SCCM).

Departamento de servicios

Proporciona compatibilidad funcional con Office para el personal de pruebas y, cuando finaliza la migración, para los usuarios.

Identificación de las unidades de negocio y realización de entrevistas

El siguiente paso en la planeación de la evaluación es identificar las agrupaciones de unidades de negocio o departamentos y entrevistar a sus representantes para comprender la forma en que el conjunto actual de complementos satisface sus necesidades comerciales. Conocer la importancia de cada complemento, su propósito, el motivo de su creación, sus funciones y su creador es importante para tomar una decisión documentada acerca de la forma de corregir el complemento y solucionar los problemas a medida que aparecen.

Es posible que algunos complementos de las aplicaciones de Office se hayan creado de manera informal dentro de la organización. Por lo tanto, es posible que deba realizar algún trabajo de investigación para rastrear un propietario y el código fuente original, si todavía existe.

Puede usar el siguiente formulario como plantilla para el cuestionario de una entrevista.

Información de la aplicación

Unidad de negocio

Nombre de la aplicación

Contacto/propietario de la aplicación

Identificador de la aplicación

Versión

Prioridad

Nivel

Estado de compatibilidad con Office 2010 si se conoce (Sin errores/Con errores)

Descripción del problema de compatibilidad (si existe)

Número de usuarios

Versión de Office que usa la aplicación (XP, 2003, 2007, 2010 ,etc.)

Describir el tipo de uso (por ejemplo, exporta un documento de Office, complemento para Office, etc)

Componentes del conjunto de Office que usa la aplicación

Word

Excel

Access

PowerPoint

Otros

¿Esta aplicación usa objetos de Office complejos como gráficos, informes de tabla dinámica o herramientas de dibujo?

¿Es este elemento una entrada de datos o una aplicación front-end? Si es así, proporcione información detallada.

¿Qué idiomas admite la aplicación?

Identificación de equipos cliente que se van a examinar

Después de determinar las diferentes unidades de negocio en las que es necesario examinar los equipos cliente, puede iniciar el proceso para identificar un muestreo estadísticamente relevante de los equipos cliente para cada unidad de negocio. No es necesario examinar todos los equipos cliente de la organización. Sin embargo, en algunos casos (según el tamaño de la organización), es posible que examinar todo el entorno o una unidad organizativa (OU) o grupo completo sea menos restrictivo (o más fácil) que definir los equipos cliente independientes que van a participar. Un muestreo estadísticamente relevante inferior al 20 por ciento debe proporcionar suficiente información como para evaluar y corregir correctamente los problemas de compatibilidad en el entorno de Office 2010.

Importante

Todos los equipos cliente que ejecutan OEAT deben tener instalado Microsoft .NET Framework 2.0 o una versión posterior. Para obtener más información acerca de los requisitos de OEAT, vea Guía del usuario de la herramienta de evaluación del entorno de Office (OEAT) para Office 2010.

Si la organización no dispone de un inventario de clientes actualizado, considere la posibilidad de ejecutar Microsoft Assessment and Planning (MAP) Toolkit para generar un inventario de clientes y evaluar la disponibilidad de Office 2010. En este inventario, puede trabajar con los líderes de grupos de negocio para seleccionar un subconjunto de equipos cliente y realizar una evaluación mediante OEAT. Para obtener más información acerca de MAP Toolkit, vea Microsoft Assessment and Planning Toolkit (https://go.microsoft.com/fwlink/?linkid=149448\&clcid=0xC0A).

Planeación de la corrección

Las siguientes secciones permiten establecer los criterios de línea base para clasificar y corregir las aplicaciones incompatibles. Llegar a un acuerdo en las primeras fases del proceso de planeación permite evitar desacuerdos u otros retrasos cuando los resultados de la evaluación y la comprobación están disponibles.

Determinación de la forma en que se deben clasificar las aplicaciones y establecer prioridades

Las empresas desarrollan, implementan y mantienen una gran variedad de aplicaciones y complementos basados en Office que pueden tener valores muy diferentes para la organización. Por lo tanto, es importante organizar las aplicaciones en clases o niveles según el valor de la aplicación para el negocio. Un método sencillo es clasificar una aplicación como esencial o no esencial. Otras clasificaciones que se pueden tener en cuenta son las siguientes:

  • Aplicaciones internas y externas

  • Aplicaciones departamentales

  • Soluciones no administradas, como plantillas, macros y complementos creados por los usuarios finales

  • Número de usuarios de la aplicación

  • Uso de la aplicación por parte de ejecutivos

  • Duración prevista de la aplicación

En la siguiente tabla se describen las formas en que una organización puede clasificar y establecer prioridades de distintos tipos de personalizaciones de Office.

Personalización Esencial No esencial

Complementos de automatización

Examen, prueba y corrección proactivos de OEAT

Reaccionar a detectado por el usuario

Complementos COM

Examen, prueba y corrección proactivos de OEAT

Reaccionar a detectado por el usuario

Complemento de VBA

Examen, prueba y corrección proactivos de OEAT y OCCI

Reaccionar a detectado por el usuario

Para facilitar la tarea de establecer prioridades entre las aplicaciones esenciales, puede clasificarlas como Nivel 1, Nivel 2 o Nivel 3. A continuación, se proporciona una orientación sobre la clasificación de muestra para cada nivel:

  • Nivel 1: Esencial para la misión Los errores en las aplicaciones esenciales para la misión perjudican la continuidad de los negocios o los ingresos de la organización. Todas las aplicaciones que usan los ejecutivos deben considerarse esenciales para la misión, independientemente del número de usuarios o la prioridad comercial de la aplicación. Este nivel incluye también las aplicaciones que más del 10 por ciento de los usuarios de la organización usan.

  • Nivel 2: Esencial para el negocio Estas aplicaciones son esenciales para el negocio o bien, el 10 por ciento o más de los usuarios de la organización las usan. Este nivel también puede incluir las aplicaciones que usan entre el 1 y el 10 por ciento de los usuarios de la organización y puede tener cualquier prioridad comercial. Estas no son aplicaciones esenciales para la misión ni aplicaciones que afecten a los ingresos. Sin embargo, pueden aumentar indirectamente los gastos o reducir los ingresos si afectan la productividad.

  • Nivel 3: Aplicaciones de negocio Estas aplicaciones no son esenciales para la misión y pueden afectar a pocos empleados (alrededor de 10) o al 1 por ciento de la organización. Por lo general, son herramientas que brindan asistencia en tareas pequeñas y tienen un impacto bajo sobre el negocio.

Identificación de estrategias de corrección

Después de definir los criterios para clasificar las aplicaciones, debe identificar las posibles estrategias de corrección. Si bien el trabajo real de corrección es difícil de planear, puede establecer estrategias genéricas que pueden guiar la resolución de problemas para cada tipo de personalización. En la siguiente tabla se proporcionan estrategias de corrección sugeridas en función del tipo de aplicación y su duración prevista.

Tipo Estrategia potencial

Aplicaciones internas con una duración limitada

Retire la aplicación y busque un nuevo proceso.

Aplicaciones internas de larga duración

Vuelva a escribir o crear el código para que se ajuste al nuevo modelo de objetos.

Aplicaciones de otros fabricantes con una duración limitada

Retire la aplicación y busque un nuevo proceso.

Aplicaciones de otros fabricantes de larga duración

Póngase en contacto con el proveedor para actualizar o reemplazar la aplicación.

La aplicación no funciona

Vuelva a instalar la aplicación con una nueva estructura de directorios o cree un entorno virtual para la aplicación.

Durante la corrección de las aplicaciones, es posible que descubra que su prioridad puede cambiar desde la evaluación inicial. Debe implementar un proceso estricto para las evaluaciones de corrección con el fin de permitir que una aplicación solo pueda moverse hacia arriba en el nivel (pero no hacia abajo). Para obtener información acerca de la forma en que el departamento de TI de Microsoft clasifica las aplicaciones y establece prioridades entre ellas, vea el tema sobre cómo implementar Office 2007 system en Microsoft (https://go.microsoft.com/fwlink/?linkid=178278\&clcid=0xC0A).

Microsoft también dispone de información descriptiva en TechNet acerca de problemas conocidos que se producen al migrar personalizaciones de Office. Para obtener más información, vea Cambios de productos y características de Office 2010. También existen asociados de Microsoft que disponen de herramientas para el proceso de corrección.

Planeación de pruebas piloto

El equipo de proyecto debe tener en cuenta la forma de desarrollar pruebas piloto para los complementos y las aplicaciones. En concreto, el equipo debe identificar lo siguiente:

  • Los usuarios que participarán en la prueba piloto.

  • La forma en que los usuarios de la prueba piloto informarán de los problemas.

  • Si los empleados del departamento de soporte técnico brindarán asistencia en la prueba piloto y, si es así, qué cursos aprendizaje recibirán.

  • El momento en que comenzará la prueba piloto. Por ejemplo, algunas organizaciones inician las pruebas piloto en las primeras fases del proceso, durante la fase de planeación, para obtener información temprana a medida que el proceso avanza.

Los siguientes recursos se encuentran disponibles como ayuda para planear la prueba piloto. Estos recursos no son específicos de las pruebas de compatibilidad de Office 2010. Sin embargo, muchos de los principios que abarcan estos recursos se aplican.

Evaluación del entorno

Durante la fase de evaluación, debe recopilar un inventario de aplicaciones y complementos mediante la ejecución de OEAT frente a un subconjunto estadísticamente relevante de equipos cliente. Después de analizar los resultados y establecer prioridades entre las aplicaciones, estará listo para la fase de comprobación y corrección.

Ejecutar OEAT

OEAT se puede ejecutar desde un recurso compartido de red o se puede distribuir entre los usuarios. OEAT examina los equipos cliente y, a continuación, guarda los resultados de los exámenes en una ubicación designada, normalmente un recurso compartido de red. Una vez completados los exámenes, puede usar OEAT para compilar los resultados en una hoja de cálculo de Microsoft Excel y usarla durante el proceso de corrección.

Según el entorno, puede implementar OEAT de una de las siguientes maneras:

  • Entornos de Active Directory Implemente OEAT mediante un script de inicio de sesión de Active Directory. A medida que los usuarios inician sesión, OEAT se ejecuta automáticamente y los resultados se guardan en la ubicación designada.

  • Entornos administrados Implemente OEAT mediante una solución de administración como Systems Management Server (SMS) o System Center Configuration Manager (SCCM).

  • Entornos de TI no administrados o no centralizados Cree un recurso compartido para OEAT y dé instrucciones a los usuarios acerca de cómo realizar un examen de forma manual.

Para obtener información acerca de la forma de implementar y usar OEAT, vea Guía del usuario de la herramienta de evaluación del entorno de Office (OEAT) para Office 2010. Para descargar OEAT, vea el tema sobre la herramienta de Office 2010: herramienta de evaluación del entorno de Office (Office Environment Assessment Tool, OEAT) (https://go.microsoft.com/fwlink/?linkid=171092\&clcid=0xC0A).

Revisar los resultados de OEAT

Una vez completados los exámenes del equipo cliente, use la opción Compilar resultados de OEAT para crear una hoja de cálculo que resuma los resultados de todos los equipos cliente que se han examinado. La hoja de cálculo contiene varias hojas, entre las que se incluyen las siguientes:

  • SummaryReport   En esta hoja de cálculo se incluye información de resumen que le ayudará a determinar si los equipos cliente examinados están preparados para Office 2010. En la hoja de cálculo se incluyen datos acerca del promedio de tamaño disponible, los procesadores, los fabricantes del equipo, las instalaciones de Windows (incluidos los niveles de Service Pack) y las instalaciones de Office. Los datos resultantes podrían ser interesantes desde la perspectiva de la administración de configuración, ya que es posible que los equipos cliente no estén ejecutando las versiones de Office o Windows que se esperaban.

  • MicrosoftOfficeAddins   En esta hoja de cálculo se incluye una lista de todos los complementos que vienen incluidos en Office.

  • AddinsNotShippedWithOffice   En esta hoja de cálculo se incluye una lista de todos los complementos que no vienen incluidos en Office. Gran parte de la planeación y la evaluación surgirá de este informe. Puede ordenar la lista por aplicación, ver las fechas del último acceso o modificación y el número de equipos cliente en los que se detectó el complemento. También podrá comparar los números de versión de los complementos iguales para determinar si algunos subconjuntos de equipos cliente están desactualizados, lo que podría indicar que existe un problema con los procesos de administración de configuración en la organización.

En la hoja de cálculo AddinsNotShippedWithOffice, comience por la columna Compatibility (Compatibilidad) para ver el estado de compatibilidad de cada complemento. OEAT genera los datos para esta columna mediante una comparación de los complementos detectados con la lista de complementos compatibles cuyo seguimiento realiza el programa de compatibilidad de ISV. Los resultados de estado de compatibilidad posibles son los siguientes:

  • UNKNOWN (Desconocido): el complemento no se encuentra actualmente en la lista de proveedores de Microsoft de complementos compatibles con Office 2010. Por lo tanto, el estado de este complemento es desconocido. Tenga en cuenta que este estado puede cambiar a medida que se pongan a disposición nuevos datos de proveedores en OEAT. Cada vez que compila la hoja de cálculo, tiene la opción de descargar nuevos datos de proveedores.

  • PARTIAL MATCH (Coincidencia parcial): OEAT informa de este estado en dos casos; OEAT encontró una coincidencia únicamente para el nombre del proveedor, o bien, OEAT encontró una coincidencia para el nombre del proveedor y del producto, pero el número de versión no coincide. Use el vínculo proporcionado en la columna URL (Dirección URL) para comprobar si aparecen complementos compatibles del proveedor en la lista de proveedores.

  • EXACT MATCH (Coincidencia exacta): se muestra este estado cuando coinciden el nombre del proveedor y del producto, y el número de versión del complemento es igual o posterior a la versión que indicó el proveedor.

Importante

La columna Compatibility (Compatibilidad) no se mostrará si eligió no descargar datos de compatibilidad cuando se le preguntó en la versión final de OEAT o si usa la versión beta de OEAT. Puede descargar la versión final de OEAT desde el Centro de descarga de Microsoft.

Finalizar planes de corrección

En este punto, estará listo para relacionar los resultados de OEAT con los criterios de asignación de prioridades que estableció durante la fase de planeación. Al establecer una programación para este trabajo, asegúrese de otorgar más tiempo para investigar y asignar prioridades entre los complementos que no se identificaron durante las entrevistas de la unidad de negocio. Para comprender el alcance de las incompatibilidades entre los complementos de VBA y los complementos de Visual Studio, el equipo de desarrollo puede ejecutar OCCI durante esta fase para comprender la cantidad de código subyacente que debe cambiarse.

Comprobación y corrección de los problemas de compatibilidad

Durante esta fase, usted y su equipo de desarrollo comenzarán a comprobar los complementos y las aplicaciones esenciales para la misión y de alta prioridad para buscar problemas de compatibilidad específicos con Office 2010. Una vez identificadas las incompatibilidades, el equipo de desarrollo comenzará a corregir los complementos y las aplicaciones incompatibles en función del trabajo realizado en la fase de planeación.

Como se suelen corregir varias aplicaciones y complementos, no se puede suponer que estas correcciones van a funcionar juntas. Deberá comprobar todas las correcciones juntas y, a continuación, realizar pruebas piloto en un escenario real. Cada paso es importante para validar las correcciones, estabilizar la implementación general de Office 2010 y, en última instancia, crear una migración con más éxito.

Comprobación de aplicaciones y complementos

Los siguientes diagramas de flujo proporcionan instrucciones generales para los programadores que comprueban distintos tipos de aplicaciones para identificar incompatibilidades con Office 2010. Para obtener instrucciones adicionales, vea los siguientes recursos:

Comprobación de aplicaciones en general

El siguiente diagrama de flujo proporciona una visión de alto nivel de la comprobación de aplicaciones. Los diagramas de flujo posteriores de esta sección describen el proceso de comprobación para determinados tipos de aplicaciones de Office, como complementos, macros y scripts, y la comprobación de automatización de Office.

Diagrama de flujo de prueba de aplicación

Comprobación de complementos de Office

Diagrama de flujo de prueba de complemento de Office

Comprobación de macros y scripts

Diagrama de flujo de prueba de macro

Comprobación de automatización de Office

Diagrama de flujo de prueba automática de Office

Ejecución de la herramienta Inspector de compatibilidad de códigos de Office

Como parte del proceso de comprobación general, los programadores pueden ejecutar la herramienta OCCI para examinar el desuso o los cambios conocidos en los miembros del modelo de objetos. OCCI también examina las instrucciones Declare de VBA y las referencias a los archivos DLL que usan los controles ActiveX que deben actualizarse para ser compatibles con las versiones de 64 bits de Office 2010. Cuando la herramienta detecta posibles problemas de compatibilidad, agrega un comentario en el código para señalar el problema al programador.

Cada vez que se completa un examen del Inspector, se proporciona un informe de resumen detallado de lo que se encontró en el proyecto. Entre los elementos que se examinan se encuentran los siguientes:

  • Cambios Se marcan todos los cambios sintácticos en un miembro del modelo de objetos. OCCI detecta el uso de cualquier miembro del modelo de objetos que presenta cambios desde Office 97.

  • Desuso Se marca cualquier uso de un miembro del modelo de objetos en desuso. OCCI detecta el uso de cualquier miembro del modelo de objetos que se encuentra en desuso desde Office 97.

Para obtener más información acerca de cómo usar el OCCI, vea Manual del usuario del Inspector de compatibilidad de códigos de Microsoft Office. Para obtener recursos de desarrollo específicos de la aplicación, como detalles sobre los cambios en el modelo de objetos con relación a las versiones anteriores de Office, vea el tema sobre Microsoft Office 2010 (https://go.microsoft.com/fwlink/?linkid=206197\&clcid=0xC0A).

Corrección de aplicaciones y complementos

Existen varios enfoques para corregir una aplicación o un complemento que presenta un problema de compatibilidad con Office 2010. En las siguientes secciones se describen brevemente las opciones de corrección.

Obtención de actualizaciones de los proveedores

Los informes de OEAT proporcionan vínculos a los complementos que se sabe que son compatibles. Sin embargo, es posible que algunas aplicaciones no estén en esta lista. En estos casos, debe ponerse en contacto directamente con el proveedor. Esté preparado para desarrollar soluciones alternativas temporales cuando el complemento actualizado no está disponible a tiempo para la migración, o cuando el complemento no se puede actualizar (o cuando el proveedor ya no existe). Si no existe una solución alternativa temporal, considere la posibilidad de ejecutar una virtualización o una instalación paralela.

Actualización de aplicaciones internas

Cuando dispone del código fuente y comprende la forma en que el complemento o la aplicación funciona, o dispone de la documentación y el equipo de desarrollo original aún se encuentra activo o puede ser consultado, la situación es ideal para actualizar una aplicación interna. El proceso de actualización de las aplicaciones internas se simplifica en gran medida con el uso de OCCI, que identifica las funciones incompatibles dentro del código fuente. Aun así, el equipo de desarrollo debe realizar las correcciones necesarias por cuenta propia. Sin embargo, OCCI facilita considerablemente la localización del código incompatible.

Nota

Si la plataforma para escribir la aplicación interna es muy antigua (por ejemplo, Visual Basic 6 o versiones anteriores), se recomienda considerar la posibilidad de reescribir completamente la herramienta mediante .NET Framework.

Las siguientes instrucciones resultan útiles para los programadores que necesitan actualizar las aplicaciones internas.

Complementos creados con Visual Studio

Los componentes de tiempo de ejecución para Office 2010 se crearon para que los complementos, las soluciones de documentos y las soluciones de hoja de cálculo de Microsoft Visual Studio Tools para aplicaciones (VSTA) y Visual Studio 2008 .NET se ejecuten en la versión de 64 bits de Office 2010. Estos componentes de tiempo de ejecución se instalan con Office 2010. Por lo tanto, un administrador no necesita incluir una instalación independiente para este tiempo de ejecución. Sin embargo, existen otras consideraciones necesarias.

En un proyecto de Visual Studio, el código de C# o Visual Basic se puede compilar en el lenguaje intermedio de Microsoft (MSIL) cuando se usa la opción Cualquier CPU. En tiempo de ejecución, el MSIL se compila de manera oportuna en el conjunto de chips correcto, ya sea AMD o Intel de 32 ó 64 bits. Sin embargo, esta tecnología no se aplica a las versiones 1.0 y 1.1 de .NET Framework. Estas versiones no permiten realizar esta transformación de 64 bits.

Incluso debe revisar el código de .NET Framework 2.0 que cumple con las especificaciones, ya que todas las llamadas a un proceso de invocación (p/invoke) en el código son nativas (específicas de la arquitectura del procesador). Si intenta llamar a un método API nativo mediante p/invoke , puede generar un problema en la solución VSTO que se ejecuta correctamente en la versión de 64 bits de Office 2010.

También pueden producirse problemas si el código realiza llamadas de forma deliberada a una API de Win32 que no tiene exactamente la misma firma (nombre de método, lista de parámetros y nombre de archivo DLL) que una API de Win64 equivalente. Esto sucede en cualquier solución, ya sea una solución de Office o una solución basada en Windows.

Para obtener más información acerca de la forma de crear soluciones para versiones de 64 bits de Office 2010, vea los temas sobre aplicaciones de 64 bits para Visual Studio 2005 (https://go.microsoft.com/fwlink/?linkid=178279\&clcid=0xC0A) y aplicaciones de 64 bits para Visual Studio 2010 (https://go.microsoft.com/fwlink/?linkid=152431\&clcid=0xC0A) en la biblioteca técnica de MSDN.

Soluciones y macros de VBA

Las soluciones y las macros que se crean con Visual Basic para Aplicaciones (VBA) funcionan mientras mantienen una interfaz con el modelo de objetos de Office 2010. Sin embargo, ciertas llamadas pueden quedar en desuso y no funcionar. Cuando el código de VBA usa las llamadas a la API de Windows, estas llamadas generalmente se dirigen a archivos DLL de 32 bits. Una solución sencilla es actualizar el código para que las instrucciones Declare usen la palabra clave PtrSafe. OCCI puede usarse para identificar estas instrucciones Declare. Para obtener más información acerca de la compatibilidad de VBA de 64 bits, vea el tema sobre la compatibilidad entre las versiones de 32 y 64 bits de Office 2010 (https://go.microsoft.com/fwlink/?linkid=186639\&clcid=0xC0A).

Controles ActiveX

Los controles ActiveX que son controles de 32 bits nativos (que suelen ser los controles compatibles con 2007 Office System y las versiones anteriores de Office) no se admiten en las versiones de 64 bits de Office 2010. Para corregir cualquiera de estos controles es necesario realizar una nueva compilación (si el código fuente se encuentra disponible), solicitar o esperar una actualización del proveedor, o usar un método de virtualización. Una vez más, para obtener más información acerca de la compatibilidad de VBA de 64 bits, vea el tema sobre la compatibilidad entre las versiones de 32 y 64 bits de Office 2010 (https://go.microsoft.com/fwlink/?linkid=186639\&clcid=0xC0A).

Aplicaciones de Outlook

Outlook 2010 aplica un nuevo proceso de cierre rápido de complementos. El nuevo proceso de cierre impide que los complementos ocasionen retrasos prolongados al mantener los recursos después de que el usuario sale de Outlook. Si bien este cambio podría afectar de manera negativa a algunos complementos existentes, los administradores de TI y los proveedores de complementos pueden resolver estos efectos obligando a Outlook a revertir el proceso de cierre de complementos estándar. Para obtener más información acerca del nuevo proceso de cierre rápido, vea el tema sobre los cambios en el cierre de Outlook 2010 (https://go.microsoft.com/fwlink/?linkid=203255\&clcid=0xC0A).

Las extensiones de cliente de Exchange (ECE) no se cargan en Outlook 2010. Algunas aplicaciones de terceros, como las soluciones de seguridad o archivado, usan las ECE y deben actualizarse para Outlook 2010. Para obtener más información, vea el tema sobre el anuncio del desuso de las extensiones de cliente de Exchange (https://go.microsoft.com/fwlink/?linkid=203888\&clcid=0xC0A).

Si va a instalar Outlook 2010 de 64 bits, debe actualizar las aplicaciones MAPI, complementos y macros de 32 bits de Outlook a 64 bits. Para obtener más información, vea Ediciones de 64 bits de Office 2010, el tema sobre cómo crear aplicaciones MAPI en plataformas de 32 y 64 bits (https://go.microsoft.com/fwlink/?linkid=203889\&clcid=0xC0A) y el tema sobre cómo desarrollar soluciones de Outlook 2010 para sistemas de 32 y 64 bits (https://go.microsoft.com/fwlink/?linkid=208699\&clcid=0xC0A).

Uso de instalaciones paralelas o virtualización

Cuando no se dispone de una solución práctica de recodificación o reescritura, existen opciones adicionales que pueden ayudarle a encontrar la solución a un problema de compatibilidad.

  • Si se encuentra esperando actualizaciones del proveedor para un complemento que puede recibir después de su fecha de implementación, puede optar por instalar Office 2003 o una versión anterior en paralelo con Office 2010 (o solo las aplicaciones específicas para las que se encuentra esperando actualizaciones del proveedor como, por ejemplo, Office Excel 2003).

    Nota

    Si va a pasar a usar una versión de 64 bits de Office 2010, no puede tener una instalación paralela de 2007 Office System (o una versión anterior) instalada al mismo tiempo. Todas las versiones anteriores se encuentran disponibles solo en versiones de 32 bits.

  • Si ejecuta Windows 7, puede instalar una instalación paralela de Office 2003 (o una versión anterior) en el modo de compatibilidad de Windows XP o bien, si se encuentra en una versión anterior de Office, puede instalarla en un entorno informático virtual.

  • Use App-V (anteriormente conocido como SoftGrid). Para obtener más información acerca de App-V, vea el tema sobre Microsoft Application Virtualization 4.6 (https://go.microsoft.com/fwlink/?linkid=143973\&clcid=0xC0A).

  • Use Windows Terminal Services y siga uno de estos procedimientos:

Aplicaciones y complementos corregidos con pruebas piloto

Llevar a cabo la prueba piloto es el último paso importante antes de implementar Office 2010. La prueba piloto es el último campo de prueba para las opciones corregidas y parte del rol del equipo de proyecto debe consistir en seguir participando en la realización de todas las pruebas piloto de Office 2010 con el fin de capturar y corregir cualquier problema que se produzca. Durante la prueba piloto, el equipo de administración de versiones de lanzamiento supervisa un entorno controlado en el que los usuarios realizan sus tareas empresariales habituales mediante las nuevas características, incluidas las aplicaciones y los componentes corregidos que interactúan con Office 2010. Esto demuestra que las correcciones funcionan según lo previsto y que se cumplen los requisitos comerciales de la organización.

A medida que se notifican los problemas en la prueba piloto, se debe adoptar un enfoque iterativo para corregir los problemas encontrados, diseñar un nuevo caso de prueba, realizar pruebas y, a continuación, implementar nuevamente las aplicaciones actualizadas en la prueba piloto para una revisión adicional. Es necesario prestar especial atención a la eficacia con la que funcionan estas opciones, a los comentarios del usuario y a todos los problemas que limitan el ámbito o la funcionalidad del complemento o la aplicación que se corrigió.

Para obtener más información acerca de la forma de estabilizar las aplicaciones y realizar pruebas piloto, vea el tema sobre cómo estabilizar la función de administración de servicios (https://go.microsoft.com/fwlink/?linkid=115624\&clcid=0xC0A) en Microsoft Operations Framework 4.0 en la biblioteca técnica de TechNet.