Entrar com a conta da Microsoft
Entrar ou criar uma conta.
Olá,
Selecionar uma conta diferente.
Você tem várias contas
Escolha a conta com a qual você deseja entrar.

Resumo

Os desenvolvedores podem usar a Automação no Microsoft Office para criar soluções personalizadas que usam os recursos e os recursos que são incorporados ao produto do Office. Embora esse desenvolvimento programático possa ser implementado em um sistema cliente com relativa facilidade, uma série de complicações podem ocorrer se a Automação ocorrer do código do lado do servidor, como ASP (Páginas do Microsoft Active Server), ASP.NET, DCOM ou um serviço Windows NT.

Este artigo discute as complicações que os desenvolvedores podem enfrentar. O artigo também oferece alternativas à Automação que podem acelerar o desempenho. Os desenvolvedores devem estar cientes, no entanto, de que as sugestões que este artigo fornece são apenas para fins informativos. A Microsoft não recomenda nem dá suporte à Automação do Office no lado do servidor.

Observação: Nesse contexto, o Mecanismo de Banco de Dados de Acesso Redistribuível e o Access Runtime são considerados componentes do Microsoft Office. O termo "lado do servidor" também se aplica ao código que está em execução em uma estação de trabalho do Windows, se o código estiver em execução de uma estação de trabalho do Windows diferente da estação interativa do usuário que está conectado. Por exemplo, o código iniciado pelo Agendador de Tarefas na conta SYSTEM é executado no mesmo ambiente que o código ASP do "lado do servidor" ou como código DCOM. Portanto, muitos dos problemas descritos por este artigo podem ocorrer. Para obter mais informações sobre estações de trabalho do Windows e sobre COM, consulte a seção "Mais Informações" e a seção "Referências".

Informações adicionais

Todas as versões atuais do Microsoft Office foram projetadas, testadas e configuradas para serem executadas como produtos de usuário final em uma estação de trabalho do cliente. Eles assumem um perfil interativo da área de trabalho e do usuário. Eles não fornecem o nível de reentrada ou segurança necessário para atender às necessidades de componentes do lado do servidor projetados para executar autônomos.

Atualmente, a Microsoft não recomenda e não dá suporte à automação de aplicativos do Microsoft Office de qualquer aplicativo ou componente cliente autônomo e não interativo (incluindo ASP, ASP.NET, DCOM e NT Services), pois o Office pode exibir um comportamento instável e/ou um impasse quando o Office é executado nesse ambiente.

Se você estiver criando uma solução que seja executada em um contexto do lado do servidor, tente usar componentes que foram tornados seguros para execução autônoma. Ou, você deve tentar encontrar alternativas que permitam que pelo menos parte do código execute o lado do cliente. Se você usar um aplicativo do Office de uma solução do lado do servidor, o aplicativo não terá muitas das funcionalidades necessárias para ser executado com êxito. Além disso, você assumirá riscos com a estabilidade de sua solução geral.

Problemas ao usar a Automação do Office no lado do servidor

