Jump to content

Easiest way to slave an Installer Build Spec version to an EXE version?


Recommended Posts

Here's what I want to do...

I have a LabVIEW project that I'm building into an EXE w/ Installer using the App Builder in the LabVIEW project environment. We've decidided to use the version number of the EXE (defined in the EXE build specification) as the definitive version of the software and let LabVIEW auto-increment the build number. The installer build specification has its own version number, which I want to be identical to the version number of the EXE (since, it doesn't make sense to have a version number for the installer that is different from the version number of the EXE). And, given that one important goal of software engineering is to have a fully automated build process (The Joel Test >> Test 2), I (passionately) dislike to have to manually sync the installer build spec version number with the executable build spec version number.

One feature that would address this need, is to be able to specify (in the installer build spec) that the installer's version number should be the same as the EXE's build number. However, I'm pretty sure that this isn't possible.

What I think I might do is create a VI that sits above the entire build process and syncs the two version numbers by reading and modifying the project (*.lvproj) file, before invoking a build on the build specifications, programmatically using <LV>\vi.lib\AppBuilder\BuildTargetBuildSpecification.vi.

Can anyone think of a better way to achieve my goal?

Thanks,

-Jim

Link to comment

QUOTE (Jim Kring @ Apr 9 2008, 08:38 PM)

Here's what I want to do...

Sorry Jim, I can't think of a way to help, but I sure support the goal. It should be user selectable on whether the exe version perpetuates to the installer, but I'd love a feature like this.

Link to comment

QUOTE (crelf @ Apr 11 2008, 08:06 AM)

Sorry Jim, I can't think of a way to help, but I sure support the goal. It should be user selectable on whether the exe version perpetuates to the installer, but I'd love a feature like this.

I second that. (Or third, or whatever.) I've noticed this issue, and although I don't need it often enough to have as strong of a desire to have it automated, I would certainly appreciate having a feature built-in to the Project Manager that would allow these versions to be synchronized.

DaveT

Link to comment
  • 4 weeks later...

QUOTE (Jim Kring @ Apr 9 2008, 05:38 PM)

The installer build specification has its own version number, which I want to be identical to the version number of the EXE (since, it doesn't make sense to have a version number for the installer that is different from the version number of the EXE).

I was just poking around trying to figure out the whole Labview versioning system and come up with a good scheme to keep track of applications. It suprised me the installer had it's own version number, but when I experimented with changing the numbers I couldn't find where the installer version number is used.

I also discovered the VI property History:Revision Number isn't available when built into an executable. It makes it a little difficult to correlate what I see on the dev screen with what I see in compiled applications.

Link to comment

QUOTE (Daklu @ May 8 2008, 03:39 PM)

It suprised me the installer had it's own version number, but when I experimented with changing the numbers I couldn't find where the installer version number is used.

The installer version is what's shown in the Add/Remove Programs list under the details dialog for an installed program. It's basically your installed program's version, as far as windows is concerned.

Link to comment

QUOTE (Jim Kring @ May 8 2008, 06:43 PM)

The installer version is what's shown in the Add/Remove Programs list under the details dialog for an installed program. It's basically your installed program's version, as far as windows is concerned.

My guess is that they didn't implement this automatic binding because installers can be used to install any number of applications from different Build Specifications, not just one. That might not be the most common use-case, but it's certainly possible. They'd have to somehow allow the user to specify what application's version takes priority, and maybe that opens a whole can of worms.

But I agree it'd be helpful!

Link to comment

QUOTE (ragglefrock @ May 9 2008, 10:46 PM)

My guess is that they didn't implement this automatic binding because installers can be used to install any number of applications from different Build Specifications, not just one. That might not be the most common use-case, but it's certainly possible. They'd have to somehow allow the user to specify what application's version takes priority, and maybe that opens a whole can of worms.

But I agree it'd be helpful!

Such a tool can be made quite easily, the scripting properties of the project return a lot of info about the builts inside a project, including a huge variant (debuggable with the Variant Browser) containing this info.

Ton

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.