4 different versions & serial numbers, 1 release?

[tdeboer]

I'm trying to figure out the best and easiest way to accomplish this. I have 4 versions of my software and each version has it's own serial number. What I want to do is be able to put them all on 1 CD, and depending on which serial number the user enters, that version gets installed.

Unfortunately, due to the way the software is programmed, I can't do it by features = each version is it's release.

Any help or insight would be appreciated. Thank you.

[Kelter]

i have an install that customizes itself based on the serial number entered in the customer information dialog. There's alot of work to do in the background to support this, but basically, I set a property after validating the serial number, and then use that property in the feature conditions. If you think this'll do what you're trying to do, i'll elaborate on the implications for implementing this.

[tdeboer]

Thank you for the quick reply! However I don't think this is what I need to do. Basically, the way our program is written, all 4 versions contain the same files. It's just that those files (which are Director files) contain more/less information depending on the version (Express, Pro, etc...). Those files have the same name, so (atleast my understanding) I cannot use the 'features' feature of Installshield. If I am incorrect in my understanding, please let me know??

[Kelter]

Ah, so you don't even have to get as convoluted as my approach.

I'd suggest that you create four different parallel directory trees on your build server, each one containing it's own respective set of file versions. Create components within your installer in quadruplicate and set the conditions on each component to depend on the serial number provided. Add only the appropriately versioned files to each component. This way, only the correct versions will get installed, and you won't have to disturb your feature breakdown.

This might be annoying if you have a few hundred components, but otherwise it should be manageable.

[jjb8297]

Kelter,

Do you have a sample script of this application on how you would set up each of these components to be associated with each serial number.

[Kelter]

Here's a generic idea...

LICENSEKEY is the property associated with the coresponding field on my CustomSetup dialog.
nEd is a code IDing which edition the Lic belongs to

MsiGetProperty(hMSI, "LICENSEKEY", svLic);
GetEdFromLic( svLic, nEd );
switch(nEd)
    case 1: SetMsiProperty(hMSI, "EDITION", "1");
    case 2: SetMsiProperty(hMSI, "EDITION", "2");
    case 3: SetMsiProperty(hMSI, "EDITION", "3");
    default: 
        Messagebox("Invalid Licence", SEVERE);
        abort;
endswitch;

Use EDITION="1", etc in your component conditions.

Make sense?

[jjb8297]

Okay, I think I understand what you meant by the code, but wanted to make sure I have this right.

I have three licence keys, one for express, professional and enterprise editions of my software.

If the user enters in the key for the express edition, then the code will check the licence key and validate it, and then install the express edition of my software and so on for the rest of the other editions that I have.

Do I need to have a separate installer for each edition of my software, that somehow the licence key is passed through to the set up file, so as to prevent the user having to type it in more than once. And if that is the case, how do you pass the licence key through to the installed

[Kelter]

Nope. Same installer...In the Setup Design view, you'd have something like this:

Feature_1
    Component_F1_1_EXP
    Component_F1_1_PRO
    Component_F1_1_ENT
    Component_F1_2_EXP
    Component_F1_2_PRO
    Component_F1_2_ENT
    Feature_11    
        Component_F11_1_EXP
        Component_F11_1_PRO
        Component_F11_1_ENT
        Component_F11_2_EXP
        Component_F11_2_PRO
        Component_F11_2_ENT
    Feature_12
        Component_F12_1_EXP
        Component_F12_1_PRO
        Component_F12_1_ENT
        Component_F12_2_EXP
        Component_F12_2_PRO
        Component_F12_2_ENT
Feature_2
    Component_F2_1_EXP
    Component_F2_1_PRO
    Component_F2_1_ENT
    Component_F2_2_EXP
    Component_F2_2_PRO
    Component_F2_2_ENT
    Feature_21
        Component_F21_1_EXP
        Component_F21_1_PRO
        Component_F21_1_ENT
        Component_F21_2_EXP
        Component_F21_2_PRO
        Component_F21_2_ENT
    Feature_22
        Component_F22_1_EXP
        Component_F22_1_PRO
        Component_F22_1_ENT
        Component_F22_2_EXP
        Component_F22_2_PRO
        Component_F22_2_ENT

that example shows 2 features each with 2 subfeatures, and each feature and subfeature has 2 components which each have 3 different versions of their respective files. Keep in mind that the users don't see Components in the CustomSetup treeview, only the features/subfeatures. Each _EXP component would have the term (EDITION="1") in its condition field. Each _PRO component would have (EDITION="2") in its condition field. Each _ENT component would have the term (EDITION="3") in its condition. I'm sure you'll probably end up with some "_PRO_ENT" components, in whose condition field you'd want (EDITION=2 OR EDITION =3). You can come up other variants on this theme as the need arizes.

