Qt Quick in Visual Studio 2022 build errors and assertion throw

MansenC

Good day everyone, I'm here with an interesting issue. I have written a project using Qt Quick and QML in the Qt Creator 7.0.0 until I was required to convert it into a Visual Studio project using the Qt VS Tools extension. Unfortunately I encountered several issues in this process. First of all, here are my specs: I'm running Windows 11 64-bit with Qt 6.2.4 and Visual Studio 22 with the latest Qt VS Tools extension version. Now to my issue:

I tested the first issue with a newly created qt quick project which I simply converted using the extension and a freshly installed Visual Studio instance. Building the project would not work due to the file qrc_qmake_qmake_immediate.cpp being generated twice apparently. This resulted in the error that the compiler generated file could not be opened since it was already in use by the compiler. This seems odd to me since it's a clean project with a clean install of everything and I cannot imagine that I'm the first converting a project using Visual Studio 2022 and its associated extension since there is no bug report of this whatsoever. Can someone help clarify this? I appended the following lines to my .pro file:

release: DESTDIR = build/release
debug:   DESTDIR = build/debug

OBJECTS_DIR = $$DESTDIR/.obj
MOC_DIR = $$DESTDIR/.moc
RCC_DIR = $$DESTDIR/.qrc
UI_DIR = $$DESTDIR/.ui

The first rebuild using Visual Studio, the same error will appear. However every subsequent build of the project will simply throw a warning and continue the build as if nothing every happened, happily completing the build without issues. After that, the application simply runs.

My second issue is related to my project and I'm not quite sure how, though I haven't found any related information so far. When starting my project in Debug mode, on the call of QQmlApplicationEngine::load I consistently get an assetion error thrown:

Affected dll: Qt6Cored.dll
Module 6.2.4
File qqmlpropertydata_p.h:284
Assert: idx != m_coreIndex

The annoying thing is that this assert is completely ignorable and the application runs just fine after ignoring it, the call stack exists only out of calls made from the Qt dlls (probably means the assert is thrown in a non-main thread) and I can't even disable the assert message (which is a bad way to deal with it anyways but there's literally 0 information on this issue out there) using _CrtSetReportMode since it seems to be ignored anyways. The even more frustrating thing is that I cannot properly isolate this issue from my project.

I hope someone kind enough can help me figure out where to either report or how to fix these incredibly frustrating issues that I have to work with here, thank you in advance.

JKSH

Hi, and welcome! Thank you for your detailed reports.

@MansenC said in Qt Quick in Visual Studio 2022 build errors and assertion throw:

I appended the following lines to my .pro file:
release: DESTDIR = build/release
debug: DESTDIR = build/debug

OBJECTS_DIR = $$DESTDIR/.obj
MOC_DIR = $$DESTDIR/.moc
RCC_DIR = $$DESTDIR/.qrc
UI_DIR = $$DESTDIR/.ui

These should not be necessary, and might be the reason for your double-ups. What's the purpose of adding these lines?

My second issue is related to my project and I'm not quite sure how, though I haven't found any related information so far. When starting my project in Debug mode, on the call of QQmlApplicationEngine::load I consistently get an assetion error thrown:

Affected dll: Qt6Cored.dll

Module 6.2.4

File qqmlpropertydata_p.h:284

Assert: idx != m_coreIndex

The annoying thing is that this assert is completely ignorable and the application runs just fine after ignoring it, the call stack exists only out of calls made from the Qt dlls (probably means the assert is thrown in a non-main thread)

The fact that an assertion occurs likely indicates that something has gone wrong, or an assumption has been violated. So I wouldn't simply dismiss it as an annoyance.

Does the assertion occur with a very basic "hello world" Qt Quick project?

MansenC

Good morning, thank your for your reply.

These should not be necessary, and might be the reason for your double-ups. What's the purpose of adding these lines?

The double-ups are in fact happening on a new project without these lines. However, adding these will allow me to build the project again so that it compiles on the second try. That is really scary and sounds extremely fragile, so I'm hoping for a solution. The purpose for these lines was to deparate the build output in Qt Creator into a debug and release folder, thinking it would affect the migration to a Visual Studio project in some manner since it looked like the Qt VS Tools project was trying to RCC in both debug and release mode even though I have the Debug x64 configuration selected. There was no way to suppress this behavior and only RCC debug files. As a short follow-up after writing this paragraph, here's a description of this issue:

The build might fail in the first place since it searches for *.qm files in the /release output folder when building in debug mode
Starting a build and letting it fail in release mode fixes this issue
Restarting the build in debug mode will display the following warning C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.CppBuild.targets(514,5): warning MSB8028: The intermediate directory (build\debug\.obj\) contains files shared from another project (Hydra.Frontend.vcxproj). This can lead to incorrect clean and rebuild behavior.
After that it will fail with the following errors: 1>\Hydra.Frontend\build\Debug\.qrc\qrc_qmake_qmake_qm_files.cpp : fatal error C1083: Cannot open compiler generated file: '\Hydra.Frontend\build\debug\.obj\qrc_qmake_qmake_qm_files.obj': Permission denied \Hydra.Frontend\build\Debug\.qrc\qrc_qmake_qmake_immediate.cpp : fatal error C1083: Cannot open compiler generated file: '\Hydra.Frontend\build\debug\.obj\qrc_qmake_qmake_immediate.obj': Permission denied
Building again fixes this issue if and only if the lines added to the project file were present.

The fact that an assertion occurs likely indicates that something has gone wrong, or an assumption has been violated. So I wouldn't simply dismiss it as an annoyance.

Does the assertion occur with a very basic "hello world" Qt Quick project?

It does in fact not. Though since it happens in the call of creating a window and appears to be thrown on a separate thread and I was so far unable to isolate the issue I feared it would become a time sink. So, how about overcoming fear, I'm gonna investigate this issue further and will follow up with a resolution or perhaps a more detailed description.

Update 1) The issue is related to my QML Code/Native registered components
Update 2) Found the root cause for the assertion. I have a QML component that defines the following two properties:

property bool isToggle: false
property bool toggled: false

If any of the two properties is named differently then the assertation is not triggered. This seems extremely weird to me and looks to me like unwanted behavior