Os desenvolvedores que tentam usar o Office em uma solução do lado do servidor precisam estar cientes de cinco áreas principais nas quais o Office se comporta de forma diferente do previsto devido ao ambiente. Se o código for executado com êxito, você deve resolver esses problemas e minimizar os efeitos deles o máximo possível. Considere esses problemas com cuidado ao 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: os aplicativos do Office assumem uma identidade de usuário quando os aplicativos são executados, mesmo quando a Automação inicia os aplicativos. Os aplicativos tentam inicializar barras de ferramentas, menus, opções, impressoras e alguns suplementos com base em configurações no hive do registro de usuário para o usuário que inicia o aplicativo. Muitos serviços são executados em contas que não têm perfis de usuário (como a conta SYSTEM ou as contas IWAM_[nome do servidor]). Portanto, o Office pode não inicializar corretamente na inicialização. Nessa situação, o Office retorna um erro na função CreateObject ou na função CoCreateInstance. Mesmo que o aplicativo do Office possa ser iniciado, outras funções podem não funcionar corretamente se nenhum perfil de usuário existir.

  • Interatividade com a área de trabalho: os aplicativos do Office assumem que estão sendo executados em uma área de trabalho interativa. Em algumas circunstâncias, os aplicativos podem precisar ficar visíveis para que determinadas funções de Automação funcionem corretamente. Se ocorrer um erro inesperado ou se um parâmetro não especificado for necessário para concluir uma função, o Office será projetado para solicitar ao usuário uma caixa de diálogo modal que pergunte ao usuário o que o usuário deseja fazer. Não é possível descartar uma caixa de diálogo modal em uma área de trabalho não interativa. Portanto, esse thread para de responder (trava) indefinidamente. Embora certas práticas de codificação possam ajudar a reduzir a probabilidade desse problema, essas práticas não podem impedir totalmente o problema. Esse fato por si só torna a execução de Aplicativos do Office de um ambiente do lado do servidor arriscada e sem suporte.

  • Reentrada e escalabilidade: os componentes do lado do servidor precisam ser componentes COM altamente reentrantes e com vários threads que tenham sobrecarga mínima e alta taxa de transferência para vários clientes. Os aplicativos do Office são, em quase todos os aspectos, exatamente o oposto. Os aplicativos do Office são servidores de Automação não reentrantes baseados em STA que foram projetados para fornecer funcionalidades diversas, mas intensivas em recursos para um único cliente. Os aplicativos oferecem pouca escalabilidade como uma solução do lado do servidor. Além disso, os aplicativos têm limites fixos para elementos importantes, como memória. Elas não podem ser alteradas por meio da configuração. Mais importante, os aplicativos usam recursos globais, como arquivos mapeados de memória, suplementos ou modelos globais e servidores de Automação compartilhada. Isso pode limitar o número de instâncias que podem ser executadas simultaneamente e podem levar a condições de corrida se os aplicativos estiverem configurados em um ambiente de vários clientes. Os desenvolvedores que planejam executar mais de uma instância de qualquer aplicativo do Office ao mesmo tempo precisam considerar "agrupar" ou serializar o acesso ao aplicativo do Office para evitar possíveis impasses ou corrupção de dados.

  • Resiliência e estabilidade: o Office 2000, o Office XP, o Office 2003 e o Office 2007 usam a tecnologia MSI (Microsoft Windows Installer) para facilitar a instalação e o auto-reparo para um usuário final. O MSI apresenta o conceito de "instalar no primeiro uso". Isso permite que os recursos sejam instalados ou configurados dinamicamente em tempo de execução para o sistema ou com mais frequência para um determinado usuário. Em um ambiente do lado do servidor, isso reduz o desempenho e aumenta a probabilidade de que uma caixa de diálogo possa aparecer que peça ao usuário que aprove a instalação ou forneça 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 de recursos msi do Office é contraproducente em um ambiente do lado do servidor. Além disso, a estabilidade do Office em geral não pode ser garantida quando o Office é executado no lado do servidor porque ele não foi projetado ou testado para esse tipo de uso. Usar o Office como um componente de serviço em um servidor de rede pode reduzir a estabilidade desse computador e, portanto, pode reduzir a estabilidade de toda a rede.

  • Segurança do lado do servidor: os aplicativos do Office nunca foram destinados ao uso do lado do servidor. Portanto, os aplicativos do Office não levam em consideração os problemas de segurança que os componentes distribuídos enfrentam. O Office não autentica solicitações de entrada. O Office também não protege você contra a execução intencional de macros ou de iniciar outro servidor que possa executar macros do seu código do lado do servidor. Não abra arquivos carregados no servidor de um site anônimo. Com base nas configurações de segurança que foram definidas pela última vez, o servidor pode executar macros em um contexto administrador ou sistema com privilégios completos e, portanto, pode comprometer sua rede. Além disso, o Office usa muitos componentes do lado do cliente (como MAPI Simples, WinInet e MSDAIPP) que podem armazenar em cache informações de autenticação do cliente para acelerar o processamento. Se o Office estiver sendo automatizado no lado do servidor, uma instância poderá atender mais de um cliente. Se as informações de autenticação tiverem sido armazenadas em cache para essa sessão, um cliente poderá usar as credenciais armazenadas em cache de outro cliente. Portanto, o cliente pode obter permissões de acesso não concedidas se passando por outros usuários.

