¿Mejor opción para alojar documentos de MS Office en una aplicación personalizada?

Actualmente estoy alojando un control de navegador IE en un formulario .NET (2.0) y lo uso para cargar archivos de Office como Excel y Word por lo tanto:

_ieCtrl.Navigate("C:\\test.xls", False); 

El alojamiento y la carga funcionan bien, excepto cuando navego a un archivo, aparece un cuadro de diálogo que pregunta si deseo guardar o abrir el archivo. (Este es el comportamiento estándar de descarga de archivos de IE). Por supuesto, siempre quiero abrirlo y no quiero que se muestre el cuadro de diálogo.

Otro problema es que cuando cierro la ventana que aloja el control de IE y el documento de Office, el documento no se cierra y permanece abierto en el disco. Esto significa que los bashs posteriores de abrir el mismo archivo a través de mi aplicación o la aplicación de oficina nativa fallarán debido a la violación de uso compartido.

¿Hay una forma programática de evitar este diálogo y limpiar los recursos después? Solicito una respuesta programática porque la investigación en la web solo ha brindado soluciones que implican la modificación de la configuración a nivel del sistema operativo.

Bounty NOTE:

Estoy abierto a cualquier solución a este problema que me permita:

  • Alojar una hoja de cálculo de Excel dentro de mi aplicación
  • Trabaje de forma bastante transparente (evite problemas de usabilidad como el descrito anteriormente)
  • Evite tener que realizar cambios específicos del sistema operativo que puedan afectar a otras aplicaciones (especialmente, por ejemplo, IE)
  • Tiene un costo adicional de cero (no se requieren licencias de terceros con licencia) El Proyecto de Código y otros recursos de código abierto están bien
  • No pierda el tiempo con el control ActiveX DSO Framer, a menos que se desarrolle / descubra una versión estable

¿Es su intención que el usuario pueda trabajar con el archivo de Excel de forma sencilla (es decir, columnas, filas, fórmulas, etc.), posiblemente guardándolo de nuevo? Si este es el caso, no puedo ver cómo puede resolver bien este problema sin confiar en COM Interop con el modelo de objetos de Excel o integrando bibliotecas de terceros para trabajar con la hoja de Excel. Sé que usted dijo que no había soluciones de pago, pero hay algunos controles de terceros con muchas funciones que funcionan solo con archivos de Excel dentro de las aplicaciones.

Noté en su comentario a SLaks que el producto final es un “tablero de instrumentos”. Si su intención es diseñar una aplicación de tablero de mandos personalizada, ¿ha considerado analizar los archivos de Excel para extraer los datos y luego presentarlos de manera lógica dentro de su aplicación? Esto elimina la necesidad de mostrar y trabajar directamente con el archivo de Excel mientras le permite trabajar con los datos dentro de ese archivo. Si está intentando obtener los datos fuera del archivo, aquí hay dos enfoques entre muchos:

  • Podría considerar usar el modelo de objetos de Excel y la interoperabilidad COM para leer los datos del archivo de Excel en su aplicación. Por supuesto, esto incluye una dependencia en la instalación de Excel, pero es una posibilidad. Este artículo tiene un código excelente para comenzar a leer archivos de Excel de esta manera.
  • Una mejor manera podría ser usar una biblioteca que no dependa de la instalación de Excel en el sistema local. Esta respuesta sugiere el uso de la biblioteca de Excel Data Reader , disponible en CodePlex.

Sé que esta respuesta separa su respuesta original de “hospedar documentos de MS Office en [una] aplicación personalizada”, pero en caso de que lo que realmente le interesa sean los datos dentro de esos archivos de Excel, espero que esta respuesta sea útil.

Este es un hack horrible y solo debe considerarse como último recurso: SendKeys.Send("{O}");

http://msdn.microsoft.com/en-us/library/system.windows.forms.sendkeys%28VS.71%29.aspx

Algo similar a
_ieCtrl.Navigate("C:\\test.xls", False);
(code to sleep or wait may be needed here)
SendKeys.Send("{O}");

Básicamente, usted envía la tecla “o” al cuadro de diálogo para que presione la opción “abrir”. Estás simulando presionar un teclado para hacer clic en el botón “abrir”. Es hackey porque

  • 1) Es posible que tenga que esperar entre llamadas. Si envía la tecla o antes de que finalice el diálogo, se perderá. Esperemos que la llamada de navegación finalice cuando aparezca el diálogo (no sé el comportamiento del control en c #). Es posible que deba experimentar con el tiempo, ya que las diferentes computadoras se abrirán más rápido y más lento
  • 2) Si el cuadro de diálogo no se muestra en una computadora, insertará “o” en él. Esto puede causar problemas al salir porque puede abrir otro cuadro de diálogo para intentar guardar los cambios. Puede evitarlo abriéndolo en modo de solo lectura
  • 3) Las diferentes versiones o ventanas pueden necesitar diferentes comandos sendkeys. Por ejemplo, puede que tenga que enviar “o” y ellos la tecla “{enter}”
  • 4) Probablemente más 🙂

Si desea abrir el archivo en una instancia de Excel separada (no integrada en el control WebBrowser), simplemente puede llamar

 Process.Start(@"C:\Test.xls"); 

Office nunca debió ejecutarse en modo integrado , no en una página web o en un host de documentos ActiveX. Microsoft nos había dado una y otra vez la advertencia. Desde sacar dsoframer de la base de conocimientos hasta omitir la clave de registro de BrowserFlags en Office 2007. Mover a los complementos de Office, Excel Web Access o Office Web Apps lo más rápido que pueda.