2010-09-13 18 views
6

Hola He estado luchando contra algunas complejidades al comprender la implementación de las Asambleas de interoperabilidad primarias (PIA) para MS Office. Tengo Visual Studio Com Add-IN integrado en VS 2008 en tecnología de com puro (no VSTO, vea la parte inferior de esto para obtener más información al respecto), que hace referencia a las Asambleas de interoperabilidad primarias de 2003 pero el complemento puede usarse en 2003, 2007 o ahora 2010 Máquinas de oficina. Como nunca sé si el cliente utilizará 2003, 2007 o 2010, no puedo simplemente implementar una versión de PIA como requisito previo (a menos que haga 3 instaladores que no quiero hacer). Ahora, tengo entendido que cuando sigue los pasos here para agregar PIA 2003 y 2007 a las listas de requisitos previos que aparecen en un paquete de instalación de Visual Studio (2008), los requisitos previos son lo suficientemente inteligentes para determinar qué versión de oficina se está ejecutando en el cliente estás apuntando Por lo tanto, si selecciona 2003 ensamblados de interoperabilidad primarios y 2007 primarios iterop como requisitos previos, cuando se instala en una máquina que tiene 2003 debe ser lo suficientemente inteligente como para intentar agregar el PIA 2003 si faltan en esta máquina y si se trata de una máquina 2007 Office, solo instalará 2007 PIA (y no intentará instalar PIA 2003).Implementación de PIA en versiones mixtas de Office

Pregunta 1 se trata de una comprensión correcta (que los paquetes de requisitos previos son tan inteligentes como para instalar sólo lo que necesita basado en la versión de Office?)

Pregunta 2 hay una manera de obtener el 2010 PIA para mostrar en la lista de requisitos previos en VS 2008 como 2003 y 2007 hacer? No quiero actualizar este proyecto a VS 2010 b/c. Se considera una aplicación heredada ahora con muchos clientes de todo el mundo que lo utilizan.

Pregunta 3 Aunque el ensamblado real hace referencia a las interoperabilidades primarias de 2003, actualmente no despliego esas interoperaciones con el complemento a la ubicación de instalación. En cambio, supongo que si puedo instalar el PIA correcto, entonces no necesito este presente en la ruta de instalación, ya que el PIA estaría en el GAC. Sin embargo, un posible enfoque puede ser simplemente incluir los ensamblados de 2003 a los que se hace referencia (en mi caso, Excel y Word) en la ruta de instalación y no preocuparse por la PIA. Sospecho que esto funcionaría en las máquinas 2003 pero quizás no en las máquinas 2007 y 2010 b/c en la última, incluso si las interpolaciones 2003 a las que se hace referencia se encuentran en tiempo de ejecución en la ruta de instalación de la instalación, creo que si no hay una Policy.11.0.Microsoft.Office.Interop.Excel/Word (etc) en el GAC, entonces 2007 y 2010 probablemente no sabrán qué hacer con las interoperabilidades de 11.0 (2003) (como creo que es la Política.11.0.Microsoft. Office.Interop archivos redireccionan las solicitudes para las interoperabilidades de 2003 a 2007 o 2010). Tiene alguna idea sobre esto?

Pregunta 4: Existe un error conocido con las aplicaciones de Framework 2.0 Office Add-Ins y Office 2003 donde el complemento no se carga. Esto fue abordado por KB907417 aka KB908002. ¿Alguien sabe si esta KB es necesaria si desarrolla en el marco 3.0 o 3.5 (y hace un requisito previo de 3.0 o 3.5) ya que este problema era específico de Framework 2.0? ¿O la KB todavía tiene que ser implementada por b/c, es la oficina 2003 que es el problema y no la versión del marco?

Como puede ver por mis 3 preguntas, lo que estoy tratando de determinar es si podemos construir un único instalador a través de la utilidad de configuración de VS. Si los PIA se pueden hacer con un instalador, pero el KB anterior es el obstáculo (ya que tal vez la respuesta sea que incluso en el marco 3.0 o 3.5 los clientes necesitarán KB), entonces la ruta a un instalador es simplemente hacer la KB es un requisito previo general e instalarlo en las máquinas 2007 o 2010, aunque técnicamente no las necesitan. Cualquier idea sobre esa opción sería apreciada también. Finalmente, soy consciente de que redactar un Com Add-IN administrado para Excel o Word ahora se hace generalmente con VSTO en lugar de código de framework administrado puro, pero actualmente no es una opción para cambiar la aplicación heredada en esta dirección. También se informa que el 4.El framework 0 ahora se puede usar para implementar complementos sin hacer ningún requisito previo, pero nuevamente, esta no es una opción viable en este momento.

Respuesta

0

que hace el código utiliza ningún 2007+ métodos o clases de Office? De lo contrario, ¿está seguro de que no puede usar los PIA de 2003 en todos los casos? Las últimas aplicaciones deben ser compatibles con versiones anteriores (admiten la misma API), por lo que la única razón por la que necesitarías una PIA actualizada es si necesitas acceder a alguna característica añadida en 2007 o posterior, creo.

Es posible que desee echar un vistazo a Add-in Express, que promete un instalador one-for-all-versions, y es bastante fácil de usar.

0

Como se puede ver por mis 3 preguntas lo que estoy tratando de averiguar es si podemos construir un único instalador a través de la utilidad de configuración del VS

No se puede. Debe crear un paquete de instalación personalizado (setup bootstrapper).

Hace muchos años usé dotNetInstaller con el constructor de GUI HTML, hoy WiX toolset sería una mejor solución, creo.

Compruebe cómo se construyen los instaladores PIA .msi con los instaladores Orca o .msi y .exe comprobando el flujo de los registros del instalador de Windows.

En función de las comprobaciones del registro, las comprobaciones de archivos, las comprobaciones de productos instalados, las versiones de Windows, las versiones de oficina, puede crear las condiciones de si el componente debe instalarse o no.

Ah, y me aconsejan hacer instaladores de plugins sin requisitos previos e instalarlos de forma condicional con su programa previo instalador personalizado.

Cuestiones relacionadas