Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Remarque
Pour ASP.NET Core, consultez la section Configurer une application ASP.NET Core pour Azure App Service. Si votre application ASP.NET s’exécute dans un conteneur Windows ou Linux personnalisé, consultez Configurer un conteneur personnalisé pour Azure App Service.
Les applications ASP.NET doivent être déployées pour Azure App Service en tant que fichiers binaires compilés. L’outil de publication Visual Studio génère la solution, puis déploie directement les fichiers binaires compilés. Le moteur de déploiement App Service déploie d’abord le référentiel de code, puis compile les fichiers binaires.
Ce guide fournit des concepts clés et des instructions pour les développeurs ASP.NET. Si cet article est votre première expérience avec Azure App Service, suivez d’abord Déployer une application web ASP.NET et déployer une application ASP.NET avec Azure SQL Database dans Azure .
Afficher les versions du runtime .NET Framework prises en charge
Dans App Service, toutes les versions de .NET Framework prises en charge sont déjà installées sur les instances Windows. Pour afficher les versions du runtime et du Kit de développement logiciel (SDK) .NET Framework disponibles, accédez à votre application dans le portail Azure. Sélectionnez Outils> de développementOutils avancés. Sélectionnez Go. Dans Kudu, sélectionnez La console Debug pour CMD ou PowerShell. Exécutez la commande appropriée dans la console basée sur le navigateur :
Pour les versions du runtime CLR 4 (.NET Framework 4 et versions ultérieures) :
ls "D:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework"
La dernière version du .NET Framework peut ne pas être immédiatement disponible.
Pour les versions du runtime CLR 2 (.NET Framework 3.5 et versions antérieures) :
ls "D:\Program Files (x86)\Reference Assemblies\Microsoft\Framework"
Si le runtime requis par votre application n’est pas pris en charge, vous pouvez le déployer avec un conteneur personnalisé.
Afficher la version du runtime .NET Framework actuelle
Exécutez la commande suivante dans le Cloud Shell :
az webapp config show --resource-group <resource-group-name> --name <app-name> --query netFrameworkVersion
Une valeur de v4.0 signifie que la dernière version de CLR 4 (.NET Framework 4.x) est utilisée. La valeur de v2.0 signifie qu’une version CLR 2 (.NET Framework 3.5) est utilisée.
Définir la version du runtime .NET Framework
Par défaut, App Service utilise la dernière version de .NET Framework prise en charge pour exécuter votre application ASP.NET. Pour exécuter votre application avec .NET Framework 3.5, exécutez la commande suivante dans le Cloud Shell (v2.0 signifie CLR 2) :
az webapp config set --resource-group <resource-group-name> --name <app-name> --net-framework-version v2.0
Que se passe-t-il pour les runtimes obsolètes dans App Service ?
Les runtimes obsolètes sont déconseillés par l’organisation de maintenance ou présentent des vulnérabilités importantes. En conséquence, ils sont supprimés de la création et de la configuration des pages dans le portail. Lorsqu’un runtime obsolète est masqué dans le portail, toute application qui utilise toujours ce runtime continue à s’exécuter.
Si vous souhaitez créer une application avec une version d’exécution obsolète qui n’est plus affichée sur le portail, utilisez Azure CLI, un modèle ARM ou Bicep. Ces alternatives de déploiement vous permettent de créer des moteurs d’exécution obsolètes qui ont été supprimés du portail, mais qui sont toujours pris en charge.
Si un runtime est entièrement supprimé de la plateforme App Service, le propriétaire de votre abonnement Azure reçoit un e-mail avant la suppression.
Accéder aux variables d’environnement
Dans App Service, vous pouvez définir les paramètres de l’application et les chaînes de connexion en dehors de votre code d’application. Vous pouvez ensuite y accéder dans n’importe quelle classe à l’aide du modèle ASP.NET standard :
using System.Configuration;
...
// Get an app setting
ConfigurationManager.AppSettings["MySetting"];
// Get a connection string
ConfigurationManager.ConnectionStrings["MyConnection"];
}
Si vous configurez un paramètre d’application portant le même nom dans App Service et dans web.config, la valeur d’App Service est prioritaire sur la valeur de web.config. La valeur web.config locale vous permet de déboguer l’application localement. La valeur App Service permet d'exécuter votre application en production avec des paramètres de production. Les chaînes de connexion fonctionnent de la même façon. De cette façon, vous pouvez conserver les secrets de votre application en dehors de votre référentiel de code et accéder aux valeurs appropriées sans modifier votre code.
Remarque
Envisagez des options de connectivité plus sécurisées qui ne nécessitent pas de secrets de connexion du tout. Pour plus d’informations, consultez Connectivité sécurisée aux services et bases de données Azure à partir d’Azure App Service.
Déployer des solutions à projets multiples
Lorsqu’une solution Visual Studio inclut plusieurs projets, le processus de publication de Visual Studio inclut la sélection du projet à déployer. Lorsque vous effectuez un déploiement vers le moteur de déploiement App Service, comme c’est le cas avec Git ou Zip Deploy, avec l’automatisation de la génération activée, le moteur de déploiement App Service sélectionne le premier site web ou projet d’application web qu’il trouve en tant qu’application App Service. Vous pouvez spécifier le projet qu’App Service doit utiliser en spécifiant le paramètre d’application PROJECT. Par exemple, exécutez la commande suivante dans le Cloud Shell :
az webapp config appsettings set --resource-group <resource-group-name> --name <app-name> --settings PROJECT="<project-name>/<project-name>.csproj"
Accéder à la page d’exceptions détaillées
Lorsque votre application ASP.NET génère une exception dans le débogueur Visual Studio, le navigateur affiche une page d’exception détaillée. Un message d’erreur générique remplace cette page dans App Service. Pour afficher la page d’exception détaillée dans App Service, ouvrez le fichier web.config et ajoutez l’élément <customErrors mode="Off"/> sous l’élément <system.web> . Exemple :
<system.web>
<customErrors mode="Off"/>
</system.web>
Redéployez votre application avec la web.configmise à jour. Vous devez maintenant voir la même page d’exception détaillée.
Accéder aux journaux de diagnostic
Vous pouvez ajouter des messages de diagnostic dans votre code d’application à l’aide de System.Diagnostics.Trace. Exemple :
Trace.TraceError("Record not found!"); // Error trace
Trace.TraceWarning("Possible data loss"); // Warning trace
Trace.TraceInformation("GET /Home/Index"); // Information trace
Pour accéder aux journaux de console générés à partir du code de votre application dans App Service, activez la journalisation des diagnostics en exécutant la commande suivante dans Cloud Shell :
az webapp log config --resource-group <resource-group-name> --name <app-name> --docker-container-logging filesystem --level Verbose
Les valeurs possibles pour --level sont Error, Warning, Info, et Verbose. Chaque niveau suivant comprend le niveau précédent. Par exemple, Error inclut uniquement les messages d’erreur.
Verbose inclut tous les messages.
Après avoir activé la journalisation des diagnostics, exécutez la commande suivante pour afficher le flux de journaux :
az webapp log tail --resource-group <resource-group-name> --name <app-name>
Si les logs de console ne s’affichent pas immédiatement, revérifiez dans 30 secondes.
Pour arrêter le streaming de journaux à tout moment, sélectionnez Ctrl+C.