Automatisation d'Excel avec ASP.NET

Question

Arrière-plan

Nous développons actuellement des utilitaires internes à l'aide d'ASP.NET 2.0. L’une d’elles consiste à extraire des informations de bases de données et à créer un classeur Excel contenant plusieurs feuilles de calcul contenant des données basées sur des requêtes dans la base de données.

Problème

Le prototype de validation (une simple page ASP.NET interrogeant un seul élément de la base de données et ouvrant Excel pour ajouter des données à une feuille de calcul) fonctionne correctement lorsqu'il est exécuté localement sur les ordinateurs de développement, créant et affichant avec plaisir une feuille de calcul Excel comme demandé. Cependant, lorsqu’il est exécuté sur notre serveur, l’erreur suivante apparaît lorsqu’on tente d’instancier Excel.

Impossible de convertir l'objet COM de type 'Microsoft.Office.Interop.Excel.ApplicationClass' en type d'interface 'Microsoft.Office.Interop.Excel._Application'. Cette opération a échoué car l'appel QueryInterface sur le composant COM de l'interface avec l'IID '{000208D5-0000-0000-C000-000000000046}' a échoué en raison de l'erreur suivante: Aucune interface de ce type n'est prise en charge (exception de HRESULT: 0x80004002 (E_NOINTERFACE)). .

Solution?

Nous utilisons le PIA pour Excel 2003 et Excel 2003 et le PIA sont installés sur le serveur. Quelqu'un peut-il expliquer pourquoi cela ne fonctionne pas ou nous donner des conseils sur la manière de dépister le problème?

Merci pour toute aide que vous pouvez fournir.

Answer 1

L'utilisateur sous lequel le pool d'applications ASP.NET s'exécute peut-il accéder à l'application? Essayez de vous connecter en tant qu'utilisateur (ou de modifier le pool d'applications pour qu'il s'exécute en tant qu'utilisateur) et d'ouvrir Excel. Si cela fonctionne, essayez d’exécuter une application WinForms sur le serveur en tant qu’utilisateur avec le code qui échoue.

Pas sûr, mais je pense que les assemblys PIA devront peut-être être enregistrés via regsvr32.

Je pense que si vous utilisez le service réseau, vous ne pourrez pas démarrer Excel (pas de connexion interactive, compte restreint, etc.). Votre code ASP.NET s'exécute dans le pool d'applications. Vous pouvez modifier l'utilisateur auquel le pool d'applications est exécuté via le gestionnaire IIS. Si vous souhaitez vérifier le code en cours d’exécution, recherchez le processus w3wp dans le Gestionnaire des tâches.

Pour les tests, modifiez le pool d'applications pour qu'il s'exécute de la même manière que l'utilisateur que vous savez utilisez avec Excel.

Answer 2

Nous utilisons Aspose (commercial). Office sur un serveur n'est pas très amusant.

• Vous devez faire attention à la licence.
• De temps en temps, vous devez arrêter un processus suspendu.
• Obtenir les droits nécessaires prend quelques efforts.

Il s’appelle PI (t) A pour une raison ...

Answer 3

Pensez à utiliser les fichiers XLSX (nouveaux dans Office 2007, mais il existe un plug-in pour Office 2003), qui ne sont que des fichiers ZIP contenant des fichiers XML que vous pouvez manipuler sans avoir besoin d'Excel. SpreadsheetML (basé sur XML) est bien documenté et n’est pas trop compliqué à programmer (vous pourriez même trouver un LINQ à SpreadsheetML quelque part sur le Web).

Comme il a été souligné ci-dessus, Excel n'est pas vraiment un produit serveur et vous pourriez rencontrer de nombreux problèmes lorsque vous l'utilisez sur un serveur.

Answer 4

Je pense que le problème est qu’une fois que vous déployez votre application sur IIS, vous vous retrouvez soudainement à l’intérieur d’un MTA COM Apartment. Je crois qu'Excel est un composant STA et ne peut donc pas être créé dans le MTA. Vous devrez définir l’option aspcompat dans la page que vous utilisez

<%@ page aspcompat=true %>

Plus d'informations ici

Answer 5

De Microsoft , (accentuation dans le source d'origine):

  

Actuellement, Microsoft ne recommande pas et ne prend pas en charge l'automatisation des applications Microsoft Office à partir d'une application ou d'un composant client non interactif sans surveillance (y compris les services ASP, ASP.NET, DCOM et NT), car Office peut présenter un comportement instable et / ou un blocage lorsque Office est exécuté dans cet environnement.

Avec une liste de raisons pour lesquelles vous ne devriez pas le faire:

  

  
• ... De nombreux services s'exécutent sous des comptes ne disposant pas de profil utilisateur (tels que le compte SYSTEM ou les comptes IWAM_ [nom du serveur]). Par conséquent, Office risque de ne pas s'initialiser correctement au démarrage. Dans ce cas, Office renvoie une erreur sur la fonction CreateObject ou la fonction CoCreateInstance. Même si l'application Office peut être démarrée, d'autres fonctions risquent de ne pas fonctionner correctement s'il n'existe pas de profil utilisateur.
  
• Si une erreur inattendue se produit ou si un paramètre non spécifié est nécessaire pour exécuter une fonction, Office est conçu pour proposer à l'utilisateur une boîte de dialogue modale lui demandant ce qu'il souhaite faire. Une boîte de dialogue modale sur un poste de travail non interactif ne peut pas être fermée. Par conséquent, ce thread cesse de répondre (se bloque) indéfiniment. Bien que certaines pratiques de codage puissent aider à réduire le risque de problème, ces pratiques ne peuvent empêcher le problème entièrement. Ce seul fait rend l'exécution d'applications Office à partir d'un environnement côté serveur risquée et non prise en charge.
  
• Les composants côté serveur doivent être des composants COM multithreads hautement réentrants avec un minimum de temps système et une capacité de traitement élevée pour plusieurs clients. Les applications Office sont, à presque tous les égards, exactement le contraire. Les applications Office sont des serveurs d'automatisation non réentrants, basés sur STA, conçus pour fournir des fonctionnalités diverses mais gourmandes en ressources à un seul client.
  

Et votre code risque de générer les erreurs suivantes:

• CoCreateInstance

  • Erreur d'exécution '429': le composant ActiveX ne peut pas créer d'objet
  • Erreur d'exécution '70': autorisation refusée
  • CO_E_SERVER_EXEC_FAILURE (0x80080005): Echec de l'exécution du serveur
  • E_ACCESSDENIED (0x80070005): accès refusé
  • se bloque
  • retourne sans erreur, mais n'a pas fonctionné

Et enfin:

  

En raison des limitations imposées à la conception d'Office, les modifications apportées à la configuration d'Office ne suffisent pas pour résoudre tous les problèmes. Microsoft recommande vivement plusieurs solutions de remplacement ne nécessitant pas l'installation d'Office côté serveur et permettant d'effectuer la plupart des tâches courantes de manière plus efficace et plus rapide qu'avec Automation. Avant d'impliquer Office en tant que côté serveur composant de votre projet, envisagez des alternatives.