Visual Studio (сброс проекта C )

#c #loadlibrary

#c #loadlibrary

Вопрос:

Я никогда не использовал C в Visual Studio, но немного поработал с C # и VB.

У меня есть простой проект x86 C , который загружает 32-битную DLL, а затем использует функцию из нее.

Он работал нормально, затем я изменил некоторые настройки (версия SDK, набор инструментов, стандарт языка C ), и теперь я получаю сообщение «Указанный модуль не найден». когда я пытаюсь загрузить DLL.

Я сбросил C в «Мастере импорта и экспорта настроек», а затем переустановил всю Visual Studio, но, похоже, я не могу найти способ вернуть проект к работе с этой DLL. Dumpbin показывает мне, что все необходимые ему зависимости находятся в SYSWOW64 :/

Я сделал копии DLL и разместил их везде, где только мог придумать, но у меня та же проблема. Он загружается с помощью C #, но у меня есть некоторые проблемы с доступом к памяти, передающие строки в одну из функций.

У кого-нибудь раньше была такая проблема?

 //Get current exe path and add DLL filename.
char cDLLPath[MAX_PATH   1];
TCHAR bufCurrentDirectory[MAX_PATH   1] = { 0 };
DWORD dwNumCharacters = ::GetCurrentDirectory(MAX_PATH, bufCurrentDirectory);

if (dwNumCharacters == 0)
{
    printf("Error getting executable pathn");
    exit(0);
}
snprintf(cDLLPath, MAX_PATH   1, "%s\MyDLL.dll", bufCurrentDirectory);
HINSTANCE myDll = LoadLibrary((LPCWSTR)cDLLPath);
//MyDLL is always NULL, error message is always "The specified module could not be found."
 

Я удалил путь, попробовал текущую рабочую папку, переместил ее в c:windowssystem32 и т.д.

Эта функция сообщает мне, что путь к DLL filename указан правильно.

 BOOL file_exists(const fs::pathamp; file_path, fs::file_status s = fs::file_status{})
{
if (fs::status_known(s) ? fs::exists(s) : fs::exists(file_path)) return true;
else return false;
}
 

-Pook

Комментарии:

1. LoadLibrary((LPCWSTR)cDLLPath); Это неправильно и не могло работать раньше. Должно быть, вы изменили какой-то другой код и / или настройку Unicode для проекта.

2. Да! спасибо, я изменил набор символов на многобайтовый, а LPCWSTR на LPCSTR, и все хорошо

3. Это хорошая новость, что это работает, но для согласованности вы не должны смешивать char и TCHAR на одном дыхании, и в современных Windows вы должны компилировать для Unicode, поскольку, например, многобайтовый GetCurrentDirectory вернет неправильный путь, если текущий каталог содержит международные символы за пределами активной кодовой страницы.

4. Так много интернет-кода все еще использует TCHAR, технологию, которая имела немного смысла в 1990-х годах. Игнорируйте все это. Используйте широкие символы в современном коде.