Comment publier et déployer un utilitaire WPF .NET

Publication depuis Visual Studio

[1:03 - 1:25] Tim commence par faire un clic droit sur le projet dans Visual Studio et sélectionne Publier. L'assistant présente plusieurs cibles (Azure, Docker, ClickOnce), mais il les contourne toutes et choisit Dossier. Pour un utilitaire personnel qui s'exécute sur vos propres machines, la publication dans un dossier est la voie la plus directe : elle produit des fichiers que vous pouvez copier où vous en avez besoin sans aucune infrastructure de déploiement.

Après avoir sélectionné la cible du dossier, Tim passe directement à la page des paramètres plutôt que de lancer immédiatement la publication. Les paramètres par défaut doivent être ajustés avant que la sortie ne corresponde à ce qu'il veut.

Dépendant du framework vs. Autonome

[1:25 - 2:32] Le premier paramètre est le mode de déploiement. Une construction dépendante du framework suppose que le SDK ou le runtime .NET est déjà installé sur la machine cible. La sortie est petite, environ 200 kilooctets pour cette application, car elle repose sur le runtime partagé qui existe sur votre système.

Une construction autonome inclut l'ensemble du runtime .NET dans la sortie. Cela rend le paquet portable vers des machines sans .NET installé, mais augmente la taille à environ 140 mégaoctets. Tim choisit dépendant du framework car chaque machine qu'il utilise a déjà .NET installé. Si vous distribuez un outil à des collègues ou clients qui pourraient ne pas avoir le runtime, autonome est l'option la plus sûre, mais pour les utilitaires personnels, le compromis n'a généralement pas de sens.

Pourquoi WPF et non MAUI

[2:50 - 4:10] Tim répond aux retours qu'il a reçus concernant l'utilisation de WPF plutôt que MAUI pour ce projet. Son raisonnement est pratique plutôt qu'idéologique. Le visualiseur d'images n'a besoin de fonctionner que sur Windows. Introduire MAUI et sa couche multiplateforme ajoute de la surcharge sans offrir de bénéfice pour un outil à plateforme unique.

Au-delà de l'argument architectural, il y a un angle de maintenance. Le code source d'origine de Tim a survécu environ sept ans sur quatre ou cinq machines avec des changements minimes. Les seules mises à jour étaient des mises à niveau de framework (de .NET Framework à .NET 8, et maintenant à .NET 10). Si l'utilitaire avait été construit sur un framework qui nécessite une attention chaque fois qu'Apple ou Google délivre une mise à jour de l'OS, ces sept ans de fonctionnement sans intervention n'auraient pas été possibles. Un utilitaire qui coûte plus de temps à maintenir qu'il n'en économise ne vous fait plus rien économiser.

Publication en fichier unique et fichiers PDB

[4:59 - 6:32] Une fois le mode de déploiement décidé, Tim active "Produire un fichier unique" et cible Windows x64. La publication se termine et ouvre le dossier de sortie, qui contient deux fichiers : le .exe et un .pdb.

Ce second fichier est un fichier Program Database, et son rôle mérite d'être compris. Lorsque vous compilez en mode Release, le compilateur optimise et renomme les symboles internes pour les performances. Le PDB mappe ces noms optimisés à votre code base réel, vous permettant d'attacher un débogueur à l'exécutable en cours d'exécution et de définir des points d'arrêt comme si vous travailliez en mode Debug. Pour une application en production au service des clients, vous devez stocker les fichiers PDB en sécurité avec chaque version pour que vous puissiez diagnostiquer les problèmes après le déploiement.

Pour un outil que vous avez construit pour vous-même, Tim note que le PDB n'est pas requis pour que l'application fonctionne. Il le supprime pour la simplicité, mais avertit les téléspectateurs de ne pas adopter cette habitude pour tout ce qui est livré aux utilisateurs. Le seul .exe fonctionne de manière autonome sans la présence du PDB.

