Vous ne pouvez pas commander par programme la version d'Excel à utiliser. Les PIA ne dictent que l'interface ou le modèle d'objet que vous développez. Mais quelle version d'Excel est en cours d'exécution est contrôlée par le registre. Toutefois, en ce qui concerne l'exécution des assemblys PIA, vous exécuterez réellement le PIA de plus haut niveau installé sur le système. Donc, si vous développez par rapport à Excel 2003 PIA, mais que le client a Excel 2007 avec le PIA Excel 2007, votre code s'exécutera contre le PIA Excel 2007 - et il devrait fonctionner correctement, car le PIA Excel 2007 est rétrocompatible. C'est-à-dire que chaque version de PIA de numéro supérieur (et le modèle d'objet Excel) est rétrocompatible avec les commandes compilées avec un ancien PIA et un ancien modèle d'objet Excel. Notez que si le client avait à la fois les PIA Excel 2007 et Excel 2003 sur la machine, le PIA versionné supérieur se chargerait, quelle que soit la version d'Excel en cours d'exécution, de sorte que le PIA Excel 2007 s'exécuterait si les deux PIA étaient disponibles. [Edit: Une mise en garde est que les PIA Excel 2007 doivent être 100% rétrocompatible lorsque vous utilisez VB.NET ou C# 4.0. Si vous utilisez C# 3.0 ou inférieur, le fait que les paramètres optionnels soient réellement requis lorsqu'ils sont appelés à partir de C# 3.0 ou inférieur créera une rupture dans du code lors de l'exécution sur le PIA ou le modèle objet de version supérieure. C'est relativement rare cependant, et avec C# 4.0, ce problème devrait disparaître, en théorie.]
Ok, donc vous n'avez pas beaucoup de contrôle sur les PIAs parce que le PIA que vous avez développé ne le fait pas contrôlez quel PIA sera réellement exécuté sur l'ordinateur client.
Vous n'avez pas beaucoup de contrôle sur la version d'Excel qui est lancée.Par exemple, lorsque vous créez une nouvelle instance Excel via:
Excel.Application excelApp = new Application();
L'application Excel chargée est définie 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 ». Changer cela seul pourrait faire l'affaire, mais je préférerais faire une réparation à la place pour m'assurer que tous les paramètres du registre sont corrigés correctement. (Et je ne pouvais pas savoir ce que tous les paramètres doivent être.) Ok, je viens de trouver un autre: vous devez également modifier:
[HKEY_CLASSES_ROOT\CLSID\{00024500-0000-0000-C000-000000000046}\ProgID]
pour maintenir une valeur de « Excel.Application.12 » . Mais je recommande fortement d'effectuer une réparation à la place. Je ne sais pas quels autres paramètres pourraient avoir besoin d'être modifiés, donc 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 here pour une nouvelle discussion.)
Je suis sûr qu'il a à voir avec le installer pour être 2007 -> 2003
Oui, cela est correct à 100% . Vous pourriez essayer d'exécuter une réparation sur Excel 2007, ce serait la chose la plus facile à faire. Si cela ne fonctionne pas, alors je désinstallerais les deux puis les réinstallerais les deux. Je voudrais désinstaller Excel 2003, puis désinstaller 2007 (en inversant l'ordre dans lequel vous les avez installés), puis installer Excel 2003 et ensuite installer Excel 2007 de sorte que vous installez les deux versions dans le bon ordre. Mais n'oubliez pas que Excel 2007 sera exécuté par défaut lorsque vous appelez Excel.Application excelApp = new Application().
La pratique réellement recommandée est et non pour que les deux versions d'Excel s'exécutent sur la machine du développeur. Pour en savoir plus, voir:
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 étaient pas aussi compliqué que ces articles le font sonner. En général, le PIA Excel 2007 est rétrocompatible avec le PIA Excel 2003 et tout fonctionne correctement. Mais une fois, je me suis retrouvé dans un gâchis de registre semblable au vôtre et j'ai décidé de «faire la bonne chose». J'ai désinstallé les deux et ensuite seulement réinstallé Excel 2007.
De là j'ai installé Virtual PC, ce qui est gratuit (VMware est en fait un peu mieux, mais ce n'est pas gratuit), puis installé mes versions inférieures d'Excel pour 2003 , 2002, 2000 et 1997 sur des machines virtuelles distinctes. C'est certainement un travail à mettre en place, mais une fois que vous faites cela, tout est propre à 100%.Cela dit, je ne voudrais probablement pas réellement développer contre les versions inférieures d'Excel sur une machine virtuelle, il serait trop difficile d'utiliser Visual Studio hébergé dans une machine virtuelle. Ces machines virtuelles ne sont donc utiles que pour tester le déploiement afin de s'assurer que votre système peut fonctionner avec différentes configurations client. Avoir du sens?
Espérons que cela aide!
Mike
Pourriez-vous essayer d'exécuter une réparation d'Excel 2007 et voir si cela rectifie? – x0n
C'est possible, mais je crains que cela ne fasse grimper les PIA 2003 pour le code du site quand je dois y travailler. Je suppose que je pourrais rebondir, mais je suis un peu préoccupé par la façon dont cela fonctionnera une fois installé sur les machines de nos utilisateurs internes. –
Cela ne changera pas les PIA. Vous pouvez vérifier le GAC pour être sûr, mais il est 99,99% certain que vous avez déjà les PIA Excel 2003 et Excel 2007 sur votre machine. Les configurations PIA ne changeront donc pas en faisant une réparation. Mais une réparation doit corriger le registre pour que la version actuelle soit Excel 2007 au lieu d'Excel 2003. Voir ma réponse ci-dessous pour plus de détails. –