Разница между LoadFile и LoadFrom with.NET Ассамблеи?

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

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

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

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

3) Наконец, в нем говорится, что LoadFile полезно в данном случае, потому что LoadFrom не может загружать сборки с одинаковыми идентификаторами, но разными путями; он будет загружать только первую такую сборку, что снова приводит меня к тому же вопросу, Что такое идентификатор сборок?

106
.net assemblies assembly-loading system.reflection

8 ответов

это проясняет ситуацию?

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

редактировать: чтобы ответить на вопросы, которые вы подняли в своем пересмотренном вопросе, вы определенно хотите прочитать Сюзанна Кук на сборке идентичности.

существует множество правил, регулирующих загрузку сборок, и некоторые из них связаны с тем, как они разрешают зависимости - если ваша сборка зависит от AssemblyB, где .NET должен искать AssemblyB? В глобальном кэше сборок, той же директории нашли Ассамблее, или где-то совсем другое? Кроме того, если он находит несколько копий этой сборки, как он должен выбрать, какой из них использовать?

LoadFrom имеет один набор правил, в то время как LoadFile имеет другой набор правил. Трудно представить себе много причин для использования LoadFile, но если вам нужно использовать отражение на разных копиях одной и той же сборки, это для вас.

85

с блог Сюзанны Кук:

LoadFile против LoadFrom

будьте осторожны - это не то же вещь.

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

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

Итак, LoadFrom () обычно дает вам то, что вы просили, но не обязательно. LoadFile () для тех, кто действительно, очень хочется именно того, что просят. (*Однако, начиная с V2, политика применяться как LoadFrom() и LoadFile (), поэтому LoadFile () не будет обязательно именно то, что было запрошенный. Кроме того, начиная с v2, если сборка со своей идентичностью находится в ГЛОБАЛЬНЫЙ КЭШ СБОРОК, будет использоваться копия GAC вместо. Используйте ReflectionOnlyLoadFrom() чтобы загрузить именно то, что вы хотите - но, обратите внимание, что сборки загружаются таким образом невозможно выполнить.)

LoadFile () имеет улов. Поскольку не использует контекст привязки, его зависимости не автоматически найдено в его каталоге. Если нет ... доступный в контексте загрузки, вы пришлось бы подписаться на AssemblyResolve событие для привязки к ним.

посмотреть здесь.

см. Также выбор контекста привязки статья в том же блоге.

55

после долгого чесания головы я сам обнаружил разницу сегодня днем.

Я хотел загрузить DLL во время выполнения, а DLL жил в другом каталоге. Эта DLL имела свои собственные зависимости (DLL), которые также жили в том же каталоге.

LoadFile (): загружена конкретная DLL, но не зависимости. Поэтому, когда первый вызов был сделан из библиотеки DLL в одну из этих других библиотек, он вызвал исключение FileNotFoundException.

LoadFrom(): Загружается DLL, которую я указал, а также все зависимости, которые жили в этом каталоге.

36

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

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

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

4

Примечание: Если одна сборка загружается с использованием пути 8.3, а затем из пути не 8.3, они будут рассматриваться как разные сборки, даже если они являются одной и той же физической DLL.

2

.NET имеет другой контекст загрузки. Сюзанна Кук писала о них здесь:1-->http://blogs.msdn.com/suzcook/archive/2003/05/29/57143.aspx

Это способ карантина .Net, в котором ссылки не смешиваются.

1

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

надеюсь, это поможет кому-то, как это было для меня.

0

согласно документации:

LoadFile (String): загружает содержимое файла сборки с заданным путем к файлу.

LoadFrom (String): загружает сборку с заданным именем файла или путем.

-1