snippets - ¿Cómo usar Office desde Visual Studio C#?

snippets visual studio code

Question

La técnica para agregar una referencia a la interoperabilidad COM de Office en Visual Studio es ir a:

1. Referencias
2. Añadir referencia
3. Seleccione la pestaña COM
4. Seleccione la biblioteca de objetos de Microsoft Office 11.0

Y aparece una referencia mágicamente nombrada:

Microsoft.Office.Core

El archivo Project.csproj muestra los detalles de la referencia:

<COMReference Include="Microsoft.Office.Core">
   <Guid>{2DF8D04C-5BFA-101B-BDE5-00AA0044DE52}</Guid>
   <VersionMajor>2</VersionMajor>
   <VersionMinor>3</VersionMinor>
   <Lcid>0</Lcid>
   <WrapperTool>primary</WrapperTool>
   <Isolated>False</Isolated>
</COMReference>

Y el proyecto se controla en el control de la fuente y todo está bien.

Entonces, un desarrollador con Office 2007 obtiene el proyecto del control de fuente y no puede construirlo porque dicha referencia no existe.

Él (es decir, yo) comprueba el archivo .csproj, elimina la referencia a

Microsoft Office 11.0 Object Library

y vuelve a agregar la referencia COM como

Microsoft Office 12.0 Object Library

Y mágicamente aparece una referencia con nombre:

Microsoft.Office.Core

El archivo Project.csproj muestra los detalles de la referencia:

<COMReference Include="Microsoft.Office.Core">
  <Guid>{2DF8D04C-5BFA-101B-BDE5-00AA0044DE52}</Guid>
  <VersionMajor>2</VersionMajor>
  <VersionMinor>4</VersionMinor>
  <Lcid>0</Lcid>
  <WrapperTool>primary</WrapperTool>
  <Isolated>False</Isolated>
</COMReference>

Y el proyecto se controla en el control de la fuente y todo está bien.

Luego, un desarrollador con Office 2003 obtiene el proyecto del control de origen y no puede construirlo porque dicha referencia no existe.

Él (es decir, no yo) comprueba el archivo .csproj, elimina la referencia a

Microsoft Office 12.0 Object Library

y vuelve a agregar la referencia COM como

Microsoft Office 11.0 Object Library

Y mágicamente aparece una referencia con nombre:

Microsoft.Office.Core

El archivo Project.csproj muestra los detalles de la referencia:

<COMReference Include="Microsoft.Office.Core">
  <Guid>{2DF8D04C-5BFA-101B-BDE5-00AA0044DE52}</Guid>
  <VersionMajor>2</VersionMajor>
  <VersionMinor>3</VersionMinor>
  <Lcid>0</Lcid>
  <WrapperTool>primary</WrapperTool>
  <Isolated>False</Isolated>
</COMReference>

Y el proyecto se controla en el control de la fuente y todo está bien.

Luego, el proyecto se construye, se presiona en CD y se envía a los clientes que tienen Office 2007 .

Y todo no está bien.

En los viejos tiempos (es decir, antes del infierno de .NET dll), nos referíamos a los objetos de Office utilizando una versión independiente ProgID , es decir:

"Excel.Application"

que se resuelve en un clsid de Office instalado, por ejemplo

{00024500-0000-0000-C000-000000000046}    

de las cuales se construye una clase utilizando una llamada a COM (pseudocódigo de lenguaje-red):

public IUnknown CreateOleObject(string className)
{
    IUnknown unk;

    Clsid classID = ProgIDToClassID(className);
    CoCreateInstance(classID, null, 
          CLSCTX_INPROC_SERVER | CLSCTX_LOCAL_SERVER, 
          IUnknown, out unk);

    return unk;
}

Preguntas

1) ¿Cuál es la técnica aprobada para automatizar las aplicaciones de Office instaladas?

2) ¿Para qué sirven las Asambleas de interoperabilidad primarias de Office 2003 ?

3) Si utilizo las Asambleas de interoperabilidad primarias de Office 2003, ¿tengo que tener Office 2003 instalado?

4) Si compilo con las Asambleas de interoperabilidad primarias de Office 2003, ¿están ligados mis clientes a Office 20003 para siempre?

5) ¿Hay alguna Asamblea primaria de Interoperabilidad de Office 2007 ?

6) Si instalo las Asambleas de interoperabilidad primarias de Office 2007, ¿tengo que tener instalado Office 2007?

