Considerações para automação do lado do servidor do Office

Todas as versões atuais do Microsoft Office foram projetadas, testadas e configuradas para serem executados como produtos do usuário final em uma estação de trabalho cliente. Eles supõem um perfil de usuário e área de trabalho interativo. Não fornecem o nível de segurança que é necessária para satisfazer as necessidades de componentes do lado do servidor que são projetados para ser executado no modo autônomo ou reentrância.A Microsoft atualmente não recomenda e não oferece suporte, aplicativos de automação do Microsoft Office de qualquer aplicativo cliente autônomo, não interativo ou componente (incluindo ASP, ASP.NET, DCOM e serviços NT), porque o Office pode apresentar comportamento instável e/ou bloqueio quando o Office é executado nesse ambiente.Se você estiver criando uma solução que é executado em um contexto do lado do servidor, você deve tentar usar componentes que tenham sido feitas seguros para a execução autônoma. Ou, você deve tentar encontrar alternativas que permitem pelo menos parte do código para ser executado no lado do cliente. Se você usar um aplicativo do Office de uma solução do lado do servidor, o aplicativo perderá muitos dos recursos necessários para executar com êxito. Além disso, você vai tirar os riscos com a estabilidade da solução geral.

Problemas ao usar automação do lado do servidor do Office

Os desenvolvedores que tentam usar o Office em uma solução do lado do servidor precisam estar ciente de cinco áreas principais em que Office se comporta de forma diferente do que o esperado devido o ambiente. Se o seu código seja executado com êxito, você deve resolver esses problemas e minimizar os efeitos tanto quanto possíveis. Considere cuidadosamente esses problemas quando você criar seu aplicativo. Uma solução não pode resolver todos os problemas. Designs diferentes exigem que você priorize os elementos de forma diferente.

