Essayer de faire Office Automation avec Excel 2007, mais Excel 2003 continue d'utiliser

Question

Environnement:

machine Windows XP
Les deux Excel 2007 et Excel 2003 est installé (dans cet ordre, et non par ordre chronologique).
C # 3.5

Problème:

Quand j'utilise les PIA pour faire un peu de bureautique, j'utilise la ligne de code suivante:

var excel = new ApplicationClass();

La version de PIA se réfère spécifiquement comme Excel 12.
C: \ WINDOWS \ assembly \ GAC \ Microsoft.Office.Interop.Excel \ 12.0.0.0__71e9bce111e9429c \ Microsoft.Office.Interop.Excel.dll
Mais:

 excel.Version;//this is 11.0 instead of 12.0

Ainsi, lorsque je tente d'ouvrir un fichier avec extention .xlsx, il me met en garde contre la fonctionnalité perdue dans la conversion de fichiers, et l'ouvre avec Excel 2003. Je suis sûr qu'il a à voir avec l'ordre d'installer être 2007 - > 2003, mais je ne peux pas désinstaller 2003 sur ma machine b / c nous avons une bureautique sur notre serveur Web pour un projet indépendant qui utilise Excel 2003.

Je l'ai regardé les choses de Policy.11.0.Microsoft.Office.Interop.Excel.config, mais il est dit

<bindingRedirect oldVersion="11.0.0.0" newVersion="12.0.0.0"></bindingRedirect>

Alors, je suis à une perte. Pourquoi ne puis-je dire à la COM Interop la version d'Excel à utiliser?

Answer 1

Vous ne pouvez pas commander programme version d'Excel à utiliser. Les PIA dictent que l'interface, ou le modèle d'objet, vous développez contre. Mais quelle version d'Excel est en fait en cours d'exécution est contrôlée par le registre.

En ce qui concerne l'exécution des PIA, cependant, vous fait courir contre le PIA plus haut niveau installé sur le système. Donc, si vous développez contre Excel 2003 PIA, mais le client a Excel 2007 avec Excel 2007 PIA, votre code heurtera Excel 2007 PIA - et il devrait fonctionner, parce que l'Excel 2007 PIA est rétrocompatible. Autrement dit, chaque version PIA numéro supérieur (et le modèle d'objet Excel) est rétrocompatible aux commandes compilées contre une ancienne PIA et le modèle d'objet Excel ancien. Notez que si le client avait à la fois Excel 2007 et Excel 2003 PIA sur la machine, puis le PIA supérieur versionné chargerait, quelle que soit la version d'Excel est en cours d'exécution -. Si le PIA Excel 2007 courrait, si les deux PIA étaient disponibles

[Edit: Une mise en garde est que les Excel 2007 PIA devrait être rétrocompatible 100% lors de l'utilisation VB.NET ou C # 4.0. Si vous utilisez C # 3.0 ou au-dessous, le fait que les paramètres facultatifs sont effectivement nécessaires lorsqu'il est appelé à partir de C # 3.0 ou ci-dessous créera une pause dans un code lors de l'exécution contre la PIA version supérieure ou modèle d'objet. Il est relativement rare cependant, et avec C # 4.0, cette question devrait aller, en théorie.]

Ok, donc vous n'avez pas beaucoup de contrôle sur les PIA parce que les PIA que vous avez développé contre ne contrôle pas réellement ce qui PIA sera effectivement en cours d'exécution sur la machine cliente.

Vous n'avez pas beaucoup de contrôle sur la version d'Excel est lancé soit. Par exemple, lorsque vous créez une nouvelle instance Excel via:

Excel.Application excelApp = new Application();

L'application Excel chargée est défini en fonction de la version actuelle définie dans le Registre. La version actuelle est enregistrée à:

HKEY_CLASSES_ROOT\Excel.Application\CurVer

Il ressemble à la clé 'CurVer dans votre cas aura une valeur par défaut de « Excel.Application.11 », au lieu de « Excel.Application.12 ». La modification de cette seule pourrait faire l'affaire, mais je préférerais faire une réparation au lieu de vous assurer que tous les paramètres de Registre sont corrigées correctement. (Et je ne pouvais pas savoir ce que tous les paramètres doivent être.) Ok, je viens de trouver un autre: vous devrez aussi changer:

[HKEY_CLASSES_ROOT\CLSID\{00024500-0000-0000-C000-000000000046}\ProgID]

pour maintenir une valeur de « Excel.Application.12 ». Mais je recommande fortement de lancer une réparation à la place. Je ne sais pas ce que les autres réglages peuvent être modifiés, afin de les changer à la main est un peu risqué.

En outre, vous devriez trouver les clés suivantes ainsi:

HKEY_CLASSES_ROOT\Excel.Application.11
HKEY_CLASSES_ROOT\Excel.Application.12

Parce que ce sont les versions d'Excel que vous avez installés.

(Voir pour une nouvelle discussion.)

  

Je suis sûr qu'il a à voir avec le   L'ordre d'installation étant 2007 -> 2003

Oui, cela est correct à 100%. Vous pouvez essayer de lancer une réparation sur Excel 2007, ce serait la chose la plus facile à faire. Si cela ne fonctionne pas, alors je désinstaller les deux et puis les réinstaller à la fois. Je désinstaller Excel 2003, puis désinstaller 2007 (inversant l'ordre dans lequel vous les avez installé) puis installez Excel 2003 et puis installez Excel 2007 de sorte que vous installez les deux versions dans l'ordre correct.

Mais gardez à l'esprit que, en faisant cela, Excel 2007 sera exécuté par défaut lorsque vous appelez Excel.Application excelApp = new Application().

La pratique recommandée est de pas pour avoir les deux versions d'Excel en cours d'exécution sur la machine du développeur. Pour en savoir plus, voir:

• Pourquoi VS le développement non pris en charge avec plusieurs versions d'office?
• Pouvez-vous construire un add-in pour plusieurs versions d'office?
• clients de l'automation pour plusieurs versions de bureau

Je l'habitude d'avoir plusieurs versions d'Excel sur ma même machine de développement, et je me sentais personnellement que les inconvénients ne sont pas aussi compliqué que ces articles font sonner. En général, Excel 2007 PIA est rétro-compatible avec Excel 2003 PIA et tout fonctionne bien. Mais je suis entré dans une fois un gâchis de registre semblable à la vôtre et a décidé de « faire la bonne chose ». Je désinstallé à la fois et seulement ré-installé Excel 2007.

A partir de là j'ai installé Virtual PC, qui est gratuit (VM Ware est en fait un peu mieux, mais ce n'est pas libre), puis installé mes versions inférieures d'Excel pour 2003, 2002, 2000 et '97 sur les machines virtuelles séparées. Il est certainement un peu de travail à mettre en place, mais une fois que vous faites cela, tout est 100% propre.

Cela dit, je ne voudrais probablement pas réellement développer contre-versions inférieures d'Excel sur une machine virtuelle, il serait trop difficile à utiliser Visual Studio hébergé dans une machine virtuelle. Donc, ces machines virtuelles ne sont bonnes que pour tester le déploiement pour vous assurer que votre système peut fonctionner contre diverses configurations des clients. Sens?

Hope this helps!

Mike