CVI 8 Distributions - controlling GUIDs?

[Ian.W]

I have to create two builds (call them "full" and "basic") of the same app. They differ in that one has a reduced feature set, they include different data files, and they differ in the shortcuts I want installed. And ... they go by the same app version number. Further, I only want one of them to exist at any time on a PC.

In CVI 6-7.1 I could make the two distribution kits from the same (albeit slightly altered) project, and they would have the same GUIDs. Therefore only one could exist on a PC at any time. The hassle was that I had to edit the Distribution Kit settings for each build (i.e. include or omit files); the nice thing was that it achieved the desired result.

With CVI 8 it seems that each distribution I create gets a unique GUID, meaning that if I install both on the same PC they co-exist, share the app files, rather then replacing one another. And if any app files are altered between the "full" and the "basic" installation kit, only the most recently installed version of that file exists.

Is there a way to make the GUIDs the same to get this replacement behavior? (I'm hoping to avoid poking around with Orca)

Or is there a better way to achive my goal? I get the feeling I may need to alter my approach ...

Thanks in advance,
Ian

[Mert_A.]

Hello Ian,

Normally, to have two mutually exclusive flavors of a distribution, you would leave them with different upgrade code GUIDs, then use the Upgrade table with custom actions to halt the install or perform an upgrade depending on whether a particular version of the other flavor was found on the system.  However, CVI does not provide this advanced functionality, and going this route (at this point) would require quite a bit of poking around with Orca.

Your best bet is to do exactly what you said: use the same upgrade code.  If you open your .cds file in a text editor, you'll see a "GUID" attribute on the "msi" item near the top of the file.  This is the upgrade code you're interested in.  You can manually copy and paste this GUID from one .cds file to the other.  Or if you prefer, just copy the entire .cds file, rename the copy, add the copy and the original to your workspace, and edit to your liking.

Keep in mind that with the same upgrade code, both flavors will be treated as the exact same thing.  This means that if you keep the installer versions the same, your basic flavor will install right over the full flavor (and vice versa).  It might be preferable to always keep the full flavor one step ahead of the basic; that is, when you rev your distributions, make your basic one version x.0.0 and your full one x.1.0 or x.0.1.  If you keep the version of the full flavor higher, it will never be "upgraded" by your basic flavor.

If you have suggestions about distribution features that would make your life easier, we would love to hear them.

Hope this helps.

Mert A.
National Instruments

[Ian.W]

Thanks Mert - that definitely helps.   It also leads me right into all those version numbers! 

Let me see if I have it right: Those installer version numbers are fully independent of the version number for the target that is built (e.g. myapp.exe). But the upgrade behavior of distribution kits that share the same GUID is dependent on those installer version numbers as you describe.

Setting aside my "flavor" issues in the earlier post, is there a standard best-practice in the relationship between app version numbers and installer version numbers?   I imagine there are some dominant version-numbering practices/scenarios that guided NI's design of CVI 8's management of distributions.

Thanks,

Ian

P.S. For those willing to read more, here's my example: if my application is seen by users as version 4.2.2, what should I do for the installer version numbers, particularly as I release 4.2.3 , 4.3.0, 5.0.0, etc.?   Right now I'm making the application title "MyApp 4.2.2" so the version number appears in the Add/Remove Programs list. But then the installation process title bar says "MyApp 4.2.2 a.b.c Installer" where a.b.c is the installer version. A bit confusing.

It seems I'm being steered toward calling my app "MyApp 4.2" as the main customer-visible name. My application title is then simply "MyApp", and I set the first two digits of the installer version to match - i.e. 4.2. Then I just let the last digit auto-increment. And all version number info on the installed .exe is available via the Add/Remove Programs "click here for support info" link. Is this a standard/good way to do things?

[Mert_A.]

Hi Ian,

You should think of your installer version as the version of your release.  This version will ensure that older releases cannot be installed over newer ones.  The file version should be treated as just that -- the version of a particular component file.  It is used by the installer to make sure a newer file is not overwritten by an older file.  Imagine that you have mutiple products packages (that you develop and release independently of each other) which contain a shared utility.  The file version of that shared utility would be used to decide whether a particular installation package replaces the existing file.  Consider this scenario: A customer installs the newest release of product A, which ships with Utility version 1.5.0.  The customer then installs a release of product B, which includes Utility version 1.2.0, but the Utility file does not install, because a higher version already exists.*

The fact is, if every installer that includes your app file has the same upgrade code GUID, the file version is not that critical.  It is only important that a newer version of your installer should not contain a lower version of your application file.  Your installer version needs to change every time you release to customers, but it may also be helpful to bump everytime you re-build your installer if you do development testing with your installed distributions.  As far as how you title your application, it is up to you.  If you want the version to appear in the Add/Remove Programs table, you should make the version part of the name (like "MyApp 4.2"), but as you said, this has the drawback of putting the version in the title bar twice.

For your purposes, you may want to go with names like "MyApp 4.2 Basic" and "MyApp 4.2" with installer versions of 4.2.0 and 4.2.1, respectively.  The versions of your application file can be the same in each one (4.2.0) without consequence.  Ensuring that the build number (third part of the version number) is higher in your full distribution will ensure it is never replaced by the basic distribution.

I hope this helps you.

Mert A.
National Instruments

*There are a few CVI-specific caveats about uninstallation in this case.

[Ian.W]

Thanks yet again, Mert.   I really appreciate the effort and detail in your answers.

--Ian

[Dubin]

Hello,

how can i get the version number (major, minor and revision) until the runtime.

The logfile of my program must have the current version number of the program eg 2.3.1

I must know, wich version of my program has generated the logfile.

I cant find any makro wich contains this information. Is there an makro like this _CVI_ DEBUG_ ???

How can i solve this problem?

[Ian.W]

I think this thread will describe what you need.

[Dubin]

Great!

Thanks a lot!