Assembly binding & Debug dans Visual Studio

De temps en temps, lors de l’utilisation du débogeur avec, par exemple, une application Web, Visual Studio nous indique, via une icône spécifique, que le point d’arrêt posé ne pourra pas être utilisé. En regardant en détail le message, on apprend souvent qu’il y a un décalage entre le fichier source et le binaire qui est exécuté. S’agissant dans mon exemple d’une application utilisant IIS, il y a de fortes chances pour que ce dernier ait verrouillé le fichier en question ce qui a empêché sa mise à jour lors du build. Un nettoyage des fichiers temporaires et un « rebuild » du site va corriger ce problème et la situation reviendra à la normale. Cependant, dans certains cas plus spécifiques, cette solution peut ne pas suffire. Il faut donc investiguer et déterminer quel binaire est utilisée et quel est son emplacement. A partir de ces informations, vous pourrez alors débloquer la situation.

La fenêtre « Modules » de Visual Studio

Le menu « Debug/Windows » comporte un certain nombre d’options dont la fenêtre « Modules ». Cette dernière est essentielle dans le cas présent car elle donne la liste de toutes les assemblies qui sont chargées par l’application. Elle donne également l’emplacement des « pdb » ainsi que la version et l’horodatage de chaque binaire.

En reprenant l’exemple précédent, on aurait sans doute constaté que l’horodatage de l’assemblie de notre site ne datait pas du dernier build mais était antérieur à ce dernier. En essayant de supprimer ce fichier, l’explorateur de Windows vous aurait indiqué que le fichier était verrouillé, confirmant ainsi l’hypothèse de départ.

Cette fenêtre permet également de connaître l’emplacement de chaque dépendance du projet. Dans le cas d’un projet complexe avec de nombreux projets librairie et encore plus de références NuGet, il est parfois indispensable de savoir quelle version d’une dépendance a été chargée. Avec cet outil, vous aurez toutes les informations nécessaires.

Assembly Binding Log Viewer

Le deuxième outil indispensable est l’ « Assembly Binding Log Viewer », plus communément appelé « fuslog ». Ce dernier liste l’ensemble des assemblies chargées par une application, avec ou sans l’aide de Visual Studio. Regardons à quoi elle ressemble. Pour ce faire, lancez une invite de commande en tant qu’administrateur et tapez la commande « fuslogvw.exe », la fenêtre suivant devrait s’ouvrir :

La première étape consiste à paramétrer l’application comme le montre la capture ci-dessus. Ensuite, lancez votre application puis cliquez sur le bouton « Refresh ». Vous devriez alors voir apparaître de nombreuses lignes, chacune correspondant à un chargement d’assembly :

En double cliquant sur celle de votre choix, vous verrez apparaitre le log complet du chargement de l’assembly. Ce qui est vraiment intéressant c’est l’explication fournie sur le choix de l’assembly. En effet, l’outil en plus de vous indiquer le nom et l’emplacement, va vous expliquer pourquoi il a choisi cette version plutôt qu’une autre. Cette information pourra se révéler essentielle dans les problèmes notamment de référence se situant dans la « GAC » et dans vos packages NuGet par exemple.