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