Вызов DLL-файлов, расположенных в другом каталоге - PullRequest
Новая
       47

Вызов DLL-файлов, расположенных в другом каталоге

2 голосов
/ 18 декабря 2011

У меня есть консольное приложение (NGameHost), работающее в определенном каталоге (C:\Program Files\NetworkGame3\api\). Он использует файлы, доступные в этом каталоге, и консольное приложение хорошо работает при запуске самостоятельно. Он также предоставляет различные методы, которые используют библиотеки DLL (и другие файлы, такие как файлы конфигурации) из этого каталога. Теперь у меня есть другое консольное приложение (расположенное в другом месте), которое пыталось вызвать эти методы и вернуть результаты. Я установил Copy Local: False, чтобы он выполнялся в этом каталоге вместо создания локальной версии. Однако я получаю сообщение об ошибке «Не удалось загрузить файл или сборку ... или одну из ее зависимостей. Система не может найти указанный файл».

Как я могу вызвать методы из консольного приложения, расположенного в другом каталоге?

Ответы [ 3 ]

3 голосов
/ 18 декабря 2011

Когда вы устанавливаете copy local = false, вы говорите, что не копируете сборку в локальный каталог, и в этом случае сборка будет доступна в одном из мест, где среда выполнения ее ищет.

См. Как среда выполнения обнаруживает сборку

Ваша сборка должна находиться либо в GAC, либо в одном из зондов обнаружения.

3 голосов
/ 18 декабря 2011

Вы можете использовать GAC, подход конфигурации или событие разрешения сборки.

Этот КБ описывает его более подробно:

http://support.microsoft.com/kb/837908

Также посмотрите на пути исследования:

http://msdn.microsoft.com/en-us/library/15hyw9x3(v=vs.71).aspx

0 голосов
/ 20 апреля 2013

Я недавно ударился головой о кирпичную стену, пытаясь решить очень похожую проблему. У меня есть DLL, которую я хочу загрузить во время выполнения, и у нее есть свои зависимости. Я не мог понять, почему он загружается, но при вызове конструктора класса в загруженной сборке ошибка не возникает, а выполнение просто останавливается, и вы задаетесь вопросом, что происходит.

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

Ошибка не появлялась, пока я не скопировал все библиотеки DLL зависимостей в мое приложение в разработке. Теперь я могу удалить их снова! При этом я получаю предупреждающее сообщение DLL Loader Lock. Если я подавляю или игнорирую это, мой код работает.

В моем случае разрешение было: 

<?xml version="1.0"?>
<configuration>
  <startup useLegacyV2RuntimeActivationPolicy="true">
    <supportedRuntime version="v4.0"/>
  </startup>
</configuration>
...