Никто еще не ответил, поэтому я предоставлю то, что мы делаем в подобных ситуациях при отладке Ruby + SWIG.
Создайте проект Visual Studio, содержащий источник C #, сгенерированный SWIG, сгенерированный C ++SWIG, ваш модульный тест C # и остальная часть источника Quantlib.
Я только что просмотрел предоставленные Quantlib файлы решения Visual Studio и не вижу целей SWIG, что вызывает сожаление, но если у вас есть исходный код C ++ по крайней мере, и вы можете построить его в режиме отладки, вы можетепопасть.Сложность в том, что C # Dll, который вы вызываете, будет ожидать ссылки на определенную C ++ DLL в своих вызовах.Возможно, вам придется переместить библиотеку отладки C ++ Quantlib в папку Debug проекта C #, чтобы она нашла нужную версию.
После того, как вы настроили свое решение, соберите все как отладочную или Rel с помощью символов отладки.
Если в этот момент у вас есть источник привязок C # и источник Quantlib C ++ в одном и том же решении, вы сможете установить точку останова в любом месте C # или C ++ и иметь возможность проходить через вызовы изодин за другим.
С нашей ситуацией с SWIG для Ruby мы можем устанавливать точки останова в сгенерированном SWIG файле CXX или в исходном коде библиотеки C ++, который оборачивается swig, и выполнять вызовы, сделанные интерпретатором Ruby.Мы можем сделать это, запустив ruby из Visual Studio в качестве стартового проекта.
- Вероятно, это ключевой момент. Иметь DLL, которую вы хотите отлаживать, и приложение, которое загружает вашу DLL (даже если это с помощью вызова LoadLibrary, так какбудет из C # или из Ruby) в том же решении.Тогда Visual Studio будет соблюдать ваши точки останова в отлаженной DLL.Если точки останова не соблюдаются, вам может потребоваться использовать procxp от Microsoft, чтобы увидеть, какая DLL загружена, и если библиотека C # находит другую версию библиотеки C ++, чем вы хотите.
Я надеюсь, что эта информация поможет вам.