136 votes

Différence entre LoadFile et LoadFrom avec les assemblys .NET ?

J'étais à la recherche, à la documentation msdn et je suis encore un peu confus sur ce qu'est exactement la différence entre l'utilisation d' LoadFile et LoadFrom lors du chargement d'une assemblée. Quelqu'un peut-il donner un exemple ou une analogie pour mieux la décrire. La documentation MSDN qui me confond plus. Aussi, Est - ReflectionOnlyLoadFrom le même que LoadFrom sauf qu'il charge l'assemblée que dans le mode de réflexion.

Depuis mon .NET de l'expérience n'est pas le plus grand, voici quelques questions concernant la documentation MSDN à l'aide de LoadFile:

1) Que signifie en LoadFile examine les assemblées qui ont la même Identité, mais sont situés dans des chemins différents? Qu'est-ce que l'identité (par exemple)?

2) Il indique le LoadFile ne prend pas en charge les fichiers dans le "LoadFrom Contexte" et de ne pas résoudre les dépendances à l'aide du chemin de chargement. Qu'est-ce que cela signifie, quelqu'un peut-il me donner un exemple?

3) Enfin, il déclare qu' LoadFile est utile dans ce scénario limité, car LoadFrom ne peut pas charger les assemblées qui ont les mêmes identités mais des chemins différents; il ne charge que la première assemblée, ce qui m'amène à la même question, qu'est-ce que les assemblées de l'identité?

99voto

Jeff Sternal Points 30147

N'est-ce clair?

// path1 and path2 point to different copies of the same assembly on disk:

Assembly assembly1 = Assembly.LoadFrom(path1);
Assembly assembly2 = Assembly.LoadFrom(path2);

// These both point to the assembly from path1, so this is true
Console.WriteLine(string.Compare(assembly1.CodeBase, assembly2.CodeBase) == 0);

assembly1 = Assembly.LoadFile(path1);
assembly2 = Assembly.LoadFile(path2);

// These point to different assemblies now, so this is false
Console.WriteLine(string.Compare(assembly1.CodeBase, assembly2.CodeBase) == 0);


Edit: pour répondre aux questions que vous avez soulevées dans votre nouvelle question, vous voulez absolument lire Suzanne Cuire à l'Assemblée de l'Identité.

Il y a beaucoup de règles qui régissent la manière dont les assemblées sont chargés, et certains d'entre eux ont à voir avec la façon dont ils résolvent des dépendances - si votre AssemblyA dépend de AssemblyB, où devrait .NET trouver AssemblyB? Dans le Global Assembly Cache, le même répertoire qu'il a trouvé AssemblyA, ou quelque part d'autre entièrement? En outre, s'il trouve de multiples copies de l'assemblée, comment doit-on choisir lequel utiliser?

LoadFrom a un ensemble de règles, tandis que d' LoadFile a un autre ensemble de règles. Il est difficile d'imaginer que de nombreuses raisons d'utiliser LoadFile, mais si vous avez besoin d'utiliser la réflexion sur les différentes copies de la même assemblée, il est là pour vous.

63voto

CraigTP Points 18514

De Suzanne Cook blog:

LoadFile vs LoadFrom

Attention, ce ne sont pas les mêmes chose.

LoadFrom() va, par la Fusion et peut être redirigé vers un autre assemblée à un chemin différent, mais avec cette même identité si l'on est déjà chargé dans le LoadFrom contexte.

LoadFile() ne veut pas se lier par le biais de la Fusion à tous - le chargeur va juste de l'avant et de charge exactement* ce que l' l'appelant a demandé. Il n'utilise pas la Charge ou le LoadFrom contexte.

Donc, LoadFrom() donne généralement ce que vous vous l'avez demandé, mais pas nécessairement. LoadFile() est pour ceux qui en ont vraiment, voulez vraiment exactement ce qui est demandé. (*Cependant, à partir de v2, politique être appliquée à la fois LoadFrom() et LoadFile(), de sorte LoadFile() ne sont pas nécessairement être exactement ce qui a été demandé. Aussi, à partir de la v2, si un ensemble avec son identité est dans l' GAC le GAC copie sera utilisée au lieu de cela. Utilisation ReflectionOnlyLoadFrom() pour charger exactement ce que vous voulez - mais, notez que des assemblages chargés de cette façon ne peut pas être exécuté.)

LoadFile() a un hic. Depuis il ne pas utiliser un contexte de liaison, de ses les dépendances ne sont pas automatiquement trouvé dans son répertoire. Si elles ne sont pas disponible dans la Charge de contexte, vous faut s'abonner à la AssemblyResolve l'événement, afin de lier pour eux.

Voir ici.

Voir également le Choix d'un Contexte de Liaison article sur le même blog.

45voto

LordWilmore Points 316

Après beaucoup de casse-tête, j'ai découvert une différence de moi-même cet après-midi.

J'ai voulu charger une DLL à l'exécution, et la DLL vécu dans un autre répertoire. Cette DLL a ses propres dépendances (Dll) qui vivait aussi dans le même répertoire.

LoadFile(): Chargement de la DLL spécifique, mais pas les dépendances. Ainsi, lorsque le premier appel a été fait à partir de l'intérieur de la DLL à l'un de ces autres Dll il jeta un FileNotFoundException.

LoadFrom(): Chargement de la DLL que j'ai indiqué et également de toutes les dépendances qui vivaient dans ce répertoire.

4voto

Gregg DeMasters Points 11

Remarque : Si un assembly est chargé à l’aide d’un chemin de 8,3 et ensuite sur un chemin non-8.3, ils seront considérés comme des assemblys différents, même s’ils sont la même DLL physique.

1voto

Arthur Points 5474

.NET a le contexte de chargement différent. Suzanne Cook a écrit à leur sujet ici : http://blogs.msdn.com/suzcook/archive/2003/05/29/57143.aspx

Il s’agit des quarantaines de .net de façon que les références ne sont pas mélangées.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X