Как ссылаться на сторонние сборки, не копируя их локально?

Я работаю со многими сторонними сборками, которые по умолчанию устанавливаются вместе с SDK. Однако при использовании Reflection .NET вылетает со следующей ошибкой «Не удалось загрузить файл или сборку [Name.dll]». Итак, я нашел 3 решения:

  • Включите "локальную копию", что заставляет компилятор копировать все сборки в папку сборки (резко увеличивая размер файла).

  • Скомпилируйте непосредственно в папку сторонних программных файлов, позволяя среде выполнения .NET легко находить сборки (поскольку они находятся в одной папке). Это затрудняет управление установкой, поскольку 2 приложения используют общую папку.

  • Добавьте большинство сторонних сборок в GAC (используя gacutil) и ссылайтесь на него, используя строгое имя. Но это вызывает другой вид ошибки «Файл не найден», вероятно, сборка не может работать только из GAC, поскольку ей нужны некоторые файлы из своего собственного каталога Program Files.

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


.net c# reflection runtime assemblies
person Robin Rodricks    schedule 19.12.2011    source источник
comment
не могли бы эти сборки быть GAC на сервере или машине, или вы могли бы создать установщик .MSI для своего приложения и, возможно, ввести управление версиями ..? просто идея ..   -  person MethodMan    schedule 19.12.2011
comment
рад, что смог быстро помочь вам в этом .. ГОЛОСОВАНИЕ ..   -  person MethodMan    schedule 19.12.2011

Ответы (3)


arrow_upward
1
arrow_downward

Поскольку сборки в настоящее время находятся в отдельном «общем» каталоге, это означает, что для них можно управлять версиями независимо от программы, которая на них ссылается. «Копировать локально» предпочтительнее, чем это здесь, иначе вы можете попасть в старый «ад DLL» несовместимых версий, замененных без вашего ведома.

GAC предназначен для решения этой проблемы, хотя тогда, конечно, вам нужно использовать строгое именование, и вам нужно, чтобы все сборки, на которые они ссылаются, имели строгие имена и также входили в GAC. Это создает дополнительную работу по управлению версиями и установкой, но позволяет параллельное управление версиями и предотвращает дублирование. Тем не менее, если вы ссылаетесь только на сборку из нескольких приложений, размещение ее в GAC, вероятно, будет излишним. Фактически вы можете в конечном итоге занять больше места на диске из-за накопления версий во время обновлений, тогда как Copy Local оставляет вам только одну версию для каждого загруженного приложения.

person Dan Bryant    schedule 19.12.2011

arrow_upward
1
arrow_downward

Не могли бы эти сборки быть GAC на сервере или машине, или вы могли бы создать установщик .MSI для своего приложения и, возможно, ввести управление версиями ..? просто идея.

person MethodMan    schedule 19.12.2011
comment
Это помогло, но сейчас я прибегаю к # 2, чтобы заставить его работать. Ваше решение (№3) не ... см. Сообщение по причинам. - person Robin Rodricks; 19.12.2011

arrow_upward
1
arrow_downward

Если сборки находятся в сетевой папке, система безопасности .NET по умолчанию не загрузит их. Вам необходимо настроить параметры безопасности в панели управления конфигурацией .NET, в разделе «Политика безопасности выполнения» есть мастер для «Настроить безопасность зоны», а затем выбрать «Локальный Интернет» с «Полным доверием».

. Настройка безопасности .NET

person John Alexiou    schedule 19.12.2011