Оказалось, что когда мой коллега сделал порт Qt, он воссоздал некоторые из файлов проекта Visual Studio, в результате чего у них были разные идентификаторы GUID для оригиналов. Когда я переключился на Qt-порт, GUID не совпадали с тем, что были показаны в проектах C# в качестве зависимостей. Visual Studio немного дерьмо при обработке этого (или говорит вам), поэтому вы получаете ошибки, перечисленные выше.
Как только мы исправили это, сборка работала нормально, но работала она ничего не делала - библиотеки C++ DLL никогда не отвечали. В конце концов я понял, что для того, чтобы таймеры Qt и очереди работали, нам пришлось вызывать QCoreApplication внутри DLL, так как мы не использовали Qt UI. Однако, поскольку были некоторые пользовательские интерфейсы 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 UI (C# и C++).