Questions before moving from InstallShield to InstallAware

[zims]

I am currently using InstallShield but for several reasons I am currently looking for another Windows Installer authoring tool.

I have installed InstallAware (trial) and made some small tests and have the following questions before I start with a “serious” project.

1 COM Registration
My application has 15 COM files (dll and OCX) that need to be registered during the installation. In every new version, patch we release some COM files have been updated and that means that the COM interface has also changed. This means that the registry data written during the registration needs to be updated. When using InstallShield they have a nice feature that will Extract COM registry data during build, this saves a lot of time since I don’t need to update the registry keys manually in InstallShield.

In InstallAware I have not found a similar feature. I have found 3 ways of taking care of COM files in InstallAware.

1. Set the files a Self Registering DLL (This is not possible to use since my files must be registered in a specific order.
2. From the part in the designer where I add Registry data I can Extract COM registry data from each file, this I guess works fine but since the extracted information changes often it will be impossible to manage this in a good way. I might have worked but since it is not possible to “filter” registry data based on files I thing will not work for me.
3. In the Script editor it looks like I can add a command called ”Registrar Library”. I think this one might solve my problem since I guess it will call RegSvr32.exe to register the file. This feature will give me to possibility to control the order the files are registered in. But I am not sure if my installation will pass the Windows Vista Logo if I use this script. Anyone have any experience of that?

Is there any other way than the 3 I mentioned above how to handle COM registration. I have search the Help for InstallAware but I can’t find any useful information about how to take care of the COM registration.

2. Same file in many Features
Lets sat that I have a project with 3 Features A, B and C
I have 1 files that shall be installed if the users select Feature A or B, but if the user only selects C then the file shall not be installed.

I have tried to add the file two times, for to Feature A and then to Feature B. But this results in that my file will be displayed 2 times if I remove the checkbox “Filter files by fetures” while looking at the files.

In InstallShield you create a Component for the file and then add the component to both features. To add the file 2 times in InstallAware feels wrong, how should I do this?

3. Install merge modules based on selected feature
I have 10 merge modules that needs to be installated with my application. But my problem is that I need to install them based on what Features has been selected.

In InstallShield you select the Merge Modules connected to Features, how can I do the same in InstallAware.

I have the same Installation program for both server and client installation. For example if you run a Server installation then I don’t want to install Crystal Reports since Crystal reports are only used by our client application.

4. Preserve registry settings during Update
When updating my application to a new version I would like to first uninstall the old version. The problem is that I need to preserve some registry settings before uninstalling the old version. When making small updates (patch) this is not necessary, but for bigger updates this is the best way if we need to remove files, add/delete features and so on.

Am I correct when I say that it is possible to do this with the script functions in InstallAware.

[zims]

5. Localized shortcuts
My installation program will always be in English, but one step during the installation is that the customer will select language. This language selection will be used to localize the test on the shortcuts and folders created, not the installation UI.

Is this possible to do with in any way? I took a quick look at the translation wizard and it looks like it only translates the installation UI, am I correct?

6. Install custom Pre-req.
In InstallAware there is a lot of pre-req that can be installed before my application, like.NET Framework and so on. I have also seen that it is possible to download even for pre-req from the website.
My questions is if it is possible to create my own Pre.rew

7. Source Control integration
Is it possible to save project files in a source code controller like Microsoft Team Foundation Server?

As far as I can see there are a lot of files called .dfm and since they are binary files I guess it is not optimal for source code integration, right?

8. Passing command line options to MSI from Setup.exe boot straper
Today I distribute my installation program as a singe setup.exe. When running the setup.exe I can add comandline options that will be passed to msiexec like adding/removing features and so on.
Is this possible with the Setup.exe generated from InstallAware.

9. Integration with Visual Studio 2008
After Installation of InstallAware I can only find a new toolbar in Visual Studio. I was expection a new project type so that I can add my installation project to my solution, is this not possible.

I am currently using Visual Studion 2008 SP1, Developer Edition

Summary
Well this is what I need more information about before I start with a new application. So far I must say that I like InstallAware. InstallShield has always a lot o bugs and are hard to use. I think InstallAware looks promising, I just hope that I will be able to do everything I need and also be able to make a Vista Logo cert. installation.

Zims

(Sorry for multiple post but I think my post was to long, I had to split it)

[CandiceJones]

1. Use option 3, that is perfectly fine for Vista logo testing as well.

2. Yes its wrong, the correct approach is to set a variable to true when either feature is selected and then install that file when that variable is true in its own If section.

3. You cannot do this with MSMs in InstallAware, but you can convert the MSMs into MSIs and conditionally install them or just use non-MSM versions of those technology runtimes with InstallAware (ex: we already have a runtime for Crystal Reports that plays well with web media blocks and conditional installations unlike MSMs).

4. Yes you can do this as easily as setting persistent variable values!

5. Wrong, it also translates your script commands, and will let you localize Shortcut names for instance.

6. Yes of course, we even have a whitepaper that describes how to do this.

7. Yes, you can add everything in your main project folder (not subfolders) minus the DLL files into source control. They are needed for your whole project.

8. Of course, you have access to the command line via the CMDLINE variable.

9. No, there is no project type for VS - the InstallAware project is automatically created and refreshed without having to have another container VS project.

[zims]

Thanks for you quick answer, I will defently give InstallAware a try during next week. But I have a follow up question.

Your answer to question nr 4 suggested to set the registry values to Persisten. I don't think this is a good solution for me since I want the registry values to be removed if the customer UnInstalls my application.

Since I need to update a version of my application created by a older version of InstallShield (where the registry keys are not Persisten) I guess I have to read the registry values before the UnInstall and then in the end of the installation process write them to the registry again.

Am I corrent when I say this is no problem with the InstallAware scripts?

Thomas

[CandiceJones]

You misunderstood, I am not taking about making a registry entry persistent, but an InstallAware script variable value persistent. This way the variable value will be recalled even when a newer version of the setup for the same product is running, automatically.

Although of course you can also use the method you thought of below - reading the registry before uninstalling the old version - using the script. That'll just be more of an indirect route, when you have the ability to directly persist your script variables.

[zims]

Ok, I think I understand, sounds like a very easy and good solution.

From my simple test so far and from your answers I think the scripting in InstallAwere looks very nice. Many things can easily be done with the scripts. I am realy looking forward to try InstallAware next week and hopefully with good results.

Thanks for your quick response.

Zims

[CandiceJones]

You're very welcome!

Please keep in mind the following two major differences between InstallAware and InstallShield scripts - both of these work to your advantage, save you time, simplify your setup:

o The visual designers in InstallAware emit the underlying script for you. Unlike InstallShield, the script is not divorced from the visual designers. This helps you rapidly design your setup visually, and then drill-down to the script to customize just what you need. In the script you have full access to - and full customization over - what you just prototyped in the visual designers.

o The InstallAware script is not just a new "language", a la WiX, to define MSI file creation. It actually adds runtime branching, decision-making capabilities to Windows Installer. Just like a BAT file, you can branch and control program flow. These runtime "decisions" are transparently applied by InstallAware to your MSI file, creating the full effect of runtime customization over your MSI setups WITHOUT transforms or other complex methods, and on ALL MSI platforms, including Windows 95.

Enjoy your product!

[vipul]

is there a converter available from installshield script?

[CandiceJones]

My colleague has replied to your post in Sample Scripts. Please do NOT cross post the same subject in multiple areas.

[zims]

I just would like to let you know that we have now purchased InstallAware Studio. I just would like to give you some feedback.

1. It is really great that you have the Trial version. With the trial version I was able to test you application fully to see if was something for us.

2. The forum has been a big help while testing InstallAware.

3. I have been working with InstallShield and basic MSI projects before. The difference between InstallAware and InstallShield MSI projects are big.

During this process I have gone throw a document that helps people like me to move from InstallShield to InstallAware would have been great. It should contain information about the difference about PRODUCT_CODE, UPGRADE_CODE and so on. It should also talk about the difference with updates (Uninstall in InstallAware, Major and Minor updates and so on).


After the migration I have made I must say that I have full control of our installation. With InstallShield there were some parts that worked but I did not actually understand why and how. With InstallAware I have full control and am now able to make our installation much better than before. It is also very easy for us to create a setup for a new version of our application. We have a batch file that extract the version of our application for our assembly and then sets the version with a compiler variable. This way we can automate our builds and very easy get a setup for our latest version.

The only thing I am missing right now is the possibility to use relative path in InstallAware.

Keep up the good work.
Zims