17 replies to this topic

[installer96]

I have types of builds of same program (development, beta, sprint review, and release)

 

The build's contents are identical, and their installations are very similar other than their names and a few registry properties.

 

They must be able to be installed concurrently, i.e. they must have different product and upgrade codes, and different installation and registry key paths.

 

I want to have different packages for each of these versions.

 

I've looked at configuring multiple instances of the same program (http://helpnet.installshield.com/installshield22helplib/helplibrary/MultipleInst-Config.htm) but that seems like it could be quite confusing to the end user.

 

I've also tried setting different product/upgrade codes from IsCmdBld.exe depending on the build type, along with passing a property that tells what type of build it is. A javascript file called by the ism then sets the install directory and registry values according that build type property. This seems quite inelegant and I'm running into issues.

 

Can anyone point me in the right direction?

[deramor]

Assuming your file paths don't change for each type, you can do:

1. Make sure any major upgrade items are set to "Sharing my upgrade code.

2. Maintain a static list of upgrade codes for each type of release.

3. Before building each release, you can use the automation interface to change/update the property.

In VB:

Set objInst = CreateObject("ISWiAuto22.ISWiProject")

This uses IS 2015 SAB

 

objInst.OpenProject <your ism file>, false

objInst.UpgradeCode = Your saved upgrade code

 

You can also set package and product codes in the same way.

objInst.PackageCode = some GUID

objInst.ProjectCode = another GUID

 

Save and close

objInst.SaveProject
objInst.CloseProject

 

To generate a guid:

Set TypeLib_project = CreateObject("Scriptlet.TypeLib")

TypeLib_project.GUID  <---- the GUID you can use

 

If you need to change registry keys between configs, you can set up Release flags in your release configurations.  It can include and exclude features based on the release you are building.  Each feature can have your unique registry values.

 

You will also need to have unique INSTALLDIR between all 3.

Again you can use the automation interface

objInst.INSTALLDIR = some path

 

Shortcuts are more complicated in case you need to change these too.

If you have your shortcuts' target all based from INSTALLDIR, the shortcuts will all work.

However the root folder typically isn't dependent on the INSTALLDIR.

For that, you need to change the String table entry.  You will need some synchronization between your project file and the script making these changes.

It is possible to not know ahead of time the string entry to edit but that makes things much more complicated (and I don't have an example )

 

for each entry in ism_project.ISWiLanguages(1).ISWiStringEntries
    if entry.ID = "ID_STRINGTABLE_ENTRY" then
        entry.Value = "Your new text"
    end if
    
next

[installer96]

Thanks for the quick reply.

The different build types do have different INSTALLDIRs. And different folders for saved data, etc.

I'm not sure I understand the automation interface-- you just run a vb script and if installshield is installed on the machine, you can create those objects?
So if not build process is in an msbuild file, I'd run a vb script to make the changes, then execute IsCmdBld?

[deramor]

Yes.  If you have Installshield installed, you should have access to the automation interface. Some install options when installing the SAB might not install the interface.  I don't believe it is part of the "Typlical" install for the SAB.

 

Note that the interface object changes version with each Installshield release.  The one in the example is for 2015.  You can count down (or up) by 1 to get to your installed version.  To find it manually, you can: open regedit, navigate to HKCR\CLSID and search for ISWiProject.  You will find all the project interfaces you have installed.  If you find none, you have none installed.  Likely because the Typical install options for Installshield SAB don't include it.

 

I don't use MSBuild to run my entire build.  I only use it to compile Visual Studio solutions so I can;t help you there.  You should be able to run some script.  Also you don't need to do this in VB.  You can use any language that can create a COM object.

[installer96]

Hm... well a large part of the reason we're redoing the installers is to eliminate any external scripts and do everything in the InstallShield GUI, in our existing Basic MSI project. Is the automation interface the only way?

[Stefan Krueger]

If you want to builod different "flavors" of your product from the same MSI, use Product Configurations in Releases View. Add a confuguration for each flavor. In the settings you can override Product Code, Product Name etc. so they can be installed side by side.

For features that are specific to a flavor, add a "release flag" in the feature settings and list the same flag in the release flags field of the product configuration. Only features with matching flags 8or no flag at all) will be included in the build.

For the INSTALLDIR use "set a property" custom actions (scheduled before CostFinalize) that set the directory property appropriately, with a condition based on the release flags - see also help topic "Conditionally Launching Custom Actions Based on Release Flags".

[installer96]

Thanks for the tips. Would this be any simpler if I were to do it in a project type other than Basic MSI? (I have Premier, so all the project types are available to me)

[installer96]

Sorry for double posting, but how can one change the display name of a shortcut at install time?

 

I know deramor touched on using the automation interface to do this, but is there no way to do it without that?

 

The display name has to be a string, but as far as I can tell, strings can't be changed at install time -- I've tried "Program Name [SHORTCUT_NAME]" and it creates a shortcut with that literal name instead of replacing [SHORTCUT_NAME] with the appropriate property.

[Stefan Krueger]

