Konfigurera en ASP.NET Core-app för Azure App Service

ASP.NET Core-appar måste distribueras till Azure App Service som kompilerade binärfiler. Visual Studio-publiceringsverktyget skapar lösningen och distribuerar sedan de kompilerade binärfilerna direkt, medan App Service-distributionsmotorn distribuerar kodlagringsplatsen först och sedan kompilerar binärfilerna.

Den här guiden innehåller viktiga begrepp och instruktioner för ASP.NET Core-utvecklare. Om du aldrig har använt Azure App Service följer du först snabbstarten ASP.NET Core och ASP.NET Core med SQL Database.

dotnet --info

az webapp config show --resource-group <resource-group-name> --name <app-name> --query linuxFxVersion

az webapp list-runtimes --os linux | grep DOTNET

Ange .NET Core version

az webapp config set --name <app-name> --resource-group <resource-group-name> --linux-fx-version "DOTNETCORE|8.0"

az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings PRE_BUILD_COMMAND="echo foo, scripts/prebuild.sh"
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings POST_BUILD_COMMAND="echo foo, scripts/postbuild.sh"

Få åtkomst till miljövariabler

I App Service kan du ange appinställningar utanför din appkod. Sedan kan du komma åt dem i vilken klass som helst med hjälp av standardmönstret för ASP.NET Core-beroendeinmatning:

using Microsoft.Extensions.Configuration;

namespace SomeNamespace 
{
    public class SomeClass
    {
        private IConfiguration _configuration;
    
        public SomeClass(IConfiguration configuration)
        {
            _configuration = configuration;
        }
    
        public SomeMethod()
        {
            // retrieve nested App Service app setting
            var myHierarchicalConfig = _configuration["My:Hierarchical:Config:Data"];
            // retrieve App Service connection string
            var myConnString = _configuration.GetConnectionString("MyDbConnection");
        }
    }
}

Om du konfigurerar en appinställning med samma namn i App Service och i appsettings.json, till exempel, har App Service-värdet företräde framför det appsettings.json värdet. Med det lokala appsettings.json-värdet kan du felsöka appen lokalt, men med App Service-värdet kan du köra appen i produktion med produktionsinställningar. Anslutningssträngar fungerar på samma sätt. På så sätt kan du hålla dina programhemligheter utanför kodlagringsplatsen och komma åt lämpliga värden utan att ändra koden.

az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings My__Hierarchical__Config__Data="some value"

az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings My:Hierarchical:Config:Data="some value"

Distribuera lösningar för flera projekt

När en Visual Studio-lösning innehåller flera projekt innehåller Visual Studio-publiceringsprocessen redan att välja det projekt som ska distribueras. När du distribuerar till App Service-distributionsmotorn, till exempel med Git eller med ZIP-distribution med versionsautomation aktiverad, väljer App Service-distributionsmotorn den första webbplatsen eller webbprogramprojektet som hittas som App Service-appen. Du kan ange vilket projekt App Service ska använda genom att ange appinställningen PROJECT . Kör till exempel följande kommando i Cloud Shell:

az webapp config appsettings set --resource-group <resource-group-name> --name <app-name> --settings PROJECT="<project-name>/<project-name>.csproj"

Få åtkomst till diagnostikloggar

ASP.NET Core tillhandahåller en inbyggd loggningsprovider för App Service. I Program.cs av projektet lägger du till providern i ditt program via ConfigureLogging tilläggsmetoden, som du ser i följande exempel:

public static IHostBuilder CreateHostBuilder(string[] args) =>
    Host.CreateDefaultBuilder(args)
        .ConfigureLogging(logging =>
        {
            logging.AddAzureWebAppDiagnostics();
        })
        .ConfigureWebHostDefaults(webBuilder =>
        {
            webBuilder.UseStartup<Startup>();
        });

Du kan sedan konfigurera och generera loggar med standardmönstret .NET Core.

Om du vill komma åt konsolloggarna som genereras i din programkod i App Service aktiverar du diagnostisk loggning genom att köra följande kommando i Cloud Shell:

az webapp log config --resource-group <resource-group-name> --name <app-name> --docker-container-logging filesystem --level Verbose

Möjliga värden för --level är: Error, Warning, Info och Verbose. Varje efterföljande nivå omfattar den föregående nivån. Exempel: Error omfattar endast felmeddelanden och Verbose omfattar alla meddelanden.

När diagnostisk loggning har aktiverats kör du följande kommando för att visa loggströmmen:

az webapp log tail --resource-group <resource-group-name> --name <app-name>

Om du inte ser konsolloggarna omedelbart kan du titta efter igen efter 30 sekunder.

Skriv Ctrl+C när som helst för att stoppa loggströmningen.

Mer information om hur du felsöker ASP.NET Core-appar i App Service finns i Felsöka ASP.NET Core i Azure App Service och IIS

Hämta sida med detaljerade undantag

När din ASP.NET Core-app genererar ett undantag i Visual Studio-felsökningsprogrammet visar webbläsaren en detaljerad undantagssida, men i App Service ersätts den sidan av en allmän HTTP 500 eller Ett fel inträffade när begäran bearbetades. Om du vill visa den detaljerade undantagssidan i App Service lägger du till appinställningen ASPNETCORE_ENVIRONMENT i din app genom att köra följande kommando i Cloud Shell.

az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings ASPNETCORE_ENVIRONMENT="Development"

Identifiera HTTPS-sessionen

I App Service sker TLS/SSL-avslutning hos nätverkslastbalanserarna, så alla HTTPS-begäranden når din app som okrypterade HTTP-begäranden. Om din applogik behöver veta om användarbegäranden är krypterade eller inte konfigurerar du mellanprogrammet Vidarebefordrade rubriker i Startup.cs:

• Konfigurera mellanprogrammet med ForwardedHeadersOptions för att vidarebefordra rubrikerna X-Forwarded-For och X-Forwarded-Proto i Startup.ConfigureServices.
• Lägg till privata IP-adressintervall till de kända nätverken så att mellanprogrammet kan lita på App Service-lastbalanseraren.
• Anropa metoden UseForwardedHeaders i Startup.Configure innan du anropar andra mellanprogram.

Om du sätter ihop alla tre elementen ser koden ut som i följande exempel:

public void ConfigureServices(IServiceCollection services)
{
    services.AddMvc();

    services.Configure<ForwardedHeadersOptions>(options =>
    {
        options.ForwardedHeaders =
            ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto;
        // These three subnets encapsulate the applicable Azure subnets. At the moment, it's not possible to narrow it down further.
        options.KnownNetworks.Add(new IPNetwork(IPAddress.Parse("::ffff:10.0.0.0"), 104));
        options.KnownNetworks.Add(new IPNetwork(IPAddress.Parse("::ffff:192.168.0.0"), 112));
        options.KnownNetworks.Add(new IPNetwork(IPAddress.Parse("::ffff:172.16.0.0"), 108));
    });
}

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    app.UseForwardedHeaders();

    ...

    app.UseMvc();
}

Mer information finns i Konfigurera ASP.NET Core att fungera med proxyservrar och lastbalanserare.

https://<app-name>.scm.azurewebsites.net/webssh/host

2019-04-08T14:07:56.641002476Z "-" - - [08/Apr/2019:14:07:56 +0000] "GET /robots933456.txt HTTP/1.1" 404 415 "-" "-"

Nästa steg

Eller se fler resurser:

Referens för miljövariabler och appinställningar