Что является причиной того, что функция C ++, вызываемая из C # в модульном тесте (NUnit или MSTest), приводит к отличному результату от того же кода, выполняемого в консольном приложении?

Я вызываю C ++ DLL из C # через P / Invoke, используя DllImport. DLL создается сторонней компанией и является только x86 (поэтому наш код на C # также построен как x86).

Если я вызываю определенную функцию в DLL из консольного приложения, я всегда получаю один правильный результат. Функция берет путь к файлу и извлекает некоторую информацию из файла.

Сигнатура функции:

private static extern int Function(
string str1,
int bool1,
ref uint outUint1,
ref uint outUint2,
ref uint outUint3,
ref double outDouble1,
ref double outDouble2,
StringBuilder outStr1);

И неожиданный результат в одном из ref uint параметры.

Если я создаю модульный тест и вызываю точно такой же код (со всеми параметрами и такими жестко закодированными), я получаю совершенно другой результат, который неверен. Неверный результат всегда одинаков. Я пробовал оба теста MSTest и NUnit, используя различные бегуны с тем же результатом.

Случаи, дающие правильные результаты:

  • Консольное приложение
  • Winforms приложение
  • Консольное приложение, запускающее код, но запущенное из модульного теста (NUnit)

Случаи, дающие неверные результаты:

  • Тестовый прогон от Resharper Test Runner (NUnit)
  • Тестовый запуск из Visual Studio Test Runner (MSTest)
  • Тестовый запуск из NUnit GUI Test Runner
  • Тестовый запуск из NUnit Console Test Runner

Моя тестовая среда — Windows 8, а C # создан для платформы x86 .NET Framework 4.

У кого-нибудь из вас есть идеи о том, что вызывает эту проблему, или что я могу сделать, чтобы исправить ее дальше?

Я определенно буду пытаться связаться с третьей стороной, которая создала DLL, но наличие точного представления о том, что именно является причиной этой проблемы, значительно увеличит вероятность ее устранения.

1

Решение

Похоже, что «filepath», который он ожидает, может относиться к рабочему каталогу, или рабочий каталог, или даже каталог приложения важен для dll.

Эта dll также может пытаться ссылаться на другие dll в своем каталоге, но не может найти их, потому что она была загружена из собственной папки вместо исполняемого файла, выполняющегося в этом каталоге.

Примерно на полпути вниз эта страница он описывает порядок поиска для разрешения dll:

  1. Каталог, из которого загружено приложение.

  2. Текущий каталог.

  3. Системный каталог. Используйте функцию GetSystemDirectory, чтобы получить
    путь к этому каталогу.

  4. 16-битный системный каталог. Там нет функции, которая получает
    путь к этому каталогу, но он ищется.

  5. Каталог Windows. Используйте функцию GetWindowsDirectory, чтобы получить
    путь к этому каталогу.

  6. Каталоги, перечисленные в переменной среды PATH.
    Обратите внимание, что это не включает указанный путь для приложения
    по разделу реестра App Paths. Ключ App Paths не используется, когда
    вычисление пути поиска DLL.

Надеюсь, это поможет.

РЕДАКТИРОВАТЬ: Другая идея … Вы могли бы пойти и написать оболочку для этой DLL, чтобы она возвращала правильные значения, и создать интерфейс, который работает с вашим модульным тестером, встроенным в вашу оболочку.

1

Другие решения

Других решений пока нет …

По вопросам рекламы ammmcru@yandex.ru
Adblock
detector