Symbian SIS QA failed for wrong UID

I've received a QA failure since the QA team detected a wrong UID for the Symbian SIS file I've submitted. Specifically, they've detected the UID I'm currently using during development, even if I've changed that before re-building it for publishing.

To avoid further similar errors, I've got some questions:

1) is there any tools that I can use to check that a SIS file only uses and contains the required UID? I've tried SISContents ([url]http://symbiandev.cdtools.net/[/url]) but could not find any trace of the wrong UID in both SIS files (the app one and the installer one).

2) in Qt Creator, when switching from dev profile (dev UID + self signing + no smart installer) to publish profile (Nokia provided UID + no signing + smart installer) is it always necessary to perform a full clean of the project before building?

3) in my experience, cleaning a project (Symbian target) literally takes a lot of time (almost a minute). Is that normal, or could that be due to some wrong config settings in my environment? Any way to have it perform quicker?

Thanks,
Pit

1) dumpsis.exe can extract the contents of a .sis/x file, and elftran/petran can show the UID-s inside the binaries ([B]petran -dump s your.exe[/B] for a shorter, and [B]petran -dump h your.exe[/B] for a longer output)
2) when Symbian tools are involved it is always a good idea to do a complete clean prior to release builds. You may event want to dig into the toolchain and remove temporary files, "traditional" Symbian C++ SDK-s create a "BUILD" folder in their epoc32 folder, and mirror project locations there, dumping a large amount of auxiliary files there, including a pre-processed file containing the UID-s. If that file does not get refreshed for any reason, the old UID-s will be in the binary file. So it is a good idea to delete these temporary files from time to time (assuming that they exist in the Qt SDK too)
3) if the above mentioned location and files exist, deleting them is probably faster than a toolchain-driven 'clean', however it may require some experimenting first, since the actual output files are elsewhere, and may require explicit deletion too

Note that you can use the 'official' UID right from the start, that is why the developer certificate is provided: it enables you to sign files with your own 'official' UID-s at home.

Thank you for the hints wizard!

Using the dev cert is one of the things I've always known but never done.. guess I have to start to ease my dev life :)