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

Je regardais la documentation msdn et je ne sais toujours pas quelle est exactement la différence entre l'utilisation LoadFileet le LoadFromchargement d'un assemblage. Quelqu'un peut-il donner un exemple ou une analogie pour mieux le décrire. La documentation MSDN m'a encore plus troublé. En outre, est ReflectionOnlyLoadFromle même que LoadFromsauf qu'il charge l'assemblage uniquement en mode réflexion.

Étant donné que mon expérience .NET n'est pas la meilleure, voici quelques questions concernant la documentation MSDN utilisant LoadFile:

1) Que signifie LoadFileexaminer les assemblys qui ont la même identité, mais sont situés dans des chemins différents? Quelle est l'identité (exemple)?

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

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

Est-ce que cela clarifie les choses?

// 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);

Edit : pour répondre aux questions que vous avez soulevées dans votre question révisée, vous voulez absolument lire Suzanne Cook sur l'identité de l'assemblée .

Il existe de nombreuses règles qui régissent la façon dont les assemblys sont chargés, et certaines d'entre elles ont à voir avec la façon dont ils résolvent les dépendances - si votre AssemblyA dépend de AssemblyB, où .NET doit-il rechercher AssemblyB? Dans le Global Assembly Cache, le même répertoire où il a trouvé AssemblyA, ou ailleurs entièrement? De plus, s'il trouve plusieurs copies de cet assemblage, comment devrait-il choisir lequel utiliser?

LoadFroma un ensemble de règles, tandis LoadFilequ'un autre ensemble de règles. Il est difficile d'imaginer de nombreuses raisons à utiliser LoadFile, mais si vous deviez utiliser la réflexion sur différentes copies du même assemblage, elle est là pour vous.

Du blog de Suzanne Cook :

LoadFile et LoadFrom

Soyez prudent - ce ne sont pas la même chose.

LoadFrom () passe par Fusion et peut être redirigé vers un autre assembly sur un chemin différent mais avec la même identité si l'un est déjà chargé dans le contexte LoadFrom.

LoadFile () ne se lie pas du tout via Fusion - le chargeur continue et charge exactement * ce que l'appelant a demandé. Il n'utilise ni le contexte Load ni le contexte LoadFrom.

Ainsi, LoadFrom () vous donne généralement ce que vous avez demandé, mais pas nécessairement. LoadFile () est pour ceux qui veulent vraiment, vraiment exactement ce qui est demandé. (* Cependant, à partir de la v2, la stratégie sera appliquée à la fois à LoadFrom () et LoadFile (), donc LoadFile () ne sera pas nécessairement exactement ce qui a été demandé. De plus, à partir de la v2, si un assembly avec son identité est dans le GAC, la copie GAC sera utilisée à la place. Utilisez ReflectionOnlyLoadFrom () pour charger exactement ce que vous voulez - mais notez que les assemblys chargés de cette façon ne peuvent pas être exécutés.)

LoadFile () a une capture. Puisqu'il n'utilise pas de contexte de liaison, ses dépendances ne sont pas automatiquement trouvées dans son répertoire. S'ils ne sont pas disponibles dans le contexte de chargement, vous devez vous abonner à l'événement AssemblyResolve pour pouvoir s'y lier.

Regardez ici .

Consultez également l'article Choisir un contexte de liaison sur le même blog.

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

Je voulais charger une DLL au moment de l'exécution, et la DLL vivait dans un autre répertoire. Cette DLL avait ses propres dépendances (DLL) qui vivaient également dans ce même répertoire.

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

LoadFrom (): a chargé la DLL que j'ai spécifiée ainsi que toutes les dépendances qui vivaient dans ce répertoire.

Remarque: Si un assembly est chargé à l'aide d'un chemin 8.3, puis à partir d'un chemin non 8.3, ils seront considérés comme des assemblys différents, même s'il s'agit de la même DLL physique.

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

C'est ainsi que .Net met en quarantaine que les références ne sont pas mélangées.

une différence que j'ai remarquée est:

Assembly.LoadFile - Charge l'assembly dans différents AppDomain avec des droits d'utilisateur limités (principe de différence). des opérations telles que la sérilisation / déserilisation n'ont pas pu être effectuées.

Assembly.LoadFrom - Charge l'assembly dans le même AppDomain avec les mêmes droits d'utilisateur (même principel).

Dans mon cas, je devais simplement supprimer le cache de l'application ASP situé @ C:\Windows\Microsoft.NET\Framework\[asp version]\Temporary ASP.NET Files. Il est reconstruit lors de la première exécution du site. Assurez-vous d'abord d'arrêter IIS.

J'espère que cela aide quelqu'un comme ça l'a fait pour moi.