Excel se bloquea al imprimir la primera vez desde ASP.NET servicio web

Question

Estamos utilizando Excel para convertir a XLS SpreatSheetML en un servicio web ASP.NET. Por otra parte, si el usuario selecciona las casillas de verificación adecuadas, que generará un subproceso que utiliza Excel para imprimir la hoja de cálculo.

Recientemente, hemos desplegado la aplicación en un entorno nuevo, y luego empezamos a tener problemas: la primera vez que alguien intenta imprimir, Excel parece que se cuelga en el servidor - es decir, la llamada al método PrintOut en el libro, nunca vuelve .

Pero si iniciar sesión en el servidor como la identidad del grupo de aplicaciones y abra Excel, enviar algo a la impresora, y cerrarla de nuevo, la impresión va a funcionar a partir de entonces!

Sospecho que Excel está mostrando un invisible dialog - los síntomas son los mismos que teníamos antes, un momento en que Excel parecía estancarse en un "no se puede utilizar el objeto de vinculación e incrustación de" -dialog que apareció cuando Excel abre

Yo sé que el uso de la automatización de la oficina del lado del servidor es malo, pero esto es una aplicación de legado que es muy difícil de cambiar, por lo que no me acaba de avisar a rediseñar nuestra solución.

Alguien ha tenido alguna experiencia con este tipo de comportamiento?

Answer 1

Bueno, nadie parece haber tenido este problema.

Lo realmente extraño es que mis trabajos nocturnos (ordinaria .NET .exe) son perfectamente capaces de imprimir - es solamente mis servicios web que tienen este problema

.

Así que resolvió el problema haciendo lo que debería haber hecho hace mucho tiempo: Hice un simple servicio de Windows con Topshelf, que responde a algunos mensajes de MSMQ y realiza la impresión, y luego mis servicios web pueden ordenar copias impresas a través de una cola de mensajes.

Mucho mejor en todos los sentidos!

Answer 2

He tenido un sin fin de problemas (bajo rendimiento, procesos colgantes, procesos, etc.) rompiendo utilizando Microsoft Excel, Word y PowerPoint a través de interoperabilidad en un servicio web para imprimir documentos de Office en formato PDF. Yo también he tenido problemas que sospecho son causa de cuadros de diálogo invisibles (tal vez un archivo está dañado, recomendado sólo lectura se ha establecido, el archivo está protegido con contraseña, o lo que sea).

Sé que hay herramientas disponibles que no utilizan Office, pero son muy caros. Mi solución fue cambiar a la automatización de OpenOffice. OpenOffice parece ser mucho más estable, y he dejado colgando procesos y similares atrás.

Así, mientras que supongo que estoy diciendo "no automatizar Microsoft Office", no estoy sugiriendo que se abandona por completo la automatización; sólo que he tenido más más éxito la automatización de OpenOffice a Microsoft Office.

Answer 3

SpreadsheetGear para .NET puede leer xls o xlsx libros de trabajo y se pueden imprimir en la impresora predeterminada sin mostrar ningún cuadros de diálogo (ver el método WorkbookView.Print ()).

Puede descargar una evaluación aquí .

exención de responsabilidad: Soy dueño de SpreadsheetGear LLC

Answer 4

Al igual que muchas personas, I Tienes visto este tipo de comportamiento. Es causada por el uso de la API de Office en un servidor, especialmente una aplicación ASP.NET multiproceso.

Sin embargo, usted ha dicho que no quiere saber acerca de no pegarse un tiro en el pie, por lo que hay poco más que decir. Usted parece estar atrapado por las consecuencias de la locura anterior.

---

OK, detenerme si has oído este una:

Un hombre hace una pregunta en StackOverflow. Él dice: "Entonces, lo malo que sucede cuando automatizo una aplicación de Office desde el interior de un servicio". Así, John Saunders dice: "Por lo tanto, no automatizar la aplicación de Office desde el interior de un servicio. Automatizarlo desde el interior de una aplicación de escritorio, como Microsoft pretende hacer."

Cuando llega una solicitud para algo que requiere Excel, se debe crear un proceso que se ejecuta una aplicación de Windows Forms. La aplicación puede tener que comenzar con una ventana, o puede que tenga que empezar en el contexto de un escritorio remoto em> conexión

Este programa puede llamar a Excel como Excel espera ser llamada. Es probable que incluso puede manejar más de un comando a Excel (uno a la vez). Sin embargo, si se cuelga, el proceso puede ser matado y otro comenzó.

Nunca he probado esto, pero suena como que iba a funcionar mejor que tratar de conseguir Ofimática para hacer algo que no fue diseñado para hacer.