Question

La technique permettant d'ajouter une référence à l'interopérabilité COM d'Office dans Visual Studio consiste à accéder à:

  1. Références
  2. Ajouter une référence
  3. Sélectionnez l'onglet COM
  4. .
  5. Sélectionnez Bibliothèque d'objets Microsoft Office 11.0

Et la référence nommée comme par magie apparaît:

Microsoft.Office.Core

Le fichier Project.csproj affiche les détails de la référence:

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

Et le projet est archivé dans le contrôle de source et tout va bien.

Ensuite, un développeur de Office 2007 obtient le projet du contrôle de code source et ne peut pas le générer car une telle référence n'existe pas.

Il (c'est-à-dire moi) extrait le fichier .csproj et supprime la référence à

Microsoft Office 11.0 Object Library

et rajoute la référence COM en tant que

Microsoft Office 12.0 Object Library

Et comme par magie, une référence nommée apparaît:

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

Le fichier Project.csproj affiche les détails de la référence:

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

Et le projet est archivé dans le contrôle de source et tout va bien.

Ensuite, un développeur de Office 2003 obtient le projet du contrôle de code source et ne peut pas le générer car une telle référence n'existe pas.

Il (c'est-à-dire pas moi) extrait le fichier .csproj et supprime la référence à

"Excel.Application"

et rajoute la référence COM en tant que

{00024500-0000-0000-C000-000000000046}    

Et comme par magie, une référence nommée apparaît:

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

Le fichier Project.csproj affiche les détails de la référence:

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

Et le projet est archivé dans le contrôle de source et tout va bien.

Ensuite, le projet est créé, inséré sur des CD , puis envoyé aux clients disposant de Office 2007 .

Et tout ne va pas bien.

Dans l'ancien temps (c'est-à-dire avant .NET dll hell), nous référençions les objets Office à l'aide d'un ProgID indépendant de la version , c'est-à-dire:

<*>

qui résout un clsid de l'Office installé, par exemple

. <*>

dont une classe est ensuite construite à l'aide d'un appel à COM (pseudo-code langage-netural):

<*>

Questions

1) Quelle est la technique approuvée pour automatiser les applications Office installées?

2) Quels sont les Bureau Assemblys d’interopérabilité primaires 2003 utiles pour?

3) Si j'utilise les assemblages d'interopérabilité primaires Office 2003, dois-je installer Office 2003?

4) Si je construis avec les assemblys d’interopérabilité primaire Office 2003, mes clients sont-ils liés à Office 20003 pour toujours?

5) Existe-t-il des Office 2007 Assemblages d'interopérabilité primaires ?

6) Si j'installe les assemblys d'interopérabilité primaires d'Office 2007, dois-je installer Office 2007?

7) Quel est le problème avec l'utilisation de l'interopérabilité COM standard pour piloter Excel, Word ou Outlook? par exemple:

<*>

8) Que fait-on quand on ajoute un

  • Référence aux éléments de onglet COM ,
  • par opposition à l’utilisation de [ComImport],
  • par opposition à l'utilisation des assemblys d'interopérabilité primaire Office 2007 ?

9) L'ajout d'une référence à l'aide de onglet COM est identique à l'utilisation de COM interop , à la différence qu'il nécessite une bibliothèque de types avant de pouvoir le voir?

10) Les assemblages d’interopérabilité primaire Office 2003 sont-ils compatibles avec:  - bureau 14  - Office 2007  - Office 2003  - Office XP  - Office 2000  - bureau 97  - Bureau 95

Si un client et un développeur installent une nouvelle version d'Office, cela fonctionnera-t-il toujours?

11) Devons-nous envoyer les assemblages d’interopérabilité primaire Office 2003 avec notre application?

12) Le client doit-il installer les assemblys d’interopérabilité primaires Office 2003 avant de pouvoir utiliser notre application?

13) Si un client installe les assemblys d’interopérabilité primaires Office 2003, doit-il installer Office ?

14) Si un client installe les assemblys d’interopérabilité primaires Office 2003, doit-il installer Office 2003 ??

15) L’interopérabilité primaire Office 2003 constitue-t-il une version gratuite, allégée et redistribuable d’Office 2003?

16) Si ma machine de développement utilise Office 2007, puis-je utiliser les PIA d'Office 2003 et envoyer à un client Microsoft Office XP installé?

Était-ce utile?

La solution 2

La réponse est de " Copier Local " quel que soit l'assemblage dll que vous obtenez pour l'interopérabilité. Une fois que vous avez la dll assembly dans votre dossier de sortie, ajoutez-y une référence et archivez-la dans le contrôle de source.

Maintenant tout le monde a la dll d'assembly référencée.

Autres conseils

Wow, c'est un très grand nombre de questions. Je pense qu'en général, si votre application utilise les PIA, vous supposez qu'une version de Microsoft Office est installée sur votre public cible. Les PIA seront installées dans le GAC lorsque l'utilisateur cible installera Office. Si Office n'est pas installé, pourquoi ciblez-vous Office?

Oui, les dll Office sont le bon moyen d'automatiser Office. Il existe une liste des assemblys ici , y compris certains pour Office 2007.

utilisez-vous VSTO (outils Visual Studio for office)?

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

Un vieux fil, et probablement la plupart des gens seraient contents de CopyLocal = True, mais voici une autre façon. Utilisez les deux (ou plusieurs ..? En pensant à Office 2010 si le problème existe toujours ..) dans vos fichiers de projet et ignorez ou dites simplement à MSBuild d'ignorer le "MSB3284". avertissement (bibliothèque introuvable). Incluez donc ceci dans votre fichier .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>

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

Je serais intéressé de voir si Microsoft fournit une bibliothèque NuGet pour cela - juste pour amener tout le monde à adopter la même approche. Je pense que cela éliminerait la nécessité pour les internautes de rechercher ces réponses sur le Web ... Je pense que cela irait à l'encontre de la licence de Microsoft Office, de sorte qu'ils sont les seuls à le fournir.

BTW avec copie locale, vous devez faire attention à ne pas redistribuer ces bibliothèques par erreur.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top