L'essentiel de Visual Studio 2015

Comprendre les configurations de compilation

Testez gratuitement nos 1300 formations

pendant 10 jours !

Tester maintenant Afficher tous les abonnements
Vous allez produire votre exécutable avec des instructions de débogage, ou un exécutable compilé avec de l'optimisation. Pour cela, vous apprendre à gérer des configurations de compilation.
06:31

Transcription

Revoyons les fichiers qui sont générés par notre compilation. Nous avons donc le « .exe », un « .config », qui correspond au fichier de configuration « xml », qui est généré dans des applications Dot-net, spécifiquement « C# » par exemple, applications Windows, ou des applications Web qui comportent un fichier qui s'appelle « Webconfig ». Ici, je suis dans une application « Wpf », j'ai donc un « .config », dont la première partie du nom correspond au fichier de l'application lui-même. Dans ce fichier de configuration « xml », j'ai pour l'instant très peu de choses, mais je peux ajouter mes propres options de configurations, par exemple une chaîne de connections pour une base de données et ensuite, utiliser cela dans mon code, pour avoir bien des configurations, qui ne sont pas compilées dans l'exécutable, mais que je vais pouvoir changer ici en pur texte, dans mon « xml », sans avoir à recompiler bien entendu, mon programme. J'ai un fichier « .pdb », qui a le même nom que mon exécutable, que le résultat de ma compilation, ça peut être une « dll » également. « Pdb », ça veut dire « program database » et c'est un fichier qui va être utilisé pour le débuggage. si vous déployez votre exécutable quelque part sur une machine, et qu'ensuite,vous voulez quand même effectuer un débuggage à l'aide de Visual Studio, par exemple. Et bien, ce fichier « pdb » vous sera indispensable pour reconnaître les identifiants qui se trouvent à l'intérieur de votre exécutable. Je m'explique. Ici, j'ai des noms, ma classe s'appelle « Main2 », je fais des « using » de différentes assembly qui sont nommées, mais quand je vais compiler ceci, et bien je vais avoir un résultat totalement binaire, et sous une forme qui correspond à peu près à de l'assembleur pour Dot-net. C'est à dire des symboles qui ne vont pas être les noms lisibles que j'ai défini dans mon code source, mais quelque chose qui est le résultat d'une compilation. Le fichier « pdb » va garder la mémoire des noms originels, de mes symboles. Et c'est donc une base de données qui va faire la liaison entre le nom de mon code source et puis ce qu'il est devenu dans mon exécutable, ce qui va donc permettre un débuggage après coup avec l'exécutable à disposition. Donc si vous avez besoin de débugger plus tard votre application, et bien, conservez le fichier « pdb », garder-le avec l'exécutable ou gardez-le quelque part au chaud et en sécurité de façon à le reprendre, si vous en avez besoin pour un débuggage après coup. Vous avez trois fichiers qui correspondent ici aussi à la compilation, et qui comportent « vshost », ça veut dire « Visual Studio host ». Il s'agit en fait d'un processus d'hébergement, qui permet à Visual Studio d'améliorer les performances de débuggage. Lorsque vous commencez le débuggage, il y a déjà un processus, qui est maintenu par Visual Studio et qui correspond à ces fichiers. Ça permet de débugger beaucoup plus rapidement votre code dans Visual Studio. Si je reviens un niveau en-dessus, je vois que j'ai deux répertoires finalement, un répertoire « debug », et un répertoire « release ». Pourquoi ? Parce que dans Visual Studio, j'ai ici des configurations de compilation. La configuration par défaut est ici « debug », pour toute la solution et puis, je vais aussi avoir des compilations par plateforme. Donc, si je reprends mon « debug » et que j'ouvre le gestionnaire de configurations, je vois que j'ai par projet des configurations et des plateformes, qui me permettent de sélectionner pour la solution toute entière, comment je vais compiler mes différents projets. Et bien entendu, je vais générer une configuration « debug » pour compiler, pour mon débuggage local, et puis je vais avoir une configuration « release », pour la génération d'une version finale ou d'une version de déploiement, que je vais déployer sur un poste client, par exemple. La différence va être, par exemple, que, dans la configuration « release », je vais avoir une optimisation du compilateur, qui va améliorer les performances de l'application, mais je n'aurai plus les instructions de débuggage, qui sont dans l'exécutable, qui me permettraient de débugger à travers Visual Studio. Donc, je vais me remettre ici en « debug », et puis je vais vous montrer à quoi ça correspond dans les projets. Parce que ici j'ai une configuration au niveau de la solution, mais qui va déclencher dans chaque projet une compilation séparée. Je vais prendre les propriétés de mon projet « WpfTest », aller ici dans build et voir les différentes configurations. J'ai donc la configuration active, qui est la configuration debug, pour telle ou telle plateforme et cette configuration je vais pouvoir la choisir ici. Donc, je vais dire, pour mon debug, je définis des constantes, je vais vous en parler dans une seconde, je vais choisir une plateforme cible plutôt, allez, X64 ou Any CPU, en préférant plutôt du 32 bits, donc, selon les environnements sur lesquels je vais compiler et déployer, et puis je vais choisir quelques options spécifiques. Mais principalement, c'est le chemin de sortie, donc dans les sous-répertoires « bin » et « debug » la compilation faite en configuration « debug » va se déposer là. Et en ce qui concerne la configuration « release », je vais le déposer dans « bin\release ». Je vais ne pas définir la constante debug et générer une compilation avec optimisation du code. C'est quand même les options les plus courantes. Vous n'avez à moins de besoins vraiment spécifiques, pas besoin de changer cette configuration. Et donc, ces options et ces configurations de compilation étant définies avec le même nombre de chaque projet, lorsque vous générez votre solution dans ce mode. Et bien, les options de compilation vont être choisies en « debug », pour tel processeur et vont être générées dans tel répertoire. Ça vous permet donc de faire une compilation en « debug » ou de faire ensuite une compilation en « release ». Et je vais générer la solution maintenant en « release », la génération a réussi, pour déploiement, par exemple. Et maintenant, dans mon répertoire « release », et bien, j'ai le résultat de ma compilation.

L'essentiel de Visual Studio 2015

Apprenez à créer des applications, à les déboguer et à les déployer avec Visual Studio. Développez des programmes en .NET pour Windows, les appareils mobiles et le web.

3h06 (40 vidéos)
Aucun commentaire n´est disponible actuellement
 
Logiciel :
Visual Studio Visual Studio 2015
Spécial abonnés
Date de parution :18 févr. 2016

Votre formation est disponible en ligne avec option de téléchargement. Bonne nouvelle : vous ne devez pas choisir entre les deux. Dès que vous achetez une formation, vous disposez des deux options de consultation !

Le téléchargement vous permet de consulter la formation hors ligne et offre une interface plus conviviale. Si vous travaillez sur différents ordinateurs ou que vous ne voulez pas regarder la formation en une seule fois, connectez-vous sur cette page pour consulter en ligne les vidéos de la formation. Nous vous souhaitons un excellent apprentissage avec cette formation vidéo.

N'hésitez pas à nous contacter si vous avez des questions !