build specifications best practice

[Bob_Preis]

---

@Yamaeda wrote:

There's no use to have separate Installer_v2.6 and 2.7 and so on as you have in the first post, when building the installer it'll use the current files anyway ...

Thus:

1 Application

1 Application installer

1 Application and RTE-installer

/Y

---

I would just like to second what was said here. It seems like no one questioned the premise of the discussion, which was that you need brand new build specs for your App and your Installer every time you decide to patch. Why not rebuild the App and Installer with a new version number (auto-incremented)? Installing the same installer with a new version number will replace the files installed by the older installer, which is what it seems like you're trying to accomplish.

Are you needing to keep a record of all the versions of your App and Installer ever created? Trying to understand where that need originated from.

[ChrisReed]

Yes that's right Bob,

Each time I make a new EXECUTABLE I want to create a new entry in the LVProject Build Specifications.  The reasons are

1) For QA documentation and control purposes.

2) Allows us to go back to a previous versions very easily.

However I seem to have a dilemma with the Application Installer (AI) part.

1) If I want to keep separate AI's for the above two reasons (as in the first image of my first post), then each new AI will add another entry to the Add/Remove Programs List and I don't want that.

2) If I use just one generic AI (as in the second image of my first post) then great it only adds one entry to the Add/Remove List, but now the Installer will only be for the latest Executable and so I would have to build it again if I wanted to go back a version and you lose some QA documentation.

I haven't tried it yet, but I'm assuming I can create separate AI's and then copy the {Upgrade Code} from the first AI version to all subsequent versions.

Chris

[Bob_Preis]

Understood. Yes, copy the upgrade code and that should solve the AI dilemma.

If the built output were archived into separate folders based on version number, would that be sufficient for reasons 1 & 2? Or do you need the build specification archived, too?

We are investigating archived built output as a feature for the Installer Builder and App Builder, which is why I ask.

[ChrisReed]

Yes I like the idea of having an archive option.  I assume this allows you to put the Executable and Installer Build entries into a Folder called say Version_2.6 or something.

Chris

[Bob_Preis]

Yes, it would be something along those lines, except the installer and app would be archived into separate folders as they would need to account for the possibility of having been built a different number of times or having different version numbers.

[Norbert_B]

---

@dan_u wrote:

I also wonder about the upgrade code. Would you use the same code for framework installer and application installer? If so, wouldn't the application installer remove the framework again?

When using different upgrade codes the user will have 2 entries in the control panel > add/remove software. In that case I how would installing a new framework deal with the files modified by another installer (the exe installer)?

Also, will uninstalling both "products" leave a clean system (independent of the uninstallation order)? 

---

No, the installers must have different upgrade codes, otherwise, it would mess up the point 😉
Since i do not likely try to get rid of framework components on my systems, i don't know if the system is really clean once uninstalling both "installer packages". Never tried it.

To be specific on the framework installer:

MSI supports collecting installation packages into a single installer by "merge modules". So the framework installer only merges the installer packages of LV RTE and selected NI drivers into an easy to use (and provide) base installation of NI components. This is btw similar (but not same) to the procedure when installing the LabVIEW Developer Suite.

The application installer must not be coupled to the framework installer. So the both installers must not contain the same components (LV RTE, driver, ...).

Norbert

[John_P1]

Great thread by the way (sorry to bring it back up again, this is my first time seeing it though).  

Each time I make a new EXECUTABLE I want to create a new entry in the LVProject Build Specifications.  The reasons are

1) For QA documentation and control purposes.

2) Allows us to go back to a previous versions very easily.

What I do for this is use SVN (I picked TortoiseSVN somewhat randomly but it seems to work well for me as an SVN client) and keep my project in the same working directory as the source VIs.  I build my application using a simple build utility VI (outside the scope of the project but also in the same working directory) that makes SVN command line calls to ensure that the entire working directory is at a consistent version, then builds the application through LabVIEW's App Builder API.  This has the nice benefit that if I update the build spec OR the source code (OR the build utility itself) and want to go back to an earlier version, everything is going to be consistent with how it was built in the first place.  The build VI also pulls in the revision from SVN and writes to the build ID parameter of the application (there isn't a great built-in way to do this, you just have to programmatically edit the lvproj file which is really just an xml document).  So for example, when I revert my SVN branch to revision 321, then run the build utility, I end up with an exe (version 2.0.0.321) that was built on the same source code and build spec that went into build 321 in the first place.  Built shipping releases are kept in a separate directory, but I always have the capability of re-building any revision from scratch if necessary.

I came across this thread because I wasn't completely decided on how I should go about including LV installers (DAQmx Core, VISA Runtime, LVRTE), but I think after reading I will make a separate framework installer like Norbert mentioned.  The application readme will document which version of the framework it has been tested with.

Best Regards,