Além dos problemas técnicos, você também deve considerar problemas de licenciamento. As diretrizes de licenciamento atuais impedem que aplicativos do Office sejam usados em um servidor para atender solicitações de cliente, a menos que esses próprios clientes tenham cópias licenciadas do Office. O uso da Automação do lado do servidor para fornecer a funcionalidade do Office a estações de trabalho não licenciados não é abordado pelo EULA (Contrato de Licença de Usuário Final).

Além desses problemas, um dos seguintes erros comuns pode ocorrer quando você tenta automatizar o lado do servidor do Office:

  • A função CreateObject e a função CoCreateInstance retornam uma das seguintes mensagens de erro em tempo de execução e não podem ser iniciadas para Automação.

    Mensagem 1

    Erro de tempo de execução '429': componente ActiveX não pode criar objeto

    Mensagem 2

    Erro de 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

  • Ao abrir um documento do Office, você receberá uma das seguintes mensagens de erro.

    Mensagem 1

    Erro de tempo de execução '5981' (0x800A175D): não foi possível abrir o armazenamento de macro

    Mensagem 2

    Erro em tempo de execução '1004': Falha no método '~' do objeto '~'

  • A função CreateObject e a função CoCreateInstance param de responder e nunca terminam ou levam 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 falham inesperadamente ou param de responder indefinidamente devido a um alerta do usuário ou outra caixa de diálogo que requer atenção do usuário.

  • Executar várias solicitações ou testes de estresse faz com que o código falhe, pare de responder ou falhe 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 encerrado, ou todas as instâncias do aplicativo que está sendo automatizado falham a partir desse ponto.

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

Alternativas à Automação do lado do servidor

A Microsoft recomenda fortemente que os desenvolvedores encontrem alternativas à Automação do Office se precisarem desenvolver soluções do lado do servidor. Devido às limitações ao design do Office, as alterações na configuração do Office não são suficientes para resolve todos os problemas. A Microsoft recomenda fortemente uma série de alternativas que não exigem que o Office seja instalado no lado do servidor e que possam executar tarefas mais comuns de forma mais eficiente e rápida do que a Automação. Antes de envolver o Office como um componente do lado do servidor em seu projeto, considere alternativas.

A maioria das tarefas de Automação do lado do servidor envolve criação ou edição de documentos. O Office 2007 dá suporte a novos formatos de arquivo Open XML que permitem que os desenvolvedores criem, editem, leiam e transformem o conteúdo do arquivo no lado do servidor. Esses formatos de arquivo usam o namespace System.IO.Package.IO no Microsoft .NET 3.x Framework para editar arquivos do Office sem usar os próprios aplicativos cliente do Office. Este é o método recomendado e compatível para lidar com alterações nos arquivos do Office de um serviço.

Os formatos de arquivo Open XML são um padrão público. 


A Microsoft fornece um SDK para manipular formatos de arquivo Open XML do .NET 3.x Framework. Para obter mais informações sobre o SDK e sobre como usar o SDK para criar ou editar arquivos XML Abertos, visite os seguintes sites da MSDN (Microsoft Developer Network):

Abrir documentação do SDK do XML

Como manipular documentos de formatos XML abertos do Office

Manipulando Word arquivos de 2007 com o modelo de objeto Open XML (Parte 1 de 3)

Manipulando Word arquivos de 2007 com o modelo de objeto Open XML (Parte 2 de 3)

Manipulando Word arquivos de 2007 com o Modelo de Objeto XML Aberto (Parte 3 de 3)

Manipulando arquivos do Excel 2007 e do PowerPoint 2007 com o Modelo de Objeto Open XML (Parte 1 de 2)

Manipulando arquivos do Excel 2007 e do PowerPoint 2007 com o Modelo de Objeto Open XML (Parte 2 de 2)

Criando Server-Side soluções de geração de documentos usando o modelo de objeto Open XML (Parte 1 de 2)

Criando soluções de geração de documentos Server-Side usando o modelo de objeto Open XML (Parte 2 de 2)

