Developer Installation Manifest

Developers of the InstallAnywhere community would be very much familiar with the terminology "Developer Installation Manifest" commonly refereed as DIM.

InstallAnywhere provides the installation developer add addition pay load to their projects without adding any rework or hassle. The use of DIM proves to be of great importance if the application is developed by a large team across multiple sites. The process of packaging and requirement gathering proves to be very tedious and error prone. Due to lack of communication or insufficient knowledge many a times small bugs are introduced to the application package in the form of extra files/files missing/non registration of OCX etc.

Now imagine if theres a way the application developers who are writing the actual software do not require to communicate the list of file to be shipped in the required directory structure :) , imagine if the developer can test his standalone package while debugging or testing his application in stand alone mode. That to the developer does not require to this into an xml with any common text editor, all he/she has to do is to use his frequently used dev IDE eclipse or .NET editor! Seems cool ..... But how????

InstallAnyewhere allows to install plugins to commonly used development IDE's currently Eclipse and .NET IDE, these plugins allow the application software engineer to author to create DIM's which contain source and target locations of the file needed to run his component . All he needs to do is to identify the files and folder source location and needs to provide the target location on the end machine where it is going to be installed. This DIM can be plugged into the main project owned by the installation author or the Build/Release engineer. This gives the development team the sense of ownership of the application files owned by them and reduces the cost of maintenance and authoring to a large extent.

If will be asked to rate features and benefits of DIM over the traditional benefit of adding the files and folder into the main project I would give it a 10 on 10.

I am listing down some of the key benefits of the DIM below

1. DIM's allows the flexibility to be updated and owned by individual developers
2. It creates sufficient data encapsulation to the rest of members of the project
3. Developers can add files and folders inside the DIM
4. They will have option to register the ocx and dll if required wihin the DIM
5. Environment variables can be created inside the DIM
6. Group functions can be assigned inside the DIM
7. DIM's can be build and tested in a stand alone mode there by reducing the build time and ease for the developer to test his/her application

Above all features are definitely a great boon for the developer and build engineers of distributed and gigantic applications

I have also observers some of the major issues with InstallAnyhwere collaboration plugin in Eclipse. They are big issues but still can be lived with, here are some of them.

1. If the folder addition feature in the DIM is given some filters to add the contents of the DIM, it cannot be build and gives some weired exception. The possible workaround for this issue is to add the folder as a speed folder inside the main project and then give constraints or filters
2. Files need to be physically present at the source location if you are trying it to add in the DIM. The possible work around for this issue is to create a dummy file at the specified source location using touch utility or its equivalent on any OS
3. The installer output of the DIM can not be used in a stand alone mode for the customer purpose as it shows a warning message that "This installer has been built using a collaboration tool and hence should not be used to production"
4. The most big issue is that all the plugins that are installed and used has to be compulsorily have a valid license for its use(i.e if you have a team of 100 people who will be writing DIM's for their small software piece you need to actually have 100 licenses). The only available workaround for this problem is to install IA collaboration tool on a common machine where all the developers are going to have access and each of them will be authoring their individual DIM at different point of time :(

All of the above pros and cons have taken me to the conclusion that DIM's are of great use if used efficiently and with proper planning.

Adding image to Add/Remove program

You might have noticed that when your installer is created using InstallAnywhere, the default icon is shown (probably ZeroG icon). To customize your product according to the look and feel of your comany its very important to add a customized icon of your company that is product specific.
This task is very easy to achieve, you just need to 'Set Windows Registry Entry' action to do it.
In your uninstaller registry key (eg: \\HKLM\Software\Microsoft\Windows\CurrentVersion\uninstall\MyProduct) create an entry named "DisplayIcon" with the value set to the full path to the icon you want to use. This means you'll need to install the icon file with your application.
There's also a host of other keys that IA doesn't automatically generate that you can manually create.
If you need any more detail pertaining to the issue browse through MSDN site for more details.

Pushing Install Updates to Customers

Dear readers all of you who has been involved in authoring installation projects must know the pain of IT companies in maintaining their product at the customer end. When a product goes through a release cycle the most important aspect of the company is to market the product, the most sell able aspects of the great products in the market is their ease of deployment and keeping it updated.
Companies spend millions of $$ in maintaining in release cycle and some more millions to support it, so that they are ahead of their competitors in the market. Releasing fixes, providing updates in a timely manner is their top priority so that they can win the confidence of their customers and keep the market growing for then.
But you all must realize that it requires huge investments for the IT companies for creating a dedicated support network for their customers to keep them updated with the latest fixes. Imagine a software which can update itself without any manual intervention, a system where the Administrator need not worry about reading the documentation before installing the updated manually, a huge enterprise system without going down for a single second updates itself !!
I think you must not have got surprised from the above statements, you might have already seen this "Windows Updates", "Java Updates" and millions of similar updates notification that might have gone un noticed!
These features are a must have for installers and frankly speaking they are very easy to achieve, just a few clicks during installation and here you are. All your customers will be using your latest version of the software and you can end up saving thousands of $$ on support calls.
You can add this feature in your installation product by using FLEXnet Connect from Macrovision.
All you need to do is add an update manager in your installation product, then list updates that will be pushed to the customers and you are done.
Some of the key benefits of using the FLEXnet Connect are listed below

Cut Costs with Electronic Software Delivery
Cut support costs by keeping users on your most current version
Cut product fulfillment, upgrade delivery, and renewal costs
Increase customer satisfaction by proactively delivering updates
Improve Customer Communication with In-Product Messaging
Deliver marketing messages to customers and evaluators as they use your software
Target users based on their product version, location, entitlement status, and more
Reach all of your customers directly, even if they purchased through a reseller
Improve Marketing and Development with Customer Data
Better understand your user base with data on total customer size, versions in use, and upgrade patterns
Learn how customers value your software by seeing which features are most popular
Use real customer data to create better marketing campaigns and more competitive products

For more details over the product visit Macrovision site

ASCII update problem with shell scripts in IA

InstallAnywhere supports ASCII update of files as its predecessor ISMP. But the interesting feature with InstallAnywhere is it substitutes everything between "$" sign. The reason behind this being IA resolves its variable which are in between two $ sign like $USER_INSTALL_DIR$ or $PRODUCT_NAME$

 

Here is the most interesting part which is going to attract your attention

 

A Shell script resolves its variable the same way IA does i.e the string starting with $ sign is considered to be a shell variable. Now here's the tweak if your shell script has multiple $ sign in a single line and if you are trying to update this file using IA ASCII update you will end up corrupting your file.

 

A very weired solution to this problem is to replace all the $ sign with "DOLLAR" 

Although tough to belief the Advanced designer has the feature where you can mention do not substitute IA variables but it actually does not respect your input.

 

So if you are trying to update a file that contains multiple $ sign in a file file use DOLLAR, once the IDE update the file as per your instruction it will automatically replace the DOLLAR with $

 

:) Keep reading many more to come....

