Разница между LoadFile и LoadFrom со сборками .NET?

Я смотрел документацию msdn, и я все еще немного смущен тем, в чем именно разница между использованием LoadFileи LoadFromзагрузкой сборки. Может ли кто-нибудь привести пример или аналогию, чтобы лучше описать это. Документация MSDN смутила меня больше. Кроме того, это ReflectionOnlyLoadFromто же самое, LoadFromза исключением того, что он загружает сборку только в режиме отражения.

Поскольку мой опыт работы с .NET не самый лучший, вот несколько вопросов относительно документации MSDN с использованием LoadFile:

1) Что означает LoadFileпроверка сборок с одинаковым идентификатором, но расположенных по разным путям? Какая личность (пример)?

2) Он заявляет, что LoadFileне загружает файлы в «контекст LoadFrom» и не разрешает зависимости с использованием пути загрузки. Что это значит, может кто-нибудь привести пример?

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 против LoadFrom

Будьте осторожны - это не одно и то же.

LoadFrom () проходит через Fusion и может быть перенаправлен на другую сборку по другому пути, но с тем же идентификатором, если он уже загружен в контекст LoadFrom.

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

Итак, LoadFrom () обычно дает вам то, что вы просили, но не обязательно. LoadFile () предназначена для тех, кто действительно хочет именно того, что требуется. (* Однако, начиная с версии 2, политика будет применяться как к LoadFrom (), так и к LoadFile (), поэтому LoadFile () не обязательно будет именно тем, что было запрошено. Кроме того, начиная с версии 2, если сборка с ее идентификатором находится в 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

Таким образом не перепутываются карантины .Net, в которых ссылки не перепутались.

одно отличие, которое я заметил:

Assembly.LoadFile - загружает сборку в другой домен приложения с ограниченными правами пользователя (принцип различия). такие операции, как серилизация / десерилизация, не могут быть выполнены.

Assembly.LoadFrom - загружает сборку в один и тот же домен приложения с одинаковыми правами пользователя (тот же принцип).

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

Надеюсь, это поможет кому-то так же, как и мне.