Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
Nota
Para ASP.NET Core, consulte Configurar um aplicativo ASP.NET Core para o Serviço de Aplicativo do Azure. Se seu aplicativo ASP.NET for executado em um contêiner personalizado do Windows ou Linux, consulte Configurar um contêiner personalizado para o Serviço de Aplicativo do Azure.
ASP.NET aplicativos devem ser implantados no Serviço de Aplicativo do Azure como binários compilados. A ferramenta de publicação do Visual Studio cria a solução e, em seguida, implanta os binários compilados diretamente. O mecanismo de implantação do Serviço de Aplicativo implanta primeiro o repositório de código e, em seguida, compila os binários.
Este guia fornece conceitos-chave e instruções para ASP.NET desenvolvedores. Se este artigo for sua primeira experiência com o Serviço de Aplicativo do Azure, siga Implantar um aplicativo Web ASP.NET e Implantar um aplicativo ASP.NET com o Banco de Dados SQL do Azure no Azure primeiro.
Mostrar versões de runtime do .NET Framework suportadas
No Serviço de Aplicativo, as instâncias do Windows já têm todas as versões suportadas do .NET Framework instaladas. Para mostrar as versões de tempo de execução e SDK do .NET Framework disponíveis para você, vá para seu aplicativo no portal do Azure. Selecione Ferramentas de Desenvolvimento>Ferramentas Avançadas. Selecione Avançar. No Kudu, selecione Consola de Depuração para CMD ou PowerShell. Execute o comando apropriado no console baseado em navegador:
Para versões de tempo de execução do CLR 4 (.NET Framework 4 e superior):
ls "D:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework"
A versão mais recente do .NET Framework pode não estar disponível imediatamente.
Para versões de tempo de execução do CLR 2 (.NET Framework 3.5 e inferior):
ls "D:\Program Files (x86)\Reference Assemblies\Microsoft\Framework"
Se o tempo de execução que seu aplicativo requer não for suportado, você poderá implantá-lo com um contêiner personalizado.
Mostrar a versão do runtime atual do .NET Framework
Execute o seguinte comando no Cloud Shell:
az webapp config show --resource-group <resource-group-name> --name <app-name> --query netFrameworkVersion
Um valor de v4.0 significa que a versão mais recente do CLR 4 (.NET Framework 4.x) é utilizada. Um valor de v2.0 significa que uma versão do CLR 2 (.NET Framework 3.5) é usada.
Definir a versão do runtime do .NET Framework
Por padrão, o Serviço de Aplicativo usa a versão mais recente do .NET Framework com suporte para executar seu aplicativo ASP.NET. Para executar seu aplicativo usando o .NET Framework 3.5, execute o seguinte comando no Cloud Shell (v2.0 significa CLR 2):
az webapp config set --resource-group <resource-group-name> --name <app-name> --net-framework-version v2.0
O que acontece com tempos de execução desatualizados no Serviço de Aplicativo?
Tempos de execução desatualizados são preteridos pela organização mantenedora ou têm vulnerabilidades significativas. Assim, eles são removidos das páginas de criação e configuração no portal. Quando um tempo de execução desatualizado é oculto do portal, qualquer aplicativo que ainda esteja usando esse tempo de execução continua a ser executado.
Se você quiser criar um aplicativo com uma versão de tempo de execução desatualizada que não é mais mostrada no portal, use a CLI do Azure, um modelo ARM ou Bicep. Essas alternativas de implantação permitem criar tempos de execução preteridos que são removidos do portal, mas ainda estão sendo suportados.
Se um tempo de execução for totalmente removido da plataforma do Serviço de Aplicativo, o proprietário da assinatura do Azure receberá um aviso por email antes da remoção.
Aceder a variáveis de ambiente
No Serviço de Aplicativo, você pode definir configurações de aplicativo e cadeias de conexão fora do código do aplicativo. Em seguida, você pode acessá-los em qualquer classe usando o padrão ASP.NET padrão:
using System.Configuration;
...
// Get an app setting
ConfigurationManager.AppSettings["MySetting"];
// Get a connection string
ConfigurationManager.ConnectionStrings["MyConnection"];
}
Se você definir uma configuração de aplicativo com o mesmo nome no Serviço de Aplicativo e no web.config, o valor do Serviço de Aplicativo terá precedência sobre o valor web.config . O valor web.config local permite depurar o aplicativo localmente. O valor do Serviço de Aplicativo permite que você execute o aplicativo no produto com configurações de produção. As cadeias de conexão funcionam da mesma maneira. Dessa forma, você pode manter os segredos do aplicativo fora do repositório de código e acessar os valores apropriados sem alterar o código.
Nota
Considere opções de conectividade mais seguras que não exijam segredos de conexão. Para obter mais informações, consulte Conectividade segura com serviços e bancos de dados do Azure do Serviço de Aplicativo do Azure.
Implementar soluções multiprojeto
Quando uma solução do Visual Studio inclui vários projetos, o processo de publicação do Visual Studio inclui a seleção do projeto a ser implantado. Quando implantas no motor de implantação do App Service, como com Git ou com a implantação ZIP com a automação de compilação ativada, o motor de implantação do App Service escolhe o primeiro Web Site ou Projeto de Aplicação Web que encontra como app do App Service. Você pode especificar qual projeto o Serviço de Aplicativo deve usar especificando a configuração do PROJECT aplicativo. Por exemplo, execute o seguinte comando no Cloud Shell:
az webapp config appsettings set --resource-group <resource-group-name> --name <app-name> --settings PROJECT="<project-name>/<project-name>.csproj"
Obter uma página de exceções detalhada
Quando seu aplicativo ASP.NET gera uma exceção no depurador do Visual Studio, o navegador exibe uma página de exceção detalhada. Uma mensagem de erro genérica substitui essa página no Serviço de Aplicativo. Para exibir a página de exceção detalhada no App Service, abra o arquivo web.config e adicione o elemento <customErrors mode="Off"/> sob o elemento <system.web>. Por exemplo:
<system.web>
<customErrors mode="Off"/>
</system.web>
Reimplique a sua aplicação com o web.config atualizado. Agora deverá ver a mesma página de exceção detalhada.
Aceder aos registos de diagnósticos
Você pode adicionar mensagens de diagnóstico no código do aplicativo usando System.Diagnostics.Trace. Por exemplo:
Trace.TraceError("Record not found!"); // Error trace
Trace.TraceWarning("Possible data loss"); // Warning trace
Trace.TraceInformation("GET /Home/Index"); // Information trace
Para acessar os logs do console gerados de dentro do código do aplicativo no Serviço de Aplicativo, ative o log de diagnóstico executando o seguinte comando no Cloud Shell:
az webapp log config --resource-group <resource-group-name> --name <app-name> --docker-container-logging filesystem --level Verbose
Os valores possíveis para --level são Error, Warning, Infoe Verbose. Cada nível subsequente inclui o nível anterior. Por exemplo, Error inclui apenas mensagens de erro.
Verbose inclui todas as mensagens.
Depois de ativar o log de diagnóstico, execute o seguinte comando para ver o fluxo de log:
az webapp log tail --resource-group <resource-group-name> --name <app-name>
Se os logs do console não aparecerem imediatamente, verifique novamente em 30 segundos.
Para interromper o streaming de logs a qualquer momento, selecione Ctrl+C.