Pourquoi .NET Runtime / Fusion ne charge-t-il pas toujours tous les assemblages référencés à partir du manifeste?

Question

Tout cela a commencé parce que j'essaye de Fxcop analyser mon assemblage, qui fait référence Crystal Reports. Chaque fois que je le fais, FXCOP ne trouve pas de référence à un assemblage nommé "BusinessObjects.Licensing.KeycodeDecoder". En essayant de localiser ce .dll, je me suis rendu compte qu'il n'existe pas du tout ... ce n'est pas sur le disque dur ou le GAC, pourtant, mon application elle-même s'exécute et affiche les rapports très bien.

Cela m'a donc conduit à la chasse ...

Dans le CrystalDecisions.CrystalReports.Engine.dll fichier, si vous l'ouvrez dans Ildasme, il inclut la référence dans son manifeste:

.assembly extern BusinessObjects.Licensing.KeycodeDecoder
{
  .publickeytoken = (69 2F BE A5 52 1E 13 04 )                         // i/..R...
  .ver 13:0:2000:0
}

Cependant, si j'ouvre le Fusion Logger (FUSLOGVW) et que je gère mon application, je peux voir Fusion charger un tas d'assemblages en cristal, y compris celui CrystalDecisions.CrystalReports.Engine, mais le référencé BusinessObjects.Licensing.KeycodeDecoder L'assemblage est Jamais même tenté être chargé.

Alors pourquoi? Comment le runtime .NET sait-il sauter ou ne pas charger cette référence au moment de l'exécution? Pourquoi la fusion ne charge-t-elle pas simplement chaque assemblage référencé récursivement? Je cherche juste des intentions de logique ou de raisonnement ou de conception derrière tout cela ...

Peut-être tout aussi important, pourquoi les projets .NET peuvent-ils être créés qui ont des références à .dlls, mais ces références ne sont pas appliquées? OMI, c'est mal que SÈVE Peut expédier des assemblages en cristal qui font référence à d'autres assemblages qui ne sont même pas installés.

Answer 1

Il les charge uniquement à la demande. Le manifeste est utilisé pour localiser l'assemblage correct (y compris la version correcte, le nom fort, etc.).

Tant que personne ne demande un type de l'assemblage, il n'y a aucune raison de le charger. Notez que les assemblages peuvent également être chargés juste pour obtenir le Type d'une classe, par exemple via un nom de type qualifié d'assemblage dans un fichier de configuration.

Answer 2

Il ne chargera l'assemblage que lorsqu'il sera réellement utilisé. Donc, si le code à l'intérieur de l'assemblage n'est jamais réellement exécuté, l'assemblage ne sera jamais chargé ou tenté de charger.