Indice dei contenuti
Se vi siete imbattuti in questo post è probabile che stiate passando un brutto quarto d'ora (per usare un eufemismo) in compagnia dei Microsoft Office primary interop assemblies (PIAs), noti anche come Microsoft.Office.Interop. Si tratta di un set di librerie, rilasciate gratuitamente da Microsoft su NuGet, che possono essere utilizzare per effettuare operazioni programmatiche - apertura, modifica, salvataggio, creazione e così via - sui principali file della Microsoft Office suite, tra cui: xls / xlsx (Excel), doc / docx (Word), mdb (Access) et al.
Se avete bisogno di una guida / tutorial / esempio di codice relativamente all'implementazione del Microsoft.Office.Interop package in una tipica applicazione web ASP.NET C#, non possiamo che suggerirvi di partire con la lettura di questo articolo: nelle righe che seguono daremo per scontato che abbiate già realizzato qualcosa del genere e che stiate avendo problemi con la fase successiva, ovvero con la pubblicazione dell'applicazione su un server di produzione con IIS7+ o IIS8+.
I problemi
Nella maggior parte dei casi, una volta installato il pacchetto NuGet di cui sopra sarà possibile accedere ai file Microsoft Office senza problemi di sorta: questo perché l'architettura su cui si basano tali librerie è ideale per essere utilizzata su un tipico ambiente di sviluppo, dove:
- non esistono accessi simultanei, poiché vi è quasi sempre un unico thread o processo, in conseguenza di una singola HTTP request;
- l'account che esegue l'applicazione (sul web server locale, Cassini, IIS Express o IIS) è quasi sempre dotato di privilegi elevati;
I problemi iniziano quando si tratta di dover passare da un ambiente di sviluppo a un ambiente di produzione, dove entrambe le agevolazioni di cui sopra non valgono più. Per questo motivo, in conseguenza della pubblicazione dell'applicazione su un tipico Windows Server dotato di IIS, è del tutto probabile vedere comparire uno dei seguenti errori:
Recupero della class factory COM per il componente con CLSID {00024500-0000-0000-C000-000000000046} non riuscito a causa del seguente errore: 80040154 Interfaccia non registrata. (Eccezione da HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG))
System.Runtime.InteropServices.COMException: Retrieving the COM class factory for component with CLSID {00024500-0000-0000-C000-000000000046} failed due to the following error: 80040154 Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG))
oppure:
System.Runtime.InteropServices.COMException: Recupero della class factory COM per il componente con CLSID {00024500-0000-0000-C000-000000000046} non riuscito a causa del seguente errore: 80070005 Accesso negato. (Eccezione da HRESULT: 0x80070005 (E_ACCESSDENIED)).
System.Runtime.InteropServices.COMException: Retrieving the COM class factory for component with CLSID {00024500-0000-0000-C000-000000000046} failed due to the following error: 80070005 Access denied. (Eccezione da HRESULT: 0x80070005 (E_ACCESSDENIED))
oppure:
System.Runtime.InteropServices.COMException: Il filtro messaggi ha indicato che l'applicazione è impegnata. (Eccezione da HRESULT: 0x8001010A (RPC_E_SERVERCALL_RETRYLATER))
System.Runtime.InteropServices.COMException: The message filter indicated that the application is busy. (Exception from HRESULT: 0x8001010A (RPC_E_SERVERCALL_RETRYLATER))
oppure:
System.Runtime.InteropServices.COMException (0x800706BA): Server RPC non disponibile. (Eccezione da HRESULT: 0x800706BA)
System.Runtime.InteropServices.COMException (0x800706BA): The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)
oppure:
System.Runtime.InteropServices.COMException (0x800A03EC): Microsoft Office Excel cannot access the file
System.Runtime.InteropServices.COMException (0x800A03EC): Impossibile accedere al file [...]. I motivi possibili sono:
Questi sono gli errori più comuni in cui è possibile (o per meglio dire probabile) imbattersi quando si lavora con Microsoft.Office.Interop in un ambiente di produzione. Come si può facilmente comprendere, è un mix di file e/o servizi mancanti, permessi insufficienti e problemi di concurrency. Per nostra fortuna, esistono valide soluzioni per ciascuno di questi problemi: vediamo quali.
Le Soluzioni
Iniziamo con la più semplice di tutte:
80040154 Interfaccia non registrata
La causa dell'errore 80040154 Interfaccia non registrata è quasi sempre da ricercare nel fatto che Microsoft Office non è installato sulla macchina di produzione (Windows Server/IIS). Proprio così: se qualcuno pensava che non fosse necessario installare MS Office sull'ambiente di produzione, ha fatto male i calcoli! La presenza di una istanza locale della suite Microsoft è resa necessaria dal fatto che, dietro le quinte, le librerie Microsoft.Office.Interop non fanno altro che richiamare in background i processi e i servizi della relativa applicazione - Word, Excel e così via. Inutile dire che questa tecnica è estremamente inefficiente, poiché si tratta di applicazioni pensate per lavorare in una sessione desktop e che mal sopportano l'architettura intrinsecamente multi-thread di una Applicazione Web: per questo motivo, è altamente consigliabile implementare un sistema di code mediante lock , Monitor.TryEnter o altri pattern di queueing similari per evitare che molteplici richieste HTTP effettuino contemporaneamente operazioni che richiedano l'utilizzo delle suddette librerie. Non affrontare questo problema nel modo corretto significherà con tutta probabilità andare incontro ad altre difficoltà, come vedremo tra un paio di paragrafi.
Non ci dilungheremo oltre su questo argomento: nel caso in cui abbiate bisogno di un esempio di implementazione tramite lockers, potete dare un'occhiata a questo articolo.
80070005 Accesso negato
Questo errore, come è prevedibile, si verifica quando l'identità associata all'Application Pool che esegue l'applicazione web non è dotata delle autorizzazioni sufficienti per utilizzare gli oggetti DCOM necessari per eseguire le applicazioni MS Office richieste. Per risolvere questo problema è necessario seguire i passaggi illustrati di seguito:
- Aprire IIS Manager > Application Pools e identificare l'identity assegnata all'Application Pool relativa all'applicazione web (si trova nella scheda delle Proprietà Avanzate / Advanced Properties). Prendete nota di quell'account utente o di sistema, poiché vi servirà a breve. Nell'eventualità in cui troviate una ApplicationPoolIdentity al posto di un utente vero e proprio, dovrete ricordarvi che l'account da modificare sarà IIS AppPool\[AppPoolName], ovvero l'utente creato dinamicamente dal sistema: ricordate che, nel caso in cui non vi troviate a vostro agio con gli utenti dinamici di IIS, potete sempre modificare l'identità dell'Application Pool assegnandola a un utente statico, come ad esempio NetworkService. Tuttavia, l'utilizzo dell'account dinamico ApplicationPoolIdentity per gestire le identità degli Application Pool è una best practice molto diffusa quando si lavora con IIS7 e IIS8 (e superiori), poiché mette automaticamente al riparo il server da problematiche di sicurezza. Per informazioni aggiuntive su questo argomento, consigliamo di dare un'occhiata a questo topic su StackOverflow.
- Eseguite il comando dcomcnfg da Windows > Start > Run o da un normale command-prompt: navigate nel pannello Component Services > Computers > My Computer > DCOM Config, quindi localizzate le varie voci "Microsoft XYZ Document" e/o "Microsoft XYZ Application", dove XYZ sono Word, Excel e/o Access - a seconda delle applicazioni che vi serve richiamare tramite DCOM dalla vostra applicazione web. Per ciascuna di queste dovrete effettuare le seguenti operazioni:
- Tasto destro sulla voce > selezionare Properties:
- Recatevi nella tab Identity, dove vedrete tre radio button: The Interactive User, The Launching User e This User. Selezionate This User, quindi inserite le credenziali dell'utente che ha installato MS Office sul computer.
- Passate ora al tab Security, dove troverete tre sezioni con altrettanti gruppi di radio button: impostate il radio button dei primi due (Launch and Activation Permissions e Access Authorization) su Customize, quindi aggiungete l'account corrispondente all'identità associata all'Application Pool dell'applicazione web - la stessa che vi siete annotati poco fa. In alcune configurazioni, e/o con alcune versioni di Windows Server, potrebbe essere necessario aggiungere anche l'account IUSR e l'account IUSR_[MACHINENAME].
IMPORTANTE: qualora nel pannello DCOM Config non vi fosse alcuna voce di tipo "Microsoft XYZ Document" e/o "Microsoft XYZ Application", è probabile che abbiate installato una versione di MS Office a 32-bit su una macchina a 64-bit: in questo caso, è necessario lanciare lo snap-in in modalità a 32-bit mediante il seguente comando:
|
1 |
> mmc comexp.msc /32 |
Per maggiori informazioni su questa problematica, consultare questo articolo su MS TechNet.
RPC_E_SERVERCALL_RETRYLATER
Questo messaggio di errore viene visualizzato in tutti i casi in cui si stanno effettuando più chiamate simultanee a Microsoft.Office.Interop senza aver implementato un sistema di code: si tratta di un tipico caso che, per i motivi espressi all'inizio di questo articolo, tende a verificarsi soltanto quando l'applicazione è stata pubblicata in un ambiente di produzione. La soluzione è, ovviamente, quella di implementare un sistema di code che consenta di mettere in queue tutte le richieste HTTP similari - utilizzando le istruzioni lock , Monitor.TryEnter o altre alternative similari (date un'occhiata a questo articolo per un esempio di implementazione completo di codice sorgente).
Server RPC non disponibile
L'errore 0x800706BA si verifica quando il servizio di Windows RPC Locator / RPC Endpoint Mapper non è in esecuzione. Per risolvere il problema è sufficiente recarsi su Pannello di Controllo > Strumenti di Amministraziones > Servizi ed avviarlo manualmente. Se il problema si risolve, ricordate di impostare l'esecuzione automatica all'avvio del sistema di tale servizio, onde evitare che la vostra applicazione web cessi di funzionare dopo ogni riavvio del server.
0x800A03EC Impossibile accedere al file
L'errore 0x800A03EC Impossibile accedere al file è forse il peggiore che può capitare, in quanto il messaggio di errore presentato è particolarmente fuorviante. Per risolverlo, è necessario compiere le seguenti operazioni:
- Creare le directory seguenti all'interno del server Windows + IIS:
- C:\Windows\SysWOW64\config\systemprofile\Desktop (per i server a 64-bit)
- C:\Windows\System32\config\systemprofile\Desktop (per i server a 32-bit e a 64-bit)
- Impostare il permesso Controllo Completo (Full control) per le due cartelle appena create per l'account associato all'identità dell'Application Pool (IIS AppPool\DefaultAppPool se abbiamo utilizzato l'account dinamico ApplicationPoolIdentity ).
Per il momento è tutto: spero sinceramente che questo articolo potrà essere di aiuto ai tanti sviluppatori che si trovano a combattere con le insidiose librerie Microsoft.Office.Interop per ASP.NET!
