Every build of LV ActiveX server Application gets NEW CLS-ID

Question

English translation of this thread? Scroll down!
Problembeschreibung – kurz
Es entstehen unterschiedliche CLS-ID’s für dieselben LV-Applikation die mit Application Builder und Option „Enable ActiveX server“ auf unterschiedlichen PCs kompiliert wird.
Fragen:
1) Wie kann man die Vergabe einer neuen CLS-ID vermeiden wenn eine Applikation nicht zum ersten mal übersetzt wird?
2) Kann man die Verwendung einer eigenen CLS-ID erzwingen?
Problembeschreibung – detailliert
1) Es gibt zwei Entwicklungssysteme (PC 1, PC 2) mit derselben LV 7.1 Entwicklungsumgebung.
2) Es gibt eine LV-Applikation „duck16“, die wie beschrieben auf beiden Rechnern kompiliert wird:
 * Erstes Kompilat - auf PC 1
 * Dann Übernahme der Quellen auf PC 2 (über Visual SourceSafe)
 * Zweites Kompilat - auf PC 2
 * Dann wieder Übernahme der Quellen auf PC 1 (über Dateien kopieren)
 * Drittes Kompilat - auf PC 1
3) Die Kompilierung erfolgt immer mit Application Builder und der Option „Enable ActiveX Server“
4) Es entstehen bei jeder Kompilierung die TypeLibrary mit 2 Proc-IDs und zugehörigen CLS-IDs:
 * duck16.Application
 * duck16.Application.7
5) Fehler 1: Die CLS-ID vom zweiten Kompilat ist anders als die vom ersten
6) Fehler 2: Die CLS-ID vom dritten Kompilat ist dieselbe wie vom zweiten – aber anders als die des ersten, welches ja auf demselben Rechner entstanden ist!
Problem – in brief
Compiling the same LV application on two different PCs brings out two different CLS-IDs using Application Builder and option “Enable ActiveX server”
Questions:
1) How to avoid that LV creates a new CLS-ID during a build that is not the first build?
2) Is it possible to force LV to use a defined CLS-ID?
Problem - in detail
1) There are two development PCs (PC 1, PC 2) having the same version of LabView installed (V7.1)
2) There is one LV application “duck16” that is compiled on both systems as described:
 * First build - on PC 1
 * Check out the applications sources on PC 2 via Visual SourceSafe
 * Second build – on PC 2
 * Copy the applications sources back to PC 1
 * Third build – on PC 1
3) We always use Application Builder and option “Enable ActiveX server” on both systems
4) Every build creates a Typelibrary with two Proc-IDs and CLS-IDs:
 * duck16.Application
 * duck16.Application.7
5) Error 1: CLS-IDs of first and second build are different.
6) Error 2: CLS-ID of build three is the same as of build two – but different as of build one (of same PC!)
Beste Grüße,
Oliver Thost.

Answer 1

You are correct that the .bld file is not the only place were the CLSIDs are 'stored'.  The EXE itself contains the CLSIDs.  The way App Builder works is initially the CLSID information is empty.  When you check the 'Enable ActiveX Server' box the information is still empty, even if you save the .bld file.  The first time you build with the box checked the App Builder will generate the CLSIDs for the exe and store them in the EXE.  The bld script will also store the CLSIDs _if_ the user saves the .bld file after building.  After that initial creation the CLSIDs are loaded from the .bld script and passed to the function that generates the exe.  The function will also read them from the EXE, the ones stored in the EXE override the ones from the .bld script, so if there is no EXE or it wasn't built with ActiveX turned on then the ones from the .bld script will be used.
So if the user wants to use the same CLSIDs for a given exe in different LabVIEWs or different machines, then they need to check the box, build the exe and save the .bld script after building.  Then they can use that .bld in the other locations as long as they don't have an exe in the build location in the new copy of LabVIEW before building (otherwise the CLSIDs will be read from the exe).
If the user wants to clear the CLSID for a .bld file and exe, they need to uncheck the Enable ActiveX Server box and recheck it and save the .bld script and delete the exe that has been built.  Then new CLSIDs will be generated for the exe.
Hope this helps,
Rebecca Fox, AE, Germany
Rebecca Fox
Applications Engineer
National Instruments