ASP.NET Core sur l’hébergement Windows

Vous pouvez exploiter des applications ASP.NET Core sur nos hébergements Windows. Les ASP.NET Core Hosting Bundles actuels sont installés sur les serveurs (actuellement .NET 8 à .NET 10), y compris ASP.NET Core Module V2 (ANCM) et le runtime en 32 et 64 bits. Aucun réglage particulier n’est nécessaire dans Plesk ou IIS.

32 ou 64 bits ?

Chaque domaine fonctionne dans son propre pool d’applications avec son propre utilisateur, séparé de vos autres domaines. En règle générale, le pool est réglé sur 32 bits : publiez alors votre application pour win-x86. S’il est réglé sur 64 bits, publiez pour win-x64. Les deux fonctionnent en mode framework-dependent ou self-contained. Si la plateforme cible ne correspond pas au pool, l’application ne démarre pas. Si vous souhaitez faire changer le pool, contactez-nous via un ticket.

Mettre en place l’application

1. Téléversez l’application publiée par FTP ou via le gestionnaire de fichiers Plesk dans la racine du document de votre domaine. Veillez à ce que le dossier wwwroot avec tous ses sous-dossiers soit également téléversé.
2. Dans Plesk, ouvrez la tuile «.NET Core» de votre domaine. Vous y définissez le fichier de démarrage de l’application, enregistrez des variables d’environnement et redémarrez l’application.

Erreur 500.30 «ASP.NET Core app failed to start»

Ce message signifie que votre application s’interrompt au démarrage. La cause se trouve presque toujours dans l’application elle-même, par exemple un dossier manquant (souvent wwwroot), un fichier de configuration manquant ou une mauvaise plateforme cible (voir «32 ou 64 bits ?»). Voici comment voir le message d’erreur exact :

1. Dans Plesk, ouvrez la tuile «.NET Core» et activez sous «Journaux» l’option «Rediriger stdout/stderr vers un fichier».
2. Choisissez comme répertoire le dossier «logs» au niveau supérieur de votre abonnement. Il se trouve en dehors de la racine du document, n’est pas accessible de l’extérieur, et votre application a le droit d’y écrire.
3. Appelez à nouveau le site web. Vous trouvez maintenant dans le dossier «logs» un fichier contenant le message d’erreur.

Vous pouvez aussi définir stdoutLogEnabled=”true” dans la section aspNetCore du fichier web.config et indiquer sous stdoutLogFile un dossier dans lequel l’application peut écrire. Comme le journal peut contenir des informations internes, désactivez-le à nouveau après le dépannage.

Stocker les données et les clés de manière protégée

• Le dossier App_Data dans la racine du document n’est jamais servi par le serveur web. Vous attribuez les droits d’écriture à votre application dans le gestionnaire de fichiers Plesk via «Modifier les droits» (utilisateur du pool d’applications, écriture et modification). Vous pouvez aussi activer dans les «Paramètres d’hébergement» du domaine l’option «Autres droits d’écriture et de modification», l’application peut alors écrire dans toute la racine du document.
• Ou créez dans le gestionnaire de fichiers Plesk un dossier à vous au niveau supérieur de votre abonnement, donc en dehors de toute racine de document, et attribuez-y les droits d’écriture via «Modifier les droits». Par FTP, ce dossier n’est accessible qu’avec l’accès principal de l’abonnement, pas avec des utilisateurs FTP supplémentaires limités à un seul domaine.
• Enregistrez explicitement les clés ASP.NET Core Data Protection dans l’un de ces dossiers (PersistKeysToFileSystem). Sinon, elles sont perdues lors d’un redémarrage et les utilisateurs connectés sont déconnectés.

Secrets (p. ex. clés API)

Dans la tuile «.NET Core», vous pouvez enregistrer des variables d’environnement. Elles ne sont pas servies publiquement. Attention : ces réglages sont stockés dans le fichier web.config de votre application. Si vous écrasez web.config lors du déploiement d’une nouvelle version, ils disparaissent. Les valeurs qui doivent survivre à chaque déploiement sont à placer de préférence dans un fichier de configuration du dossier protégé, lu au démarrage de l’application.

Redémarrer ou arrêter l’application

• Dans la tuile «.NET Core» avec «Redémarrer», ou sur le domaine sous «Pool d’applications IIS dédié» avec les boutons pour arrêter, démarrer et recycler. Vos autres domaines ne sont pas concernés.
• Si vous placez un fichier app_offline.htm dans la racine du document, l’application s’arrête de manière contrôlée jusqu’à ce que vous supprimiez à nouveau le fichier. C’est pratique pour les mises à jour ou une sauvegarde cohérente.
• Il n’y a pas d’accès en ligne de commande. Via «Tâches planifiées» dans Plesk, vous pouvez toutefois exécuter vos propres programmes, scripts batch ou PowerShell de manière planifiée ou immédiate.

Vous trouverez plus d’informations sur les différences entre les deux types d’hébergement dans l’article Différence entre l’hébergement UNIX & Windows.