5

Tengo una aplicación desarrollada en Visual Studio 2005 que estoy implementando usando ClickOnce. Mi solución contiene dos proyectos: una capa de interfaz de usuario codificada en VB y una biblioteca de clase codificada en C#. La biblioteca de mi clase C# tiene algún código que usa las Asambleas de Interoperación de Outlook y Excel (Microsoft.Office.Interop.Outlook y Microsoft.Office.Interop.Excel, ambas versiones 11). Aquí están mis preguntasMicrosoft Office Interop Assembly referencias

  1. Aunque no he encontrado que esto se afirma como un absoluto, mi entendimiento es que debes tener las versiones adecuadas de las aplicaciones de Office (Outlook/Excel) con el fin de instalar una aplicación que utiliza la ensamblados de interoperabilidad . ¿Es esto correcto?

Si (1 = Sí) Entonces

¿Cómo manejaría la situación en la que la aplicación utiliza los ensamblados de interoperabilidad por sólo un par de características que va a ser utilizado por sólo unos pocos elegidos de la base total de usuarios? ¿Por qué debo exigir a cada usuario de mi aplicación que instale Microsoft Office si solo algunos usuarios necesitarán usar esas características? Estos ensambles Interop son solo .dll, entonces ¿qué los hace tan diferentes de otros en que no se puede simplemente publicar el archivo con su proyecto y hacer que satisfaga la referencia sin importar qué software está instalado en el cliente? (Claramente no entiendo bien el GAC y su efecto en el comportamiento de Visual Studio). Me gustaría escribir mi propio código para verificar la existencia del software de Office requerido para las pocas características que los usan. No Oficina, sin acceso a la función ...

Else

Si mi entendimiento sobre esto es incorrecto, entonces, ¿cómo puedo configurar mis referencias y ajustes de ClickOnce para que los usuarios no se encuentran con el siguiente mensaje de error tras intento de instalación?

"No se puede instalar o ejecutar la aplicación. La aplicación requiere que la versión 11.0.0.0 oficina de montaje se instala en el caché de ensamblados global (GAC) en primer lugar.

Póngase en contacto con el administrador del sistema."

  • He intentado configurar mi referencia de Interoperación propiedad CopyLocal a True y False.
  • En mi lista de archivos de la aplicación ClickOnce, he intentado configurar estos conjuntos para Incluir, Excluir y Prerrequisito.
  • En mi investigación he visto que algunas personas tienen estas referencias que apuntan a * C: \ WINDOWS \ assembly \ GAC *, mina puntos a * C: \ Archivos de programa \ Microsoft Visual Studio 9.0 \ Visual Studio Tools para Office \ PIA \ Office11 * pero no he encontrado una forma de cambiar la ruta de referencia. De acuerdo con http://msdn.microsoft.com/en-us/library/ez524kew(VS.80).aspx NO PUEDE agregar referencias del GAC, entonces, ¿cómo lo administraron otras personas?
  • He intentado copiar las referencias de * C: \ Archivos de programa \ Microsoft Visual Studio 9.0 \ Herramientas de Visual Studio para Office \ PIA \ Office11 * a mi directorio de proyecto y hacer referencia allí.

End If

supongo que lo más importante que hay que saber es cómo/si puedo incluir estos ensamblajes en mi publicación y satisfacer o pasar por alto el requisito GAC.

Siempre que sea posible, intente responder mis preguntas tan directamente como sea posible. Si bien los artículos son útiles, ya he leído MUCHOS artículos y he probado MUCHAS soluciones sugeridas y no he encontrado ningún éxito. Tenga en cuenta mi falta de comprensión de la logística de cómo funciona todo esto para empezar.

Perdóneme por mi falta de comprensión y gracias por cualquier ayuda que pueda ofrecer. ¡Es muy apreciado!

Respuesta

2

En mi experiencia, tratar de administrar conjuntos de interoperabilidad de oficina en un escenario de despliegue amplio es una pesadilla. Si se está desplegando a través de ClickOnce, incluso si soluciona el problema del GAC que anota arriba (tal vez haciendo que su departamento de TI envíe un registro GAC de los ensamblados de interoperabilidad, si este es un entorno corporativo), deberá manejar situaciones donde los usuarios tienen una versión de Office diferente a la estándar, y lo ayudan mucho cuando sale Office 13 y los usuarios comienzan a actualizar y rompe su aplicación.

Para poder utilizar los ensamblajes de interoperabilidad atados a la versión, es posible automatizar la oficina utilizando pinvoke directamente en los contenedores COM de Office, que son independientes de la versión (extraen la versión actual de la oficina del cliente el registro). Sin embargo, esto tendrá sus propios desafíos de implementación (es posible que necesite actualizar el registro para manejar máquinas que tienen los PIA instalados, lo que podría ser muy desafiante al usar ClickOnce para la implementación), y es mucho más difícil desarrollarlo.

