Automatizzare Excel usando ASP.NET

StackOverflow https://stackoverflow.com/questions/285715

Domanda

Sfondo

Stiamo sviluppando alcune utility interne usando ASP.NET 2.0. Uno dei quali è l'estrazione di alcune informazioni dai database e la creazione di una cartella di lavoro di Excel contenente un numero di fogli di calcolo con dati basati su query nel database.

Problema

Il prototipo di proof of concept (una semplice pagina ASP.NET che richiede un singolo elemento dal database e apre Excel per aggiungere dati a un foglio di lavoro) funziona bene quando viene eseguito localmente sulle macchine di sviluppo, creando e visualizzando felicemente un foglio di calcolo Excel come richiesto. Tuttavia, quando eseguito sul nostro server, viene visualizzato il seguente errore quando si tenta di creare un'istanza di Excel.

Impossibile eseguire il cast dell'oggetto COM di tipo "Microsoft.Office.Interop.Excel.ApplicationClass" per interfacciare il tipo "Microsoft.Office.Interop.Excel._Application". Questa operazione non è riuscita perché la chiamata QueryInterface sul componente COM per l'interfaccia con IID '{000208D5-0000-0000-C000-000000000046}' non è riuscita a causa del seguente errore: Nessuna interfaccia supportata (Eccezione da HRESULT: 0x80004002 (E_NOINTERFACE)) .

Soluzione?

Stiamo utilizzando PIA per Excel 2003 e abbiamo Excel 2003 e PIA installati sul server. Qualcuno può spiegare perché questo non funziona o darci alcuni consigli su come potremmo rintracciare il problema?

Grazie per l'assistenza che puoi fornire.

È stato utile?

Soluzione

L'utente con cui viene eseguito il pool di applicazioni ASP.NET può accedere all'applicazione? Prova ad accedere come quell'utente (o modifica il pool di applicazioni per eseguirlo come quell'utente) e apri Excel. Se funziona, prova a eseguire un'applicazione WinForms sul server come quell'utente con il codice che non funziona.

Non sono sicuro ma penso che potrebbe essere necessario registrare gli assiemi PIA tramite regsvr32.

Sospetto che se si esegue come servizio di rete, non sarà possibile avviare Excel (nessun accesso interattivo, account con restrizioni, ecc.). Il codice ASP.NET viene eseguito all'interno del pool di applicazioni. È possibile modificare l'utente su cui viene eseguito il pool di applicazioni tramite il gestore IIS. Se vuoi controllare quale codice è attualmente in esecuzione come cerca il processo w3wp in Task Manager.

Per i test, modifica il pool di applicazioni in modo che l'utente che conosci funzioni con Excel.

Altri suggerimenti

Usiamo Aspose (commerciale). Office su un server non è molto divertente.

  • Devi stare attento alle licenze.
  • Di tanto in tanto devi interrompere un processo di sospensione.
  • Ottenere i diritti giusti richiede un certo sforzo.

Si chiama PI (t) A per un motivo ...

Prendi in considerazione l'idea di lavorare con file XLSX (nuovo in Office 2007, ma esiste un plug-in per Office 2003), che sono solo file ZIP contenenti file XML che puoi manipolare senza la necessità di Excel. SpreadsheetML (basato su XML) è ben documentato e non troppo complicato da programmare (potresti persino trovare un LINQ to SpreadsheetML da qualche parte sul web).

Come indicato sopra, Excel non è in realtà un prodotto server e potresti riscontrare tutti i tipi di problemi quando lo usi su un server.

Penso che il problema sia che una volta distribuita la tua applicazione su IIS, ti trovi improvvisamente all'interno di un appartamento COM MTA. Credo che Excel sia un componente STA e quindi non possa essere creato all'interno dell'MTA. Dovrai impostare l'opzione aspcompat nella pagina che stai utilizzando 

<%@ page aspcompat=true %>

Ulteriori informazioni qui

Da Microsoft , (enfasi nella fonte originale):

  

Microsoft attualmente non consiglia e non supporta l'automazione di applicazioni Microsoft Office da qualsiasi applicazione o componente client non presidiato e non interattivo (inclusi ASP, ASP.NET, DCOM e NT Services), perché Office può presentare comportamenti instabili e / o deadlock quando Office viene eseguito in questo ambiente.

Con un elenco di motivi per cui non dovresti farlo:

  
      
  • ... Molti servizi vengono eseguiti con account che non hanno profili utente (come l'account SYSTEM o gli account IWAM_ [servername]). Pertanto, Office potrebbe non inizializzare correttamente all'avvio. In questa situazione, Office restituisce un errore sulla funzione CreateObject o CoCreateInstance. Anche se è possibile avviare l'applicazione di Office, altre funzioni potrebbero non funzionare correttamente se non esiste un profilo utente.
    •   
  • Se si verifica un errore imprevisto o se è necessario un parametro non specificato per completare una funzione, Office è progettato per richiedere all'utente una finestra di dialogo modale che chiede all'utente cosa desidera fare. Non è possibile chiudere una finestra di dialogo modale su un desktop non interattivo. Pertanto, quel thread smette di rispondere (si blocca) indefinitamente. Sebbene alcune pratiche di codifica possano aiutare a ridurre la probabilità di questo problema, queste pratiche non possono impedirlo del tutto. Questo fatto da solo rende rischiose e non supportate l'esecuzione delle applicazioni di Office da un ambiente lato server.
    •   
  • I componenti lato server devono essere componenti COM multi-thread altamente rientranti con un overhead minimo e un throughput elevato per più client. Le applicazioni di Office sono quasi esattamente l'opposto. Le applicazioni di Office sono server di automazione non rientranti, basati su STA, progettati per fornire funzionalità diverse ma ad alta intensità di risorse per un singolo client.   

E il tuo codice potrebbe generare i seguenti errori:

  • CoCreateInstance

    • Errore di runtime "429": il componente ActiveX non è in grado di creare l'oggetto
    • Errore di runtime "70": autorizzazione negata
    • CO_E_SERVER_EXEC_FAILURE (0x80080005): esecuzione del server non riuscita
    • E_ACCESSDENIED (0x80070005): accesso negato
    • si blocca
    • ritorna senza errori, ma non ha funzionato

E infine:

  

A causa delle limitazioni alla progettazione di Office, le modifiche alla configurazione di Office non sono sufficienti per risolvere tutti i problemi. Microsoft consiglia vivamente una serie di alternative che non richiedono l'installazione di Office sul lato server e che possono eseguire le attività più comuni in modo più efficiente e rapido rispetto all'automazione. Prima di coinvolgere Office come lato server componente nel tuo progetto, considera le alternative.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top