Hello Andre,
First of all, I apologize for the delayed reply.
When we create a new "release" build for an app, we keep a copy of all built files in a network share, where the folder path itself includes identifying information for the release, including the version string: "\\network\builds\[brand]\[product]\[version]\".
Keeping track of the released builds is a really good practice.
Each time I build a new installer package, I end up copying the contents of the new release folder into the AI project folder, then update any required installer settings, bump the version number and build. This process does get rather time consuming when I have multiple setup packages to build, but I'm pretty sure this is a case of me simply not using the most appropriate workflow here.
I think that, given your scenario, you may find useful having a look over our
"Working with Synchronized Folders" article. The Synchronized Folders functionality from Advanced Installer allows you to create a synchronization link between a folder located on you hard-drive and one created in your project. This means that every time a project is open, built or you press the [ Refresh ] button in the
"Files and Folders" page, the content of that folder is synchronized to the content of the source folder on disk.
Any modification made to the source folder on the disk will also be made to the synchronized folder in your project. For example, if you add some files in the source folder on the disk they will be added automatically to the synchronized folder in your project.
Quick note for later on: Synchronized folders shouldn't be used in patches because they might generate new components when their content is re-added to the project.
In what regards the Product Version manual update, you can try to set the file version from a file. To retrieve the Product Version from a file (EXE file for example), right-click in the edit box and select the
“Set version from file...” menu item. This will allow you to select a file from Files and Folders page. You can change the source file by clicking the [ ... ] button in the edit box.
The version must be contained by the file metadata, not as a string in a text file.
You can revert to a simple string value by right-clicking in the edit box and selecting the
“Set version to string value” menu item.
Should I spend some time investigating AI's CLI tool for this?
Advanced Installer CLI tool can be really helpful if you plan to automate some of the processes. This may reduce the time consumed during the setup creation process considerably. For more information about Advanced Installer CLI tool, you can have a look on the following article:
https://www.advancedinstaller.com/user- ... -line.html
Should I rather try create a new project for each release (perhaps from a template)?
The
"Save as Template" option is very useful when you already created a project with many configurations and want to duplicate it for creating another similar project. All information and settings in the template will be added to the new project, except for all the GUIDs which will be changed. This way, the resulted package will be seen as a completely different package compared to other packages created from the same template.
Should I store the ".aip" file with source code, copy it as part of the build and try script the creation of an installer from a "known folder structure"?
I am not sure what you mean by this. Could you please give me some more details (maybe exemplify)?
Is there some secret magic tool that will just do my work for me??
I am afraid that I am not aware of any "magic" tool that will do the work for you.
If I've got version 1.0.0 already released (we follow SemVer here) and we do a feature release as 1.1.0, what should I do to have both a full setup package for a fresh install of 1.1.0 and a smaller patch setup to upgrade from 1.0.0 to 1.1.0?
- A major upgrade actually means the uninstallation of the old product and the installation of the new product. Its main advantage is the fact that it can act as both an upgrade and a first-time-install.
- A patch actually means the diffs between two versions of the same product. Its main advantage is the fact that it is much smaller than an upgrade (memory wise), but it can not be installed as long as the previous version is not installed on the target machine (it can not act as a first-time-install).
The
ProductCode property is a unique GUID used to identify your application. This identifier varies from version to version or between different languages of the same installer. You can check this first hand from Advanced Installer by going to
Project->Options->Project IDs
If, for example, you want to create a major upgrade but you do not change the "ProductCode" when changing the "ProductVersion", you will be prompted the following message upon trying to install your new version:
Another version of this product is already installed. Installation of this version cannot continue. To configure or remove the existing version of this product, use Programs and Features in the Control Panel.
In what regards the patch, it is quite the opposite. Since the patch means only the diffs between two products and since it can not act as a first-time-install, it needs to "attach" to an already existing (and installed) product. How does it do that? It's pretty simple, through the "ProductCode". This is why you are being asked to keep the same
"ProductCode" upon changing the version from the
"Product Details" page (if you plan to create patches).
Hope this helps.
All the best,
Catalin
