Lukas -
Currently installers built by an NI Package Builder solution can include
(a) the last built version of a package in the solution,
(b) a package that is installed on the system building the package, or
(c) a top-level package included in an installer on disk.
As you noticed option (a) does not allow you to include a previously built version that is not the latest; the version and name of the last built package is included in the solution file when saved. Option (b) has a limitation that the installed package cannot be included if the solution is configured to build that package. Option (c) requires that the package be included in a previously built installer as a "top-level" product in the installer.
FWIW: Just letting you know this option but not recommending it; you can post process an installer and swap the newer package with the older package by editing the feed(s) it is in and the installer top-level reference. As an example, to fix the feed you could edit the Packages file in the feed directory of the installer as follows:
- nipkg feed-add-pkg "%CD% "..\..\pool\mycompany-myproduct_1.0.0.0_windows_x64.nipkg"
- nipkg feed-remove-pkg "%CD% "..\..\pool\mycompany-myproduct_1.0.0.1_windows_x64.nipkg"
Since the package is likely top-level, you would have to edit the ".\bin\suite.dat" file for the installer to change the 2 references to 1.0.0.1 to 1.0.0.0.
In the future we could make this easier by supporting something like the following, but these are not planned:
- Allow user to specify a specific version of the solution package to include, and the package would need to be still available on disk where the solution builds it.
- Allow user to reference a specific package on disk to include in an installer.
Hope this helps.
Scott Richardson
https://testeract.com
