Should you use CustomActionData?

InstallShield 12 can be the bane of Deployment architects everywhere if there are existing MSI projects with InstallScript Custom Actions that need to be migrated to this new version!  All of their carefully worked Custom Action scripts created for earlier IS versions, will need to be re-evaluated after migrating to version 12.A severe problem that I have seen is that Custom Action written in InstallScript that are set to run Deferred will not have access to any MSI Property – there are very few exceptions, one MSI property accessable will be “CustomActionData”. So MSI Properties like “INSTALLDIR” and “PROGRAMFILES” are not accessible – no warning will be issues, just any attempt to retrieve data will result in a NULL value received.  Kind of destroys your script coding logic!

In my scripts, I tend to evaluate the workstation using InstallScript Custom Actions (Immediate Execution) and stash data in public MSI properties.  For example if I determine that Adobe Acrobat was installed, I store a boolean value (TRUE/FALSE) in an MSI Property, and the install path in another MSI Property.  Later when I want to launch the release notes, I have a InstallScript Custom Action set to Deferred to evaluate the MSI properties and take appropriate action.

With InstallShield 12 these InstallScript Custom Actions will no longer work correctly.  I will need to rework the Custom Action to store the data in the MSI Property CustomActionData.  Check out Christopher Painter’s blog notes on CustomActionData and its issues.  Normally the field would be used for a single value, but Christopher offers a technique to ’stuff’ multiple values in the field for retrieval. 

Technically a great solution, but hard to implement and a bear in long term maintenance.I feel that there is a better solution for modifying existing/legacy scripts, simply by using the registry as your sandbox.  For example, take a section of the HKLM\SOFTWARE, which is normally suggested that you place specs on your Company Name (see entries for Adobe).  Use it as a sandbox and stash installation variables gleaned during the UI Sequence and later retrieve them during the Install Execute sequence.   Here is an example of the technique that I use:

Prime RegistryJust after the dialogs have completed create a InstallScript Custom Action that will allow you to gather up all of your special MSI Properties that were initialized during previous CA’s and write them to the registry.  Here is a script extract:

RegDBSetDefaultRoot(HKEY_LOCAL_MACHINE ); 
szRegKey = “SOFTWARE\\Install Solutions\\Framework”; 
nvType = REGDB_STRING;

szRegSubKey =   “InstallDir”;
szProgramFilesDir = INSTALLDIR;
nResult = RegDBSetKeyValueEx(szRegKey, szRegSubKey, nvType, szInstallDir,-1);
if (nResult < 0 )then
   szBuffer = “ISI–>  ERROR – szInstallDir Directory” + could not be updated in registry:  ‘%s’” ;
 Sprintf (szLogMessage, szBuffer, szRegKey);
 ISI_Fn_WriteLogFile (szLogMessage);      
else
 szBuffer = “ISI–>  INFO – szInstallDir Directory location ‘%s’ updated in registry: ‘%s’ with key of ‘%s’ “;
 Sprintf (szLogMessage, szBuffer, szInstallDir, szRegKey, szRegSubKey);
 ISI_Fn_WriteLogFile (szLogMessage);      
endif;   
RegDBSetDefaultRoot(HKEY_LOCAL_MACHINE ); 
szRegKey = “SOFTWARE\\Install Solutions\\Framework”; 
nvType = REGDB_STRING;

// Obtain MSI Property for CustomerName and update Registry
nBuffSize = 256;
szMSIProperty = “ISI_CUSTNAME”;
szRegSubKey   = “CustomerName”;
  MsiGetProperty (ISMSI_HANDLE, szMSIProperty, svValue, nBuffSize);
  //Update the CustomerName Key.
  nResult = RegDBSetKeyValueEx(szRegKey, szRegSubKey, nvType, svValue, -1);
 if (nResult < 0 )then
   szBuffer=”ISI–>  ERROR-MSI Property ‘%s’ could not be updated in registry:  ‘%s’” ;
  Sprintf (szLogMessage, szBuffer, szMSIProperty, szRegKey);
  ISI_Fn_WriteLogFile (szLogMessage);      
 else
  szBuffer=”ISI–>INFO-MSI Property ‘%s’ updated in registry: ‘%s’ w/value of ‘%s’ “;
  Sprintf (szLogMessage, szBuffer, szMSIProperty, szRegKey, svValue);
  ISI_Fn_WriteLogFile (szLogMessage);      
 endif;   

Retrieve Registry ValuesIn each InstallScript Custom Action, simply add this script at the beginning to retrieve the values from the registry and store them into variables.  It should flow seamlessly into your existing script – here is some sample script that I use:

nvSize=256;  

RegDBSetDefaultRoot(HKEY_LOCAL_MACHINE); 

szKey=”SOFTWARE\\Install Solutions\\Framework”;nType=REGDB_STRING;  

//Get the InstallDir Key.

RegDBGetKeyValueEx(szKey,”InstallDir”, nType, svInstallDir, nvSize);     

szBuffer = “Retrieved from registry key ‘%s’ the InstallDir key which was ‘%s’ “;      Sprintf (szLogMessage, szBuffer, szKey, svInstallDir );     

ISI_Fn_WriteLogFile (szLogMessage);               

//Get the Customer Name.RegDBGetKeyValueEx(szKey,”ISI_CustName”,nType,szCustName,nvSize);     

szBuffer=”Retrieved from registry key ‘%s’ the ISI_CustName key which was ‘%s’ “;     

Sprintf (szLogMessage, szBuffer, szKey, szCustName );     

ISI_Fn_WriteLogFile (szLogMessage);    

After the install has been completed, should the install variables placed in the registry be deleted?  Not necessarily, it could have use in the uninstall process.  But remember to delete them when the uninstall has completed. 

Hope this helps! 

Charles  

Enable MSI logging

The use of the MSI log cannot be underestimated in its ability to resolve technical issues.  It can be complicated to review the contents, so much so there are tools available to assist you.  

But first you must ensure that a MSI log is generated for your installs – here is the best method  to have one generated each time your install is run.  Add this registry entry to the workstation/server:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Installer]
“Logging”=”voicewarmup”

Hint:  take the above text and save as “MSILogging.reg” and then double-click it.

Now whenever a MSI install is run – even if you perform a Modify/Repair/Remove from the Add/Remove Program Control Panel, a verbose MSI log is generated.  The log is created in the Windows Temp directory (use %TEMP% in the Start | Run dialog box to access).  Look for a recent file named MSI9999.log (where 9999 is a random number).

This is much easier to accomplish instead of creating the complex batch statement to create a MSI log during execution.

Charles

Updated:  It was noted that the correct phrase should be “voicewarmup” – thanks Colin!

Soliciting suggestions!

I have just a few ideas for tips and techniques remaining that I will be posting soon. 

If anyone has a special request for something that I may be able to assist – please just add a comment and request it.

Best Regards

Charles

Creating Common Scripts for InstallShield projects

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

Make an MSI run multiple times

One of the options that was available to you with installations prior to Windows Installer emergence was the ability to rerun an installation multiple times.  By this I mean running the setup again without entering Maintenance Mode – as if it had never been run before.

You can still use InstallShield to create an InstallScript using the  option and then select the Multi-Instance option which lets your end users rerun an installation multiple times as a first-time installation rather than as a maintenance installation. 

But as you know, I studiously avoid InstallScript projects – I use Basic MSI Projects, so how do you make a Basic MSI Project eligible to be rerun?

Look at this dialog extract from the Sequences Table for the Install Execute Sequence:

 

Note that there are four Standard MSI actions that are the primary method by which the MSI Application is registered under the Windows Installer that we need to be concerned with: 

• RegisterUser
• RegisterProduct
• PublishFeatures
• PublishProduct

Alter the condition on each of these Standard Actions to use zero – which means the condition will never be set true and the Standard Action will never run.  I recommend you alter the comment to reflect the change – as I have shown above.

Impact

The usage of this technique means the product will not be registered under Windows Installer – nor will it appear in the Add/Remove Programs Control Panel.   Use only if you have a specific requirement!

Usage Scenarios

I have encountered two separate situation where this technique served admirably.  

Once a vendor was creating unique sales video/slideshow presentations to sell to his customers.  After a few customers used his services, he encountered a situation where the same end-client was attempting to install the presentations from two of his customers.  The dreaded Maintenance mode was disrupting the end-client from installing the second presentation.   I was able to make the install rerunable – and used a scripted Custom Action to read a special file delivered with each presentation.  This information allowed me to install the unique files, create shortcuts to access the presentation and create a uninstall technique to allow the end-user to remove the files when no longer required.

Another vendor needed to be able to allow an unlimited amount of customers to be established on the server.  Each customer would have a unique IIS Virtual Directory with the same files installed.  XML documents that were specially configured during the install would maintain the customer data within the Virtual Directory.  A very complex Visual Studio .NET solution was involved to support the customer processes.  Each customer install used a rerunable Basic MSI Webproject to deliver the files and create the Virtual Directory.

Warning!

I don’t recommend you do this to simply to avoid the Maintenance Mode!  A great technique if you have a specific requirement – but you will lose so much functionality that Windows Installer/MSI packages offer.
Charles

Dress up the dialogs with customized bitmaps

I absolute detest the generic bitmaps that InstallShield provides with the dialog screens.  For a market leading product – why are the bitmaps so kindergarden looking? 

There are two distinct types of bitmaps used with the product line:  the dialog bitmap and the banner bitmap.  The dialog bitmap is used on the “exterior” dialogs, typically the Welcome and Summary – but is also found on the Maintenance dialog screen.  Here is a sample image:

 There is another bitmap used as the banner on all of the interior screens, here is a sample image:

 

There is a lengthly document that has been posted on the InstallShield Tips and Tricks webpage

http://www.installshield.com/news/newsletter/details.asp?source=isd 

Here is the specific link to the article: 

http://www.installshield.com/news/newsletter/0301-articles/DialogBitmaps.asp

Unfortunately it is very confusing to read, so I will attempt to boil the process down to the essentials.

How to change all Exterior Bitmaps

Navigate to the Direct Editor and look at the contents of the binary table – here is a sample:

Look for any entry that has “ISDialogBitmap.ibd”  – which is the bitmap used in the InstallShield exterior dialogs (they use the legacy extension “.IBD” instead of “.BMP”.  If you replace the path entry with a path to your customized bitmaps they will appear in all of the exterior bitmaps.

How to change all Interior Bitmaps

Look for any entry that has “ISDialogBanner.ibd”  – which is the bitmap used in the InstallShield interior dialogs (they use the legacy extension “.IBD” instead of “.BMP”.  If you replace the path entry with a path to your customized bitmaps they will appear in all of the interior bitmaps.

Bitmaps specifics

I recommend that you take a copy of the “ISDialogBitmap.ibd” and “ISDialogBanner.ibd” bitmaps (rename them to .BMP) and have the Graphics group get the specifics on the attributes.  Note that on the bitmap for the exterior dialogs, the image can only be on the left side of the bitmap.  Everything in white will be transparent in the dialog and all of your text will be superimposed.

Here is the location for these default bitmaps on a InstallShield v11.0 project:

C:\Program Files\InstallShield 11\Redist\Language Independent\OS Independent

Customized Bitmap Storage

If you read my post on “Path Variables and Project Organization” then you realize the best approach would be to store the bitmaps in a location that any InstallShield project can access.

I typically create a storage location and place all components used accross multiple InstallShield projects.  Here is a sample structure of reference files stored along side the InstallShield projects. 

I can store the customized bitmaps in this location:

C:\Project Source\Reference Files\Bitmaps\Dialog Bitmaps

 If I use the technique discussed about Path Variables, then I would add a new Path Variable to the project “PATH_TO_DIALOG_BITMAPS” and create a path reference such as:

<ISProjectFolder>..\..\..\..\Reference Files\Bitmaps\Dialog Bitmaps

Then within the Direct Editor, I would simply alter the source path to reflect this:

 

Imported Dialogs

Doesn’t seem to be on topic, but guess what happens if you export one of your dialogs that has a customized bitmap?  Turns out when you import the dialog into another InstallShield project, you will see a strange file “InteriorBin1″ littered somewhere in your project structure.  This is the way InstallShield attempts to handle the customized interior bitmap.  Don’t believe me – just take the file and add the .BMP extension and open it with Paint.  If you want to get rid of it, simply go back into the Direct Editor and alter the path reference for this to be your customized interior banner bitmap and rebuild.

Hope this helps!

Charles

Path Variables and Project Organization

Did you ever open a project and find that various components (binary files, .RUL, etc. ) were missing? 

Typically you will discover that the last person who maintained the InstallShield project did not take care of organizing the project carefully – letting components be littered accross the network. 

For example, here is a image of a complex project with files being pulled from who knows where…

With files being pulled from such a myriad of locations, it is bound to lose some over time. 

 Solution – Organize and use Path Variables correctly.  Let’s first discuss how best to organize your project files. 

 Project Files Organization

 Look at how I organize a typical project

Under the Project directory will be the InstallShield .ISM project, with all supporting files found within the store directory. 

If you have full control of the source staging, then stash it under the Source directory.  Typically the source will be staged in a specific directory after a build process.   Ensure all components are placed within the Source Management repository for ensuring the ability to rebuild the project for future upgrades.

But what happens if the next person places the project structure on a different drive? Or a different directory structure?  If you utilize Path Variables correctly, then you can shift the project around and never encounter a problem when you go to rebuild the project.

Path Variables 

When you look in the InstallShield project at the Path Variables panel, notice that you have a constant reference point.  That is where the project .ISM resides – which is referenced by the Path Variable <ISProjectFolder>.  No matter where the project structure is placed (on a network or buried in sub-directories), if you set your Path variables up to have a reference to the ISProjectFolder then any file can be found.

The easiest method to determine this is to count the directory up from the project .ISM file.  For example, for the bitmaps used as replacements for the basic interior/exterior dialogs, they exist in the sub-directory “..\TestProject\packages\store\Bitmaps_Icons\Dialog Bitmaps”.  To reference them I will need to go up one directory from the .ISM, and then drive down into the “store” sub-directory until we get to the dialogs.   Bottom line, the path reference would be:

<ISProjectFolder>..\store\Bitmaps_Icons\Dialog Bitmaps

Now look how the other path variables can be resolved to reference everything else in the projct structure:

Well, I hope this helps you to organize your project files so that when you get to pass on a project for maintenance, the next guy can find everything – right where you left it.

Charles
InstallShield Tips and Techniques
InstallShield Consulting
InstallShield Tips and Techniques
InstallShield Consulting

Top 10 Issues in InstallShield that will bite you!

1. Never use Dynamic File linking.  Never, NEVER!  Causes severe problems when attempting Upgrades/Patches.  More posts have been written on how to work around issues caused by this. 
2. When creating Custom Actions, always name it unique (i.e, ISI_StopServices, ISI_ModifyRegistry) – this will assist you in quickly determining if the C.A. was successful within the MSI logging.  
3. When referring to the same file numerous times (for example a specific version of a Release Notes) try to make a string value and reference the string value (@Release_Notes).  This will prevent having to locate each and every occurrence when the name changes.
4. Caution when using SQL within project – default will attempt to uninstall scripts at application removal, which will destroy customer data.  Always leave database data populated – let the DBA handle deletion. 
5. Issues with XML within project working – most Developers cannot get it working correctly – check the message boards.  If you use XML query to grab values during a AppSearch, expect excessive time delay. 
6. Have staging for binaries separate from the compile output directories to ensure only specific items are handled within project.  This will ensure that when a build process fails, the last good compile is not incorrectly incorporated into the InstallShield CAB files.
7. COM Extraction
   1. Concept works most of the time – but must guard against developer hard include of ATL code, and situations which end up having the developer workstation machineIDs incorporated into web server configs.
   2. Never run COM Extract at build time – extract and verify and freeze.  Granted, this runs the risk of developers adding functionality without notifying IS Developer who will need to extract COM again. But when they do this, you may encounter possibly new Microsoft Redistributables need to be included as well. 
   3. Personnally I recommend never do COM extraction.  Use scripting instead to register/unregister all files for ease in specifying sequence.  Yes, you could use properties to select registration – but then need to use DirectEdit on the ISSelfReg table to specify sequence – which applies to both install and uninstall.  Think of long term maintenance aspects – Keep It Simple, Simpleton! NT Services
8. 1. Again the issues with COM Extract has caused me serious problems with hard includes of ATL code
   2. I cannot easily specify which other Services to stop/start in specific order when I have more than one service – consequently I use scripting to Stop/Start the services when required
   3. I use scripting to create the services and then unregister the service on uninstall.  
9. Windows Installer “Repair” capability has issues.  Although typically the restoration of a DLL/Executable has been flawless (when used with Static File Linking), the Repair process also will drive in the InstallShield project registry.  In my situation, the registry template carried in the IS Project will have properties (Version, INSTALLDIR, [PropertyValue]) that are reflected within the project registry – I also take customer input from the dialogs and translate that into fields to update the registry after it has been applied to the workstation.  Since the “Repair” process does not present dialogs – so it doesn’t resolve the property values – the resulting registry is essentially corrupt because of missing values.  To resolve, I have created Custom Actions that run before a “Repair” to archive the registry to a file, and another Custom Action that runs after the “Repair” to delete the registry and restore from the archived file. 
10. InstallShield version 12 has been radically restructured and you may encounter serious issues within your project’s scripts when you upgrade. For example there are the issues that I have encountered:
    1. Global variables will no longer pass information to scripts – but no message is given, either during compile or execution – just blank values received.
    2. Within the “Execution Sequence”, the ability to extract values from predefined directories (INSTALLDIR, SETUPEXEDIR, PROGRAMFILES) will no longer work.  Again, no message is given, either during compile or execution – just blank values received. 
    3. Within the “Execution Sequence”, the ability to extract values from MSI Properties that were defined during the “UI Sequence” will no longer work. Again, no message is given, either during compile or execution – just blank values received. 
    4. Conceptually, the use of the MSI Property “CustomActionData” is allowed – but severe gyrations required to pass multi-value string into the MSI Property during the “UI Sequence” for retrieval during the “Execution Sequence”.  I ended up writing all of the values needed in the “Execution Sequence” to a registry while they are accessible during the “UI Sequence”.  Then during the “Execution Sequence” when I need a value (i.e,., INSTALLDIR), I extract the values from the registry. 

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

Tools and Utilities

A word about tools/utilities that I use to do my job. 

To do the job of building installations, you must be meticulous about testing – almost fanatical!  One of the requirements of testing installations is a set of tools & utilities that you are comfortable and can depend on to analyze and give you dependable results. 

But a bigger issue is that we are human and once we get comfortable with a set of tools, we tend to ignore newer, more robust tools that become available.  Force yourself to learn a new tool.  Given that, I am going to embrace a new tool – at the bottom of the list is a replacement for wordpad that I am going to download and try.  See – I am trying to grow too!

Last comment.  Most are not freeware – they are build by professionals who expect a small monetary contribution/fee.  When you appreciate the time savings, please take the time to pay for a license.  It is only fair.

 VMware

Vendor:  VMware, Inc.

www.vmware.com

Use:  Virtual Machine concept.  Started using in 2003 and found it invaluable in install testing.  Have created multiple Operating Systems and snapshots with each Service pack install – so testing of Win2000 with no SP and Win2000 with SP1 installed can be done quickly and effectively.      

Many Server OS will have Databases installed for customer testing (Oracle and SQLServer).  After testing, can quickly restore OS image to be back to pristine state prior to install testing.

At the time, the only comparable solution was Symantec Ghost – which is a great solution, but required a separate machine to be available.  When I started I had a dedicated testing machine and used Ghost – but finally was swayed by the ease of VMware.

  Beyond Compare 

Vendor:  Scooter Software

www.scootersoftware.com

Use:  Excellent tool that allows me to compare both single files and entire directories to look for differences after installs.  Great for upgrade testing.  Superior than others in that it will allow simple right click to select a directory to compare against another. 

 PFE: 

            Freeware & no longer supported

            http://www.lancs.ac.uk/staff/steveb/cpaap/pfe/

Use:  Started using this file editor because of the ability to execute dos commands and get output into the editor.  Now very comfortable and hesitate to change to better ones.  (hmm…)

 SR

            Search and Replace

Funduc Software, Inc.

www.funduc.com

Use:  Excellent for search for strings in multiple .RUL files.  Has a replace function which works quite well when evaluating/altering resource files across the entire project.  Also has a batch command interface for running scripts.

 FileGrab

            Ziff-Davis Publishing

            Freeware

Use:  Once Windows File Explore allowed you to search for various files within a sub-directory, I use this tool to highlight the selected files and copy the file names into a panel – which I then can copy into a editor for creating batch files. 

For example, I can create a Batch file for registering all of the dlls within an application for testing.  I start by doing a search of the directory using *.dll with the Windows File Explorer, highlight all of the files and drag into FileGrab.  Then copy the file path & names into a .BAT file and place “regsvr32.exe ” in front of each line. 

 Microsoft Virtual PC

Microsoft Product

Workstation version 2007 is now free!

Use:  trying to take over the market share from VMware in the Virtualization market.  Good product, I hesitate to give up VMware because of the ability it has to create a snapshot and return to that state. 

http://www.microsoft.com/windows/products/winfamily/virtualpc/default.mspx

           

Dependency Walker           

http://support.microsoft.com/kb/256872

Use:  Microsoft tool that I use to debug issues with DLLs not registering – when there are missing dependencies.

 MSI Zap

Microsoft Windows Installer Cleanup Utility

http://support.microsoft.com/kb/290301

Use:  Microsoft tool that will safely eliminate all traces of a MSI registered application from the registry.  Useful when all else fails during a unsuccessful removal/uninstall.

 

Monitoring tools (RegMon, FileMon, DiskMon)

Original utilities were created by Mark Russinovich, and recently acquired by Microsoft and will be upgraded to new versions “Process Monitor”. 

http://www.microsoft.com/technet/sysinternals/utilities/regmon.mspx

Use:  when you are tracking down issues with an install that is hitting the registry but somehow is being denied access, these tools can display realtime information on the keys that are being accessed – and which programs are doing it.

Invaluable during repackaging efforts that requires a bit of investigative tracking.

           

 XMLStarlet 

Open Source XML editor that has a valuable command line execution. 

http://xmlstar.sourceforge.net/

Use:  can use in Custom Actions to obtain data from XML documents and update them in a batch method.  No issue distributing with your installation. 
Documentation on how to use it for complex tasks is not truly covered in the doc – information is available only thru the expertise of the users in various forums.

 TextPad 

Robust Wordpad replacement – kind of like wordpad on “steroids”.

http://www.textpad.com/products/textpad/features.html

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

InstallShield Reference Books

 I get quite a few requests for some good reference books that will help to understand InstallShield.  As it turns out, most are written by InstallShield employee’s – go figure.

 Here is my list of beneficial reference books that I frequently pick up and review:

Practical Windows Installer Solutions

Author: Bob Baker – 2004.

Most recent book on the subject, again written by Bob Baker – at Technical Trainer at InstallShield Corp, and the prolific author of at least three InstallShield reference books.  Focus is on truly practical solutions to application packaging; the section on understanding Patches and Updates is worth the price.

http://www.amazon.com/Practical-Installer-Solutions-InstallShield-Applications/dp/0971570833/ref=sr_1_11/105-2782788-1155664?ie=UTF8&s=books&qid=1181875516&sr=8-11

The Official InstallShield for Windows Installer Developer’s Guide 

Author: Bob Baker  – 2001

Bob Baker is the author – this book is somewhat dated because it used the ISWI tool – when it was still in competion with IS’s version 6, it does have a good bit of instruction on how to create Dialogs using the internal C++ dialog layout editor.  It discusses thoroughly the concept that I fully embrace – using Basic MSI with InstallScript Custom Actions to extend its functionality.

http://www.amazon.com/Official-InstallShield-Windows-Installer-Developers/dp/0764547232/ref=pd_sim_b_2/105-2782788-1155664?ie=UTF8&qid=1181876931&sr=8-4 

BulletProof Installs

Author: Leslie E. Easter – 1998

Written when IS 5.0 was in production – quite aged and showing its age.   The first book that I know of that approached the authoring of install setups as a method to achieve a solid install of a product.   One of the strongest presentations of the intricacies of the InstallScript language that you can find.

http://www.amazon.com/Bulletproof-Installs-Developers-Install-Programs/dp/0137980914/ref=pd_bbs_4/105-2782788-1155664?ie=UTF8&s=books&qid=1181876931&sr=8-4 

Getting Started with InstallShield Developer and Windows Installer Setups

Author: Bob Baker – 2002

This book uses IS Developer 7.x as the model – which allows you to continue to be comfortable all thru version 12.0.  Granted there are subtle changes and new additions (XML Editing,  SQL Scripts, etc), but by far most of the panels and dialogs look quite similar.  A testament to the graceful aging of the IS Product line.

http://www.amazon.com/Getting-Started-InstallShield-Developer-Installer/dp/0971570809/ref=pd_bbs_sr_3/105-2782788-1155664?ie=UTF8&s=books&qid=1181877155&sr=8-3 

Administrator’s Introduction to Application Repackaging and Software Development using Windows Installer 

Authors:  Bob Baker and Robert Dickau  – 2002 (Robert Dickau is a frequent contributor in the InstallShield forums.)  

Although this is THE book for Repackaging applications (taking legacy app and using the AdminStudio product to create a MSI for distribution) it goes i-ndepth into Tranforms and handling locked-down environments.  

http://www.macrovision.com/services/education/publications/repackaging/index.shtml 

Mastering Windows XP Registry

Author: Peter Hipson  – 2002

This book provides an in-depth reference to various HKLM registry keys that I can use to determine NT Service status, how to plug information into the “RUNONCE” registry key, etc.

http://www.amazon.com/Mastering-Windows-Registry-Peter-Hipson/dp/0782129870/ref=sr_1_5/105-2782788-1155664?ie=UTF8&s=books&qid=1181877227&sr=1-5