Considerazioni sull'automazione lato server di Office

Si applica a
Office Products Access 2010 Excel 2010 Microsoft Outlook 2010 PowerPoint 2010 Microsoft Word 2010 Project Professional 2010 Project Standard 2010 Visio Standard 2010 Visio Professional 2010 Microsoft OneNote 2010 InfoPath 2010 Access 2013 Excel 2013 InfoPath 2013 Outlook 2013 PowerPoint 2013 Visio Professional 2013 Visio Standard 2013 Word 2013 Access 2016 Excel 2016 Outlook 2016 PowerPoint 2016 Visio Professional 2016 Visio Standard 2016 Word 2016 Office 365

Riepilogo

Gli sviluppatori possono usare l'automazione in Microsoft Office per creare soluzioni personalizzate che usano le funzionalità e le funzionalità incorporate nel prodotto Office. Anche se tale sviluppo programmatico può essere implementato in un sistema client con relativa facilità, se l'automazione viene eseguita da codice sul lato server, ad esempio Microsoft Active Server Pages (ASP), ASP.NET, DCOM o un servizio Windows NT, l'automazione può verificarsi.

Questo articolo descrive le complicazioni che gli sviluppatori possono affrontare. L'articolo offre anche alternative all'automazione che possono velocizzare le prestazioni. Tuttavia, gli sviluppatori devono tenere presente che i suggerimenti forniti in questo articolo sono solo a scopo informativo. Microsoft non consiglia o supporta l'automazione lato server di Office.

Nota

In questo contesto, il motore di database di Access Redistributable e Access Runtime sono considerati componenti di Microsoft Office. Il termine "lato server" si applica anche al codice in esecuzione su una workstation Windows, se il codice è in esecuzione da una workstation Windows diversa dalla stazione interattiva dell'utente connesso. Ad esempio, il codice avviato da Utilità di pianificazione con l'account SYSTEM viene eseguito nello stesso ambiente del codice ASP "lato server" o come codice DCOM. Di conseguenza, potrebbero verificarsi molti dei problemi descritti in questo articolo. Per ulteriori informazioni sulle workstation Windows e su COM, vedi la sezione "Ulteriori informazioni" e la sezione "Riferimenti".

Altre informazioni

Tutte le versioni correnti di Microsoft Office sono state progettate, testate e configurate per l'esecuzione come prodotti per l'utente finale su una workstation client. Presuppongono un desktop interattivo e un profilo utente. Non forniscono il livello di pertinenza o sicurezza necessario per soddisfare le esigenze dei componenti lato server progettati per l'esecuzione automatica.

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

Se si sta creando una soluzione che viene eseguita in un contesto lato server, è consigliabile provare a utilizzare componenti resi sicuri per l'esecuzione automatica. In alternativa, è consigliabile cercare alternative che consentano di eseguire almeno parte del codice sul lato client. Se si usa un'applicazione di Office da una soluzione lato server, nell'applicazione non saranno disponibili molte delle funzionalità necessarie per l'esecuzione corretta. Inoltre, ci si assumerà dei rischi con la stabilità della soluzione complessiva.

Problemi con l'automazione lato server di Office

