Vista, Office Interop ne fonctionne pas

Question

Quelqu'un sait-il comment faire fonctionner les bibliothèques MS Office 2007 .NET C # Interop avec Vista?

J'ai une application .NET C # que j'ai configurée pour être exécutée en tant que service Windows. Ce programme ouvrira un modèle Word ou Excel en fonction de la situation, modifiera son contenu, puis enregistrera le document. Tout cela fonctionnait bien lorsque je le faisais sur un ordinateur Windows Server 2003 ou XP sous Office 2007. Lorsque je déplaçais tout dans une boîte Server 2008, tout cessait de fonctionner. Dans Excel, par exemple, une exception COM m'indique que le fichier Excel ne peut pas être ouvert lorsque le fichier est clairement présent et que je peux l'ouvrir très bien si vous le faites manuellement. Le service Windows s'exécute sous le même compte d'utilisateur que celui auquel je me connecte à la machine et ce compte est un administrateur.

Quelqu'un at-il une idée de ce qu'il faut faire?

Answer 1

Vous devriez vraiment éviter d’exécuter les clients Office en tant qu’applications côté serveur. Pensez à utiliser xml comme format de fichier (xlsx pour Office 2007 ou à l'aide du classeur Excel xsd pour des versions (un peu) plus anciennes.) Vous ne seriez alors plus autorisé à utiliser l'API Excel sur le serveur.

Answer 2

Sous Vista et Windows Server 2008, les services s’exécutent dans une session appelée Session0. Avant Vista, les programmes classiques étaient exécutés dans Session0 avec les services.

Cela signifie que Session0 est devenue un terrain vague sans bureau où vos services ne peuvent même pas accéder à explorer.exe. Je suis presque sûr que le problème est que les applications Office s'attendent à pouvoir accéder à quelques composants qui se trouvent normalement sur le bureau.

Etant donné qu'Excel, Word, etc. ne sont pris en charge que sur une session de bureau, vous n'avez que quelques choix:

1. Cochez la case Bureau dans l'onglet Connexion des propriétés de votre service et priez pour qu'il apaise les dieux de l'Office. (Probablement pas.)
   • Après avoir essayé 1, parcourez votre code et essayez de supprimer / résoudre tout ce qui peut provoquer son blocage.
2. Utilisez remoting / WCF pour créer un serveur qui effectue le travail d'interopérabilité et pour que votre service communique avec lui.
   • Vous devez avoir un utilisateur interactif connecté et l'utilisateur doit démarrer l'application serveur d'une manière ou d'une autre. Il vaut peut-être mieux utiliser le démarrage automatique.
   • Vous pouvez essayer d'activer la connexion automatique. http://support.microsoft.com/kb/324737
3. Essayez d'emprunter l'identité d'un utilisateur connecté à l'aide de CreateProcessAsUser et de ses amis.
   • Remarque: je ne sais pas si cela fonctionne correctement à moins qu'un utilisateur ne soit réellement connecté. Par conséquent, il pourrait ne pas être plus utile que 2 ci-dessus et il est beaucoup plus difficile à retirer. (Nécessite P / Invoke)
4. Réécrivez votre programme pour qu'il utilise le kit de développement OpenXML ou utilisez quelque chose comme SpreadsheetGear.

Answer 3

J'ai trouvé un article intéressant de Microsoft en disant essentiellement ne faites pas l'automatisation Office.

Answer 4

Obtenir les fichiers installables de http://www.microsoft. fr / downloads / details.aspx? FamilyID = 59daebaa-bed4-4282-a28c-b864d8bfa513 & amp; displaylang = fr

installez-le sur votre système et faites référence à Excel dll dans votre solution. Espérons que cela fonctionne.

Answer 5

Les assemblys d’interopérabilité principaux sont-ils installés sur le serveur? Celles-ci sont généralement situées dans le GAC et ne sont pas incluses dans le répertoire bin lorsque vous générez votre programme. Elles devront donc être installées localement sur le serveur.

Answer 6

Ceci n’est qu’une hypothèse, mais il s’agit peut-être de UAC. Je sais que les applications privilégiées (admin) et les applications utilisateur ne peuvent ni s'échanger des messages ni communiquer de quelque manière que ce soit. Votre service fonctionne en tant qu'administrateur, mais votre bureau s'exécute en tant qu'utilisateur régulier sous UAC, même s'il s'agit du même utilisateur. Je m'attends également à ce qu'Office ait démarré (déjà chargé) certaines de ses parties au démarrage et qu'il s'exécute en tant qu'utilisateur standard.

Essayez de désactiver le contrôle de compte d'utilisateur et voyez si cela vous aide. Si oui, au moins vous savez ce que c'est.

Answer 7

Laissez-vous un compte connecté à la machine? Office n'est pas une application côté serveur et vous obtiendrez des erreurs aléatoires si vous essayez de lancer l'un des exécutables sans contexte de bureau.

Answer 8

Quelque chose à retenir à propos d'Office. Son x86 uniquement. Par conséquent, si vous créez une application en x64, vous ne pourrez pas accéder aux objets COM sous-jacents d’Office. Vous devrez compiler votre application en x86 pour que cela fonctionne.

Vous pouvez le faire en allant dans les propriétés de votre projet et en sélectionnant x86 sous l'onglet Construction de Visual Studio.

Tout cela en supposant que votre application est en cours de développement / d'exécution dans un environnement x64.