Diferenças entre compilar um site e um aplicativo web

Existem muitas variedades de módulos ASP.NET baseados em várias plataformas, como formulários da Web, páginas da Web, MVC (Model-View-Controller) e o mais recente - Core. Neste artigo, desejo examinar várias diferenças entre compilar um site ASP.NET e um aplicativo Web ASP.NET.



Compilação de um site (Fig. 1) e um aplicativo da Web (Fig. 2).



Fig. 1: site ASP.NET e a distinção entre site ASP.NET e aplicativo Web ASP.NET



Fig. 2: Aplicativo da Web ASP.NET e a distinção entre o site ASP.NET e o aplicativo ASP.NET

Este artigo não é sobre a estrutura interna dos projetos do ASP.NET, mas sobre a experiência que adquiri ao trabalhar na plataforma do Serviço de Aplicativo do Azure. O dispositivo interno já está documentado aqui - “Pré-compilando seu site (C #)” (“Pré-compilando um site em C #”). Você deve entender a diferença entre compilação automática e explícita. Além disso, se você estiver lidando com um site ASP.NET, considere seriamente pré-compilar com aspnet_compiler.exe, conforme descrito em Como pré-compilar sites ASP.NET (como pré-compilar sites) ASP.NET ").

Aqui estão algumas publicações que ajudarão você a ampliar seus horizontes nessa questão e a explorar outros tópicos:

• "Por que meu aplicativo ASP.NET está reciclando, reiniciando" ("Por que o aplicativo ASP.NET é recompilado, recarregado")
• “Deve usar, deve conhecer os comandos WinDbg, o mais usado” (“Comandos do WinDbg que eu preciso conhecer e aplicar e que eu uso com mais frequência”)
• Laboratório 28: O impacto de debug = true ("Lição 28: o impacto de debug = true")
• "Debug = True"
• Todos os meus artigos do ASP.NET

Então, onde tudo começou? Queria verificar se entendi o processo de compilação de módulos ASP.NET em assemblies corretamente e decidi fazer isso no ambiente do Serviço de Aplicativo do Azure. Eu já tinha um conceito sobre arquivos ASP.NET temporários, sobre a compilação de arquivos ASPX em um assembly .dll e sobre onde eles estavam armazenados em um servidor autônomo. Eu tinha certeza de que, na plataforma do Serviço de Aplicativo, os dois primeiros pontos foram implementados de maneira semelhante, mas duvidei do terceiro - ou seja, onde os assemblies compilados são armazenados. Então, eu escrevi um código para descobrir.

public partial class _default : System.Web.UI.Page { protected void Page_Load(object sender, EventArgs e) { LabelFileLocation.Text = $"{System.Web.HttpRuntime.CodegenDir}"; rptResults1.DataSource = System.IO.Directory.GetFiles(System.Web.HttpRuntime.CodegenDir, "*.dll"); rptResults1.DataBind(); } }      () <asp:Repeater ID="rptResults1" runat="server"> <HeaderTemplate><table></HeaderTemplate> <ItemTemplate> <tr> <td><%# Container.DataItem %></td> </tr> </ItemTemplate> <FooterTemplate></table></FooterTemplate> </asp:Repeater> 

Depois publiquei esse código na plataforma do serviço de aplicativos.

Quando acessei o site pela primeira vez, obtive o resultado mostrado na Fig. 3 (originalmente na raiz do meu site ASP.NET havia três páginas)



Fig. 3: compilando um site ASP.NET na plataforma Azure App Service

Reiniciei o site e os binários compilados em uma nova montagem (Figura 4). Isso foi inesperado, pois apenas reiniciei e não fiz implantações ou alterações.



Fig. 4: compilando um site ASP.NET na plataforma do Serviço de Aplicativo do Azure

Eu procurei no KUDU o diretório de montagem e não o encontrei; foi muito estranho.

Depois de clicar nos links "Outra página" e "E outra página", todas as minhas páginas foram compiladas em um assembly e fiquei muito surpreso ao descobrir isso porque debug = true foi definido no meu arquivo web.config.

Eu precisava descobrir as respostas para as seguintes perguntas:

1. Por que meu aplicativo recompilou após a reinicialização, embora eu não tenha realizado nenhuma alteração de implantação ou configuração?
2. Por que não encontrei o assembly no KUDU, mesmo que meu código-fonte estivesse correto?
3. Por que meu aplicativo foi compilado em um único assembly, embora debug = true tenha sido definido no arquivo web.config?

A resposta para a primeira pergunta foi que eu estava realmente olhando para a montagem do KUDU, não a que foi compilada para o Serviço de Aplicativo. Dê uma olhada na Figura 2 no artigo “Crie um despejo de memória para o Web App de desempenho lento”. Isso mostra que o KUDU está sendo executado em um processo diferente do Serviço de Aplicativo. Portanto, o KUDU se recompilou ao criar a instância, e não era minha instância do Serviço de Aplicativo.

Também resolvi a segunda pergunta com base nas informações recebidas na primeira pergunta. Omitirei detalhes sobre a configuração dos arquivos na plataforma do Serviço de Aplicativo e direi que pude exibir meus assemblies de site ASP.NET nesta plataforma: para isso, defino WEBSITE_DISABLE_SCM_SEPARATION como true (veja a Figura 5). Faça isso apenas para teste e (ou) depuração e nada mais. Não recomendo mapear várias páginas de um site para um único processo no App Service. Após a conclusão da depuração, redefina esse valor e separe os processos novamente.



Fig. 5: compilar o site ASP.NET no Serviço de Aplicativo do Azure; Não consigo encontrar arquivos ASP.NET temporários no KUDU

A resposta para a terceira pergunta foi que, se o arquivo Web.Debug.config estiver presente, o atributo debug = true será excluído durante o processo de implantação.

 <compilation xdt:Transform="RemoveAttributes(debug)" /> 

Eu escrevi sobre arquivos XDT aqui , aqui e aqui , mas nesse caso eu tive que pensar um pouco para entender (lembrar, perceber) o significado deles.

Depois de definir WEBSITE_DISABLE_SCM_SEPARATION como true, parei e iniciei, em outras palavras, um começo a frio ... e vi que o SCM / KUDU e meu site realmente começaram no mesmo processo (Fig. 6.)



Fig. 6: compilar o site ASP.NET no Serviço de Aplicativo do Azure; Não consigo encontrar arquivos ASP.NET temporários no KUDU

A publicação e compilação do default.aspx é iniciada, o nome do assembly permanece inalterado após todas as solicitações (Fig. 7).



Fig. 7: compilando um site ASP.NET na plataforma do Serviço de Aplicativo do Azure

Para verificar isso, peguei um despejo da memória do processo, fiz um despejo do módulo e o analisei. Honestamente, eu ainda estava intrigado com o resultado exibido pelo assembly, porque descobri o parâmetro debug = true somente depois que todos os testes foram concluídos. Às vezes, escrevo artigos na ordem errada em que os eventos se seguem. Confuso, decidi testar a compilação em lote; leia aqui : “Elemento de compilação (esquema de configurações do ASP.NET)” (“Elemento de compilação - diagrama de parâmetros da Web do ASP.NET”). Eu esperava que um assembly por página fosse compilado, então o resultado (veja a Figura 8) foi uma surpresa completa.



Fig. 8: compilando um site ASP.NET na plataforma Azure App Service

Eu esperava ver um assembly por página, porque pensei que estava trabalhando com o parâmetro debug = true. Lendo sobre a compilação em lote, percebi que ele compila todas as páginas no assembly contido em um diretório específico. Então, criei dois diretórios e coloquei os arquivos .aspx em cada um deles. O PID não mudou, então não houve "partida a frio" (Fig. 9).



Fig. 9: compilando um site ASP.NET na plataforma Azure App Service

No entanto, o site foi realmente recompilado em outro arquivo binário, mas permaneceu no mesmo diretório (caminho) (Fig. 10).



Fig. 10: compilando um site ASP.NET na plataforma do Serviço de Aplicativo do Azure

Despejei a memória para verificar completamente a exatidão das minhas conclusões. E, assim que voltei à raiz do site e vi que todas as páginas do diretório foram compiladas, percebi que minha hipótese sobre a compilação em lote foi confirmada (Fig. 11).



Fig. 11: compilando um site ASP.NET na plataforma Azure App Service

Segui o link “Diretório 1” e vi outra montagem (Fig. 12).



Fig. 12: compilando um site ASP.NET na plataforma Azure App Service

Despejei a memória novamente, removi o despejo do módulo e vi que ele realmente corresponde à página “Diretório 1” (Fig. 13).



Fig. 13: compilando um site ASP.NET na plataforma Azure App Service

Fiz o mesmo na página do Diretório 2 (Fig. 14 e 15).



Fig. 14: compilando um site ASP.NET na plataforma do Serviço de Aplicativo do Azure



Fig. 15: compilando um site ASP.NET na plataforma do Serviço de Aplicativo do Azure

Eu também tive a oportunidade de ir às próprias assembléias em SCM / KUDU (Fig. 16).



Fig. 16: compilando um site ASP.NET na plataforma Azure App Service

Assim que descobri o problema com o parâmetro debug = true, tudo se encaixou e foi uma boa experiência de aprendizado. Espero que você ache meu artigo útil.

Recursos úteis

Guia de arquitetura de aplicativos em nuvem

Adote uma abordagem estruturada para desenvolver aplicativos em nuvem. Este e-book de 300 páginas sobre arquitetura de computação em nuvem discute as diretrizes de arquitetura, desenvolvimento e implementação que se aplicam independentemente da plataforma de nuvem que você escolher. Este guia inclui etapas para:

• Escolhendo o estilo certo de arquitetura de aplicativo em nuvem para seu aplicativo ou solução;
• seleção de tecnologias apropriadas de computação e armazenamento de dados;
• implementar 10 princípios de desenvolvimento para criar um aplicativo escalável, resiliente e gerenciável;
• seguindo os cinco princípios da criação de software de qualidade que garanta o sucesso do seu aplicativo na nuvem;
• Usando padrões de design projetados para o problema que você está tentando resolver.

→ Baixar

Guia do desenvolvedor do Azure

Nesta atualização do Guia do Desenvolvedor do Azure, você verá como o conjunto completo de serviços da plataforma de software do Azure atende às suas necessidades. Aqui você encontrará informações sobre abordagens arquiteturais e as situações mais comuns que surgem ao criar aplicativos em nuvem.


→ Baixar

Noções básicas do Microsoft Azure

Este livro fornece informações importantes sobre os principais serviços do Azure para desenvolvedores e profissionais de TI que são novos na computação em nuvem. Demonstrações passo a passo estão incluídas para ajudar o leitor a entender como começar com cada um dos principais serviços. Cada capítulo é independente, não é necessário realizar demonstrações práticas de capítulos anteriores para entender qualquer capítulo em particular.

Os seguintes tópicos são abordados neste livro:

• Introdução ao Azure;
• Serviço de Aplicativo do Azure e Aplicativos Web;
• Máquinas virtuais;
• Serviço de armazenamento;
• Bases de dados
• Serviços adicionais do Azure.

→ Baixar

Links úteis

• Documentação do ASP.NET
• Tutoriais principais do ASP.NET