Оказалось, что когда мой коллега сделал порт Qt, он воссоздал некоторые файлы проекта Visual Studio, в результате чего у них были разные GUID для оригиналов. Когда я переключился на порт Qt, идентификаторы GUID не совпадали с тем, что проекты C # указывали как зависимости. Visual Studio немного не справляется с этим (или говорит вам), поэтому вы получаете ошибки, перечисленные выше.
Как только мы исправили это, сборка работала нормально, но при запуске она ничего не делала - DLL C ++ никогда не отвечали. В конце концов я понял, что для того, чтобы таймеры и очереди Qt работали, нам пришлось вызывать QCoreApplication внутри DLL, поскольку мы не использовали интерфейс Qt. Однако, поскольку были некоторые пользовательские интерфейсы Qt, в которых использовались одни и те же библиотеки DLL, мы не всегда могли вызывать QCoreApplication в случае, если пользовательский интерфейс уже вызвал QApplication. Вы можете использовать QCoreApplication :: instance (), чтобы проверить, требуется ли вызов, но вы не можете сделать это в DllMain () для DLL_PROCESS_ATTACH, потому что, во-первых, это слишком рано, а во-вторых, это зависит от Windows. Итак, мы придумали это:
static struct Vars
{
QCoreApplication *l_pQt;
bool l_bQtCoreCreated;
Vars()
: l_pQt(NULL), l_bQtCoreCreated(false)
{
}
virtual ~Vars()
{
if (l_pQt != NULL)
{
if (l_bQtCoreCreated)
{
delete l_pQt;
}
l_pQt = NULL;
l_bQtCoreCreated = false;
}
}
} g_private;
static void InitQtCore(void)
{
if (g_private.l_pQt == NULL)
{
g_private.l_pQt = QCoreApplication::instance();
if (g_private.l_pQt == NULL)
{
g_private.l_bQtCoreCreated = true;
int argc = 0;
char *argv = NULL;
g_private.l_pQt = new QCoreApplication(argc, &argv);
}
}
}
Любая функция в DLL, которая не является просто базовой установкой, вызывает InitQtCore () при запуске. Это прекрасно работает для интерфейсов Qt и не-Qt (C # и C ++).