• Identidade do usuário: aplicativos de escritório assumem uma identidade de usuário quando os aplicativos são executados, mesmo quando a automação inicia os aplicativos. Os aplicativos tentam inicializar as barras de ferramentas, menus, opções, impressoras e alguns suplementos com base nas configurações na seção de registro do usuário para o usuário que inicia o aplicativo. Muitos serviços executados sob contas com nenhum perfil de usuário (como a conta do sistema ou as contas IWAM _ [nome_do_servidor]). Portanto, Office não pode inicializar corretamente na inicialização. Nessa situação, o Office retorna um erro na função CreateObject ou a função CoCreateInstance . Mesmo se o aplicativo do Office pode ser iniciado, outras funções podem não funcionar corretamente se não existe nenhum perfil de usuário.
• Interatividade com a área de trabalho: aplicativos do Office que assumem que estão sendo executados em uma área de trabalho interativa. Em algumas circunstâncias, aplicativos talvez precise ficar visível para determinadas funções de automação para funcionar corretamente. Se ocorrer um erro inesperado, ou se um parâmetro não especificado será necessário para concluir uma função, Office foi projetado para oferecer ao usuário uma caixa de diálogo modal que pede ao usuário o que o usuário deseja fazer. Caixa de diálogo modal em um desktop não interativo não pode ser descartada. Portanto, esse thread para de responder (trava) indefinidamente. Embora certas práticas de codificação podem ajudar a reduzir a probabilidade dessa questão, essas práticas não podem impedir completamente o problema. Esse fato isolado já faz executando aplicativos do Office em um ambiente de servidor arriscadas e sem suporte.
• Reentrada e escalabilidade: componentes do lado do servidor precisam ser altamente reentrantes, multithread componentes COM sobrecarga mínima e alto throughput em vários clientes. Aplicativos do Office estão em quase todos os aspectos exatamente o oposto. Aplicativos do Office são baseados em STA, não reentrante servidores de automação que são projetados para fornecer a funcionalidade de diversa mas consomem muitos recursos para um único cliente. Os aplicativos oferecem pouca escalabilidade como uma solução do lado do servidor. Além disso, os aplicativos resolveu limites para elementos importantes, como a memória. Isso não podem ser alterados por meio da configuração. Mais importante, os aplicativos usam recursos globais como compartilhadas servidores de automação, suplementos globais ou modelos e arquivos de memória mapeada. Isso pode limitar o número de instâncias que podem ser executados simultaneamente e pode levar a condições de corrida, se os aplicativos são configurados em um ambiente de vários cliente. Os desenvolvedores que planejam executar mais de uma instância de qualquer aplicativo do Office ao mesmo tempo precisam considerar "pooling" ou serializar o acesso ao aplicativo do Office para evitar deadlocks potenciais ou corrupção de dados.
• Resiliência e estabilidade: Office 2000, Office XP, Office 2003 e Office 2007 usam tecnologia Microsoft Windows Installer (MSI) para instalação e reparo automático mais fácil para um usuário final. MSI apresenta o conceito de "instalar no primeiro uso". Isso permite que recursos a ser instalado ou configurado em tempo de execução para o sistema, ou mais frequentemente para um determinado usuário dinamicamente. Em um ambiente de servidor, isso os torna lento o desempenho e aumenta a probabilidade que pode aparecer uma caixa de diálogo que solicita que o usuário aprove a instalação ou para fornecer um disco de instalação. Embora isso seja projetado para aumentar a resiliência do Office como um produto de usuário final, a implementação do Office recursos MSI é contraproducente em um ambiente de servidor. Além disso, a estabilidade do Office em geral não pode ser assegurada quando o Office é executado no servidor porque ele não foi projetado ou testado para esse tipo de uso. Usando o Office como um componente de serviço em um servidor de rede pode reduzir a estabilidade do computador e, portanto, pode reduzir a estabilidade da rede inteira.
• Segurança do lado do servidor: aplicativos Office nunca foram destinados ao uso do servidor. Portanto, aplicativos do Office não levam em consideração os problemas de segurança distribuído face de componentes. Office não autenticar solicitações de entrada. Office também não protege você de acidentalmente executar macros ou inicie outro servidor que pode executar macros a partir do código do lado do servidor. Não abra arquivos que são carregados para o servidor de um site anônimo. Com base nas configurações de segurança que foram definidas pela última, o servidor pode executar macros em um contexto de administrador ou de sistema com privilégios totais e, portanto, pode comprometer a sua rede. Além disso, o Office usa muitos componentes do lado do cliente (por exemplo, Simple MAPI, WinInet e MSDAIPP) que podem armazenar em cache informações de autenticação do cliente para agilizar o processamento. Se o Office estiver sendo automatizado do lado do servidor, uma instância pode atender mais de um cliente. Se as informações de autenticação armazenadas em cache para a sessão, um cliente pode usar as credenciais em cache de outro cliente. Portanto, o cliente pode obter permissões de acesso concedidas não representem outros usuários.

Além de problemas técnicos, você também deve considerar a problemas de licenciamento. Diretrizes atuais de licenciamento impedir que aplicativos Office sendo usado em um servidor para solicitações de cliente do serviço, a menos que os próprios clientes têm licenciado cópias do Office. Usando a automação do lado do servidor para fornecer a funcionalidade do Office nas estações de trabalho sem licença não é coberto pelo contrato de licença de usuário final (EULA).Além desses problemas, um dos seguintes erros comuns pode ocorrer quando você tentar automatizar o Office no servidor:

• A função CreateObject e a função CoCreateInstance retornam uma das seguintes mensagens de erro de tempo de execução e não podem ser iniciados para automação.  
  Mensagem 1
  Erro em tempo de execução '429': componente ActiveX não pode criar objeto
  Mensagem 2
  Erro em tempo de execução '70': permissão negada
  Mensagem 3
  CO_E_SERVER_EXEC_FAILURE (0x80080005): Falha na execução do servidor
  Mensagem 4
  E_ACCESSDENIED (0x80070005): Acesso negado
• Quando você abre um documento do Office, você recebe uma das seguintes mensagens de erro.  
  Mensagem 1
  Erro em tempo de execução '5981' (0x800A175D): não foi possível abrir o armazenamento de macro
  Mensagem 2
  Run-time error '1004': método ' ~' do objeto ' ~' falhou
