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

StackOverflow https://stackoverflow.com/questions/1477843

Question

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

Depuis mon expérience .NET est le plus grand, voici quelques questions concernant la documentation MSDN en utilisant LoadFile:

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

2) Il indique la LoadFile ne charge pas les fichiers dans le « contexte LoadFrom » et ne résout pas les dépendances en utilisant le chemin de charge. Qu'est-ce que cela signifie, quelqu'un peut-il donner un exemple?

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

Était-ce utile?

La solution

Est-ce clair vers le haut? 

// 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(assembly1.CodeBase == assembly2.CodeBase);

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

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

Modifier : pour répondre aux questions que vous avez posées dans votre question révisée, vous voulez certainement lire Suzanne Cook sur l'identité Assemblée .

Il y a beaucoup de règles qui régissent la façon dont les assemblages sont chargés, et certains d'entre eux ont à voir avec la façon dont ils résolvent les dépendances - si votre AssemblyA dépend de AssemblyB, où devrait chercher .NET pour trouver AssemblyB? Dans le Global Assembly Cache, le même répertoire dans lequel il a trouvé AssemblyA, ou ailleurs tout à fait? De plus, si elle trouve des copies multiples de cette assemblée, comment faut-il choisir lequel utiliser?

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

Autres conseils

De blog de Suzanne Cook :

  

LoadFile contre LoadFrom

     

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

     

LoadFrom () passe par la fusion et peut être redirigé vers un autre   assemblage à une voie différente mais avec   cette identité même si l'on est déjà   chargé dans le contexte LoadFrom.

     

LoadFile () ne se lie pas par fusion du tout - le chargeur va juste   avant et charges * exactement ce que le   l'appelant a demandé. Il n'utilise pas   soit la charge ou la LoadFrom   contexte.

     

Alors, LoadFrom () vous donne généralement ce   vous avez demandé, mais pas nécessairement.   LoadFile () est pour ceux qui vraiment,   vraiment envie exactement ce qui est demandé.   (* Cependant, à partir de v2, politique   être appliqué à la fois LoadFrom () et   LoadFile (), donc LoadFile () NUL   nécessairement exactement ce qui était   demandé. De plus, à partir de v2, si un   ensemble avec son identité se trouve dans la   GAC, la copie GAC sera utilisé   au lieu. Utilisez ReflectionOnlyLoadFrom ()   pour charger exactement ce que vous voulez - mais,   noter que les assemblées chargées de cette façon   ne peut pas être exécuté.)

     

LoadFile () présente une prise. Puisqu'il   ne pas utiliser un contexte de liaison, son   dépendances ne sont pas automatiquement   trouvé dans son répertoire. Si elles ne sont pas   disponible dans le contexte de charge, vous   au devra souscrire   AssemblyResolve événement en vue d'engager   pour eux.

Voir .

Voir aussi Choisir l'article d'un contexte de liaison sur le même blog.

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

Je voulais charger un DLL lors de l'exécution, et la DLL vécu dans un autre répertoire. Cette DLL avait ses propres dépendances (DLL), qui a également vécu dans ce même répertoire.

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

LoadFrom (): chargé de la DLL que je spécifié et aussi toutes les dépendances qui vivaient dans ce répertoire

.

Note:. Si un ensemble est chargé à l'aide d'un chemin 8.3, puis d'un chemin non-8.3, ils seront considérés comme des différentes assemblées, même si elles sont les mêmes DLL physique

une différence que je remarque est:

Assembly.LoadFile - Les charges d'assemblage dans les différents AppDomain avec des droits utilisateur limités (diffrence de principeles). opérations comme serilization / deserilization ne pouvaient être effectués.

Assembly.LoadFrom -. Les charges assemblage dans la même AppDomain avec les mêmes droits d'utilisateur (même principeles)

Dans mon cas, je ne devais supprimer simplement le cache de l'application ASP @ situé C:\Windows\Microsoft.NET\Framework\[asp version]\Temporary ASP.NET Files. Il est reconstruit lorsque le site est le premier terme. Assurez-vous d'arrêter IIS d'abord.

Espérons que cela aide quelqu'un comme elle l'a fait pour moi.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top