Собственный VC++ с использованием внешней (не проектной) ссылки на dll, как указать путь к dll
У меня есть собственный проект VC++, который использует dll (которого нет в проекте). Теперь я должен поместить dll в один из «Пути поиска, используемый Windows для поиска DLL». связь
но я не хочу, чтобы dll находилась в исполняемом или текущем, или в Windows, или в системном каталоге.
Итак, мой единственный вариант в соответствии с этим - добавить путь к переменной среды% PATH%.
Есть ли другой путь?
Есть ли элегантный способ сделать это (добавить в PATH)? я должен сделать это при установке? я должен беспокоиться, если я делаю это?
Ответы 8
Если вы знаете, где, вероятно, будет находиться DLL, вы можете попытаться загрузить ее во время выполнения с помощью LoadLibrary (), а затем использовать GetProcAddress () для привязки к функциям, которые вам нужно вызвать.
Я был бы не рад, если бы установленное приложение добавляло случайные вещи в мою глобальную переменную PATH. Поскольку это влияет на все приложения и может иметь неприятные побочные эффекты.
Я заметил, что у меня есть стартовый скрипт. Сценарий выглядит и действует как приложение для пользователя (так что вы по-прежнему удваиваете часы). Но сценарий устанавливает соответствующий путь, а затем запускает реальное приложение.
Вы имеете в виду рабочий каталог под "сценарием, устанавливающим соответствующий путь"?
Нет, я имел в виду переменную окружения% PATH%. Обратите внимание, когда сценарий устанавливает значение, оно является локальным для сценария и его дочерних элементов, а не глобально.
Вот несколько предложений:
Вы можете встроить dll в качестве ресурса в свой основной исполняемый файл, а затем извлечь его во временный каталог и загрузить его с помощью LoadLibrary, а затем получить соответствующие адреса функций с помощью GetProcAddress.
Вы можете изменить путь поиска основных процессов, используя SetDllDirectory (), чтобы указать местоположение DLL. Это избавляет от необходимости вносить какие-либо глобальные изменения в систему. И снова используйте LoadLibrary / GetProcAddress для разрешения адресов функций.
SetDllDirectory хорош. Интересно, можно ли использовать отложенную загрузку DLL в сочетании с этим вызовом, чтобы избежать LoadLibrary / GetProcAddress. msdn.microsoft.com/en-us/library/151kt790.aspx
это решение, похоже, работает для меня. Я использую библиотеку (.lib) в качестве входных данных для моего клиентского собственного проекта vC++, затем я вызываю SetDllDirectory с дополнительным путем, и я не использую LoadLibrary.
Однако я могу добавить только один путь, второй путь, который я добавляю, вероятно, заменяет первый.
Я предполагаю, что вы могли бы передать разделенный точкой с запятой набор путей к вызову?
Обобщая все найденные мной техники:
- Если вы используете управляемый проект в качестве стартового (что, собственно, и есть в моем случае) использовать класс Enviroment
строка temp = "myFullDirectoryPathToDll"; строка temp2 = Environment.GetEnvironmentVariable ("ПУТЬ") + ";" + темп; Environment.SetEnvironmentVariable ("ПУТЬ", temp2);
это, и я думаю, что MSDN должен был подчеркнуть это, изменяет переменную среды PATH только в этом процессе.
при отладке в VS appPath не работает использовать свойства-> отладка-> среда и объединить переменные среды связь
- Если вы используете родной: сделать явную ссылку - кажется, большая работа для чего-то простого, возможно, использовать регистрационный ключ appPath при развертывании связь, ни у кого не было проверенного и проверенного ответа
Если вы используете DelayLoad, то перед вызовом любой функции, которая вызовет загрузку dll, вызовите LoadLibrary. Это «заправит» приложение, и оно не будет искать его. Нет необходимости в GetProcAddress
Если вы запускаете с ярлыка Windows, вы можете указать путь к DLL в месте «Начать в», а полное имя и путь .exe в поле «Целевой».
Если в каталоге .exe есть библиотеки DLL, которые необходимы, Windows должен также сможет их найти, потому что я считаю, что порядок поиска DLL Windows сначала смотрит в путь .exe (текущий каталог занимает пятое место в списке).
Я много раз использовал метод LoadLibrary / GetProcAddress, я стараюсь его избегать, поскольку он требует дополнительной работы - множества определений типов и приведений типов.
Метод отложенной загрузки работает с рабочим каталогом в то время, когда он решает вызвать LoadLibrary. Вы можете использовать это в своих интересах. См. http://msdn.microsoft.com/en-us/library/ms682586(VS.85).aspx для получения подробной информации о порядке пути поиска.
Я попытался указать путь к приложению в системном реестре. Он работает нормально только тогда, когда у пользователя есть права на доступ к regedit. А также изменение переменной окружения PATH. Мой тестовый пользователь не имеет права администратора изменять переменную.
Я не хочу делать явные ссылки.