Gli sviluppatori che provano a usare Office in una soluzione lato server devono essere consapevoli delle cinque aree principali in cui Office si comporta in modo diverso rispetto al previsto a causa dell'ambiente. Se il codice deve essere eseguito correttamente, è necessario risolvere questi problemi e ridurrne al minimo gli effetti il più possibile. Quando si crea l'applicazione, prestare attenzione a questi problemi. Una soluzione non può risolvere tutti i problemi. Schemi diversi richiedono la definizione della priorità degli elementi in modo diverso.

  • Identità utente: le applicazioni di Office presuppongono un'identità utente durante l'esecuzione delle applicazioni, anche quando l'automazione avvia le applicazioni. Le applicazioni tentano di inizializzare barre degli strumenti, menu, opzioni, stampanti e alcuni componenti aggiuntivi in base alle impostazioni nell'hive del Registro di sistema utente per l'utente che avvia l'applicazione. Molti servizi vengono eseguiti in account senza profili utente, ad esempio l'account SYSTEM o gli account IWAM_[nomeserver]. Pertanto, Office potrebbe non essere inizializzato correttamente all'avvio. In questo caso, Office restituisce un errore nella funzione CreateObject o CoCreateInstance. Anche se è possibile avviare l'applicazione di Office, altre funzioni potrebbero non funzionare correttamente se non esiste alcun profilo utente.
  • Interattività con il desktop: le applicazioni di Office presuppongono l'esecuzione sotto un desktop interattivo. In alcuni casi, per il corretto funzionamento di determinate funzioni di automazione, potrebbe essere necessario rendere visibili le applicazioni. 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 vuole fare. Una finestra di dialogo modale su un desktop non interattivo non può essere ignorata. Pertanto, il thread smette di rispondere (si blocca) all'infinito. Anche se alcune procedure di codifica possono contribuire a ridurre la probabilità di questo problema, queste procedure non possono impedire del tutto il problema. Solo questo fatto rende l'esecuzione delle applicazioni di Office da un ambiente lato server rischioso e non supportato.
  • Reentrancy e scalabilità: i componenti lato server devono essere componenti COM altamente reentranti e multithread con un sovraccarico minimo e una velocità effettiva elevata per più client. Le applicazioni di Office sono in quasi tutti gli aspetti l'esatto contrario. Le applicazioni di Office sono server di automazione basata su STA non reentrant progettati per fornire funzionalità diverse ma a uso intensivo di risorse per un singolo client. Le applicazioni offrono scarsa scalabilità come soluzione lato server. Inoltre, le applicazioni hanno limiti fissi per gli elementi importanti, come la memoria. Questi non possono essere modificati tramite la configurazione. E soprattutto, le applicazioni usano risorse globali come file di memoria mappati, modelli o componenti aggiuntivi globali e server di automazione condivisa. Questo può limitare il numero di istanze che possono essere eseguite contemporaneamente e può portare a condizioni race se le applicazioni sono configurate in un ambiente multi-client. Gli sviluppatori che prevedono di eseguire più istanze di qualsiasi applicazione di Office contemporaneamente devono prendere in considerazione il "pooling" o la serializzazione dell'accesso all'applicazione di Office per evitare potenziali deadlock o danneggiamento dei dati.
  • Resilienza e stabilità: Office 2000, Office XP, Office 2003 e Office 2007 usano la tecnologia Microsoft Windows Installer (MSI) per semplificare l'installazione e il ripristino automatico per un utente finale. MSI introduce il concetto di "installazione al primo utilizzo". In questo modo è possibile installare o configurare dinamicamente le funzionalità in fase di esecuzione per il sistema, o più spesso per un utente specifico. In un ambiente lato server, le prestazioni rallentano e aumentano la probabilità che venga visualizzata una finestra di dialogo che chiede all'utente di approvare l'installazione o di fornire un disco di installazione. Anche se questo è progettato per aumentare la resilienza di Office come prodotto per utenti finali, l'implementazione di Office delle funzionalità MSI è controproducente in un ambiente lato server. Inoltre, la stabilità di Office in generale non può essere garantita quando Office viene eseguito sul lato server perché non è stato progettato o testato per questo tipo di utilizzo. L'uso di Office come componente del servizio in un server di rete può ridurre la stabilità del computer e quindi ridurre la stabilità dell'intera rete.
  • Sicurezza sul lato server: le applicazioni di Office non sono mai state destinate all'uso lato server. Pertanto, le applicazioni di Office non prendono in considerazione i problemi di sicurezza che i componenti distribuiti devono affrontare. Office non autentica le richieste in arrivo. Office non protegge inoltre dall'esecuzione accidentale di macro o dall'avvio di un altro server che potrebbe eseguire macro dal codice sul lato server. Non aprire file caricati nel server da un sito Web anonimo. In base alle impostazioni di sicurezza impostate per l'ultima volta, il server può eseguire macro in un contesto di amministratore o di sistema con privilegi completi e può pertanto compromettere la rete. Inoltre, Office usa molti componenti lato client, ad esempio Simple MAPI, WinInet e MSDAIPP, che possono memorizzare nella cache le informazioni di autenticazione client per velocizzare l'elaborazione. Se Office è automatizzato sul lato server, un'istanza può richiedere più client. Se le informazioni di autenticazione sono state memorizzate nella cache per la sessione, un client può usare le credenziali memorizzate nella cache di un altro client. Di conseguenza, il client può ottenere autorizzazioni di accesso non concesse rappresentando altri utenti.