• A função CreateObject a função CoCreateInstance parar de responder e nunca terminar e levar muito tempo para retornar. Em alguns servidores, a criação é rápida, mas 1004 erros aparecem no log de eventos do Windows que indicam que o aplicativo foi interrompido.
• Determinadas funções falharem inesperadamente ou parar de responder indefinidamente devido a um alerta para o usuário ou outra caixa de diálogo que requer atenção do usuário.
• Executando várias solicitações ou estresse teste faz com que o código falhe, parar de responder ou falha na criação ou terminação de um aplicativo do Office. Quando isso ocorre, o processo é deixado em execução na memória e não pode ser terminado, ou todas as instâncias do aplicativo que está sendo automatizada falha desse ponto no.

Outros problemas ou mensagens podem aparecer além dos listados aqui, mas esses problemas geralmente ocorrem como resultado de cinco principais problemas listados anteriormente neste artigo.

Alternativas à automação do lado do servidor

A Microsoft recomenda que os desenvolvedores encontrar alternativas para automação do Office se eles precisam desenvolver soluções do lado do servidor. Devido às limitações de design do Office, as alterações na configuração do Office não são suficientes para resolver todos os problemas. A Microsoft recomenda um número de alternativas que não exigem o Office ser instalado no servidor e pode executar tarefas mais comuns de forma mais eficiente e mais rapidamente do que a automação. Antes que você envolva o Office como um componente do lado do servidor em seu projeto, considere as alternativas.A maioria das tarefas de automação do lado do servidor envolvem a criação de documentos ou edição. Office 2007 oferece suporte a novos formatos de arquivo Open XML que permitem aos desenvolvedores criar, editar, ler e transformar o conteúdo do arquivo no lado do servidor. Esses formatos de arquivo usam o namespace System.IO.Package.IO no Microsoft .NET Framework para editar arquivos do Office sem usar os próprios aplicativos do cliente Office de 3. x. Esse é o método recomendado e com suporte para lidar com alterações em arquivos do Office de um serviço.Os formatos de arquivo Open XML são um padrão público. Para obter uma cópia da especificação, visite o seguinte site:A Microsoft fornece um SDK para manipulação de formatos de arquivo Open XML do .NET Framework de 3. x. Para obter mais informações sobre o SDK e sobre como usar o SDK para criar ou editar arquivos Open XML, visite os seguintes sites da Microsoft Developer Network (MSDN): Para obter mais informações sobre como usar o Open XML do .NET Framework 3.0 e para obter um exemplo, clique nos números abaixo para visualizar os artigos na Base de Conhecimento da Microsoft: Quando você transmite arquivos Open XML do ASP ou ASP.NET, você deve fornecer o tipo correto de dinâmica de hosts (MIME, Multipurpose Internet Mail Extension) do conteúdo desse fluxo você. Para obter uma lista de tipos MIME para arquivos do Office 2007, visite o seguinte site:Se você tiver como alvo apenas clientes anteriores ao Office 2007 e não deseja exigir o uso de XML aberto na solução, você pode usar outros formatos de arquivo do Office não-binários, como HTML, XML e RTF. Em seguida, você pode transmitir esses arquivos para um cliente usando um tipo de MIME para que o texto resultante é exibida no Office. O documento pode ser editado, salvo e até mesmo retornado para o servidor usando ASP no servidor. Para obter mais informações sobre qualquer um desses tópicos e para obter exemplos que mostram como implementá-los, clique nos números abaixo para visualizar os artigos na Base de Conhecimento da Microsoft: Se sua empresa requer a criação do servidor do Office 97, Office 2000, Office XP e formatos de arquivo binário do Office 2003, os fornecedores oferecem componentes que podem ajudá-lo. A Microsoft não fornece esses componentes, portanto, você precisará criar uma solução por conta própria ou adquirir uma de um fornecedor de terceiros. Muitos produtos de terceiros diferentes estão disponíveis. Você deve investigar cada solução para melhor coincidir com o fornecedor para suas necessidades de negócios.