VS add on Error

[danielweberdlc]

When compiling a project using 1.1.17 of the VS add on I get the warning:
"Build must be stopped before the project can be closed"

Disabling the add on removes the warning.

What I've found is that if the MocDirectory is ./Generated and the Rcc and Uic Directory are ./GeneratedFiles it will create this error condition. I made all the folder locations match and the problem went away.

Something to ponder on a slow day....

[danielweberdlc]

Looks like I spoke too soon - the error message is back. Apparently if the project actually has to build, then there is no warning. However, if the project is up to date, the warning appears. It also appears that the project file is being saved (the time stamp changes), even though the project is up to date.

This is with a solution with 6 interconnected projects (libraries, DLLs and executables).

Disabling the add on still gets rid of the problem.

This is only happening in one configuration of the build (the x86 CE6 build), while the other 2 configurations (ARM CE6 and Win32) have never shown the problem. I'm thinking there's some issue with my project or solution file I have yet to track down...

[danielweberdlc]

I've solved my VS add on problem. I'm building using a custom Qt build for a CE x86 device. When I compiled Qt, I entered the CE_ARCH as _X86_, which turns out is wrong. When I found the error, a co-worker I'm blaming everything on figured we could fool the Qt add on by just changing the value in the mkspec. turns out the add on is much smarter than us, and it was totally freaked out by some value it found in some file.

I'm not sure where exactly the add on was finding the value, but the solution was just to rebuild Qt using the correct value and now it all appears to be working. the only issue I ran into was that I had changed the MOC dir to not use the \$(ConfigurationName)" at the end, and the add on would keep excluding the moc files. Apparently there is a requirement to separate the debug versus release versions of the moc_xxx files.

All seems to be happy now, except for the fact that signal/slot performance sucks, for some reason - it makes the system very slow, but that's the subject for another thread...