Не вдається завантажити DLL (модуль не знайдено HRESULT: 0x8007007E)

У мене є бібліотека dll з некерованим кодом API C ++, який мені потрібно використовувати у своєму додатку .NET 4.0. Але кожен метод я намагаюся завантажити мій dll, я отримую помилку:

Не вдається завантажити DLL 'MyOwn.dll': Вказаний модуль не вдалося знайти. (Виняток з HRESULT: 0x8007007E)

Я прочитав і спробував рішення severa, які я знайшов в Інтернеті. Нічого не працює ..

Я спробував використовувати наступні методи:

[DllImport("MyOwn.dll",  CallingConvention = CallingConvention.Cdecl)]
[return: MarshalAs((UnmanagedType.I4))]
public static extern Int32 MyProIni(string DBname, string DBuser_pass,
    string WorkDirectory, ref StringBuilder ErrorMessage);

Коли я намагався виконувати цю статтю і коли я запускаю цей приклад (із завантаженого коду), він працює без проблем (використовуваний dll знаходиться у папці bin / debug)

Я скопіював свій dll (разом із усіма файлами, від яких залежить, у мою папку bin).

Я також спробував такий підхід, але отримав ту ж помилку:

[DllImportAttribute(MyOwnLibDllPath, EntryPoint="TMproIni")]
[return: MarshalAs(UnmanagedType.I4)]
public static extern  int MyproIni(string DBname, string DBuser_pass, 
    string WorkDirectory, ref StringBuilder ErrorMessage);

Будь-які пропозиції?

З того, що я пам'ятаю в Windows, порядок пошуку для dll є:

1. Поточний довідник
2. Системна папка C:\windows\system32 or c:\windows\SysWOW64(для 32-бітного процесу в 64-бітному вікні).
3. Читання із Pathзмінної середовища

Крім того, я би перевірив залежності DLL, ходувач залежностей, наданий Visual Studio, може допомогти вам тут, його також можна завантажити безкоштовно: http://www.dependencywalker.com

Ви можете скористатися інструментом "дампбін", щоб дізнатися необхідні залежності DLL:

dumpbin /DEPENDENTS my.dll

Це покаже вам, які DLL-файли потрібно завантажити. Особливо слідкуйте за MSVCR * .dll. Я бачив, як ваш код помилки виникає, коли не встановлено правильний перерозподільний диск Visual C ++.

Ви можете отримати "Передані пакети Visual C ++ для Visual Studio 2013" з веб-сайту Microsoft. Він встановлює c: \ windows \ system32 \ MSVCR120.dll

У назві файлу 120 = 12,0 = Visual Studio 2013.

Будьте уважні, що у вас є правильна версія Visual Studio (10.0 = VS 10, 11 = VS 2012, 12.0 = VS 2013 ...) правильна архітектура (x64 або x86) для цільової платформи DLL, а також вам потрібно бути обережними налагоджує. Збірка налагодження DLL залежить від MSVCR120d.dll, яка є налагодженою версією бібліотеки, яка встановлюється за допомогою Visual Studio, але не за допомогою пакета перерозподілу.

Це "хитрість", але ви можете принаймні використати його для перевірки здоровості: Спробуйте жорстко кодувати шлях до DLL у своєму коді

[DllImport(@"C:\\mycompany\\MyDLL.dll")]

Сказавши, що; у моєму випадку запуск, dumpbin /DEPENDENTSяк це запропонував @ anthony-hayward, і копіювання 32-бітних версій DLL, перерахованих там, у мій робочий каталог вирішив цю проблему для мене.

Повідомлення трохи вводить в оману, тому що це не "мій" dll, який неможливо завантажити - це залежність

DLL має бути в папці bin.

У Visual Studio я додаю dll до свого проекту (НЕ у посиланнях, а "Додати існуючий файл"). Потім встановіть властивість «Копіювати у каталог виводу» для dll значення «Копіювати, якщо новіше».

Спробуйте ввести повний шлях DLL. Якщо це не працює, спробуйте скопіювати dll у папку system32.

Переконайтесь, що всі залежність вашого власного dll присутні біля dll або в System32.

Є одна дуже смішна річ (і має технічну актуальність), яка може втратити ваші години, тому думайте поділитися нею тут -

Я створив проект консольного додатка ConsoleApplication1та проект бібліотеки класів ClassLibrary1.

Весь код, який робив p / invoke, був присутній у ClassLibrary1.dll. Тому перед налагодженням програми з візуальної студії я просто скопіював керовану збірку C ++ ( myUnmanagedFunctions.dll) у \bin\debug\каталог ClassLibrary1проекту, щоб вона могла бути завантажена CLR під час виконання.

Я продовжував отримувати

Не вдається завантажити DLL

помилка годинами. Згодом я зрозумів, що всі такі некеровані збірки, які потрібно завантажити, потрібно скопіювати в \bin\debugкаталог стартового проекту, ConsoleApplication1який зазвичай є виграшною формою, консоллю або веб-додатком.

