PDA

View Full Version : InstallShield Technology Comparison



doohickey11
06-22-2004, 11:33 AM
Hello All
I needed to do a techincal comparison between InstallScript MSI, InstallScript Objects and Universal Installers. It is required for the Installation Framework i am working on, If someone could please help me out with some related documentation it'll be great !
Thank You
Harry

RobertDickau
06-23-2004, 09:44 AM
For a start, you might look at the InstallShield X help section Getting Started > Projects > Project Types.

A short description of the types you've mentioned:

InstallScript MSI projects are for a product installer that uses the Windows Installer (MSI) service for data transfer and InstallScript for the installation user interface. Runs only on Windows.

InstallScript Objects are partial installers that can't be installed by themselves, but instead must be included in a full installation project.

Universal projects use a combination of Java code and native code to create installers that run on Windows, Linux, Solaris, HP-UX, Mac OS X, AIX, OS/400, ...

doohickey11
06-23-2004, 11:45 AM
Hi Robert
Thank you for all your help
I already have a comparison list of about 35 points but i wanted to add more stuff to it thats why i came this route.

Say for instance Merge Modules, Objects & Java Beans all are redistributables but what are the factors that make them different from each other?

Another question would be universal has the following run time options
1.Java Application Launcher
2.Remote Installation Option
3.An .exe file
4.Silent JAR installation
5.Installation through the browser

what are the options for InstallScript/Object & InstallScript MSI projects?

If you could help me with this kind of comaprison i would highly appreciate it

thank you
regards
harry

RobertDickau
06-23-2004, 12:05 PM
Merge modules, InstallShield Objects, and Java beans all do essentially the same thing---they're snapped into a full installation project to install data on a target machine---but each is appropriate only for a single project type (MSI, InstallScript, and Universal, respectively).

For a pure InstallScript project, the options are to create a Windows executable or a Web installation; for InstallScript MSI, the output can also be a Windows executable or a Web installation, but the underlying run-time technology used is different.

P.S. InstallScript and InstallScript MSI projects can be deployed silently, as well.

doohickey11
06-23-2004, 12:19 PM
Hi Robert
If the Requirements for Installation Framework are as follows
1. Common Installation technology
2. Maximise Code Reuse
3. Minimize Installer creation time.
4. Self Contained Components
5. Suite Installers
6. Product Installers
7. Component Installers
8. Object Re-use
9. Inter Package and Intra Package Commuincation.
10. Third Party software repackaging
11 Support Continuous Integration, cruise control/ Ant Build Scripts
12. Plug and Play Components

which Installation technology would you reccomend & why ?
Thanks a bunch
regards
harry

doohickey11
06-23-2004, 12:25 PM
I missed a very important fact that Installation is mostly for Windows Platform.
Thanks

doohickey11
06-23-2004, 12:28 PM
Hi Robert
I guess we can do Silent Installations for Universal Installer too, Please do confirm on this.
Thank You
Regards
Harry

RobertDickau
06-23-2004, 01:14 PM
Yes, Universal installation projects can be deployed silently.

As for your list of points, all project types support object reuse (merge modules, InstallShield Objects, or Java beans), automated build processes, and product installers.

Only Universal projects directly support suite installations, though MSI or InstallScript installations can launch other installations using custom code.

As for repackaging, the AdminStudio product can turn a legacy installation into an MSI installation, about which please see http://www.installshield.com/products/adminstudio/.

I'm not sure how you're using the word "component", so I can't speak to "plug-and-play components" or "component installers".

For Windows-only installations, I'd suggest InstallScript or MSI projects, since they have the highest level of integration with the target operating system. If you'll need to support other platforms, though, the Universal project type is most appropriate.

doohickey11
06-23-2004, 02:09 PM
Hi Robert
components can be referred to as a minimal bundle that is self contained and can be installed as a part of another installation or just by itself (say we wanna do a feature addition)
its similar to the levels we have
Products (Multiple Products ) Suite Installer i.e. a Base Installer
Features for an Individual Product
Components for individual bundles that go inside every product.

I hope this clears out the picture.
Based on this how would you justify those requirements.

Thank You once again

Regards
Harry

RobertDickau
06-23-2004, 09:21 PM
In that sense, there's no real equivalent to a "component" in Windows Installer, the way a child product acts in a suite installation; you could, of course, add a merge module to an otherwise empty project to install the module's data.

doohickey11
06-23-2004, 09:43 PM
Hi Robert

How would you justify the usage of InstallScript Object as the component?
For instance consider the scenario
Object as the Product (will contain multiple components each are objects) as such Object as a Component.
Thank You
Regards
Harry

RobertDickau
06-24-2004, 09:43 AM
Like a merge module, an InstallShield Object cannot be installed by itself: you would need to merge it into a full installation project.

doohickey11
06-24-2004, 07:31 PM
Hi Robert
Thanks for the reply.
Based on our earlier discussion, which technology according to you offers a best solution for continuos integration.
Regards
Harry