For the shortcuts there's no completely easy way. One option would be to have multiple shortcuts, each in a separate feature, which you then filter using the product configuration flags.

[installer96]

Ah, not the most convenient but it works. Thanks!

[installer96]

Ok, so I ended up not using release configurations, but overriding the product and upgrade code for each "flavor" when invoking the standalone builder, which I thought would have the same effect. Installing works well -- all the files are in the correct location and the registry values are being set correctly. However, I'm having an issue when uninstalling (and I can only assume I'll have issues when upgrading, though I haven't tried it).

 

When installing two of the flavors side by side, when I uninstall one of them it is also deleting the files of the other one. I read something that suggested the component GUIDs must be different for each. Is this true? Would this be solved if I used release configurations?

[deramor]

Having identical component GUIDs is how you share files across installations. I would expect that uninstalling one version would not touch either set of files. Then when you remove the second, it's matching files would be removed and leave the first set alone. The first set of files becomes "orphaned".

Now you are seeing different behavior than the above but in general, the component GUIDs should all be different. I have an installer I intentionally create to install side by side previous releases. The code I shared before was from the build script that created it. When I make a new version, I update all the component GUIDs, upgrade code, package code, install dir, and update the folder I install shortcuts into. One shortcut is mapped with installdir as the root so it automatically gets changed.

Every build of that new version will perform an upgrade of any earlier build but never for any previous releases.

For example, 2 builds of version 2.0. Call them 2.0.1 and 2.0.2. The later will upgrade the former. Neither will touch any build from 1.0.

Release flags include or omit features from the resulting installer but their guids remain unchanged. If you included entirely new components for each configuration of releases, that might work. Otherwise you are stuck changing the component guids in order to switch between releases. I would actually think creating duplicate features and components would be easier to implement than changing all the guids. You wouldn't want to assign the guids randomly so you'd need to keep track of them and in what order etc...

[installer96]

Is there any way to duplicate features or components without creating a new one and manually setting the settings? I have close to a hundred components... manually recreating them would be very time consuming and error prone.

[deramor]

I am not sure.  You could try to export them to a blank project and try to import them again 2 more times but you still need to change the feature names, component names, and component GUIDS to be unique before importing them back.  I think you might be stuck with the manual task.  You are, after all, making 3 installers.

 

You might be able to create the features and through the Project Assistant tab -> Application files view, add files from your disk.  This will create new components for you under the selected feature and selected folder.  But you still need to actually select files.  Good thing is that if you select 10 DLLs at once, it creates 10 components which saves time.

[installer96]

It turns out the strange behavior with one flavor of the program deleting the files of another flavor is because of some javascript behind the scenes. I've since scrapped all the javascript.

 

According to the below article from Microsoft, "To keep the nonfile data of each instance isolated, the base package should collect nonfile data into sets of components for each instance. The appropriate components should then be installed based on conditional statements that depend on the instance identifier."

https://msdn.microso...7(v=vs.85).aspx

 

I'm not using instance transforms (I'm using product configurations and setting the product/upgrade codes differently for each one), but I think this should still apply for me.

 

Anyway, I've done that. The nonfile components (registry values and shortcuts) are installed conditionally based on the flavor. When I uninstall using the .exe, it works great. The right folder is deleted and the others are untouched. However, when uninstalling with the .msi, nothing is deleted. Why would that be?

 

I've made sure that none of the components are shared or permanent. I've also checked the SharedDlls key in the registry to make sure none of my components are in there.

 

EDIT: Turns out its because one of the registry keys depended on the product name, and I wasn't setting the product name. The .exe was somehow resolving a product name from the installer name or something, but the .msi wasn't.

Edited by installer96, 23 May 2017 - 14:23.

[installer96]

I want to uninstall other flavors when upgrading.
 

Say I have flavors A, B, and C.

 

If I upgrade A, I want to uninstall B and C.

If I upgrade B, I want to uninstall C.

 

I'm aware that I could use a Nested MSI, but that uses a product code and I need to use an upgrade code.

Launching msiexec from a custom action also requires a product code, and it has to be in the UI sequence so it won't run in silent mode.

I could also use the Upgrade table, but that only executes on major upgrades, and I can't do the upgrades conditionally based on the current build type.

 

Is there any way to do this?

 

EDIT: I decided that it was alright to only do the uninstallations during a major upgrade/fresh install, so I decided to go the Upgrade table route. Then I used an InstallScript CA between FindRelatedProducts and ExistingProducts to delete the "Detect Property" when running installation C so that it wouldn't uninstall B.

Edited by installer96, 26 May 2017 - 00:26.

[deramor]

If you had different Upgrades codes between all 3 flavors, and set your major upgrade item to only upgrade setups "Sharing myupgrade code" one flavor by default would not remove any other flavors. 

 

If you even wanted to remove one or more flavors, you could add upgrade codes to this list but it could no longer be "Sharing my upgrade code"

[installer96]

Yes, that's what I did, it's just that I deleted the "detect property" if running installation C.

Thank you guys so much for your help.