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

Question

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

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

Так что мой единственный вариант в соответствии с этим - добавить путь к переменной окружения% PATH%.

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

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

Answer 1

Подводя итог всем техникам, которые я нашел:

• Если вы используете управляемый проект в качестве стартового проекта (на самом деле это мой случай) использовать класс окружающей среды

string temp = "myFullDirectoryPathToDll"; string temp2 = Environment.GetEnvironmentVariable ("PATH") + ";" + темп; Environment.SetEnvironmentVariable ("PATH", temp2);

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

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

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

Answer 2

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

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

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

Answer 3

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

Answer 4

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

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

Answer 5

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

Answer 6

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

Answer 7

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

Answer 8

Если вы запускаете из ярлыка Windows, вы можете указать путь к DLL в папке «Start in», указав полное имя .exe и путь в папке «Target».

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

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