Now, to elaborate a bit on my sample code from my previous post,
- Assume that you have a License field on one of the dialogs (probably CustomerInformation)
- Assume that in the properties for that control, the "Property" property is set to "LICENSEKEY." this way, when you call MsiGetProperty(hMSI, "LICENSEKEY", svLic); it will populate svLic with whatever has been entered in the License field on the CustomerInformation dialog.
- Assume that GetEdFromLic( svLic, nEd ); will validate svLic and populate svEd with a 1, a 2, or a 3 depending on what edition the License key belongs to (obviously assuming that the edition can be determined from the License Key)

The "Next" button on said dialog should have the following events in the following order:[CODE]
Event |Argument |Condition |
-------------|-------------|----------------|
[EDITION] |0 |1 |
EvaluateLic | |1 |
NewDialog |CustomSetup |NOT(EDITION="0")|[/CODE]
"EvaluateLic" here represents the name of the IS (Type 65536) CA that calls the function I posted on 11-09. It should be scheduled for immediate execution. Also, you probably want to delete the "abort;" line in my example.

[jjb8297]

I see where you are going with the feature setup, but I am afraid that is not how the software is set up.

It is broken down into three different applications, so you do have a set of files for each edition of the software. So I don't think the approach you stated will work in this instance.

That was why I was thinking that it would be a separate install for each edition, and then one master installer that would run off of the CD and the user enters in their licence key.

And based on the licence key, the installer for one of the three editions would run. The problem I would need to make sure doesn't happen, is if the user decides to go into one of the three editions and tries to install it without the licence key. That is why I am thinking that I would need to pass the licence key from the master installer down to the edition installer and let that complete the installation of the software.

[Kelter]

You could start looking into merge modules. That's the closes solution to what you are implying.

Is the feature breakdown different for each of your three apps? one of my installers has this sort of situation, and i use feature conditions to determine what features will be visible, and within some features, different components may or may not be installed based on similar conditions. The trick is to make the MSI re-evaluate the feature conditions between validating the LicenseKey and displaying the customSetup dialog.

It sounds to me like MergeModules might be your best bet, however, since calling an msi from another msi is highly discouraged.

[jjb8297]

thanks for the help. Merge modules, I have not touched installshield in nearly 10 years, so I am pretty rusty on alot of things on this product right now. So I will research what these are, thanks again.:)

[jjb8297]

Kelter,

I am a wee bit confused, so I will restart all of this again and see if we are on the same page at the end. 🙂


This is what I have
One application that comes in the following editions:
1. Express
2. Professional
3. Enterprise

Based on a certain licencekey will determine which edition is installed on the user's machine. What I need to be able to do is set this up in Installshield so that it prompts the user for the licence key, and then installs the appropriate edition.

You mention features/merge modules and no matter how I look at the installshield software, I am not seeing how all of that will work for me. So what I was wondering is if you could give me the steps that you would go about to set this up in installshield, that is if you have the time to do so.

