Domanda

La tecnica per aggiungere un riferimento all'interoperabilità COM di Office in Visual Studio è di andare a:

  1. Riferimenti
  2. Aggiungi riferimento
  3. Seleziona la scheda COM
  4. Seleziona Libreria oggetti di Microsoft Office 11.0

Viene visualizzato il riferimento magicamente denominato:

Microsoft.Office.Core

Il file Project.csproj mostra i dettagli del riferimento:

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

E il progetto viene controllato nel controllo del codice sorgente e tutto va bene.


Quindi uno sviluppatore con Office 2007 ottiene il progetto dal controllo del codice sorgente e non può costruirlo perché tale riferimento non esiste.

Lui (cioè io) controlla il file .csproj, elimina il riferimento a

Microsoft Office 11.0 Object Library

e aggiunge nuovamente il riferimento COM come

Microsoft Office 12.0 Object Library

E magicamente appare un riferimento nominato:

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

Il file Project.csproj mostra i dettagli del riferimento:

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

E il progetto viene controllato nel controllo del codice sorgente e tutto va bene.


Quindi uno sviluppatore con Office 2003 ottiene il progetto dal controllo del codice sorgente e non può costruirlo perché tale riferimento non esiste.

Lui (cioè non io) controlla il file .csproj, elimina il riferimento a

"Excel.Application"

e aggiunge nuovamente il riferimento COM come

{00024500-0000-0000-C000-000000000046}    

E magicamente appare un riferimento nominato:

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

Il file Project.csproj mostra i dettagli del riferimento:

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

E il progetto viene controllato nel controllo del codice sorgente e tutto va bene.

Quindi il progetto viene creato, premuto su CD e inviato ai clienti che hanno Office 2007 .

E non tutto va bene.


Ai vecchi tempi (cioè prima dell'inferno di .NET dll), faremmo riferimento agli oggetti di Office usando una ProgID indipendente dalla versione , ovvero:

<*>

che si risolve in un clsid dell'ufficio installato, ad esempio

<*>

di cui viene quindi costruita una classe utilizzando una chiamata a COM (pseudo-codice net-language):

<*>

Domande

1) Qual è la tecnica approvata per automatizzare le applicazioni di Office installate?

2) Cosa sono gli Office Assemblee di interoperabilità primaria 2003 utili per?

3) Se utilizzo gli assembly di interoperabilità primari di Office 2003, devo avere Office 2003 installato?

4) Se costruisco con gli assembly di interoperabilità primari di Office 2003, i miei clienti sono legati a Office 20003 per sempre?

5) Esistono Office 2007 Assemblee di interoperabilità primarie ?

6) Se installo gli assembly di interoperabilità primari di Office 2007, devo avere Office 2007 installato?

7) Cosa c'è di sbagliato nell'usare l'interoperabilità COM standard per guidare Excel, Word o Outlook? per esempio:.

<*>

8) Cosa si ottiene quando si aggiunge un

  • Riferimento agli elementi nella scheda COM ,
  • anziché usare [ComImport],
  • anziché utilizzare Assemblee di interoperabilità primaria di Office 2007 ?

9) L'aggiunta di un riferimento utilizzando la scheda COM identica all'utilizzo di Interoperabilità COM , tranne per il fatto che necessita di una libreria dei tipi prima di poter lo vedi?

10) Gli assembly di interoperabilità primari di Office 2003 sono retrocompatibili con:  - Ufficio 14  - Office 2007  - Office 2003  - Office XP  - Office 2000  - Office 97  - Office 95

Se un cliente e uno sviluppatore installano una nuova versione di Office, funzionerà comunque?

11) Dobbiamo spedire gli Assiemi di interoperabilità primaria di Office 2003 con la nostra applicazione?

12) Il cliente deve installare gli assembly di interoperabilità primari di Office 2003 prima di poter utilizzare la nostra applicazione?

13) Se un cliente installa gli Assiemi di interoperabilità primari di Office 2003, deve avere Office installato?

14) Se un cliente installa gli Assiemi di interoperabilità primaria di Office 2003, deve avere Office 2003 installato?

15) Gli assembly di interoperabilità primaria di Office 2003 sono una versione gratuita, lite e ridistribuibile di Office 2003?

16) Se la mia macchina di sviluppo ha Office 2007, posso utilizzare le PIA di Office 2003 e spedire a un cliente con Office XP installato?

È stato utile?

Soluzione 2

La risposta è di " Copia locale " qualunque assemblea riceverai per l'interoperabilità. Una volta che hai l'assembly dll nella cartella di output, aggiungi un riferimento ad esso e controllalo nel controllo del codice sorgente.

Ora tutti hanno l'assembly dll di riferimento.

Altri suggerimenti

Wow, questo è un numero enorme di domande. Penso che in generale se la tua app utilizza i PIA, allora stai assumendo che il tuo pubblico di destinazione abbia installato una versione di Office. Le PIA verranno installate nel GAC quando l'utente di destinazione installa Office. Se non hanno Office installato, allora perché stai prendendo di mira Office?

Sì, le DLL di Office sono il modo corretto di automatizzare Office. C'è un elenco degli assiemi qui , tra cui alcuni per Office 2007.

usi VSTO (strumenti di Visual Studio per Office)?

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

Un vecchio thread, e probabilmente la maggior parte delle persone sarebbe contenta di CopyLocal = True, tuttavia ecco un altro modo .. Usa i riferimenti entrambi (o più ..? Pensando a Office 2010 se il problema persiste ..) nei tuoi file di progetto e ignora o dì semplicemente a MSBuild di ignorare "MSB3284" avviso (libreria non trovata). Quindi includilo nel tuo file .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>

Seguito da:

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

Sarei interessato a vedere se Microsoft fornisce una libreria NuGet per questo - solo per convincere tutti a seguire lo stesso approccio. Penso che eliminerebbe la necessità che le persone cerchino queste risposte sul Web ... Credo che ciò sarebbe contrario alla licenza di Microsoft Office, quindi sono le uniche a fornirlo.

A proposito con copia locale devi fare attenzione a non ridistribuire per errore questa libreria.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top