Ao transmitir arquivos XML Abertos do ASP ou de ASP.NET, você deve fornecer o tipo MIME (Extensão de Internet) multiuso correto para o conteúdo que você transmite. Para obter uma listagem dos tipos MIME para arquivos do Office 2007, visite o seguinte site:

Tipos MIME de formato de arquivo do Office 2007 para streaming de conteúdo HTTP

Se você estiver mirando somente clientes pré-Office 2007 e não quiser exigir o uso do Open XML na solução, poderá 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 MIME para que o texto resultante seja exibido no Office. O documento pode ser editado, salvo e até retornado ao servidor usando ASP no servidor.

Para obter mais informações sobre qualquer um desses tópicos e, para exemplos que mostram como implementá-los, clique nos seguintes números de artigo para exibir os artigos na Base de Dados de Conhecimento da Microsoft:

198703 Como automatizar o Excel de um VBScript do lado do cliente

Como consultar e atualizar dados do Excel usando o ADO do ASP

286023 Como usar um componente do VB ActiveX para automação de Word da Internet Explorer
 

Se sua empresa exigir a criação do lado do servidor dos formatos de arquivo binário office 97, Office 2000, Office XP e Office 2003, fornecedores de terceiros oferecem componentes que podem ajudá-lo. A Microsoft não fornece nenhum desses componentes, portanto, você precisará criar uma solução por conta própria ou comprar uma de um fornecedor de terceiros. Muitos produtos de terceiros diferentes estão disponíveis. Você deve investigar cada solução para melhor corresponder o fornecedor às suas necessidades de negócios.

Se você quiser criar sua própria solução que edite os formatos de arquivo binário office 97, Office 2000, Office XP e Office 2003 diretamente, você pode obter as especificações de formato de arquivo gratuitamente nos termos da Promessa de Especificação Aberta do Microsoft (OSP). Não há suporte técnico disponível para a documentação ou para os produtos que você cria, mas a documentação está disponível. 


As soluções do lado do servidor também podem querer permitir que os usuários carreguem arquivos e, em seguida, fazer com que o servidor renderize os arquivos para exibição na Web ou em outros meios. Atualmente, a Microsoft está trabalhando para oferecer esses recursos e fornece uma versão inicial desse recurso no Microsoft Serviços do Excel.

Serviços do Excel é uma nova tecnologia de servidor incluída no Microsoft Office SharePoint Server 2007 e que permite carregar, calcular e exibir pastas de trabalho do Excel no Office SharePoint Server 2007. Para obter mais informações sobre Serviços do Excel, visite os seguintes sites da MSDN (Microsoft Developer Network):

Visão geral Serviços do Excel

Passo a passo: desenvolvendo um aplicativo personalizado usando os Serviços Web do Excel

Criando aplicativos empresariais usando formatos XML Serviços do Excel e Office Open Word Automation Services é um novo aplicativo de serviço no SharePoint Server 2010. Word Os Serviços de Automação fornecem conversão autônoma do lado do servidor de documentos em formatos compatíveis com o aplicativo cliente do Microsoft Word.

Visão geral dos Serviços de Automação Word

Introdução Word Serviços de Automação Você precisa avaliar qual das opções que este artigo descreve atende às suas necessidades e a melhor maneira de implantar sua solução. As informações que este artigo fornece não são garantidas para resolve todos os problemas para todos os clientes. Você é encorajado a testar sua solução completamente antes de implantar a solução.

Precisa de mais ajuda?

Quer mais opções

Explore os benefícios da assinatura, procure cursos de treinamento, saiba como proteger seu dispositivo e muito mais.

As comunidades ajudam você a fazer e responder perguntas, fazer comentários e ouvir especialistas com conhecimento avançado.

Essas informações foram úteis?

Qual é o seu grau de satisfação com a qualidade do idioma?
O que afetou sua experiência?
Ao pressionar enviar, seus comentários serão usados para aprimorar os produtos e serviços da Microsoft. Seu administrador de TI poderá coletar esses dados. Política de Privacidade.

Agradecemos seus comentários!

×