2009-12-07 13 views
5

Estoy trabajando en una aplicación que genera una cantidad relativamente grande de salida de Word. Actualmente, estamos usando servicios de Word Interop para hacer la creación de documentos, pero es bastante lento, especialmente en versiones anteriores (anteriores a 2007) de Office. Nos gustaría acelerar la generación.¿Cómo acelerar la generación de archivos de Word desde C#?

No he trabajado mucho en perfiles, pero estoy bastante seguro de que el problema es que estamos haciendo un montón de llamadas COM. Espero que la creación de perfiles produzca un subconjunto de llamadas que son más lentas que las demás, pero mi instinto me dice que probablemente se trate de sobrecarga COM (o sobrecarga de Word Interop), y no solo de unas pocas llamadas lentas.

Además, el producto puede generar resultados en HTML, y ese proceso (a) es muy rápido, y (b) usa prácticamente los mismos recorridos de codificación, solo con una subclase diferente para las funciones específicas de HTML. Así que estoy bastante seguro de que nuestro algoritmo no es fundamentalmente lento.

Así que ... Estoy buscando sugerencias para formas alternativas de acelerar la generación de archivos de Word.

No podemos simplemente cambiar el nombre de los archivos HTML generados a .doc, y no podemos generar RTF en su lugar; en ambos casos, se pierde información importante de formato, y en el caso RTF, los gráficos en línea no funcionan robustamente.

Uno de los enfoques que estamos evaluando es generar y abrir mediante programación un archivo de Word (a través de interoperabilidad) desde una plantilla que tiene una macro que sabe cómo consumir un archivo plano y crear el resultado requerido. Nos interesan los comentarios sobre ese enfoque, así como cualquier otra idea para acelerar las cosas.

Respuesta

5

Si puede pagarlo, recomendaría el producto Aspose.Words. Muy rápido y Word no necesita ser instalado.

También es mucho más fácil de usar que la interoperabilidad de oficina.

+0

Me encantaría usarlo, pero el precio es prohibitivo para nuestras necesidades particulares: nuestra aplicación es una aplicación de escritorio, por lo que cuesta $ 2500/desarrollador más o menos. –

+0

Sí, sé lo que quieres decir. Requiere mucho esfuerzo girar para obtener herramientas tan caras. Una pieza de código que escribí me llevó unas 4 horas, sospecho que me habría llevado una semana hacer que todo funcionara bien ya baja velocidad. Siento que tenemos nuestro dinero vale la pena. – Crispy

1

Su enfoque macro es exactamente cómo aceleramos la interoperación lenta de Excel (usando la versión 2003 creo).

Encontramos (al menos con Excel) que gran parte de la lentitud se debía a las llamadas individuales repetidas a través de la interoperabilidad. Comenzamos a agrupar comandos (es decir, formateamos grandes rangos, y luego cambiamos celdas específicas según sea necesario en lugar de formatear cada celda individualmente) y lógicamente pasamos a las macros.

Creo que el enfoque de macro + plantilla se traduciría felizmente.

+0

Genial ... ¿cómo manejaste la comunicación de datos desde tu aplicación .NET a la macro? –

+0

Desde la memoria, tratamos de enviar los datos con el número mínimo de llamadas interoperativas. Tal vez si tiene suerte, puede empujarlo en un bloque y hacer que su macro lo analice y haga su trabajo. – Gregory

Cuestiones relacionadas