Różnica między LoadFile i LoadFrom z zestawami .NET?

Przeglądałem dokumentację msdn i nadal jestem trochę zdezorientowany, jaka dokładnie jest różnica między używaniem LoadFilea LoadFromładowaniem zestawu. Czy ktoś może podać przykład lub analogię, aby lepiej to opisać. Dokumentacja MSDN bardziej mnie zmyliła. Ponadto ReflectionOnlyLoadFromdziała tak samo, jak LoadFromz tą różnicą, że ładuje zespół tylko w trybie odbicia.

Ponieważ moje doświadczenie z .NET nie jest najlepsze, oto kilka pytań dotyczących dokumentacji MSDN przy użyciu LoadFile:

1) Co to znaczy, że LoadFileanalizuje zespoły, które mają tę samą tożsamość, ale znajdują się na różnych ścieżkach? Jaka jest tożsamość (przykład)?

2) Stwierdza, że LoadFilenie ładuje plików do „LoadFrom Context” i nie rozwiązuje zależności za pomocą ścieżki ładowania. Co to znaczy, czy ktoś może podać przykład?

3) Na koniec stwierdza się, że LoadFilejest to przydatne w tym ograniczonym scenariuszu, ponieważ LoadFrom nie może załadować zestawów, które mają te same tożsamości, ale różne ścieżki; załaduje tylko pierwszy taki zestaw, co ponownie prowadzi mnie do tego samego pytania, jaka jest tożsamość zestawów?

Czy to wyjaśnia to?

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

Edycja : aby odpowiedzieć na pytania zadane w poprawionym pytaniu, na pewno chcesz przeczytać Suzanne Cook na temat Assembly Identity .

Istnieje wiele reguł, które regulują sposób ładowania zestawów, a niektóre z nich mają związek ze sposobem rozwiązywania zależności - jeśli AssemblyA jest zależna od AssemblyB, gdzie powinna szukać .NET, aby znaleźć AssemblyB? W Global Assembly Cache, w tym samym katalogu, w którym znalazł AssemblyA, czy zupełnie gdzie indziej? Ponadto, jeśli znajdzie wiele kopii tego zestawu, w jaki sposób powinien wybrać, którego użyć?

LoadFrom ma jeden zestaw reguł, podczas gdy LoadFile ma inny zestaw reguł. Trudno sobie wyobrazić wiele powodów, dla których warto skorzystać LoadFile, ale jeśli potrzebowałeś zastanowić się nad różnymi kopiami tego samego złożenia, to jest dla Ciebie.

Z bloga Suzanne Cook :

LoadFile vs. LoadFrom

Uważaj - to nie to samo.

LoadFrom () przechodzi przez Fusion i może zostać przekierowany do innego zestawu w innej ścieżce, ale z tą samą tożsamością, jeśli jest już załadowany w kontekście LoadFrom.

LoadFile () w ogóle nie wiąże się z Fusion - moduł ładujący po prostu kontynuuje i ładuje dokładnie * to, czego zażądał wywołujący. Nie używa kontekstu Load ani LoadFrom.

Tak więc LoadFrom () zwykle daje ci to, o co prosiłeś, ale niekoniecznie. LoadFile () jest dla tych, którzy naprawdę chcą dokładnie tego, o co proszą. (* Jednak począwszy od wersji 2, zasady zostaną zastosowane zarówno do LoadFrom (), jak i LoadFile (), więc LoadFile () niekoniecznie będzie dokładnie tym, czego zażądano. Ponadto począwszy od wersji 2, jeśli zestaw z jego tożsamością jest w GAC, zamiast tego zostanie użyta kopia GAC. Użyj ReflectionOnlyLoadFrom (), aby załadować dokładnie to, co chcesz - ale pamiętaj, że zestawy załadowane w ten sposób nie mogą zostać wykonane).

LoadFile () ma haczyk. Ponieważ nie używa kontekstu powiązania, jego zależności nie są automatycznie odnajdywane w jego katalogu. Jeśli nie są dostępne w kontekście Load, musisz subskrybować zdarzenie AssemblyResolve, aby powiązać z nimi.

Zobacz tutaj .

Zobacz także artykuł o wybieraniu kontekstu powiązania na tym samym blogu.

Po wielu drapaniach po głowie sam odkryłem różnicę tego popołudnia.

Chciałem załadować bibliotekę DLL w czasie wykonywania, a biblioteka DLL mieszkała w innym katalogu. Ta biblioteka DLL miała własne zależności (biblioteki DLL), które również znajdowały się w tym samym katalogu.

LoadFile (): załadowano konkretną bibliotekę DLL, ale bez zależności. Więc kiedy pierwsze wywołanie zostało wykonane z wewnątrz biblioteki DLL do jednej z tych innych bibliotek DLL, zgłosiło wyjątek FileNotFoundException.

LoadFrom (): załadowano bibliotekę DLL, którą podałem, a także wszystkie zależności, które żyły w tym katalogu.

Uwaga: Jeśli jeden zestaw jest ładowany przy użyciu ścieżki 8.3, a następnie ze ścieżki innej niż 8.3, będą one postrzegane jako różne zestawy, nawet jeśli są to ta sama fizyczna biblioteka DLL.

.NET ma inny kontekst ładowania. Suzanne Cook pisała o nich tutaj: http://blogs.msdn.com/suzcook/archive/2003/05/29/57143.aspx

W ten sposób .Net poddaje kwarantannie, aby odwołania nie były pomieszane.

jedna różnica, którą zauważyłem, to:

Assembly.LoadFile - ładuje zestaw w różnych AppDomain z ograniczonymi prawami użytkownika (różnica Principel). nie można wykonać operacji takich jak serilizacja / deserilizacja.

Assembly.LoadFrom - ładuje zestaw w tej samej AppDomain z tymi samymi prawami użytkownika (ten sam podmiot).

W moim przypadku wystarczyło po prostu usunąć pamięć podręczną aplikacji ASP znajdującą się @ C:\Windows\Microsoft.NET\Framework\[asp version]\Temporary ASP.NET Files. Jest odbudowywany podczas pierwszego uruchomienia witryny. Pamiętaj, aby najpierw zatrzymać usługi IIS.

Mam nadzieję, że to pomoże komuś takiemu jak mnie.