Pré-compilação do seu site (C#)

por Scott Mitchell

O Visual Studio oferece aos desenvolvedores ASP.NET dois tipos de projetos: WAPs (Projetos de Aplicativo Web) e WSPs (Projetos de Site). Uma das principais diferenças entre os dois tipos de projeto é que os WAPs devem ter o código explicitamente compilado antes da implantação, enquanto o código em um WSP pode ser compilado automaticamente no servidor Web. No entanto, é possível pré-compilar um WSP antes da implantação. Este tutorial explora os benefícios da pré-compilação e mostra como pré-compilar um site de dentro do Visual Studio e da linha de comando.

Introdução

O Visual Studio oferece aos desenvolvedores ASP.NET dois tipos de projeto diferentes: WAP (Projetos de Aplicativo Web) e WSP (Projetos de Site). Uma das principais diferenças entre esses tipos de projeto é que os WAPs exigem compilação explícita , enquanto os WSPs usam a compilação automática, por padrão. Com WAPs, você compila o código do aplicativo Web em um único assembly, que é criado na pasta do Bin site. A implantação envolve a cópia do conteúdo de marcação (os .aspx.ascxarquivos e .master ) no projeto, juntamente com o assembly na Bin pasta; os próprios arquivos de classe code-behind não precisam ser implantados. Por outro lado, você implanta WSPs copiando as páginas de marcação e suas classes code-behind correspondentes para o ambiente de produção. As classes code-behind são compiladas sob demanda no servidor Web.

Observação

Consulte a seção "Compilação Explícita versus Compilação Automática" no tutorial Determinando quais arquivos precisam ser implantados para obter mais informações sobre as diferenças entre os modelos de projeto, a compilação explícita e automática e como o modelo de compilação afeta a implantação.

A opção de compilação automática é simples de usar. Não há nenhuma etapa de compilação explícita e apenas os arquivos que foram modificados precisam ser implantados, enquanto a compilação explícita requer a implantação das páginas de marcação alteradas e do assembly apenas compilado. No entanto, a implantação automática tem duas possíveis desvantagens:

• Como as páginas devem ser automaticamente compiladas quando são visitadas pela primeira vez, pode haver um atraso curto, mas perceptível, quando uma página ASP.NET é solicitada pela primeira vez após ser implantada.
• A compilação automática exige que a marcação declarativa e o código-fonte estejam presentes no servidor Web. Essa pode ser uma opção pouco atraente se você planeja vender o aplicativo Web para clientes que o instalarão em seus servidores Web.

Se uma das duas deficiências acima for disjuntor, você poderá alternar para o modelo WAP ou pré-compilar o WSP antes da implantação. Este tutorial examina as opções de pré-compilação mais adequadas para um site hospedado e percorre o processo de pré-compilação e a implantação de um site pré-compilado.

Uma visão geral da geração e compilação de código ASP.NET

Antes de examinarmos as opções de pré-compilação disponíveis, vamos primeiro falar sobre a geração e compilação de código que ocorre quando uma página de ASP.NET é solicitada pela primeira vez desde que foi criada ou atualizada pela última vez. Como você sabe, ASP.NET páginas são compostas por duas partes: marcação declarativa no .aspx arquivo e uma parte de código-fonte, normalmente em um arquivo de classe code-behind separado (.aspx.cs). As etapas executadas pelo runtime quando uma página ASP.NET é solicitada dependem do modelo de compilação do aplicativo.

Com WAPs, o código-fonte das páginas deve ser compilado explicitamente em um único assembly antes de ser implantado. Durante a implantação, esse assembly e as várias páginas de marcação são copiados para o ambiente de produção. Quando uma solicitação chega ao servidor Web para uma página ASP.NET, o runtime cria uma instância da classe code-behind da página e invoca seu ProcessRequest método, que inicia o ciclo de vida da página e, por fim, gera o conteúdo da página, que é retornado ao solicitante. O runtime pode funcionar com a classe code-behind da página ASP.NET porque a classe code-behind já foi compilada em um assembly antes da implantação.

Com WSPs e compilação automática, não há nenhuma etapa de compilação explícita antes da implantação. Em vez disso, a implantação envolve a cópia do conteúdo declarativo e do código-fonte para o ambiente de produção. Quando uma solicitação chega ao servidor Web para uma página ASP.NET pela primeira vez desde que a página foi criada ou atualizada pela última vez, o runtime deve primeiro compilar a classe code-behind em um assembly. Esse assembly compilado é salvo na pasta %WINDIR%\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files, embora o local dessa pasta possa ser personalizado por meio do <compilation tempDirectory="" /> elemento de <system.web>, geralmente em Web.config. Como o assembly é salvo em disco, ele não precisa ser recompilado em solicitações subsequentes para a mesma página.

Observação

Como era de se esperar, há um pequeno atraso ao solicitar uma página pela primeira vez (ou pela primeira vez desde que ela foi alterada) em um site que usa a compilação automática, pois leva um momento para o servidor compilar o código da página e salvar o assembly resultante em disco.

Em suma, com a compilação explícita, você precisa compilar o código-fonte do site antes da implantação, salvando o runtime de ter que executar essa etapa. Com a compilação automática, o runtime manipula a compilação do código-fonte das páginas, mas com um pequeno custo de inicialização para a primeira visita à página desde que ela foi criada ou atualizada pela última vez.

Mas e a parte declarativa de ASP.NET páginas (o .aspx arquivo)? É óbvio que há uma relação entre os .aspx arquivos e o código em suas classes code-behind, pois os controles da Web definidos na marcação declarativa são acessíveis no código. Também é óbvio que o conteúdo nos .aspx arquivos influencia muito a marcação renderizada gerada pela página. Então, como o runtime funciona com a sintaxe de texto, HTML e controle da Web definida no .aspx arquivo para gerar o conteúdo renderizado da página solicitada?

Não quero ficar muito desviado nos detalhes de implementação de baixo nível, que variam entre WAPs e WSPs, mas, em poucas palavras, o runtime gera automaticamente um arquivo de classe que contém os vários controles da Web como membros e métodos protegidos. Esse arquivo gerado é implementado como uma classe parcial para a classe code-behind correspondente. (Classes parciais permitem que o conteúdo de uma única classe seja distribuído em vários arquivos.) Portanto, a classe code-behind é definida em dois locais: no .aspx.cs arquivo que você cria e nessa classe gerada automaticamente criada pelo runtime. Essa classe gerada automaticamente é armazenada na %WINDIR%\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files pasta .

O importante aqui é que, para que uma página ASP.NET seja renderizada pelo runtime, as partes declarativas e de código-fonte devem ser compiladas em um assembly. Com WAPs, o código-fonte é compilado explicitamente em um assembly antes da implantação, mas a marcação declarativa ainda deve ser convertida em código e compilada pelo runtime no servidor Web. Com os WSPs usando a compilação automática, o código-fonte e a marcação declarativa precisam ser compilados pelo servidor Web.

É possível usar a compilação explícita com o modelo WSP. Você pode compilar explicitamente a parte do código-fonte, como com o modelo WAP. Além disso, você também pode compilar a marcação declarativa.

Opções de pré-compilação

O .NET Framework é fornecido com uma ferramenta de compilação ASP.NET (aspnet_compiler.exe) que permite compilar o código-fonte (e até mesmo o conteúdo) de um aplicativo ASP.NET criado usando o modelo WSP. Essa ferramenta foi lançada com o .NET Framework versão 2.0 e está localizada na %WINDIR%\Microsoft.NET\Framework\v2.0.50727 pasta ; ela pode ser usada na linha de comando ou iniciada de dentro do Visual Studio por meio da opção Publicar Site do menu Build.

A ferramenta de compilação fornece duas formas gerais de compilação: pré-compilação in-loco e pré-compilação para implantação. Com a pré-compilação in-loco, você executa a aspnet_compiler.exe ferramenta na linha de comando e especifica o caminho para o diretório virtual ou caminho físico de um site que reside no computador. Em seguida, a ferramenta de compilação compila cada página ASP.NET no projeto, armazenando a versão compilada na %WINDIR%\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files pasta, assim como se as páginas tivessem sido visitadas pela primeira vez de um navegador. A pré-compilação in-loco pode acelerar a primeira solicitação feita para páginas de ASP.NET recém-implantadas em seu site, pois alivia o runtime da necessidade de executar essa etapa. No entanto, a pré-compilação in-loco não é útil para a maioria dos sites hospedados porque exige que você seja capaz de executar programas na linha de comando do servidor Web. Em ambientes de hospedagem compartilhados, esse nível de acesso não é permitido.

Observação

Para obter mais informações sobre a pré-compilação in-loco, confira How To: Precompile ASP.NET Web Sites and Precompilation in ASP.NET 2.0.

Em vez de compilar as páginas no site para a pasta , a Temporary ASP.NET Files pré-compilação para implantação compila as páginas em um diretório de sua escolha e em um formato que pode ser implantado no ambiente de produção.

Há dois tipos de pré-compilação para implantação que exploramos neste tutorial: pré-compilação com uma interface do usuário atualizável e pré-compilação com uma interface do usuário não atualizável. A pré-compilação com uma interface do usuário atualizável deixa a marcação declarativa nos .aspxarquivos , .ascxe .master , portanto, permitindo que um desenvolvedor exiba e, se desejado, modifique a marcação declarativa no servidor de produção. A pré-compilação com uma interface do usuário não atualizável gera páginas que são nulas .aspx.ascx de qualquer conteúdo e remove e .master arquivos, ocultando assim a marcação declarativa e proibindo um desenvolvedor de alterá-la do ambiente de produção.

Pré-compilação para implantação com uma interface do usuário atualizável

A melhor maneira de entender a pré-compilação para implantação é ver um exemplo em ação. Vamos pré-compilar o WSP revisões de livro para implantação usando uma interface do usuário atualizável. A ferramenta de compilação ASP.NET pode ser invocada no menu Build do Visual Studio ou na linha de comando. Esta seção examina o uso da ferramenta de dentro do Visual Studio; A seção "Pré-compilação da Linha de Comando" analisa a execução da ferramenta do compilador na linha de comando.

Abra o WSP revisão de livro no Visual Studio, vá para o menu Compilar e selecione a opção de menu Publicar Site. Isso inicia a caixa de diálogo Publicar Site (consulte a Figura 1), onde você pode especificar o local de destino, se a interface do usuário do site pré-compilado é atualizável e outras opções de ferramenta do compilador. O local de destino pode ser um servidor Web remoto ou servidor FTP, mas, por enquanto, escolha uma pasta no disco rígido do computador. Como queremos pré-compilar o site com uma interface do usuário atualizável, deixe a caixa de seleção "Permitir que este site pré-compilado seja atualizável" marcada e clique em OK.

Figura 1: a ferramenta de compilação ASP.NET pré-compilará seu site para o local de destino especificado
(Clique para exibir a imagem em tamanho real)

Observação

A opção Publicar Site no menu Compilar não está disponível no Visual Web Developer. Se você estiver usando o Visual Web Developer, precisará usar a versão de linha de comando da ferramenta de compilação ASP.NET, que é abordada na seção "Pré-compilação da Linha de Comando".

Depois de pré-compilar o site, navegue até o local de destino inserido na caixa de diálogo Publicar Site. Reserve um momento para comparar o conteúdo dessa pasta com o conteúdo do seu site. A Figura 2 mostra a pasta do site Revisões de Livros. Observe que ele contém arquivos .aspx e .aspx.cs . Além disso, observe que o Bin diretório inclui apenas um arquivo, Elmah.dll, que adicionamos no tutorial anterior

Figura 2: o diretório do projeto contém .aspx e .aspx.cs arquivos; a Bin pasta inclui apenas Elmah.dll
(Clique para exibir a imagem em tamanho real)

A Figura 3 mostra a pasta local de destino cujo conteúdo foi criado pela ferramenta de compilação ASP.NET. Essa pasta não contém arquivos code-behind. Além disso, o diretório dessa pasta Bin inclui vários assemblies e dois .compiled arquivos, além do Elmah.dll assembly.

Figura 3: a pasta local de destino inclui os arquivos para implantação
(Clique para exibir a imagem em tamanho real)

Ao contrário da compilação explícita em WAPs, a pré-compilação para o processo de implantação não cria um assembly para todo o site. Em vez disso, ele agrupa várias páginas em cada assembly. Ele também compila o Global.asax arquivo (se presente) em seu próprio assembly, bem como em qualquer classe na App_Code pasta. Os arquivos que mantêm a marcação declarativa para ASP.NET páginas da Web, Controles de Usuário e páginas mestras (.aspx, .ascxe .master arquivos, respectivamente) são copiados no estado em que se encontram para o diretório de localização de destino. Da mesma forma, o Web.config arquivo é copiado diretamente, juntamente com todos os arquivos estáticos, como imagens, classes CSS e arquivos PDF. Para obter uma descrição mais formal de como a ferramenta de compilação lida com vários tipos de arquivo, consulte Tratamento de arquivos durante ASP.NET pré-compilação.

Observação

Você pode instruir a ferramenta de compilação a criar um assembly por página de ASP.NET, Controle de Usuário ou página mestra marcando a caixa de seleção "Assemblies de nomenclatura e página única usados" na caixa de diálogo Publicar Site. Ter cada ASP.NET página compilada em seu próprio assembly permite um controle mais refinado sobre a implantação. Por exemplo, se você atualizou uma única página da Web ASP.NET e precisou implantar essa alteração, precisará implantar apenas o arquivo dessa .aspx página e o assembly associado no ambiente de produção. Consulte Como gerar nomes fixos com a ferramenta de compilação ASP.NET para obter mais informações.

O diretório de local de destino também contém um arquivo que não fazia parte do projeto Web pré-compilado, ou seja PrecompiledApp.config, . Esse arquivo informa ao runtime do ASP.NET que o aplicativo foi pré-compilado e se ele foi pré-compilado com uma interface do usuário atualizável ou não atualizável.

Por fim, reserve um momento para abrir um dos .aspx arquivos no local de destino usando o Visual Studio ou o editor de texto escolhido. Ao pré-compilar a implantação com uma interface do usuário atualizável, as páginas ASP.NET no diretório de localização de destino contêm exatamente a mesma marcação que os arquivos correspondentes no site.

Pré-compilação para implantação com uma interface do usuário não atualizável

A ferramenta do compilador ASP.NET também pode ser usada para pré-compilar um site para implantação com uma interface do usuário não atualizável. Pré-compilar o site com uma interface do usuário não atualizável funciona muito como pré-compilar com uma interface do usuário atualizável, a principal diferença é que as páginas ASP.NET, controles de usuário e páginas mestras no diretório de destino são despojadas de sua marcação. Para pré-compilar um site para implantação com uma interface do usuário não atualizável, escolha a opção Publicar Site no menu Compilar, mas desmarque a opção "Permitir que este site pré-compilado seja atualizável" (consulte a Figura 4).

Figura 4: desmarque a opção "Permitir que este site pré-compilado seja atualizável" para pré-compilar com uma interface do usuário não atualizável
(Clique para exibir a imagem em tamanho real)

A Figura 5 mostra a pasta local de destino após a pré-compilação com uma interface do usuário não atualizável.

Figura 5: a pasta local de destino para implantação com uma interface do usuário não atualizável
(Clique para exibir a imagem em tamanho real)

Compare a Figura 3 com a Figura 5. Embora as duas pastas possam parecer idênticas, observe que a pasta de interface do usuário não atualizável não tem a página mestra, Site.master. E enquanto a Figura 5 inclui as várias páginas ASP.NET, se você exibir o conteúdo desses arquivos, verá que eles foram removidos da marcação declarativa e substituídos pelo texto do espaço reservado: "Este é um arquivo de marcador gerado pela ferramenta de pré-compilação e não deve ser excluído!"

Figura 5: a marcação declarativa foi removida das páginas do ASP.NET

As Bin pastas nos Números 3 e 5 diferem mais substancialmente. Além dos assemblies, a Bin pasta na Figura 5 inclui um .compiled arquivo para cada página ASP.NET, Controle de Usuário e página mestra.

Pré-compilar um site com uma interface do usuário não atualizável é útil em situações em que você não deseja que o conteúdo das páginas ASP.NET seja modificado pela pessoa ou empresa que instala ou gerencia o site no ambiente de produção. Se você criar um aplicativo Web ASP.NET que você vende aos clientes para instalar em seus próprios servidores Web, convém garantir que eles não modifiquem a aparência do seu site editando diretamente as .aspx páginas enviadas por você. Ao pré-compilar seu site com uma interface do usuário não atualizável, você envia as páginas de espaço reservado .aspx como parte da instalação, impedindo assim que seus clientes examinem ou modifiquem seu conteúdo.

Pré-compilação da linha de comando

Nos bastidores, a caixa de diálogo Publicar Site do Visual Studio invoca a ferramenta de compilação ASP.NET (aspnet_compiler.exe) para pré-compilar o site. Como alternativa, você pode invocar essa ferramenta na linha de comando. Na verdade, se você usar o Visual Web Developer, precisará executar a ferramenta do compilador na linha de comando, pois o menu Build do Desenvolvedor web visual não inclui a opção Publicar Site.

Para usar a ferramenta do compilador da linha de comando, comece soltando para a linha de comando e navegando até o diretório da estrutura, %WINDIR%\Microsoft.NET\Framework\v2.0.50727. Em seguida, insira a seguinte instrução na linha de comando:

aspnet_compiler -p "physical_path_to_app" -v / -f -u "target_location_folder"

O comando acima inicia a ferramenta do compilador ASP.NET (aspnet_compiler.exe) e, por meio da opção , instrui-a -p a pré-compilar o site com raiz em physical_path_to_app; esse valor será algo como C:\MySites\BookReviewse deve ser delimitado pelas aspas.

A -v opção especifica o diretório virtual do site. Se o site estiver registrado como o site padrão na metabase do IIS, você poderá omitir a opção -p e apenas especificar o diretório virtual do aplicativo. Se você usar a opção -p , o valor que prosseguirá a opção -v indicará a raiz do site e será usado para resolver referências raiz do aplicativo. Por exemplo, se você especificar um valor de -v /MySite , as referências no aplicativo a ~/path/file serão resolvidas como ~/MySite/path/file. Como o site revisões de livros está localizado no diretório raiz da minha empresa de hospedagem da Web, usei a opção -v /.

A -f opção, se presente, instrui a ferramenta de compilação a substituir o diretório target_location_folder se ele já existir. Se você omitir a opção -f e a pasta de local de destino já existir, a ferramenta de compilação encerrará com o erro: "error ASPRUNTIME: O diretório de destino não está vazio. Exclua-o manualmente ou escolha um destino diferente."

A -u opção, se presente, informa a ferramenta para criar uma interface do usuário atualizável. Omita essa opção para pré-compilar o site com uma interface do usuário não atualizável.

Por fim, o target_location_folder é o caminho físico para o diretório de localização de destino; esse valor será algo como C:\MySites\Output\BookReviewse deverá ser delimitado pelas aspas.

Implantando o site pré-compilado

Neste ponto, vimos como usar a ferramenta de compilação ASP.NET para pré-compilar um site usando as opções de interface do usuário atualizáveis e não atualizáveis. No entanto, nossos exemplos até agora pré-compilaram o site para uma pasta local e não para o ambiente de produção. A boa notícia é que implantar o site pré-compilado é fácil e pode ser feito por meio do Visual Studio ou por meio de algum outro mecanismo de cópia de arquivo, como de um cliente FTP autônomo.

A caixa de diálogo Publicar Site (mostrada pela primeira vez na Figura 1) tem uma opção de local de destino, que indica para onde os arquivos de site pré-compilados são copiados. Esse local pode ser um servidor Web remoto ou servidor FTP. Inserir um servidor remoto nessa caixa de texto pré-compila e implanta o site no servidor especificado em uma etapa. Como alternativa, você pode pré-compilar o site para uma pasta local e copiar manualmente o conteúdo dessa pasta para o ambiente de produção por meio de FTP ou alguma outra abordagem.

Ter o site pré-compilado implantado automaticamente por meio da caixa de diálogo Publicar Site do Visual Studio é útil para sites simples em que não há diferenças de configuração entre os ambientes de desenvolvimento e produção. No entanto, conforme observado no tutorial Diferenças comuns de configuração entre desenvolvimento e produção, não é incomum que essas diferenças existam. Por exemplo, o aplicativo Web Revisões de Livros usa um banco de dados diferente no ambiente de produção do que no ambiente de desenvolvimento. Quando o Visual Studio publica o site em um servidor remoto, ele copia cegamente as informações do arquivo de configuração no ambiente de desenvolvimento.

Para sites com diferenças de configuração entre os ambientes de desenvolvimento e produção, talvez seja melhor pré-compilar o site para um diretório local, copiar os arquivos de configuração específicos de produção e copiar o conteúdo da saída pré-compilada para produção.

Para obter uma atualização sobre como copiar arquivos do ambiente de desenvolvimento para o ambiente de produção, consulte os tutoriais Implantando seu site usando um cliente FTP e implantando seu site usando o Visual Studio .

Resumo

ASP.NET dá suporte a dois modos de compilação: automático e explícito. Conforme discutido nos tutoriais anteriores, os WAPs (Projetos de Aplicativo Web) usam compilação explícita, enquanto os WSPs (Projetos de Site) usam a compilação automática, por padrão. No entanto, é possível compilar explicitamente um WSP antes da implantação usando a ferramenta de compilação ASP.NET.

Este tutorial se concentrou no suporte à Pré-compilação da ferramenta de compilação para implantação. Ao pré-compilar a implantação, a ferramenta de compilação cria uma pasta de local de destino, compila o código-fonte do aplicativo Web especificado e copia esses assemblies compilados e os arquivos de conteúdo para a pasta local de destino. A ferramenta de compilação pode ser configurada para criar uma interface do usuário atualizável ou não atualizável. Ao pré-compilar com uma opção de interface do usuário não atualizável, a marcação declarativa nos arquivos de conteúdo é removida. Em poucas palavras, a pré-compilação permite que você implante seu aplicativo baseado no Projeto do Site sem incluir arquivos de código-fonte e com a marcação declarativa removida, se desejado.

Programação feliz!

Leitura Adicional

Para obter mais informações sobre os tópicos discutidos neste tutorial, consulte os seguintes recursos:

• Pré-compilação do site ASP.NET
• Codebehind e Compilation no ASP.NET 2.0
• Pré-compilação em ASP.NET
• Opções de site pré-compilados em ASP.NET

AnteriorAvançar