7) ¿Qué hay de malo con el uso de la interoperabilidad COM estándar para manejar Excel, Word o Outlook? p.ej:

[ComImport]
[Guid("00024500-0000-0000-C000-000000000046")]
public class Excel
{
}

8) ¿Qué se logra cuando se agrega un

• Referencia a los elementos en la pestaña COM ,
• en lugar de usar [ComImport],
• en lugar de utilizar las Asambleas primarias de interoperabilidad de Office 2007 ?

9) ¿Está agregando una referencia usando la pestaña COM idéntica a usar interoperabilidad COM , excepto que necesita una biblioteca de tipos para poder verla?

10) ¿Son compatibles los conjuntos de interoperabilidad primarios de Office 2003 hacia atrás y hacia adelante con: - Office 14 - Office 2007 - Office 2003 - Office XP - Office 2000 - Office 97 - Office 95

Si un cliente y un desarrollador instalan una nueva versión de Office, ¿seguirá funcionando?

11) ¿Tenemos que enviar las Asambleas de Interoperabilidad Primaria de Office 2003 con nuestra aplicación?

12) ¿El cliente tiene que instalar las Asambleas de interoperabilidad primarias de Office 2003 antes de que puedan usar nuestra aplicación?

13) Si un cliente instala los ensamblados de interoperabilidad primaria de Office 2003, ¿tiene que tener Office instalado?

14) Si un cliente instala las Asambleas de interoperabilidad primarias de Office 2003, ¿tiene que tener instalado Office 2003 ?

15) ¿Office 2003 Primary Interop se ensambla como una versión gratuita, liviana y redistribuible de Office 2003?

16) Si mi máquina de desarrollo tiene Office 2007, ¿puedo usar los PIA de Office 2003 y enviarlos a un cliente con Office XP instalado?

Answer 1

Wow, esa es una gran cantidad de preguntas. Creo que, en general, si su aplicación usa los PIA, está asumiendo que su público objetivo tiene instalada alguna versión de Office. Los PIA se instalarán en el GAC cuando el usuario objetivo instale Office. Si no tienen Office instalado, ¿por qué apunta a Office?

Sí, los dlls de Office son la forma correcta de automatizar Office. Aquí hay una lista de los ensamblados, incluidos algunos para Office 2007.

Answer 2

usas VSTO (herramientas de Visual Studio para oficina)?

http://msdn.microsoft.com/en-us/office/aa905533.aspx

Answer 3

La respuesta es "Copiar local" cualquier dll de ensamblaje que obtenga para la interoperabilidad. Una vez que tenga el dll de ensamblaje en su carpeta de salida, agregue una referencia y verifíquelo en el control de fuente.

Ahora todos tienen el dll de ensamblaje al que se hace referencia.

Answer 4

Un hilo viejo, y probablemente la mayoría de la gente estaría contenta con CopyLocal = True, sin embargo aquí hay otra manera ... Use ambos (o más ... pensando en Office 2010 si el problema aún existe ...) referencias en sus archivos de proyecto, y tampoco ignore o simplemente dile a MSBuild que ignore la advertencia "MSB3284" (no se encuentra la biblioteca). Así que incluye esto en tu archivo .csproj:

<COMReference Include="Microsoft.Office.Core">
   <Guid>{2DF8D04C-5BFA-101B-BDE5-00AA0044DE52}</Guid>
   <VersionMajor>2</VersionMajor>
   <VersionMinor>3</VersionMinor>
   <Lcid>0</Lcid>
   <WrapperTool>primary</WrapperTool>
   <Isolated>False</Isolated>
</COMReference>

Seguido por:

<COMReference Include="Microsoft.Office.Core">
   <Guid>{2DF8D04C-5BFA-101B-BDE5-00AA0044DE52}</Guid>
   <VersionMajor>2</VersionMajor>
   <VersionMinor>4</VersionMinor>
   <Lcid>0</Lcid>
   <WrapperTool>primary</WrapperTool>
   <Isolated>False</Isolated>
</COMReference>

Me interesaría ver si Microsoft proporciona una biblioteca NuGet para esto, solo para que todos sigan con el mismo enfoque. Creo que eso eliminaría la necesidad de que las personas busquen en la web estas respuestas ... Creo que esto iría en contra de la licencia de Microsoft Office, por lo que son los únicos que la suministran.

Por cierto, con copy local debe tener cuidado de no redistribuir esta biblioteca por error.