Как использовать правильный неуправляемый .dll в зависимости от архитектуры процессора? - PullRequest
2 голосов
/ 02 октября 2010

Я использую неуправляемую библиотеку в приложении .net, которое используется как в x86, так и в 64-битных системах и поэтому компилируется как «Любой ЦП».Однако неуправляемый нативный .dll поставляется в двух разных .dll для этого (один для win32 и один для x64).

Есть ли способ сохранить «любой процессор» / один двоичный файл с другим нативным.dll относительно сигнатур P / Invoke для x86 и 64-битных систем?Или - единственный способ создать отдельные конфиги и, следовательно, дистрибутивы?Если да, есть ли какие-нибудь флаги # if / # endif, которые я могу использовать для этого?

Ответы [ 3 ]

1 голос
/ 02 октября 2010

В папке bin вы можете добавить еще две папки с именами x86 и x64. Эта папка будет содержать x64 и x86 образы вашей нативной DLL.
При запуске (до того, как ваше приложение загрузит какие-либо внешние DLL), вы можете изменить переменную среды PATH процесса , чтобы она включала соответствующий подкаталог в соответствии с разрядностью процесса (IntPtr.Size должен указывать вашу битность).

Для управляемого исследования DLL вы можете подписаться на событие AppDomain.AssemblyResolve , чтобы вы могли самостоятельно загрузить сборку из правильного подкаталога (например, с помощью Assembly.Load * 1015). *).

0 голосов
/ 02 октября 2010

Вы можете вручную вызвать LoadLbrary & GetProcAddress, преобразовать указатели функций в делегаты, вызвав Marshal.GetDelegateForFunctionPointer(procAddress, delegateType).Это приводит к большему количеству кода, но позволяет хранить весь код взаимодействия в одной сборке.Этот подход используется NHanspell, например.

0 голосов
/ 02 октября 2010

Я бы поместил код p / invoke в отдельные сборки (один для 32 и один для 64 бит), а затем загрузил соответствующий код во время выполнения в зависимости от платформы.

Существует много способов определения типа системы. Лоты описаны здесь .

...