Oltre ai problemi tecnici, è necessario considerare anche i problemi di licenza. Le attuali linee guida sulle licenze impediscono alle applicazioni di Office di essere usate in un server per fornire assistenza alle richieste dei client, a meno che tali client non dispongano di copie di Office con licenza. L'uso dell'automazione sul lato server per fornire le funzionalità di Office alle workstation senza licenza non è coperto dal Contratto di licenza con l'utente finale.

Oltre a questi problemi, quando si tenta di automatizzare Office lato server può verificarsi uno dei seguenti errori comuni:

  • La funzione CreateObject e la funzione CoCreateInstance restituiscono uno dei seguenti messaggi di errore di runtime e non possono essere avviati per l'automazione.
    Messaggio 1

    Nota

    Errore di runtime '429': il componente ActiveX non riesce a creare l'oggetto

    Messaggio 2

    Nota

    Errore di runtime '70': Autorizzazione negata

    Messaggio 3

    Nota

    CO_E_SERVER_EXEC_FAILURE (0x80080005): esecuzione del server non riuscita

    Messaggio 4

    Nota

    E_ACCESSDENIED (0x80070005): accesso negato

  • Quando si apre un documento di Office, viene visualizzato uno dei messaggi di errore seguenti.
    Messaggio 1

    Nota

    Errore di runtime '5981' (0x800A175D): Impossibile aprire l'archiviazione delle macro

    Messaggio 2

    Nota

    Errore di runtime '1004': Metodo '~' dell'oggetto '~' non riuscito

  • La funzione CreateObject e la funzione CoCreateInstance smettono di rispondere e non vengono mai completate oppure impiegano molto tempo per essere restituite. In alcuni server la creazione è veloce, ma nel registro eventi di Windows vengono visualizzati 1004 errori che indicano che l'applicazione è stata interrotta.

  • Alcune funzioni non funzionano in modo imprevisto o smettono di rispondere indefinitamente a causa di un avviso utente o di un'altra finestra di dialogo che richiede l'attenzione dell'utente.

  • L'esecuzione di più richieste o test di stress causa errori, blocchi o arresti anomali del codice alla creazione o alla chiusura di un'applicazione di Office. In questo caso, il processo viene lasciato in esecuzione in memoria e non può essere terminato oppure tutte le istanze dell'applicazione che viene automatizzata non riescono da quel punto in poi.

Altri problemi o messaggi possono essere visualizzati in aggiunta a quelli elencati qui, ma in genere si verificano come risultato dei cinque problemi principali elencati in precedenza in questo articolo. 

Alternative all'automazione lato server

Microsoft consiglia vivamente agli sviluppatori di trovare alternative all'automazione di Office se devono sviluppare soluzioni lato server. A causa delle limitazioni alla progettazione di Office, le modifiche apportate alla configurazione di Office non sono sufficienti per risolvere tutti i problemi. Microsoft consiglia vivamente numerose 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 componente lato server nel progetto, è consigliabile usare alternative.

La maggior parte delle attività di automazione sul lato server implica la creazione o la modifica di documenti. Office 2007 supporta nuovi formati di file Open XML che consentono agli sviluppatori di creare, modificare, leggere e trasformare il contenuto dei file sul lato server. Questi formati di file usano lo spazio dei nomi System.IO.Package.IO in Microsoft .NET 3.x Framework per modificare i file di Office senza usare le applicazioni client di Office. Questo è il metodo consigliato e supportato per gestire le modifiche ai file di Office da un servizio.

I formati di file Open XML sono standard pubblici. 

Microsoft fornisce un SDK per modificare i formati di file Open XML da .NET 3.x Framework. Per ulteriori informazioni sull'SDK e su come utilizzare l'SDK per creare o modificare file Open XML, visitare i seguenti siti Web Microsoft Developer Network (MSDN):

Documentazione di Open XML SDK

Procedura: Modificare i documenti in formati Open XML di Office

Modifica di Word 2007 Files con il modello a oggetti Open XML (parte 1 di 3)