Do I put anything in the respective sections
1. Installation Information
2. Organization
3. Application Data
4. System Configuration
5. Server Configuration
6, Behaviour and Logic (pretty sure I need to have stuff in here)
7. User Interface (pretty sure I need to add in a custom dialog here to get the licence key and process it in #6 above).
8. Media
9. Additional tools


Any help you can give on this will be appreciated, so thanks in advance.

[Kelter]

1. Installation information

Set this up with normal info about your company, product. as for product and package codes, you'll start worrying more about these when you release upgrades. Don't forget to do this come next release. The help topic "Major Upgrade vs. Minor Upgrade vs. Small Update " will come in handy as a place to start, anyways.

2. Setup design

Yes, i know you labled 2 "Organizations" but i do just about all this work within the setup design view. Since you came from the 5.5 days, i should point out that your old idea if "Components" and "File Groups" are now loosely interpreted as "Features" and "Components," respectively. Don't let the demotion of "Components" trick you. What the user would see in the CustomSetup dialog if you were to use it (think of it as SdComponentDialog2 from oldschool IS) would be your Feature breakdown (less the invisilbe features, obviously.) In short, the Features are the Customer's view of your product (whether they see them or not) (Forgive my overparenthesization). Features contain Components. Components are your building blocks. They are the designer's view of the installation. At a "getting-started" level, components encapsulate files with the same destinations and installation conditions. It is recommended that you only include one executable per component. See documentation on "Repair" functionality for details. They also allow you to associate reg entries, shortcuts, and other stuff with said files (Like FileGroups on steroids.)

Since it sounds like you don't really need to give the customer any choices (no customSetup dialog) you can rely on component conditions to determine what will be installed and what won't. You should have enough information now to seperate out all the files you install into components. Create Components for all files for all editions. I'd recommend you end the name of each Component with "_" to identify to which edition each Component belongs. Assign a condition to each component referencing the "EDITION" property like I'd indicated 11/15.

You could create 1 feature and assign every component to it if you're not going to use the CustomSetup dialog. Components not assigned to features don't get installed.

3. Appliaction data

If you added files to each component as you created it, you won't need to use this view, except to verify that you didn't screw up setting the targets for any of your components.

4. System Configuration

I set up this info while creating components, too. Add your reg entries and Shortcuts under their respective components. For simple installations. Chances are good that you don't have to worry about the other settings in this section.

5 Servier Configuration

I haven't had to worry about this yet...but i don't install servers

6. Behavior and logic

InstallScript
You'll need to write a function that performs similar functionality to the example i used earlier.

Custom Actions and Sequences
Create an InstallScript (type 65536) CA that calls the function i mentioned above. There's plenty of documentation on how to export an IS CA. Name it "EvaluateLic" In-Script Scheduling should be "Immediate." Don't add it to the sequence, however.

7. User Interface

My recommendayion would be the following sequence of dialogs (which you "chain" together with "NewDialog" Actions assigned to the "Next" and "Back" buttons)

InstallWelcome
LicenseAgreement
CustomerInformation
DestinationFolder
ReadyToInstall

Embellish this where necessary.

Make sure the CustomeInformation Dialog has a field on it for the License Key. In the properties pane for this control, set the "Property" property to LICENSEKEY. In so doing, you are equating the text in this control to a new property called LICENSEKEY. This is the property that the IS code will query, and pass you your validation function.

Go to the behavior view for this dialog. on the "Next" button assign the following events:[CODE]Event |Argument |Condition |
-------------|---------------|----------------|
[EDITION] |0 |1 |
EvaluateLic | |1 |
NewDialog |ReadyToInstall |NOT(EDITION="0")|[/CODE]The first event resets the [EDITION] property for initialization purposes. The second action calls your script function (which should in tern update the EDITION property upon successful validation of the LICENSEKEY property.) If the key validates, then the NewDialog Action will advance the dialog sequence. If not, then nothing will happen. (which is okay, be cause upon failing the GetEdFromLic() function in your script, you'll be popping up a messageBox to instruct the user.)

8. and 9.

I have nothing case-specific to indicate to you here. any further questions should be answerable by the help docs.

So therei's the whole solution layed out for ya. If it is slightly off from your desired behavior, it should still be enough of an example/tutorial that you should be able to figure out the changes.

Good luck, and happy T-Day.

[jjb8297]

Kelter,

Just confirm on the adding of components, attached is a screen shot of the files that make our app. Am I correct in thinking that I would need to add component for each dll that you see in the screen shot. And then for each of the sub folders I would add component for each of the files that are in those folders.

Question, how would the installation know that for each of these files, that they need to be set up in a sub folder.

The assets folder has a number of sub folders and files in it, so as you can understand this may be a long process to set this for each of the three editions of our software. So I want to make sure I am doing this correctly. Thanks. 🙂

[jjb8297]

Just wanted to make sure this is the way you were stating to set up the components, I have included a screen shot of how I am setting these up.

Really would be cool if the drag and drop could do recursive, but that does not seem to be the case. 🙂

[Kelter]

Destination directories are set at the component level. (Just like your old FileGroups.) If you use the component wizard, you can select all those DLLs, and it'll automatically create components for each of them, and extract any COM registration data (if you check the appropriate checkbox i nthe wizard.) I know as a Senior Software Developer, you're probably thinking , "I don't need no stnking wizards." But really, these wizards in IS are actually useful. :cool: you'll want to set the Destination to [INSTALLDIR]. Actually, if you right click a feature with a particular destination directory set, and click the component wizard from the context menu, then the components created will inherit the destination directory of the feature by default. This can save you some clicking.

When you add the necessary components from the other directories, ("assets" for example) you can just set the component targets to [INSTALLDIR]Assets. MSI is smart enough to insert the "\" after a directory identifier.

[Kelter]

FYI the red "!" icons mean that those components don't belong to a feature, and therefore will not be installed. Some prefer to set thing up this way, first setting up all the components, then creatign the features (or "a" feature as your case may be) and associating components with the Features after that...but it's up to you. Just making sure you know the feature/component dependency.

[jjb8297]

Probably would be really helpful if you were sitting alongside me as I do this. 😄

[jjb8297]

And as a senior developer, I love anything that will make my life easier and if a wizard will do that. Then the more the merrier.:)

[jjb8297]

Okay, I have the editions set up and wanted to make sure that this is set up correctly. I have not even gotten to the code part yet, I have some questions on that.:) I will ask about the coding in a different post on this thread.

