Pregunta

¿Alguien sabe cómo hacer que las bibliotecas de interoperabilidad C # de MS Office 2007 .NET trabajen con Vista?

Tengo una aplicación .NET C # que tengo configurada para ejecutarse como un servicio de Windows. Este programa abrirá una plantilla de Word o Excel según la situación, modificará su contenido y luego guardará el documento de nuevo. Todo esto funcionó muy bien cuando lo estaba haciendo en una máquina con Windows Server 2003 o XP usando Office 2007. Cuando lo moví todo a una caja de Server 2008, todo dejó de funcionar. En Excel, por ejemplo, recibo una excepción de COM que me dice que el archivo de Excel no se puede abrir cuando el archivo está claramente allí y puedo abrirlo bien cuando lo hago manualmente. El servicio de Windows se ejecuta con la misma cuenta de usuario con la que inicio sesión en la máquina y esa cuenta es un Administrador.

¿Alguien tiene alguna idea de qué hacer?

¿Fue útil?

Solución

Debería evitar realmente ejecutar los clientes de Office como aplicaciones del lado del servidor. Considere usar xml como formato de archivo (xlsx para Office 2007, o usar el libro de trabajo de Excel xsd para (en cierto modo) versiones anteriores). Entonces se liberará de usar la API de Excel en el servidor.

Otros consejos

En Vista y Windows Server 2008, los servicios se ejecutan en algo llamado Session0. Antes de Vista, los programas normales se ejecutaban en Session0 junto con los servicios.

Esto significa que Session0 se ha convertido en un páramo sin escritorio donde sus servicios ni siquiera pueden acceder a explorer.exe. Estoy bastante seguro de que el problema es que las aplicaciones de Office esperan poder acceder a algunos componentes que normalmente están en el escritorio.

Dado que Excel, Word, etc. solo se admiten en una sesión de escritorio, solo tiene unas pocas opciones:

  1. Establezca la casilla de verificación Escritorio en la pestaña Inicio de sesión de las propiedades de su Servicio y ore para que apacigüe a los dioses de la Oficina. (Probablemente no lo haga).
    • Después de intentar 1, revisa tu código e intenta eliminar / solucionar cualquier cosa que cause que se bloquee.
  2. Use remoting / WCF para hacer que un servidor que realiza el trabajo de interoperabilidad, y haga que su servicio se comunique con él.
    • Deberá tener un usuario interactivo conectado y el usuario debe iniciar la aplicación del servidor de alguna manera. Quizás sea mejor utilizar el inicio automático.
    • Puedes intentar activar el inicio de sesión automático. http://support.microsoft.com/kb/324737
  3. Intente suplantar a un usuario que inició sesión con CreateProcessAsUser y sus amigos.
    • Nota: no sé qué tan bien funciona esto a menos que un usuario esté realmente conectado, por lo que podría no ser más útil que los 2 anteriores y es mucho más difícil de lograr. (Necesita P / Invocar)
  4. Vuelva a escribir su programa para usar OpenXML sdk o use algo como SpreadsheetGear.

Encontré un artículo interesante de Microsoft básicamente diciendo que no haga la automatización de Office.

Obtener los instalables de http://www.microsoft. com / downloads / details.aspx? FamilyID = 59daebaa-bed4-4282-a28c-b864d8bfa513 & amp; displaylang = es

instálelo en su sistema y refiera excel dll en su solución y espero que funcione.

¿Tiene los ensamblajes de interoperabilidad primarios instalados en el servidor? Por lo general, estos se encuentran en el GAC y no se incluyen en el directorio bin cuando compila su programa, por lo que deberán instalarse localmente en el servidor.

Esto es solo una suposición, pero podría ser UAC. Sé que las aplicaciones privilegiadas (admin) y las aplicaciones de usuario no pueden enviarse mensajes ni comunicarse de ninguna manera. Su servicio se está ejecutando como administrador, pero su escritorio se está ejecutando como un usuario regular en UAC aunque sean el mismo usuario. También espero que Office haya iniciado (precargado) partes de sí mismo en el inicio y que se ejecute como un usuario regular.

Intenta apagar UAC y ver si eso ayuda. Si es así, al menos sabes lo que es.

¿Deja una cuenta iniciada en la máquina? Office no es una aplicación del lado del servidor, y obtendrá errores aleatorios si intenta iniciar cualquiera de los ejecutables sin un contexto de escritorio.

Algo para recordar sobre Office. Solo es x86, por lo que si crea una aplicación en x64, no podrá acceder a los objetos COM subyacentes de Office. Necesitará compilar su aplicación en x86, entonces funcionará.

Puedes hacerlo entrando en las propiedades de tu proyecto y seleccionando x86 en la pestaña de compilación en Visual Studio.

Todo esto suponiendo que tu aplicación se está desarrollando / ejecutando en un entorno x64, es decir.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top