Une particularité à noter : si vous passez de dépendant du framework à autonome et gardez "fichier unique" activé, la sortie n'est plus un fichier unique. Des fichiers runtime supplémentaires apparaissent à côté de l'exécutable. L'option fichier unique ne produit un vrai fichier unique que lorsqu'elle est couplée à une construction dépendante du framework.

Placer l'utilitaire sur votre machine

[7:17 - 7:52] Avec l'exécutable en main, Tim le déplace à un emplacement permanent. Il utilise un dossier C:\Apps\SimpleImageViewer dédié, une convention qui garde les outils personnels séparés des Program Files et faciles à localiser. L'exécutable de 2024 fonctionne toujours de manière identique sur sa machine actuelle, ce qui renforce le point abordé précédemment sur la longévité : un utilitaire bien défini avec une structure de projet simple peut survivre aux changements matériels et mises à jour de l'OS sans modification.

Ajouter l'outil au menu contextuel

[7:52 - 10:21] La dernière étape connecte l'utilitaire au menu contextuel de l'Explorateur Windows. Tim modifie le Registre Windows pour ajouter des entrées à deux endroits : un pour faire un clic droit sur un dossier (pour que vous puissiez ouvrir un répertoire d'images) et un pour faire un clic droit sur un espace blanc dans un dossier (pour lancer le visualiseur dans le répertoire actuel).

Chaque entrée de registre crée une commande shell qui passe le chemin sélectionné comme un argument en ligne de commande à l'exécutable. C'est là que le paramètre args dans le point d'entrée de l'application reçoit sa valeur.

Tim fournit un fichier .reg mais le renomme en .txt avant de le partager. Cette précaution est importante : un double-clic sur un fichier .reg incite immédiatement à écrire des valeurs dans le registre, et exécuter un fichier de registre non fiable peut entraîner de graves problèmes système. Son approche nécessite d'ouvrir le fichier, de vérifier les chemins, de les mettre à jour pour correspondre à votre machine, de renommer l'extension en .reg, puis seulement de l'exécuter. Si cela vous semble inconnu, le conseil de Tim est direct : ne modifiez pas le registre.

Pour les développeurs à l'aise avec le registre, les deux entrées sont simples. Chacun crée une commande shell nommée sous la clé appropriée, pointant vers le chemin complet de votre exécutable avec un espace réservé %V ou %1 qui transmet le répertoire cible ou le chemin du fichier à l'exécution. Un redémarrage peut être nécessaire avant que les nouvelles entrées du menu contextuel ne s'affichent.

Conclusion : Déployez une fois, utilisez toujours

[10:21 - 10:30] Le processus de déploiement entier se résume en deux étapes : publier dans un dossier, puis enregistrer l'exécutable dans le menu clic droit. Pas d'installeur, pas de mécanisme de mise à jour, pas de service cloud. Pour un utilitaire à but unique sur votre propre machine, cette simplicité est le but.

Conclusion

[10:30 - 10:40] Pour résumer : dotnet publish avec des réglages dépendant du framework et de fichier unique produit un exécutable léger que vous pouvez placer n'importe où. Une paire d'entrées de registre le transforme en une action de menu contextuel disponible n'importe où dans l'Explorateur Windows.

La leçon qui traverse toute la vidéo est la retenue. Adaptez votre approche de déploiement à la portée de votre application. Un utilitaire construit pour un usage personnel n'a pas besoin de la même infrastructure qu'un produit distribué à des milliers de clients, et le traiter ainsi ne fait que créer un travail de maintenance qui érode le temps que l'outil était censé économiser.

Astuce par exemple : conservez vos fichiers PDB même pour des projets personnels. Stockez-les dans le même dossier que l'exécutable ou dans une archive proche. Si l'utilitaire se comporte de manière inattendue quelques mois plus tard, avoir le PDB vous permet de relier Visual Studio et de déboguer la version de sortie sans recompilation à partir de la source.

Regardez la vidéo complète sur sa chaîne YouTube et obtenez plus d'informations sur le déploiement des applications de bureau .NET.