Собственный VC ++ с использованием внешней (не проектной) ссылки на dll, как указать путь к dll

У меня есть собственный проект VC ++, который использует dll (которого нет в проекте). Теперь я должен поместить dll в один из «Пути поиска, используемый Windows для поиска DLL» ссылка

но я не хочу, чтобы dll находилась в исполняемом или текущем, или в Windows, или в системном каталоге.

Итак, мой единственный вариант в соответствии с этим - добавить путь к переменной среды% PATH%.

Есть ли другой способ?

Есть ли элегантный способ сделать это (добавить в PATH)? я должен сделать это при установке? я должен беспокоиться, если я делаю это?


c++ native dll visual-studio-2005
person Hanan    schedule 23.10.2008    source источник

Ответы (8)


arrow_upward
5
arrow_downward

Обобщая все найденные мной техники:

  • Если вы используете управляемый проект в качестве проекта запуска (что на самом деле мой случай), используйте класс Enviroment

строка temp = "myFullDirectoryPathToDll"; строка temp2 = Environment.GetEnvironmentVariable ("ПУТЬ") + ";" + темп; Environment.SetEnvironmentVariable ("ПУТЬ", temp2);

это, и я думаю, что MSDN должен был подчеркнуть это, изменяет переменную среды PATH только в этом процессе.

при отладке в VS appPath не «работает», используйте свойства-> debug-> environment и объедините переменные среды ссылка

  • Если вы используете native: do явное связывание - кажется, большая работа для чего-то простого, возможно, используйте регистрационный ключ appPath при развертывании link, ни у кого не было проверенного и проверенного ответа
person Hanan    schedule 23.10.2008

arrow_upward
4
arrow_downward

Вот несколько предложений:

  • Вы можете встроить dll в качестве ресурса в свой основной исполняемый файл, а затем извлечь его во временный каталог и загрузить его с помощью LoadLibrary, а затем получить соответствующие адреса функций с помощью GetProcAddress.

  • Вы можете изменить путь поиска основных процессов с помощью SetDllDirectory (), чтобы указать расположение библиотеки DLL. Это избавляет от необходимости вносить какие-либо глобальные изменения в систему. И снова используйте LoadLibrary / GetProcAddress для разрешения адресов функций.

person QAZ    schedule 23.10.2008
comment
SetDllDirectory хорош. Интересно, можно ли использовать отложенную загрузку DLL в сочетании с этим вызовом, чтобы избежать LoadLibrary / GetProcAddress. msdn.microsoft.com/en-us/library/151kt790.aspx - person Aardvark; 23.10.2008
comment
это решение, похоже, работает для меня. Я использую библиотеку (.lib) в качестве входных данных для моего клиентского нативного проекта vc ++, затем я вызываю SetDllDirectory с дополнительным путем, и я не использую LoadLibrary. - person Hanan; 23.10.2008
comment
Однако я могу добавить только один путь, второй путь, который я добавляю, вероятно, заменяет первый. - person Hanan; 23.10.2008
comment
Я предполагаю, что вы могли бы передать разделенный точкой с запятой набор путей к вызову? - person J Francis; 23.10.2008

arrow_upward
1
arrow_downward

Если вы знаете, где, вероятно, будет находиться DLL, вы можете попытаться загрузить ее во время выполнения с помощью LoadLibrary (), а затем использовать GetProcAddress () для привязки к функциям, которые вам нужно вызвать.

person J Francis    schedule 23.10.2008
comment
Я не хочу делать явные ссылки. - person Hanan; 23.10.2008

arrow_upward
1
arrow_downward

Я был бы не рад, если бы установленное приложение добавляло случайные вещи в мой глобальный PATH. Поскольку это влияет на все приложения и может иметь неприятные побочные эффекты.

То, что я видел, - это начальный сценарий.
Этот сценарий выглядит и действует как приложение для пользователя (так что вы по-прежнему удваиваете часы). Но сценарий устанавливает соответствующий путь, а затем запускает реальное приложение.

person Martin York    schedule 23.10.2008
comment
Под скриптом установить соответствующий путь вы имеете в виду рабочий каталог? - person Hanan; 23.10.2008
comment
Нет, я имел в виду переменную окружения% PATH%. Обратите внимание, когда сценарий устанавливает значение, оно является локальным для сценария и его дочерних элементов, а не глобально. - person Martin York; 24.10.2008

arrow_upward
1
arrow_downward

Если вы используете DelayLoad, то перед вызовом любой функции, которая вызовет загрузку dll, вызовите LoadLibrary. Это «заправит» приложение, и оно не будет искать его. Нет необходимости в GetProcAddress

person Joel Lucsy    schedule 23.10.2008

arrow_upward
0
arrow_downward

Если вы запускаете с ярлыка Windows, вы можете указать путь к DLL в месте «Начать в», а полное имя и путь к .exe в поле «Целевой».

Если в каталоге .exe есть библиотеки DLL, которые необходимы, Windows должна также найти их, потому что я считаю, что порядок поиска DLL Windows сначала смотрит в путь .exe (текущий каталог пятое место в списке).

Я много раз использовал метод LoadLibrary / GetProcAddress, я стараюсь его избегать, поскольку он требует дополнительной работы - множества определений типов и приведений типов.

person Marc Bernier    schedule 23.10.2008

arrow_upward
0
arrow_downward

Метод отложенной загрузки работает с рабочим каталогом в то время, когда он решает вызвать LoadLibrary. Вы можете использовать это в своих интересах. См. http://msdn.microsoft.com/en-us/library/ms682586(VS.85).aspx для получения подробной информации о порядке пути поиска.

person spoulson    schedule 23.10.2008

arrow_upward
0
arrow_downward

Я попытался указать путь к приложению в системном реестре. Он работает нормально только тогда, когда у пользователя есть права на доступ к regedit. А также изменение переменной окружения PATH. Мой тестовый пользователь не имеет права администратора изменять переменную.

person Community    schedule 15.01.2009