Hi,
I'm using InstallAware 8 to create installers for our product. In addition to this, our product is being sold as a "rebranded" product by other vendors. What this
means is basically new name and graphics. This of course means a separate installer. I'd like to hear some opinions on the best way to do this.
What I want is a simple way to build several installer packages which are pretty much identical except for the following things:
most of the stuff in the project settings dialog (product name, product code, company name, output filename etc.) shortcuts, dialog graphics (the dialogs would be the same except some logo images) and icons.
The files that go in it should be slightly different between them but changing that is something I can easily do with our build scripts (unless of course you have some even better suggestion).
My first idea was to use compiler variables for things like company name. This didn't work since I couldn't use variables for the shortcuts.
My second idea was separate project files for each rebrand. This turns out to be quite the hassle because I want the script to be the same except for the things mentioned above. I still think that this route is the way to go though but I think I need some guidance into making it work more smoothly.
If I go the second route it seems I'd have to make a conditional statement everywhere there is any difference that cannot be handled by variables. This I guess would be the shortcuts and every time I wish to open a dialog? This isn't all that appealing really.
Anyone doing something like this and have suggestions on how to handle this smoothly?
Thanks,
Erik
Rebranding the installer packages
-
MichaelNesmith
- Posts: 3452
- Joined: Thu Dec 22, 2005 7:17 pm
- Contact:
Compiler Variables aren't Script Variables, and you may use them in Create Shortcut, or any other place which accepts only string literals.
Everything should work just great with Compiler Variables, the only issue is bitmaps in dialogs. I would suggest that you add each bitmap to your dialog, and show/hide them at runtime based on the value of a script variable, which is set to a compiler variable at build time (compiler variables do not resolve on dialogs, otherwise you could have done that too).
This way, you get to maintain just one setup project for everybody!
Everything should work just great with Compiler Variables, the only issue is bitmaps in dialogs. I would suggest that you add each bitmap to your dialog, and show/hide them at runtime based on the value of a script variable, which is set to a compiler variable at build time (compiler variables do not resolve on dialogs, otherwise you could have done that too).
This way, you get to maintain just one setup project for everybody!
Michael Nesmith
Install[b]Aware[/b]
[i]Home of The Next Generation MSI Installer[/i]
Get your free copy today - http://www.installaware.com/
Install[b]Aware[/b]
[i]Home of The Next Generation MSI Installer[/i]
Get your free copy today - http://www.installaware.com/
Thank you for your suggestions. I'd given the compiler variable method a try before but experienced some problems with it but I'll give it another shot. I had some issues of getting shortcuts called #PRODUCTNAME# and such but maybe that was just a fluke, it seems to be working now.
There are two more issues that have come up related to the rebranding and I was wondering if anyone had any good suggestions on how to handle them?
First of all, the EULA. Today I have a rich text control in one of the dialog boxes which is set to receive its text from the EULA as added in the "EULA and ReadMe" screen. If I want to be able to switch this out, how would I go about doing this in the best way? It will need to be available in several translations as well. Keeping it as a rich text control is not absolutely necessary but some basic formatting (bolding text, different font sizes) needs to be there.
Second of all, I have a small application that is run to perform some small task during the installation. I've put this in the support files since I want to run it before any files are actually installed (as well as after so it's actually installed to the program files directory too). The problem is that for reasons out of my control, this little application has our company name in its title and that's no good for rebrands. This file will not be used (nor installed) by any rebranded versions apart from our own so it won't leave the temporary folder so it's not a huge deal but is it possible to selectively leave something out of the support files like this?
There are two more issues that have come up related to the rebranding and I was wondering if anyone had any good suggestions on how to handle them?
First of all, the EULA. Today I have a rich text control in one of the dialog boxes which is set to receive its text from the EULA as added in the "EULA and ReadMe" screen. If I want to be able to switch this out, how would I go about doing this in the best way? It will need to be available in several translations as well. Keeping it as a rich text control is not absolutely necessary but some basic formatting (bolding text, different font sizes) needs to be there.
Second of all, I have a small application that is run to perform some small task during the installation. I've put this in the support files since I want to run it before any files are actually installed (as well as after so it's actually installed to the program files directory too). The problem is that for reasons out of my control, this little application has our company name in its title and that's no good for rebrands. This file will not be used (nor installed) by any rebranded versions apart from our own so it won't leave the temporary folder so it's not a huge deal but is it possible to selectively leave something out of the support files like this?