[jjb8297]

Kelter wrote:
1. Installation information

Set this up with normal info about your company, product. as for product and package codes, you'll start worrying more about these when you release upgrades. Don't forget to do this come next release. The help topic "Major Upgrade vs. Minor Upgrade vs. Small Update " will come in handy as a place to start, anyways.

2. Setup design

Yes, i know you labled 2 "Organizations" but i do just about all this work within the setup design view. Since you came from the 5.5 days, i should point out that your old idea if "Components" and "File Groups" are now loosely interpreted as "Features" and "Components," respectively. Don't let the demotion of "Components" trick you. What the user would see in the CustomSetup dialog if you were to use it (think of it as SdComponentDialog2 from oldschool IS) would be your Feature breakdown (less the invisilbe features, obviously.) In short, the Features are the Customer's view of your product (whether they see them or not) (Forgive my overparenthesization). Features contain Components. Components are your building blocks. They are the designer's view of the installation. At a "getting-started" level, components encapsulate files with the same destinations and installation conditions. It is recommended that you only include one executable per component. See documentation on "Repair" functionality for details. They also allow you to associate reg entries, shortcuts, and other stuff with said files (Like FileGroups on steroids.)

Since it sounds like you don't really need to give the customer any choices (no customSetup dialog) you can rely on component conditions to determine what will be installed and what won't. You should have enough information now to seperate out all the files you install into components. Create Components for all files for all editions. I'd recommend you end the name of each Component with "_" to identify to which edition each Component belongs. Assign a condition to each component referencing the "EDITION" property like I'd indicated 11/15.

You could create 1 feature and assign every component to it if you're not going to use the CustomSetup dialog. Components not assigned to features don't get installed.

3. Appliaction data

If you added files to each component as you created it, you won't need to use this view, except to verify that you didn't screw up setting the targets for any of your components.

4. System Configuration

I set up this info while creating components, too. Add your reg entries and Shortcuts under their respective components. For simple installations. Chances are good that you don't have to worry about the other settings in this section.

5 Servier Configuration

I haven't had to worry about this yet...but i don't install servers

6. Behavior and logic

InstallScript
You'll need to write a function that performs similar functionality to the example i used earlier.

Custom Actions and Sequences
Create an InstallScript (type 65536) CA that calls the function i mentioned above. There's plenty of documentation on how to export an IS CA. Name it "EvaluateLic" In-Script Scheduling should be "Immediate." Don't add it to the sequence, however.

7. User Interface

My recommendayion would be the following sequence of dialogs (which you "chain" together with "NewDialog" Actions assigned to the "Next" and "Back" buttons)

InstallWelcome
LicenseAgreement
CustomerInformation
DestinationFolder
ReadyToInstall

Embellish this where necessary.

Make sure the CustomeInformation Dialog has a field on it for the License Key. In the properties pane for this control, set the "Property" property to LICENSEKEY. In so doing, you are equating the text in this control to a new property called LICENSEKEY. This is the property that the IS code will query, and pass you your validation function.

Go to the behavior view for this dialog. on the "Next" button assign the following events:[CODE]Event |Argument |Condition |
-------------|---------------|----------------|
[EDITION] |0 |1 |
EvaluateLic | |1 |
NewDialog |ReadyToInstall |NOT(EDITION="0")|[/CODE]The first event resets the [EDITION] property for initialization purposes. The second action calls your script function (which should in tern update the EDITION property upon successful validation of the LICENSEKEY property.) If the key validates, then the NewDialog Action will advance the dialog sequence. If not, then nothing will happen. (which is okay, be cause upon failing the GetEdFromLic() function in your script, you'll be popping up a messageBox to instruct the user.)

8. and 9.

I have nothing case-specific to indicate to you here. any further questions should be answerable by the help docs.

So therei's the whole solution layed out for ya. If it is slightly off from your desired behavior, it should still be enough of an example/tutorial that you should be able to figure out the changes.

Good luck, and happy T-Day.

#7 I am little hazy on this. I am at the CustomerInformation dialog and trying to set up the events on the next button as you called out. And I am not seeing an event called Edition, so I tried to create it and set the argument to 0 and no luck.

You also mention to have the following dialogs to show up InstallWelcome, LicenceAgreement, CustomerInformation, DestinationFolder, ReadyToInstall and so on. How do you select these so that they show up in this sequence?
:confused: