InstallShield Tips and Techniques

July 6, 2007

Creating Common Scripts for InstallShield projects

Filed under: Techniques — shieldmaster @ 12:30 am

Let’s talk about creating common scripts for InstallShield projects.  EVERYBODY creates script functions in the same directory as the Setup.RUL – but when you have multiple projects that use the same script functions, then the replication will cause code regression issues.  For example:

I have 9 active InstallShield projects, everyone of them uses the same script function “Adobe.rul”.  This script function is run as a Custom Action and will look to see if Adobe is installed.  If installed, it will verify the specific version of Adobe installed – our documentation uses features that won’t work for anything prior to version 6.0 of Adobe Reader.  The script did other things, like snare the installdir value for the launching of the ReadMe at the end – it also hid the checkbox/text field if they did not have Adobe, and elected not to install it. 

So I found myself with 9 copies of the same RUL file in 9 locations.  Obviously I would encounter a logic bug!  I found out later that I only corrected the logic bug in 7 of the 9 copies!  After the release, I was determine to come up with a better solution.

Common Scripts

I wanted to store the Adobe.RUL script function only once and reference it with all of the projects.  The critical thing is that I wanted to have access to the script function in the InstallShield IDE – which is what was a really issue to contend with! 

I ended up creating a directory “Common Scripts” under my InstallShield Reference directory – and stored all of the common scripts there.  I defined common script to the extreme – every script function would be stored there, the only exception was the Setup.RUL would be stored with the InstallShield project.

I did create a naming standard – to differenciate between the scripts used for any project versus the scripts that were specific to one project.  For example:

  • ISI_Adobe.RUL
  • ISI_Engine_RegFiles.RUL
  • ISI_Fn_RegFiles.RUL

My naming standard added Fn to indicate a that the script was called by another script function, such as the Custom Action called “ISI_Engine_RegFiles”, which registered certain Engine files by calling the routine “ISI_Fn_RegFiles” which had the generic registering script.  Another Custom Action called “ISI_Adobe” which performed the script as described above. 

Usage in InstallShield Project 

There is no difference in the usage of the Prototype statements:

export prototype ISI_Adobe(HWND);
export prototype ISI_Engine_RegFiles(HWND);
prototype ISI_Fn_RegFiles (BOOL, STRING, STRING, BOOL);

There is a difference in how you include the external script file for compiling:

#include “..\..\..\Reference Files\CommonScripts\ISI_Adobe.rul”
#include “..\..\..\Reference Files\CommonScripts\ISI_Engine_RegFiles.rul”
#include “..\..\..\Reference Files\CommonScripts\ISI_Fn_RegFiles.rul”

Notice that I used the relative DOS Path reference to locate the script functions – critical difference is that I need to offset from the location of the Setup.RUL – not the .ISM file.  (See earlier post for how to accomplish this).

Finally – if you want to see the script file in your IDE, you need to right-click on the Setup.rul and select “Insert Script files”, and navigate to the Common Scripts directory and select the “.RUL” to add.  Now the script will appear exactly like any normal included script for viewing and editing by the IDE.

Issues 

Of course there will be issues!  Biggest one is that when the InstallShield project is open, and you made edits to the scripts then when you compile the scripts are rewritten back into the Common Files directory.  Not a big deal – but if you have two project open at once, then when you compile the second project – it will overwrite the changes you just did in the first project.   Apparently a copy is stored in memory and will refresh/rewrite the scripts back. 

So open and change only one at at time.  NEVER open a project and then use another editor to quickly apply a change to the common script.  Again it will be overwritten!

Hope this helps!

CharlesInstallShield Tips and Techniques
InstallShield Consulting
InstallShield Tips and Techniques
InstallShield Consulting
InstallShield Tips and Techniques
InstallShield Consulting
InstallShield Tips and Techniques
InstallShield Consulting
InstallShield Tips and Techniques
InstallShield Consulting

Advertisements

3 Comments »

  1. Charles,

    I found your post because this is exactly what I’m trying to do. However, I have a different situation. I inherited six projects that have all but one or two common .rul files. However, I don’t know that I can include them via the DOS Path reference, because the different projects have the setup.rul file at different “depths” from the main root.

    Do you have this situation? If so, how did you get around it?

    Thanks!!!

    Dave

    Comment by Dave C — September 26, 2007 @ 2:36 pm

  2. Dave,

    If I understand your issue, each project carries a common set of scripts, but the projects are at different levels.

    Handle each project separately, remove the common scripts from the project’s SCRIPT directory, and reference the common area. The Path Variable reference is contained within the .ISM – so it doesn’t matter that each project is at separate levels.

    Hope that helps.
    Charles

    Comment by shieldmaster — September 26, 2007 @ 6:53 pm

  3. Hi, Charles,

    Thanks for the reply. What I ended up with is a subdirectory with all of the common *.rul files, and then a unique “setup.rul” for each project. The setup.rul contains nothing more than #includes for each of the common files. Each project has a different number of “..\\..\\..\\” directory traversing strings. It seems to be working.

    Thanks again! Have a great weekend!

    Dave

    Comment by Dave C — September 28, 2007 @ 2:48 pm


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at WordPress.com.

%d bloggers like this: