Ce guide couvre le flux de travail développeur : écrire/builder l'application dans VS Code, générer le paquet de publication, puis le déployer à la main (copie de fichiers, sans CI/CD ni Web Deploy automatisé). Pour la configuration serveur/IIS elle-même (Hosting Bundle, site IIS, CORS, base SQLite, dépannage), voir le guide dédié — celui-ci se concentre sur le cycle “je code → je publie → je copie sur le serveur”.
Trois temps : développer et vérifier en local dans VS Code, générer un paquet de publication propre (``dotnet publish``), puis le transférer sur le serveur par copie manuelle (RDP ou partage réseau) sans écraser ce qui doit rester stable côté serveur (configuration de production, base de données).
Ce qui ne doit jamais être écrasé par un déploiement, à garder en tête tout du long :
dotnet --version
Pour éviter de retaper la commande à chaque fois, créez ``.vscode/tasks.json`` :
{
"version": "2.0.0",
"tasks": [
{
"label": "publish",
"command": "dotnet",
"type": "process",
"args": [
"publish",
"${workspaceFolder}/Logeas.Forms.Server.csproj",
"-c",
"Release",
"-o",
"${workspaceFolder}/publish"
],
"problemMatcher": "$msCompile"
}
]
}
Ensuite, ``Terminal → Exécuter la tâche…`` → ``publish`` lance la publication sans retaper la commande.
Ne publiez jamais sans avoir vérifié que l'application compile et démarre proprement en local :
dotnet build dotnet run
Vérifiez dans la console qu'il n'y a pas d'erreur de compilation, que les migrations EF Core s'appliquent sans erreur, et que le message ``Application started`` apparaît. Arrêtez ensuite avec ``Ctrl+C``.
Si votre ``appsettings.json`` de développement pointe vers une base SQLite locale de test, c'est normal et attendu — c'est ``appsettings.Production.json``, présent uniquement sur le serveur (ou explicitement exclu du paquet, voir étape 6), qui redirigera vers la vraie base en production.
Dans le terminal intégré VS Code :
dotnet publish -c Release -o ./publish
(ou ``Terminal → Exécuter la tâche… → publish`` si vous avez créé la tâche de l'étape 3.1).
Cette commande génère dans ``./publish`` : les DLL compilées, les dépendances, le ``web.config`` prêt pour IIS, et tout fichier marqué « Copy to Output Directory » dans le ``.csproj`` (typiquement ``appsettings.json``, et ``appsettings.Production.json`` si il est inclus dans le projet — voir avertissement étape 6).
Get-ChildItem ./publish
Contrôlez la présence de :
Point d'attention sur ``appsettings.Production.json`` : s'il est versionné dans votre dépôt Git avec les vraies valeurs de production (CORS, chemin de base), il sera republié et écrasera la version du serveur à chaque déploiement — ce qui est en fait acceptable si ce fichier ne contient aucun secret sensible et que ses valeurs sont censées être identiques à chaque déploiement (ex. l'origine CORS ne change pas souvent). Si en revanche il contient des valeurs qui ne doivent jamais être committées (chaîne de connexion avec mot de passe, clé de licence), gardez-le hors du dépôt Git (``.gitignore``) et hors du dossier publié — dans ce cas il doit être créé une seule fois manuellement sur le serveur (voir guide serveur, étape 8) et jamais recopié depuis le poste de dev. Adaptez l'étape 8 ci-dessous en fonction de votre choix.
Deux méthodes possibles, au choix selon votre confort :
Si le serveur expose un partage administratif ou dédié accessible depuis le poste de dev :
# Depuis le poste de développement, dans le terminal VS Code robocopy .\publish "\\app-logeas-ovh\c$\RemoteApp\Formulaire" /MIR /XF appsettings.Production.json /XD logs
Que vous copiiez à la main (RDP) ou via ``robocopy`` (partage réseau), n'écrasez jamais :
Si vous copiez à la main via RDP (pas de ``robocopy``), soyez vigilant à ne pas écraser ``appsettings.Production.json`` par un glisser-déposer global du dossier ``publish`` — copiez plutôt fichier par fichier, ou dossier par dossier en excluant ce fichier spécifique.
Le process .NET de l'application a certains fichiers ouverts (DLL en cours d'exécution) — les écraser directement peut échouer ou nécessiter un redémarrage du pool après coup. Méthode propre :
New-Item -ItemType File -Path "C:\RemoteApp\Formulaire\app_offline.htm" -Force
Remove-Item "C:\RemoteApp\Formulaire\app_offline.htm"
L'application redémarre automatiquement à la requête suivante.
Reprenez la méthode de test fiable du guide serveur (le piège du SNI avec curl s'applique toujours) :
curl.exe -v -k --resolve formulaire.logeas-web.fr:443:127.0.0.1 https://formulaire.logeas-web.fr/
Un ``404`` sur ``/`` est normal (API sans route racine). Testez ensuite une vraie route, puis depuis l'application Angular réelle pour valider CORS. En cas de problème, reportez-vous à la table de décision du guide serveur (annexe A) plutôt que de repartir de zéro.
| Élément | Statut |
|---|---|
| Build local sans erreur (dotnet build) | ☐ |
| Démarrage local sans exception (dotnet run, puis Ctrl+C) | ☐ |
| Publication générée (dotnet publish -c Release -o ./publish) | ☐ |
| Contenu du dossier publish vérifié (DLL, web.config, licence) | ☐ |
| app_offline.htm déposé avant la copie | ☐ |
| Copie effectuée SANS écraser appsettings.Production.json ni le dossier logs/données | ☐ |
| app_offline.htm supprimé après la copie | ☐ |
| Test post-déploiement réussi (curl –resolve, route réelle, Angular) | ☐ |
Un script qu'on lance soi-même à la main (pas de CI/CD), juste pour fiabiliser la séquence et éviter les oublis (app_offline, exclusions) :
# À exécuter depuis le poste de dev, dans le terminal VS Code, à la racine du projet $serveur = "\\app-logeas-ovh\c$\RemoteApp\Formulaire" dotnet publish -c Release -o ./publish New-Item -ItemType File -Path "$serveur\app_offline.htm" -Force Start-Sleep -Seconds 2 robocopy .\publish $serveur /MIR /XF appsettings.Production.json /XD logs Remove-Item "$serveur\app_offline.htm" Write-Host "Déploiement terminé. Pensez à tester avec curl --resolve."
Document préparé le 18 août 2026.