Поместите DLL в другой каталог

Question

Поместите DLL в другой каталог

0

Я хочу разместить библиотеки DLL в другую папку, а затем exe файл, потому что это огромный беспорядок. (Я использую SDL2, но это не относится к этому, я думаю)

Изменение: Как импортировать DLL из другого каталога? (Я импортирую их только заготавливаемые заголовки)

PSSGCSim 01 янв. 2014, в 22:15

Источник

1

Я не вижу здесь вопроса.
Dani 01 янв. 2014, в 20:59
0

Пожалуйста, задайте вопрос.
TimDave 01 янв. 2014, в 20:59
2

Лучший план состоит в том, чтобы поместить библиотеки DLL в тот же каталог, что и исполняемый файл.
David Heffernan 01 янв. 2014, в 21:14
0

@DavidHeffernan Как общее правило. Но для комплексных решений я бы хотел организовать организацию пари. Я не знаю, почему на самом деле этот вопрос был отвергнут, и я прошу от даунготера (кого бы то ни было), пожалуйста, объясните.
MasterMastic 01 янв. 2014, в 21:19
0

@Ken Хотя это может быть приятно, загрузчик действительно предпочитает dll в том же каталоге, что и exe.
David Heffernan 01 янв. 2014, в 21:21
0

У загрузчика нет предпочтений. Он просто делает то, что ему говорят.
IInspectable 01 янв. 2014, в 21:22
0

Вы можете сделать это с помощью манифеста, который содержит элемент <dependentAssembly> для объявления частной зависимости. Это настолько плохо документировано, что это не стоит хлопот.
Hans Passant 01 янв. 2014, в 21:51
0

@IInspectable, если вы хотите связать время загрузки, то вы не можете сказать ему, что делать
David Heffernan 01 янв. 2014, в 21:51
0

@Hans Это интересно, и вы правы, что плохо документированы. Я не смог найти ничего, что позволило бы указать путь поиска. Вы намекаете , что <assemblyIdentity> s name атрибут может содержать относительный путь? Или я просто неправильно тебя истолковал?
IInspectable 01 янв. 2014, в 22:06

Показать ещё 7 комментариев

Теги:

c++

dll

windows

2 ответа

-1

Переменная среды PATH должна делать трюк

Ed Heal 01 янв. 2014, в 18:20

2

Это глобальное решение локальной проблемы
David Heffernan 01 янв. 2014, в 21:13
1

@DavidHeffernan - Сделать его локальным - есть командный файл ?!
Ed Heal 01 янв. 2014, в 21:15
2

Это все еще глобально. Это влияет не только на вызовы LoadLibrary .
IInspectable 01 янв. 2014, в 21:16

Показать ещё 1 комментарий

Ещё вопросы

Лучший план состоит в том, чтобы поместить библиотеки DLL в тот же каталог, что и исполняемый файл.
@DavidHeffernan Как общее правило. Но для комплексных решений я бы хотел организовать организацию пари. Я не знаю, почему на самом деле этот вопрос был отвергнут, и я прошу от даунготера (кого бы то ни было), пожалуйста, объясните.
@Ken Хотя это может быть приятно, загрузчик действительно предпочитает dll в том же каталоге, что и exe.
У загрузчика нет предпочтений. Он просто делает то, что ему говорят.
Вы можете сделать это с помощью манифеста, который содержит элемент <dependentAssembly> для объявления частной зависимости. Это настолько плохо документировано, что это не стоит хлопот.
@IInspectable, если вы хотите связать время загрузки, то вы не можете сказать ему, что делать
@Hans Это интересно, и вы правы, что плохо документированы. Я не смог найти ничего, что позволило бы указать путь поиска. Вы намекаете , что <assemblyIdentity> s name атрибут может содержать относительный путь? Или я просто неправильно тебя истолковал?
Это глобальное решение локальной проблемы
@DavidHeffernan - Сделать его локальным - есть командный файл ?!
Это все еще глобально. Это влияет не только на вызовы LoadLibrary .

IInspectable · Accepted Answer · 2014-01-01T18-08-00.000Z

3

Лучший ответ

Для этого вам нужно указать свои библиотеки как /DELAYLOAD и установить соответствующие каталоги DLL во время запуска приложения, вызывая AddDllDirectory (Windows 8 и выше) или SetDllDirectory (Windows XP SP1 и выше).

Задержка загрузки DLL требуется в этом сценарии. В противном случае загрузчик попытается разрешить таблицы импорта, прежде чем ваше приложение получит возможность установить соответствующие каталоги для поиска.

IInspectable 01 янв. 2014, в 18:08

1

Есть ли минусы для задержки загрузки?
MasterMastic 01 янв. 2014, в 21:28
1

@Ken Ошибки об отложенном разрешении импорта появляются позже (при первой попытке выполнить неудовлетворенный импорт). Для надежного решения вам необходимо реализовать соответствующую обработку ошибок . Существуют также некоторые ограничения DLL-библиотеки с отложенной загрузкой .
IInspectable 01 янв. 2014, в 21:36
0

@Ken У меня нет опыта работы с /DELAYLOAD но я могу вспомнить о двух незначительных проблемах: 1) легче случайно забыть распространить редко используемую библиотеку DLL (поскольку программа только попытается загрузить ее и, таким образом, отобразит ошибку после первого вызова к функции в этой DLL) 2) вы также потенциально торгуете более длительное время запуска за более короткую, но с возможностью (возможно, довольно незначительного) всплеска каждый раз, когда загружается новая DLL.
user2802841 01 янв. 2014, в 21:43
0

@ user2802841 Ваш первый пункт обычно не проблема. Даже если вы получите удар один раз, вы включите тест для этого в ваше тестирование качества. Второй пункт читается скорее как про, чем как против.
IInspectable 01 янв. 2014, в 21:48
0

@IInspectable Я согласен, что они оба очень незначительны, и, наверное, слишком сложно назвать их проблемами :)
user2802841 01 янв. 2014, в 21:51

Показать ещё 3 комментария