Advanced dubugging during installer builds

You might have encountered many instances where you need to turn on advanced debugging options to get proper and detailed debugging information. The usual build log does not provide detailed information. Some time you struggle through a Java I/O error or your custom code or your source code management system is behaving improper.

 

There have been instances when I noticed a build success but the installation operation failing, even after trying various options with my Install Anywhere IDE nothing was useful. Finally playing with the InstallAnywhere lax properties file worked for me.

 

These were the steps I took to get things working..

 

1.) Close the IDE.

2.) Open the file <IAHOME>/InstallAnywhere.lax in a text editor.

3.) Modify the following properties in the file so they read as follows:

lax.stderr.redirect=console

lax.stdout.redirect=console

4.) Add the following line to the top of the file:

lax.nl.java.option.additional=-Dlax.debug.level=3 -Dlax.debug.all=true

5.) Save the .lax file and close it.

6.) Start the IDE with the following command:

./InstallAnywhere 1>buildConsole.txt 2>&1

7.) Run the build.

Once you are done with these steps you will notice a launch anywhere window opening during the build, when your build finishes all the stderr that you were able to see in the console windows is written into a console.txt file at your <IA_HOME> directory.

A tweak here is that, if you keep this option on-ever you will always see a debug console opening whenever you launch a InstallAnywhere application, so it depends on you discretion to turn on this feature or to turn it off as it gives you a detailed report of your operations performed at the cost of few extra CPU cycles and additional memory usage.

Keep reading there are more to come.... :)

InstallAnywhere 2008 Released

Macrovision released InstallAnywhere 2008 Enterprise and standard edition late 2007, it contains many fixes and new features.
The most important was removal of support for JRE 1.4, it came in support for Java 1.6. Other promising features that came in was support for MSI installers and Windows VISTA.

To download the latest version of InstallAnywhere browse the site

Download

Release notes for InstallAnwhere are located at

Release Notes

So old InstallAnywhere and InstallShield users start migrating your project to latest InstallAnywhere 2008 edition.

File Service in Custom Codes

Many of the installer user use FileService and Win32RegistrySerives in their custom codes. Although InstallAnywhere provides support for putting and retriving Registry entries at the software install location but some times it becomes a complsion for the installer auother to use these services in their custom code.

In order to use FileService in you custom code you need to activate support for File Service in your project. This can be checking the property in Project-->>Java-->> Check the radio button saying "Add File Service support"

This would enable your project to over take File Service of the operating system. While developing the project add IAClasses.zip, services.jar, win32ppk.jar file to your project. IAClasses.jar file is present in the resources folder of your $IA_HOME services.jar will be found inside servises folder of Resources folder. Win32ppk.jar present in the OS specific folder under services.

FileServices interface and Win32RegistryService interface is present in Services.jar and win32ppk.jar respectively which are hidden for new InstallAnywhere users as they are aquinted of using IAClasses.zip files in their project.

When developing the custom code implement the FileService and Win32RegistryService interfaces in your project. I am putting an example below on how to implement the custom code, it will help the new users for using Registry and FileService

package com.mycompany.project

import com.zerog.IAClasses.*;
import com.installshield.FileServices.*;
import com.installsheild.RegistryService.*;

public myClass extends CustomCodeAction
{
public void install(InstallerProxy proxy) throws InstallException
{
String install_path = proxy.substitute("$USER_INSTALL_DIR$");
FileService fs = (FileService)proxy.getService(FileService.class);
// Now you will be able to use all the methods in FileService
fs.mkdir(install_path+"\\bin");
win32RegistryService reg = (win32RegistryService)proxy.getService(win32RegistryService.class);
/* Now you can use the methods exposed by Win32RegistryServices */
}
public void uninstall(UninstallerProxy Uproxy) throws InstallException
{
// @@TBD
}
}

The above code snippet will explain the basic usage of FileService and Win32RegistryService in Custom code.

As a matter of practice it is always advisable to use the actions provided inside the Advanced designer of InstallAnywhere, as the custom code maintenance and writing is costlier. Always refer to your installer design before deciding on the usage of InstallAnywhere Custom Code.

If you require any clarification on the topic feel free to write mailto:jha.yogi@gmail.com