Configurare un'app ASP.NET per Servizio app di Azure

Note

Per ASP.NET Core, vedere Configurare un'app ASP.NET Core per il Servizio app di Azure. Se l'app ASP.NET viene eseguita in un contenitore Windows o Linux personalizzato, vedere Configurare un contenitore personalizzato per Servizio app di Azure.

Le app ASP.NET devono essere distribuite nel Servizio app di Azure come file binari compilati. Lo strumento di pubblicazione di Visual Studio compila la soluzione e quindi distribuisce direttamente i file binari compilati. Il motore di distribuzione del servizio app distribuisce prima il repository di codice e quindi compila i file binari.

Questa guida fornisce concetti chiave e istruzioni per gli sviluppatori ASP.NET. Se questo articolo rappresenta la tua prima esperienza con Azure App Service, segui prima Distribuire un'app Web ASP.NET e poi Distribuire un'app ASP.NET con il database SQL di Azure in Azure.

Visualizzare le versioni di runtime di .NET Framework supportate

In Servizio app di Azure, tutte le versioni di .NET Framework supportate sono già installate nelle istanze di Windows. Per visualizzare il runtime di .NET Framework e le versioni sdk disponibili, passare all'app nel portale di Azure. Selezionare Strumenti>di sviluppo Strumenti avanzati. Fai clic su Vai. In Kudu selezionare Console di debug per CMD o PowerShell. Eseguire il comando appropriato nella console basata su browser:

Per le versioni di runtime CLR 4 (.NET Framework 4 e versioni successive):

ls "D:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework"

La versione più recente di .NET Framework potrebbe non essere immediatamente disponibile.

Per le versioni di runtime di CLR 2 (.NET Framework 3.5 e versioni successive):

ls "D:\Program Files (x86)\Reference Assemblies\Microsoft\Framework"

Se il runtime richiesto dall'applicazione non è supportato, è possibile distribuirlo con un contenitore personalizzato.

Visualizzare la versione corrente del runtime di .NET Framework

Eseguire il comando seguente in Cloud Shell:

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

Un valore pari a v4.0 indica che viene utilizzata la versione più recente di CLR 4 (Microsoft .NET Framework 4.x). Un valore pari a v2.0 indica che viene usata una versione CLR 2 (.NET Framework 3.5).

Impostare la versione del runtime di .NET Framework

Per impostazione predefinita, Servizio app di Azure usa la versione di .NET Framework supportata più recente per eseguire l'app ASP.NET. Per eseguire l'app usando .NET Framework 3.5, eseguire invece il comando seguente in Cloud Shell (v2.0 significa CLR 2):

az webapp config set --resource-group <resource-group-name> --name <app-name> --net-framework-version v2.0

Cosa accade ai runtime obsoleti nel servizio app?

I runtime obsoleti sono deprecati dall'organizzazione che li gestisce o presentano vulnerabilità significative. Di conseguenza, vengono rimossi dalle pagine di creazione e configurazione nel portale. Quando un runtime obsoleto è nascosto dal portale, qualsiasi app che usa ancora tale runtime continua a essere eseguita.

Se si desidera creare un'app con una versione di runtime obsoleta non più visualizzata nel portale, usare l'interfaccia della riga di comando di Azure, un modello di Resource Manager o Bicep. Queste alternative di distribuzione consentono di creare runtime deprecati che vengono rimossi dal portale, ma che continuano a essere supportati.

Se un runtime viene rimosso completamente dalla piattaforma del servizio app, il proprietario della sottoscrizione di Azure riceve un avviso di posta elettronica prima della rimozione.

Accedere alle variabili di ambiente

In Servizio app di Azure, è possibile configurare le impostazioni dell'app e le stringa di connessione al di fuori del codice dell'app. È quindi possibile accedervi da qualsiasi classe utilizzando il modello standard di ASP.NET:

using System.Configuration;
...
// Get an app setting
ConfigurationManager.AppSettings["MySetting"];
// Get a connection string
ConfigurationManager.ConnectionStrings["MyConnection"];
}

Se si configura un'impostazione dell'app con lo stesso nome in Servizio app di Azure e in web.config, il valore del Servizio app di Azure ha la precedenza sul valore web.config. Il valore web.config locale consente di eseguire il debug dell'app in locale. Il valore del servizio app consente di eseguire l'app nel prodotto con le impostazioni di produzione. Le stringhe di connessione funzionano nello stesso modo. In questo modo è possibile mantenere i segreti dell'applicazione al di fuori del repository del codice e accedere ai valori appropriati senza modificare il codice.

Note

Prendere in considerazione opzioni di connettività più sicure che non richiedono affatto segreti di connessione. Per altre informazioni, vedere Proteggere la connettività ai servizi e ai database di Azure dal servizio app di Azure.

Distribuire soluzioni multiprogetto

Quando una soluzione di Visual Studio include più progetti, il processo di pubblicazione di Visual Studio include la selezione del progetto da distribuire. Quando si esegue la distribuzione nel motore di distribuzione del Servizio app di Azure, ad esempio con Git o con distribuzione ZIP con automazione della compilazione abilitata, il motore di distribuzione del Servizio app di Azure seleziona il primo sito Web o il progetto di applicazione Web trovato come app di Servizio app di Azure. È possibile specificare quale servizio app di progetto usare specificando l'impostazione dell'app PROJECT. Ad esempio, eseguire il comando seguente in Cloud Shell:

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

Pagina Ottieni eccezioni dettagliate

Quando l'app ASP.NET genera un'eccezione nel debugger di Visual Studio, nel browser viene visualizzata una pagina dettagliata dell'eccezione. Un messaggio di errore generico sostituisce tale pagina nel servizio app. Per visualizzare la pagina dettagliata dell'eccezione in App Service, aprire il file web.config e aggiungere l'elemento <customErrors mode="Off"/> sotto l'elemento <system.web>. Ad esempio:

<system.web>
    <customErrors mode="Off"/>
</system.web>

Ridistribuire l'app con il file web.config aggiornato. Verrà ora visualizzata la stessa pagina dettagliata dell'eccezione.

Accedere ai log di diagnostica

È possibile aggiungere messaggi di diagnostica nel codice dell'applicazione usando System.Diagnostics.Trace. Ad esempio:

Trace.TraceError("Record not found!"); // Error trace
Trace.TraceWarning("Possible data loss"); // Warning trace
Trace.TraceInformation("GET /Home/Index"); // Information trace

Per accedere ai log della console generati dall'interno del codice dell'applicazione nel servizio app, attivare la registrazione diagnostica eseguendo il comando seguente in Cloud Shell:

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

I valori possibili per --level sono Error, Warning, Infoe Verbose. Ogni livello successivo include il livello precedente. Ad esempio, Error include solo messaggi di errore. Verbose include tutti i messaggi.

Dopo aver attivato la registrazione diagnostica, eseguire il comando seguente per visualizzare il flusso di log:

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

Se i log della console non vengono visualizzati immediatamente, controllare di nuovo in 30 secondi.

Per arrestare lo streaming dei log in qualsiasi momento, selezionare CTRL+C.

Contenuti correlati

• Esercitazione: Creare un'app ASP.NET in Azure con un database SQL
• Informazioni di riferimento sulle variabili di ambiente e le impostazioni dell'app