Si estuviera en su lugar, comenzaría por analizar detenidamente la funcionalidad de interoperabilidad que está utilizando en la biblioteca de su clase. ¿Hay alguna otra manera de proporcionar la funcionalidad que necesita, fuera de la interoperabilidad de la oficina? la máquina del cliente? Quizás una solución orientada a servicios en la que los clientes envían un pedido a un servidor para generar un documento de Office personalizado y proporcionarlo para su descarga ...

+0

Gracias por su respuesta. Hasta el momento no he tenido problemas de conflicto de versiones: los usuarios con tanto 2003 como 2007 han podido usar estas funciones muy bien. Supongo que una pregunta más simple para apuntar realmente a lo que me pregunto es: ¿puedo hacer que mi aplicación sea instalable para usuarios que NO TIENEN CUALQUIER versión de Office, permitiéndoles usar las características que no son de Interop de mi aplicación? Entiendo que deben tener Outlook/Excel para usar mis funciones basadas en Interop, pero la mayor parte de mi aplicación no tiene nada que ver con Office. –

+0

Me gustaría pensar que una instancia del código de Interop no limitaría por completo su aplicación a aquellos que tienen Office instalado. –

+0

Una cosa que debes probar es usar Descargar a petición (http://msdn.microsoft.com/en-us/library/ak58kz04(VS.80).aspx) - deberías poder codificar para que antes de invocando/descargando el ensamblado que contiene sus clases de interoperabilidad de Office, se verifica si Office está instalado. Lo que no sé es si ClickOnce demora la verificación de dependencias hasta que realmente se solicite la descarga del ensamblaje Descargar a pedido o si se verifican todas las dependencias posibles fuera de la puerta de enlace. –

1

Esto es lo que sé por experiencia (debo señalar que no usamos ClickOnce pero no estoy seguro de por qué eso sería materia):

Si se escribe a la API de Excel 2003 y desplegar a una máquina con Excel 2007 que va a funcionar porque Excel 2007 suplanta esencialmente Excel 2003. El problema es que algunas APIs han cambiado y sus son algunos que incluso han sido eliminados. Tendrá que probarlo usted mismo para ver si su aplicación se ve afectada.

De hecho, es un poco peor que eso. Si ejecuta su aplicación en una máquina con Excel 2003 y Excel 2007 instalado, su uso de Interop aún usará Excel 2007.

Una posibilidad es usar que le da un control de Windows Forms compatible con Excel implementado por completo en uno. Conjunto NET que puede implementar con su aplicación, por lo que su aplicación no dependerá de Office.

Puede descargar una versión de prueba gratuita here si quiere probarlo.

responsabilidad: Soy dueño de SpreadsheetGear LLC

1

La mejor manera es utilizar finales de la biblioteca de unión

https://sourceforge.net/projects/exceldata/

  • sin nigthmare con iterops y TLB con diferentes versiones de oficina
  • apoyo de diversas oficinas
  • fácil de modificar

Sin embargo:

  • es difícil apoyar esta biblioteca
0

Uso de la interfaz COM y la ligadura. VB.NET siempre ha sido compatible con la vinculación tardía. Simplemente use Marshal.GetActiveObject() y establezca el tipo de su variable en Object. Puede hacer un objeto VB.NET que hace esto y llamarlo desde C#.

Con C# recibes un enlace tardío si usas la API de reflexión pero es muy doloroso escribir código con esto. En C# 4 también puede obtener vinculaciones finales a través del tipo dinámico.

Si hace esto, no necesita distribuir ningún conjunto de Office y su código funcionará siempre que los atributos en los objetos en la API de Office no cambien.

El código de enlace tardío es más lento que el código de enlace anticipado, pero para muchos propósitos esto no es un problema.

8

Puede que desee echarle un vistazo al proyecto de NetOffice: http://netoffice.codeplex.com/.

Es un conjunto gratuito (Licencia MIT) y completo (todas las versiones 2000-2010 y todas las aplicaciones de Office) de conjuntos de interoperabilidad independientes de la versión. Los ensamblajes se generan a partir de los PIA reales con una herramienta, por lo que son correctos, completos y actualizados, y es probable que se actualicen rápidamente para futuras versiones.

Otra buena característica es que el IntelliSense para cada miembro muestra qué versiones de Office implementan ese miembro.

Para la implementación, puede copiar o instalar los ensamblajes con su aplicación.

Cuestiones relacionadas