Excel si blocca quando si stampa la prima volta da ASP.NET webservice

Question

Stiamo usando Excel per convertire SpreatSheetML in XLS in un webservice ASP.NET. Inoltre, se l'utente controlla le caselle giuste, abbiamo genera un thread che utilizza Excel per stampare il foglio di calcolo.

Di recente, abbiamo implementato l'applicazione in un nuovo ambiente, e poi abbiamo iniziato ad avere problemi: la prima volta che qualcuno tenta di stampare, Excel sembra bloccarsi sul server - cioè la chiamata al metodo PrintOut sulla cartella di lavoro non ritorna mai .

Ma se accediamo al server come l'identità del pool di applicazioni e aprire Excel, inviare qualcosa alla stampante, e richiuderlo, la stampa lavorerà da allora in poi!

Ho il sospetto che Excel mostra un invisible dialog - i sintomi sono gli stessi che avevamo in precedenza, un momento in cui Excel sembrava stallo su una "non può usare Object Linking and Embedding" -dialog che è apparso quando Excel aperto

Lo so che l'utilizzo di Office automation sul lato server è male, ma questo è un app un'eredità che è molto difficile da cambiare, quindi per favore non solo io consiglio di ri-progettare la nostra soluzione.

Qualcuno ha avuto esperienze con questo tipo di comportamento?

Answer 1

Bene, nessuno sembra aver avuto questo problema.

La cosa veramente strana è che i miei lavori notturni (ordinaria .NET .exe) sono perfettamente in grado di stampare - è solo la mia servizi web che hanno questo problema

.

Così ho risolto il problema facendo quello che avrei dovuto fare molto tempo fa: ho fatto un semplice servizio di Windows con TopShelf, che risponde ad alcuni messaggi MSMQ e fa la stampa, e poi i miei servizi web possono ordinare stampe attraverso una coda di messaggi.

Molto più bello in ogni modo!

Answer 2

ho avuto problemi a non finire (scarso rendimento, processi che pendono, processi ecc infrangono) utilizzando Microsoft Excel, Word e PowerPoint attraverso l'interoperabilità in un servizio web per stampare documenti Office in formato PDF. Anch'io ho affrontato i problemi che ho il sospetto che sono causa di finestre di dialogo invisibili (forse un file è danneggiato, Consigliata sola lettura è stato impostato, il file è protetto da password, o qualsiasi altra cosa).

So che ci sono strumenti a disposizione che non utilizzano Office, ma sono molto costosi. La mia soluzione era quella di passare a OpenOffice l'automazione. OpenOffice sembra essere molto più stabile, e ho lasciato i processi appesa e simili alle spalle.

Così, mentre suppongo che sto dicendo "non automatizzare Microsoft Office", non sto suggerendo che si abbandona l'automazione del tutto; solo che ho avuto molto più successo l'automazione di OpenOffice a Microsoft Office.

Answer 3

SpreadsheetGear per NET può leggere xls o xlsx cartelle di lavoro e possono stampare sulla stampante predefinita senza visualizzare alcun le finestre di dialogo (si veda la WorkbookView.Print () metodo).

È possibile scaricare una valutazione qui .

Disclaimer: possiedo SpreadsheetGear LLC

Answer 4

Come molte persone, I sono visto questo tipo di comportamento. E 'causata da utilizzando le API di Office in un server, in particolare un'applicazione ASP.NET multithread.

Comunque, hai detto che non vuoi sapere di non sparare in un piede, quindi c'è poco altro da dire. Ti sembra di essere intrappolati dalle conseguenze di precedenti stoltezza.

---

OK, mi fermano se hai sentito questo un

Un uomo fa una domanda su StackOverflow. Egli dice: "Allora, cose cattive succede quando automatizzare un'applicazione di Office all'interno di un servizio". Così, John Saunders dice: "Quindi, non automatizzare l'applicazione di Office all'interno di un servizio. Automatizzare dall'interno di un'applicazione desktop, come Microsoft destinato a essere fatto".

Quando arriva una richiesta per qualcosa che richiede di Excel, è necessario creare un processo in esecuzione un'applicazione Windows Form. L'applicazione può essere necessario iniziare senza finestra, o potrebbe essere necessario avviarlo nel contesto di una Remote Desktop di connessione. In ogni caso, il compito di eseguire può essere passato come parametro della riga di comando, o il programma può ospitare un servizio WCF avere comandi inviati ad esso.

Questo programma può chiamare Excel come Excel si aspetta di essere chiamato. Si può probabilmente anche di gestire più di un comando in Excel (uno alla volta). Tuttavia, se si blocca, il processo può essere ucciso e un altro ha iniziato.

Non ho mai provato questo, ma suona come avrebbe funzionato meglio che cercare di ottenere Office Automation a fare qualcosa che non è stato progettato per fare.