Відмінність LoadFile від LoadFrom від .NET зборів?

Я переглядав документацію msdn, і я все ще трохи розгублений у тому, яка саме різниця між використанням LoadFileта LoadFromзавантаженням збірки. Чи може хтось навести приклад чи аналогію, щоб краще описати його. Документація MSDN мене більше збентежила. Також, це ReflectionOnlyLoadFromте саме, що, LoadFromза винятком того, що він завантажує збірку лише у режимі відображення.

Оскільки мій досвід .NET не найбільший, ось декілька питань щодо документації MSDN за допомогою LoadFile:

1) Що означає LoadFileпідслідження збірок, які мають однакову ідентичність, але розташовані різними шляхами? Що таке особистість (приклад)?

2) У ньому зазначено, що LoadFileне завантажує файли у "LoadFrom Context" і не розв'язує залежності, використовуючи шлях завантаження. Що це означає, чи може хтось навести приклад?

3) Нарешті, він заявляє, що LoadFileце корисно в цьому обмеженому сценарії, оскільки LoadFrom не може завантажувати збірки, що мають однакові ідентичності, але різні шляху; вона завантажить лише першу таку збірку, що знову підводить мене до того ж питання, що таке ідентичність збірок?

Це зрозуміло це?

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

Редагувати : щоб відповісти на запитання, поставлені у вашому переглянутому запитанні, ви обов'язково хочете прочитати Сюзанні Кук про особу, що посвідчує особу .

Існує маса правил, які регулюють завантаження асамблей, і деякі з них мають відношення до того, як вони вирішують залежності - якщо ваша AssemblyA залежить від AssemblyB, куди .NET повинен шукати AssemblyB? У кеш глобальної асамблеї, той самий каталог, який він знайшов AssemblyA, або деінде повністю? Крім того, якщо він знаходить кілька копій цієї збірки, як слід вибрати, яку саме використовувати?

LoadFromмає один набір правил, тоді як LoadFileмає інший набір правил. Важко уявити багато причин для використання LoadFile, але якщо вам потрібно було використовувати відображення на різних копіях однієї збірки, це для вас.

З блогу Сюзанні Кук :

LoadFile vs. LoadFrom

Будьте уважні - це не одне і те ж.

LoadFrom () проходить через Fusion і може бути перенаправлений на іншу збірку по іншому шляху, але з тією самою ідентичністю, якщо вона вже завантажена в контексті LoadFrom.

LoadFile () взагалі не зв’язується через Fusion - завантажувач просто йде вперед і завантажує саме * те, що вимагав абонент. Він не використовує ні контекст Load, ні LoadFrom.

Отже, LoadFrom () зазвичай дає вам те, про що ви просили, але не обов’язково. LoadFile () призначений для тих, хто дійсно дуже хоче саме те, що вимагається. (* Однак, починаючи з v2, політика застосовуватиметься як до LoadFrom (), так і до LoadFile (), тому LoadFile () не обов'язково буде саме тим, про що вимагали. Також, починаючи з v2, якщо збірка з її ідентичністю знаходиться в GAC, замість цього буде використана копія GAC. Використовуйте ReflectionOnlyLoadFrom (), щоб завантажити саме те, що ви хочете, - але зауважте, що завантажені таким чином збірки неможливо виконати.)

LoadFile () має улов. Оскільки він не використовує обов'язковий контекст, його залежності не знаходяться автоматично в його каталозі. Якщо вони не доступні в контексті "Завантажити", вам доведеться підписатися на подію AssemblyResolve, щоб прив'язати їх.

Дивіться тут .

Також див. Стаття про вибір обов'язкового контексту в тому самому блозі.

Після численних чухань в голові я сьогодні виявив різницю.

Я хотів завантажити DLL під час виконання, і DLL жив в іншому каталозі. Ця DLL мала свої власні залежності (DLL), які також жили в тому самому каталозі.

LoadFile (): завантажується конкретна DLL, але не залежність. Отже, коли перший дзвінок був зроблений з DLL в одну з інших DLL, він кинув FileNotFoundException.

LoadFrom (): Завантажив DLL, який я вказав, а також всі залежності, які існували в цьому каталозі.

Примітка: Якщо одна збірка завантажується за допомогою шляху 8.3, а потім з не-8.3 шляху, вони будуть розглядатися як різні збірки, навіть якщо вони однакові фізичні DLL.

.NET має різний контекст завантаження. Сюзанна Кук писала про них тут: http://blogs.msdn.com/suzcook/archive/2003/05/29/57143.aspx

Це шлях. Чистий карантин, що посилання не змішуються.

одна різниця, яку я помітив, це:

Assembly.LoadFile - завантажує збірку в різних AppDomain з обмеженими правами користувача (diffrence principel). такі операції, як серіалізація / десерилізація, не вдалося виконати.

Assembly.LoadFrom - завантажує збірку в одному AppDomain з тими ж правами користувача (той же принцип).

У моєму випадку мені просто довелося просто видалити кеш додатків ASP, розташований @ C:\Windows\Microsoft.NET\Framework\[asp version]\Temporary ASP.NET Files. Він відновлюється під час першого запуску сайту. Обов’язково спочатку зупиніть IIS.

Сподіваюсь, це допомагає комусь, як це зробило для мене.