Тож будь ласка, будьте обережні, що Current Directoryу прийнятій відповіді насправді є засобом Current Directoryголовного виконуваного файлу, звідки починається процес подання заявки. Схоже, це очевидна річ, але часом може бути не так.

Заняття уроку - завжди розміщуйте некеровані DLL-адреси в тій самій директорії, що і виконавчий файл запуску, щоб переконатися, що його можна знайти.

Увімкніть журнал термоядерного синтезу, див. Це питання, щоб отримати багато порад, як це зробити. Налагодження проблем із завантаженням програм із змішаним режимом може бути справжнім болем у королівстві. Спільна реєстрація може бути великою підмогою.

Переконайтеся, що ви встановили ціль платформи збірки на x86 або x64, щоб вона була сумісною з вашою DLL - яка може бути скомпільована для 32-бітної платформи.

Якщо проекти DLL та .NET знаходяться в одному і тому ж рішенні, і ви хочете збирати та запускати обидва рази, ви можете клацнути правою кнопкою миші властивості проекту .NET, Build події, а потім додати щось подібне до події після збирання. командний рядок:

copy $(SolutionDir)Debug\MyOwn.dll .

Це в основному лінія DOS, і ви можете налаштувати, залежно від того, де будується ваша DLL.

У мене була така ж проблема, коли я розгортав свою програму для тестування ПК. Проблема розвитку ПК була msvcp110d.dllіmsvcr110d.dll , але не тестовий комп'ютер.

Я додав модуль злиття "Visual Studio C ++ 11.0 DebugCRT (x86)" в InstalledSheild і він працював. Сподіваюся, що це буде корисно для когось іншого.

У моєму випадку один некерований DLL залежав від іншого, якого бракувало. У цьому випадку помилка вкаже на існуючий dll замість відсутнього, який може бути дуже заплутаним.

Саме це сталося в моєму випадку. Сподіваюся, що це допомагає комусь іншому.

Я думаю, що вашій некерованій бібліотеці потрібен маніфест.
Ось як додати його у свій двійковий файл. і тут чому.

Підсумовуючи, у вашому вікні може бути встановлено кілька перерозподілених бібліотечних версій, але лише одна з них повинна задовольняти вашій програмі, і це може бути не за замовчуванням, тому вам потрібно повідомити системі про версію, яку потрібна вашій бібліотеці, ось чому маніфест.

Налаштування : 32-розрядна Windows 7

Контекст : Встановлено драйвер PCI-GPIB, через який я не зміг спілкуватися через вищезгадану проблему.

Короткий відповідь : Перевстановіть драйвер.

Довгий відповідь : я також використовував Denderpend Walker , який ідентифікував декілька відсутніх модулів залежності. Відразу я подумав, що це, мабуть, було встановленим драйвером. Я не хотів перевіряти та відновлювати кожен файл, що відсутній.

Той факт, що мені не вдалося знайти видалення програми в розділі Програми та функції панелі управління, є ще одним показником поганої установки. Мені довелося видалити пару * .dll в \ system32 та ключі реєстру, щоб дозволити повторну інсталяцію драйвера.

Виправлення виправлено.

Несподіваною частиною було те, що не всі модулі залежності були вирішені. Тим не менш, тепер може бути посилається на * .dll інтерес.

Я зіткнувся з тією ж проблемою, У моєму випадку у мене було два 32-бітні ПК. Один з .NET4.5 встановлений, а інший - свіжий ПК.

мій 32-бітний cpp dll (збірка в режимі випуску) добре працював із встановленим ПК .NET, але не зі свіжим ПК, де я отримав помилку нижче

Не вдається завантажити DLL 'PrinterSettings.dll': Вказаний модуль не вдалося знайти. (Виняток з HRESULT: 0x8007007E)

нарешті,

Я щойно побудував свій проект у конфігурації режиму налагодження, і на цей раз мій cpp dll працював чудово.

Також зіткнулися з тією ж проблемою при використанні керованого файлу dll c / c ++ у середовищі c #.

1.Перевірена сумісність dll з 32-бітним або 64-бітовим процесором.

2.Перевірив правильні шляхи папки DLL .bin, system32 / sysWOW64 або заданий шлях.

3.Перевірено, чи відсутні файли PDB (бази даних програми). Це відео дає вам найкращі результати щодо файлів pdb.

При запуску 32-бітного C / C ++ бінарного коду в 64-бітовій системі це може виникнути через несумісність платформи. Ви можете змінити його за допомогою Build> Configuration Manager.

Я зіткнувся з тією ж проблемою, коли імпортував C ++ Dll в .Net Framework +4, я не перевірив Project-> Properties-> Build-> Віддаю перевагу 32-бітовій версії, і вона вирішилася для мене.