Comment fonctionne exactement la propriété “Version spécifique” d’une référence d’assemblage dans Visual Studio?

Aujourd’hui, j’ai examiné de plus près la propriété “Version spécifique” des références d’assemblage dans Visual Studio 2010. Après quelques expériences avec des résultats inattendus, j’ai tenté d’en apprendre le plus possible sur le fonctionnement de la propriété. Même SO, il me semble, n’a pas toutes les réponses, alors voici ma tentative de répondre à la question:

Comment fonctionne exactement la propriété “Version spécifique” d’une référence d’assemblage dans Visual Studio?

C’est une propriété à la compilation!

L’une des choses les plus importantes à savoir est que “Version spécifique” est une propriété qui prend effet à la compilation et non à l’exécution.

C’est à propos de quoi?

Lorsqu’un projet est créé, les références d’assemblage du projet doivent être résolues afin de trouver les assemblages physiques que le système de génération doit utiliser. Si la vérification “Version spécifique” est effectuée (voir la section “Quand” Version spécifique “est-elle cochée?”), Cela affecte le résultat du processus de résolution de l’assemblage:

  • Le système de construction localise un assemblage physique qu’il peut potentiellement utiliser
  • Le système de génération compare la version de l’assembly physique à la version de l’assembly stockée dans le fichier .csproj pour la référence de l’assembly
  • Si les deux versions d’assembly sont exactement les mêmes, le processus de résolution réussit et l’assembly physique trouvé est utilisé pour la génération.
  • Si les deux versions d’assembly ne correspondent pas, l’assembly physique est ignoré et le processus de résolution se poursuit en localisant l’assembly potentiel suivant
  • Si aucun autre assemblage physique potentiel ne peut être localisé, le processus de résolution échoue. Cela se traduit par un avertissement du compilateur (avertissement MSB3245) qui vous indique que la référence n’a pas pu être résolue.
  • Chose intéressante, la construction se poursuit alors! Si le code n’a pas de références réelles à l’assembly, la génération réussit (avec l’avertissement mentionné précédemment). Si le code a des références, la génération échoue avec une erreur qui semble indiquer que le code utilisait des types ou des espaces de noms inconnus. La seule indication pour laquelle la construction a réellement échoué est l’avertissement MSB3245.

Ordre dans lequel les assemblages sont résolus

L’ordre dans lequel le processus de résolution d’assemblage localise les assemblages potentiels semble être le suivant:

  1. L’assembly référencé par l’élément dans le fichier .csproj
  2. Le chemin de sortie du projet
  3. Le GAC

Notez que si plusieurs versions de l’assembly existent dans le GAC, le processus de résolution tente d’abord de résoudre l’assembly avec la version la plus élevée. Ceci n’est important que si la vérification “Version spécifique” n’est pas effectuée.

Quand “Version spécifique” est-il coché?

Visual Studio fonde sa décision d’exécuter ou non la vérification “Version spécifique” sur deux informations contenues dans le fichier .csproj:

  • La présence ou l’absence de l’élément et sa valeur (si elle est présente)
  • La présence ou l’absence d’informations de version dans la référence d’assemblage

Voici à quoi ressemble une référence d’assembly type avec des informations de version:

  True ..\..\Bar\Foo.dll  

Et voici à quoi ressemble la référence d’assemblage sans informations de version:

  [...] 

Le tableau suivant indique quand la vérification “Version spécifique” est effectuée et quand elle ne l’est pas.

  | Version information | Present Not present ----------------------------+------------------------------  | - Present, has value True | Yes (1) Yes (check always fails) (2) - Present, has value False | No (3) No (4) - Not present | Yes (5) No (6) 

Ce qui est surprenant, c’est qu’aucune vérification n’est effectuée si les deux informations et la version sont absentes (cas 6). Je m’attendrais à ce que la vérification soit effectuée et à toujours échouer (comme dans le cas 2) car, à mon sens, l’absence de implique la valeur par défaut “True”. Cela peut être une bizarrerie de Visual Studio 2010 où j’ai effectué mes tests.

Lorsque vous examinez les propriétés d’une référence d’assembly dans l’interface utilisateur Visual Studio (sélectionnez la référence et appuyez sur F4), la valeur que vous voyez pour la propriété “Version spécifique” vous indique si Visual Studio va ou non exécuter la “version spécifique”. vérifier. Dans le cas 6, l’interface utilisateur affichera “True”, bien que l’élément ne soit pas présent dans le fichier .csproj.

Effets secondaires sur “Copie locale”

Si la propriété “Copy Local” est définie sur “True” mais que le processus de résolution de l’assemblage échoue en raison de la vérification “Version spécifique”, aucun assembly n’est copié.

Matériel de référence

  • Ce que vous devez savoir sur les assemblys référencés dans VS2005 (article blogs.msdn.com)
  • Quoi de neuf dans .NET 2.0 pour les assemblages et la gestion des versions? (article codemag.com qui reproduit l’article MSDN ci-dessus, jusqu’au libellé, mais contient quelques captures d’écran et des informations supplémentaires sur la gestion des versions d’assemblage)

Lorsque vous ajoutez une référence, Visual Studio enregistre la [AssemblyVersion] de l’assembly dans le fichier de projet. C’est important. Si, par exemple, vous créez un correctif de bogue un an plus tard, vous devez vous assurer que vous reconstruisez le projet avec la même version de la référence, ce qui en fait un véritable drop-in. Vous obtiendrez une erreur si l’assembly de référence a changé.

Mais ce n’est pas toujours souhaitable. Certains programmeurs permettent à la version d’assemblage de s’incrémenter automatiquement, générant une nouvelle version à chaque fois qu’ils se reconstruisent. Même si l’interface publique de l’assemblage n’a jamais changé. Certains configurent leur projet en utilisant Nuget pour obtenir des bibliothèques et permettent de mettre à jour automatiquement la bibliothèque quand une nouvelle version est disponible. Ils aimeront définir la propriété Version spécifique sur False pour supprimer l’erreur de compilation.

Assez important pour comprendre la conséquence, vous devez redéployer la totalité du programme pour éviter les accidents. Les versions incompatibles à l’exécution bloquent le programme et ne peuvent être supprimées qu’avec un dans le fichier .config qui est risqué.