Publier une application WinForms : dotnet publish

Publier une application, c'est produire les fichiers à installer sur les postes des utilisateurs : l'exécutable, ses bibliothèques et sa configuration, compilés en mode Release. Avec .NET 10, la commande dotnet publish (ou l'assistant Publier de Visual Studio) produit un dossier prêt à copier, ou même un seul fichier .exe. Ce chapitre explique les choix à faire : runtime inclus ou non, fichier unique, configuration, installation et numéro de version.

Debug et Release

Pendant le développement, Visual Studio compile en configuration Debug : code non optimisé, informations de débogage complètes. Pour livrer, on compile en Release : le code est optimisé, et les vérifications réservées au débogage disparaissent. Ne livre jamais le contenu de bin\Debug.

Dépendante du runtime ou autonome ?

Une application .NET a besoin du runtime .NET pour s'exécuter. Deux modes de publication :

Les tailles ci-dessus ont été mesurées sur le projet complet du cours, qui embarque EF Core et deux pilotes MySQL ; une application qui n'utilise que MySqlConnector est nettement plus légère.

Les commandes

Depuis le dossier de la solution :

# Dépendante du runtime, un seul fichier .exe pour Windows 64 bits
dotnet publish Gsb.Ui -c Release -r win-x64 --no-self-contained -p:PublishSingleFile=true -o publication

# Autonome : le runtime .NET est inclus
dotnet publish Gsb.Ui -c Release -r win-x64 --self-contained -p:PublishSingleFile=true -o publication

Quelques options utiles en plus :

• -p:IncludeNativeLibrariesForSelfExtract=true : les bibliothèques natives (des .dll non .NET, comme celles qu'apporte MySql.Data pour Kerberos) restent sinon à côté de l'exécutable, même en fichier unique ;
• -p:EnableCompressionInSingleFile=true : compresse un fichier unique autonome ;
• -p:PublishReadyToRun=true : précompile le code pour un démarrage plus rapide, au prix d'un fichier plus gros.

Le découpage (trimming), qui retire le code inutilisé pour réduire la taille, n'est pas pris en charge pour WinForms : -p:PublishTrimmed=true produit l'erreur NETSDK1175.

Dans Visual Studio, l'assistant fait la même chose : clic droit sur Gsb.Ui > Publier > Dossier, puis Afficher tous les paramètres pour choisir le mode de déploiement, le runtime cible et l'option « Produire un seul fichier ». Le profil est enregistré dans Properties\PublishProfiles et se relance d'un clic.

La configuration à côté de l'exécutable

Le fichier appsettings.json du chapitre 12 doit être copié avec l'application. Dans le fichier projet :

<ItemGroup>
  <None Update="appsettings.json" CopyToOutputDirectory="PreserveNewest" />
</ItemGroup>

Il reste un fichier séparé, à côté de l'exécutable, même en fichier unique : l'administrateur peut ainsi changer le nom du serveur sans recompiler. Il ne contient aucun mot de passe.

Numéroter les versions

Indique la version dans le fichier projet, en suivant la gestion sémantique de version (majeure.mineure.correctif) :

<PropertyGroup>
  <Version>1.2.0</Version>
</PropertyGroup>

L'application peut l'afficher dans sa fenêtre « À propos » avec Application.ProductVersion. Depuis .NET 8, le SDK ajoute à cette version l'identifiant du commit Git (1.2.0+3f2a9c1…) ; pour l'enlever, ajoute <IncludeSourceRevisionInInformationalVersion>false</IncludeSourceRevisionInInformationalVersion>. Chaque version livrée correspond à une étiquette Git (v1.2.0) et l'exécutable se dépose dans une release GitHub, pas dans le dépôt (publier une version).

Installer sur les postes

Installer avec ClickOnce pas à pas

ClickOnce est la technologie de déploiement de Microsoft pour les applications Windows Forms et WPF : l'application s'installe dans le profil de l'utilisateur, sans droits d'administrateur, et vérifie à chaque lancement si une version plus récente a été publiée. Pour GSB Ordonnances, installée sur les postes d'un cabinet qui partagent un serveur de fichiers, c'est la façon la plus simple d'obtenir des mises à jour automatiques.

Créer le profil dans Visual Studio 2026.

1. Clic droit sur Gsb.Ui > Publier ; si un profil existe déjà, crée-en un nouveau.
2. Choisis la cible Dossier, puis la cible spécifique ClickOnce.
3. Emplacement de publication : le dossier où Visual Studio dépose les fichiers, ici le partage réseau du cabinet, \\srv-cabinet\logiciels\gsb-ordonnances\.
4. Emplacement d'installation : d'où les utilisateurs installent l'application ; choisis le chemin UNC (le partage de fichiers).
5. Paramètres : rends l'application disponible hors connexion, pour qu'elle soit installée avec un raccourci dans le menu Démarrer et qu'elle se mette à jour. Règle la version de publication (1.2.0.0) et laisse cochée l'incrémentation automatique. Dans Prérequis, coche le .NET Desktop Runtime 10 (x64) : le programme d'installation l'installera s'il manque.
6. Signer les manifestes : avec un certificat de signature de code pour une vraie distribution.
7. Configuration : Release, net10.0-windows, le mode de déploiement et le runtime cible win-x64, comme dans les commandes plus haut.
8. Terminer, puis Publier. Le profil est enregistré dans Properties\PublishProfiles\ClickOnceProfile.pubxml.

Ce que contient le dossier publié.

\\srv-cabinet\logiciels\gsb-ordonnances\
├── setup.exe                  le programme d'installation : prérequis, puis application
├── Gsb.Ui.application         le manifeste de déploiement : quelle version est à jour
└── Application Files\
    └── Gsb.Ui_1_2_0_0\        les fichiers de la version 1.2.0.0 et son manifeste

Sur chaque poste, l'utilisateur ouvre le partage et lance setup.exe une seule fois. Ensuite, il démarre GSB Ordonnances depuis le menu Démarrer. À chaque lancement, ClickOnce relit Gsb.Ui.application sur le partage : si une version plus récente a été publiée, il propose de la télécharger avant de démarrer l'application (avec .NET 10, la vérification en arrière-plan, pendant que l'application tourne, n'est pas prise en charge).

Publier une nouvelle version. Corrige, lance les tests, puis clique de nouveau sur Publier : la version de publication passe à 1.2.0.1, un dossier Gsb.Ui_1_2_0_1 s'ajoute et le manifeste de déploiement pointe dessus. Au prochain lancement, chaque poste propose la mise à jour. En ligne de commande, la documentation de Microsoft passe par MSBuild, avec le profil créé par Visual Studio : msbuild Gsb.Ui /t:publish /p:PublishProfile=ClickOnceProfile.

ClickOnce a ses limites : l'installation se fait par utilisateur (deux sessions Windows sur le même poste font deux installations), et elle ne sait ni écrire dans le registre de la machine ni installer un service Windows. Pour un parc géré par Intune ou une installation pour toute la machine, on choisit MSIX ou un installateur classique.

Avant de livrer, teste la publication sur un poste neuf, sans Visual Studio ni SDK : c'est là qu'on découvre le runtime manquant, le fichier de configuration oublié ou le chemin écrit en dur vers C:\Users\toi\….

Automatiser la publication avec GitHub Actions

Publier à la main, c'est risquer d'oublier les tests, de compiler depuis une copie modifiée ou de se tromper d'option. Une chaîne d'intégration continue le fait à ta place, toujours de la même façon. Ce workflow se déclenche quand tu pousses une étiquette de version (git tag v1.2.0 puis git push origin v1.2.0) : il lance les tests, publie l'exécutable autonome et le conserve comme artefact téléchargeable.

# .github/workflows/publier.yml
name: Publier GSB Ordonnances

on:
  push:
    tags: ['v*']

jobs:
  publier:
    runs-on: windows-latest          # WinForms ne se compile que sous Windows
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-dotnet@v6
        with:
          dotnet-version: '10.0.x'
      - run: dotnet test
      - run: dotnet publish Gsb.Ui -c Release -r win-x64 --self-contained -p:PublishSingleFile=true -o publication
      - uses: actions/upload-artifact@v7
        with:
          name: gsb-ordonnances-${{ github.ref_name }}
          path: publication

Si un test échoue, l'étape dotnet test s'arrête en erreur et rien n'est publié. La syntaxe des workflows et la création automatique d'une release sont expliquées dans le cours Intégration continue.

Prévenir l'utilisateur d'une nouvelle version

Un client lourd installé ne se met pas à jour tout seul, sauf avec ClickOnce ou MSIX. Une solution simple : au démarrage, l'application lit la dernière version disponible (dans un petit fichier JSON publié sur un serveur, ou par l'API de l'application) et la compare à la sienne.

Version installee = typeof(Program).Assembly.GetName().Version!;   // 1.2.0.0, tiré de <Version>
Version disponible = new Version("1.3.0");                         // lue sur le serveur
if (disponible > installee)
{
    MessageBox.Show($"La version {disponible} est disponible. Contacte le support pour l'installer.",
        "Mise à jour", MessageBoxButtons.OK, MessageBoxIcon.Information);
}

System.Version compare les numéros composante par composante : 1.10.0 est bien plus récente que 1.9.0, ce qu'une comparaison de chaînes de caractères donnerait à l'envers. Avec un seul argument, <Version>1.2.0</Version> donne une version d'assemblage 1.2.0.0 : new Version("1.3.0") et 1.2.0.0 se comparent correctement, la quatrième composante absente comptant comme inférieure à 0.

Exercices

<IncludeSourceRevisionInInformationalVersion>false</IncludeSourceRevisionInInformationalVersion>