Modifica di Word 2007 Files con il modello a oggetti Open XML (parte 2 di 3)

Modifica di Word 2007 Files con il modello a oggetti Open XML (parte 3 di 3)

Modifica dei Files di Excel 2007 e PowerPoint 2007 con il modello a oggetti Open XML (parte 1 di 2)

Modifica dei Files di Excel 2007 e PowerPoint 2007 con il modello a oggetti Open XML (parte 2 di 2)

Creazione di Server-Side soluzioni di generazione di documenti mediante il modello a oggetti Open XML (parte 1 di 2)

Creazione di Server-Side soluzioni di generazione di documenti mediante il modello a oggetti Open XML (parte 2 di 2)

Quando si esegue il flusso di file Open XML da ASP o da ASP.NET, è necessario fornire il tipo mime (Multipurpose Internet Mail Extension) corretto per il contenuto in streaming. Per un elenco dei tipi MIME per i file di Office 2007, visitare il sito Web seguente:

Office 2007 File Format MIME Types for HTTP Content Streaming

Se si intende solo client pre-Office 2007 e non si vuole richiedere l'uso di Open XML nella soluzione, è possibile usare altri formati di file di Office non binari, ad esempio HTML, XML e RTF. È quindi possibile trasmettere questi file a un client usando un tipo MIME in modo che il testo risultante venga visualizzato in Office. Il documento può essere modificato, salvato e anche restituito al server utilizzando ASP sul server.

Per altre informazioni su uno di questi argomenti e per esempi su come implementarli, fare clic sui numeri dell'articolo seguente per visualizzare gli articoli della Microsoft Knowledge Base:

198703 Come automatizzare Excel da un file VBScript sul lato client

Come eseguire query e aggiornare dati di Excel utilizzando ADO da ASP

286023 Come usare un componente ActiveX VB per l'automazione Word da Internet Explorer
 

Se l'azienda richiede la creazione sul lato server dei formati di file binari di Office 97, Office 2000, Office XP e Office 2003, i fornitori di terze parti offrono componenti utili. Microsoft non fornisce alcun componente di questo tipo, quindi sarà necessario creare una soluzione autonomamente o acquistarne una da un fornitore di terze parti. Sono disponibili molti prodotti di terze parti diversi. È consigliabile analizzare ogni soluzione in modo che corrisponda al fornitore in base alle esigenze aziendali.

Se si vuole creare una soluzione personalizzata che modifichi direttamente i formati di file binari di Office 97, Office 2000, Office XP e Office 2003, è possibile ottenere gratuitamente le specifiche del formato di file in base ai termini di Microsoft Open Specification Promise (OSP). Non è disponibile alcun supporto tecnico per la documentazione o per i prodotti creati dall'utente, ma è disponibile la documentazione. 

Anche le soluzioni lato server potrebbero voler consentire agli utenti di caricare file e quindi fare in modo che il server esercizzi il rendering dei file per la visualizzazione sul Web o su altri mezzi. Microsoft sta attualmente lavorando per offrire tali funzionalità e fornisce una versione precedente di questa funzionalità in Microsoft Excel Services.

Excel Services è una nuova tecnologia server inclusa in Microsoft Office Server SharePoint 2007 che consente di caricare, calcolare e visualizzare cartelle di lavoro di Excel in Office Server SharePoint 2007. Per ulteriori informazioni su Excel Services, visitare i seguenti siti Web MICROSOFT Developer Network (MSDN):

Panoramica Excel Services

Procedura dettagliata: Sviluppo di un'applicazione personalizzata con Excel Web Services

La creazione di applicazioni aziendali mediante i formati Excel Services e Open XML di Office Word Automation Services è una nuova applicazione di servizio di Server SharePoint 2010. Word Automation Services fornisce una conversione automatica sul lato server dei documenti in formati supportati dall'applicazione client Microsoft Word.

Panoramica di Word Automation Services

Introduzione a Word Automation Services È necessario valutare le opzioni descritte in questo articolo in base alle proprie esigenze e il modo migliore per distribuire la soluzione. Le informazioni fornite in questo articolo non sono garantiti per risolvere tutti i problemi per tutti i client. È consigliabile testare la soluzione in modo approfondito prima di distribuirla.