Pregunta

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

  1. Referencias
  2. Agregar referencia
  3. Selecciona la pestaña COM
  4. Seleccione Biblioteca de objetos de Microsoft Office 11.0

Y aparece una referencia con nombre mágico:

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 está incluido en el control de código fuente y todo está bien.


Luego, un desarrollador con Office 2007 obtiene el proyecto del control de código fuente y no puede compilarlo porque no existe tal referencia.

Él (es decir, yo) verifica el archivo .csproj, borra 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:

<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>

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 está incluido en el control de código fuente y todo está bien.


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

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

"Excel.Application"

y vuelve a agregar la referencia COM como

{00024500-0000-0000-C000-000000000046}    

Y mágicamente aparece una referencia con nombre:

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;
}

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

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

Y el proyecto está incluido en el control de código fuente y todo está bien.

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

Y no todo está bien.


En los días anteriores (es decir, antes de .NET dll hell), haríamos referencia a los objetos de Office utilizando un ProgID independiente versión independiente , es decir:

<*>

que se resuelve en un clsid de la Oficina instalada, por ejemplo

<*>

de los cuales se construye una clase usando una llamada a COM (pseudo-código netural de idioma):

<*>

Preguntas

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

2) ¿Qué son las Oficina Asambleas de interoperabilidad primaria de 2003 útiles para?

3) Si uso los ensamblados de interoperabilidad primarios de Office 2003, ¿tengo que tener Office 2003 instalado?

4) Si compilo con los ensamblajes de interoperabilidad primarios de Office 2003, ¿mis clientes estarán atados a Office 20003 para siempre?

5) ¿Hay Office 2007 Asambleas de interoperabilidad primarias ?

6) Si instalo los ensamblajes de interoperabilidad primarios de Office 2007, ¿debo tener instalado Office 2007?

7) ¿Qué hay de malo con el uso de la interoperabilidad COM estándar para impulsar Excel, Word o Outlook? por ejemplo:

<*>

8) ¿Qué se consigue cuando se agrega una

  • Referencia a los elementos en la pestaña COM ,
  • a diferencia de usar [ComImport],
  • en lugar de usar los Office 2007 Primary Interop Assemblies ?

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

10) ¿Los conjuntos de interoperabilidad primarios de Office 2003 son compatibles con:  - Oficina 14  - Oficina 2007  - Oficina 2003  - Office XP  - Office 2000  - Oficina 97  - Oficina 95

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

11) ¿Debemos enviar los conjuntos de interoperabilidad primaria de Office 2003 con nuestra aplicación?

12) ¿El cliente debe instalar los ensamblajes de interoperabilidad primarios de Office 2003 antes de poder usar nuestra aplicación?

13) Si un cliente instala los ensamblajes de interoperabilidad primarios de Office 2003, ¿tienen que tener Office instalado?

14) Si un cliente instala los conjuntos de interoperabilidad primarios de Office 2003, ¿tiene que tener Office 2003 instalado?

15) ¿Son los ensamblajes principales de interoperabilidad de Office 2003 una versión gratuita, gratuita 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?

¿Fue útil?

Solución 2

La respuesta es " Copiar local " Cualquier ensamblaje dll que obtengas para la interoperabilidad. Una vez que tenga el archivo DLL de ensamblaje en la carpeta de salida, agregue una referencia a él y verifíquelo en el control de origen.

Ahora todos tienen la dll del ensamblado al que se hace referencia.

Otros consejos

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

Sí, las dll de Office son la forma correcta de automatizar Office. Hay una lista de los ensamblados aquí , incluido algunos para Office 2007.

¿Utiliza VSTO (Visual studio tools for office)?

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

Un hilo antiguo, 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 persiste) en las referencias de los archivos de su proyecto, e ignore o simplemente diga a MSBuild que ignore el " MSB3284 " advertencia (biblioteca no encontrada). 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 de:

<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 gustaría ver si Microsoft proporciona una biblioteca de NuGet para esto, solo para que todos tengan 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 proporcionan.

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

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top