Evaluation Questions

[TimMayert]

I was getting evaluation questions answered from Candice Jones, but I was asking a lot so she suggested that I post them here.

I am currently using InstallShield 12 (basic MSI project) and therefore I am performing my comparison against that version, so I was hoping that the following questions could be answered:

In my IS 12 installs I mainly do Major upgrades between version, Major.Minor.Build.Patch, where only the Major and/or the Minor version numbers change and Minor/Small upgrades between individual Build and/or Patch numbers change.

On Major upgrades I usually have to change the Product Code and author a Major upgrade so that when the install sees that there is an earlier version on the machine that the install will detect that and perform the Major Upgrade, meaning that when it gets to the file transfer section it will perform the uninstall of the previous version and then install the new version.

On a Minor/Patch upgrade the install will simply detect the previous build and simply update the files that have been added or updated. No Product Code changes here.

1.) My question is does InstallAware have the same functionality and if so where do I find it and what needs to be done under Major/Minor upgrades versus Build/Patch number upgrades?

2.) Oh and another question that I have concerns custom actions. My installs again call many different kinds of custom actions, like launching apps during install, calling functions within MSI DLLs, ... etc. I can see in InstallAware where you can Run Programs during install, but I do not see where you can call functions within MSI or other DLLs without having to script the call, also I do not see if you can call MSI dlls. Can InstallAware call functions in both MSI and Standard DLLS without script?

3.) With Multi-Language support: How do you set up the InstallAware project to support multiple languages in the one install, meaning that if I support 33 languages and I install on French then the install will be French, where as if I install on German then the install will be in German. So can I have one install that will have all languages built into it?

4.) Where do you set properties so that on the MSI command line they can pass in properties to trigger different states of the install?

5.) This question is in regard to creating registry keys/values. What I am trying to do is produce an install to match one that I have in IS and therefore I need to make it do basicly the same thing and that is what is prompted my questions. What I have are registry keys that are only created if specific components (files) are installed onto the machine. If the file/component is installed then these keys will be written to the registry, but if they are not then the registry entries are not added.
So what I need to know is if InstallAware can associate registry keys with files and if so how?

Thanks for any help on these question.

[stevew]

one thing is that i don't think you should compare against "Basic MSI" instead compare to "InstallScript MSI Project" because InstallAware doesn't do Basic MSI. I think they have a WIX product that appears to generate the basic MSI files.

1. i'm pretty sure that IS has some restrictions against the simply replacing files option. One example is you can't have any new components. IA has the same types of features but it also has major update concept where the previous version is automatically uninstalled as part of the new install.

[TimMayert]

thanks for the reply.

The reason I mentioned basic MSI is because most of our installs are in basic msi format. We tried moving all our installs out from InstallScript MSI projects because of the overhead of having to include the InstallScript engine, as well we have a lot of demand for administrator pushes and you can not do a MSI push with InstallScript MSI projects by using on the MSI file, you have to push the setup.exe file and admins do not want to do that.

I also do not want to create installs with two products to support my MSI push installs and regular user installs.

Are there many people that have moved from IS to InstallAware because of feature sets, or ease of use, or just simply better than IS?

[CandiceJones]

According to our customer survey, 40% of our customers moved from InstallShield. The same survey indicates that our customers found the product easier to use and more powerful.

[MichaelNesmith]

You can build an EXE install with InstallAware, and then convert it into an MSI using the Group Policy Wizard. This will work well with Group Policy deployment, and you can also use the MSI stand-alone if you wish.

Also, note that we do not install a setup engine, or a scripting runtime, unlike InstallShield. Our EXE runs out of the box on all operating systems from Windows 95 Gold to Windows Vista Ultimate 64-bit, without pre-installation or any other dependencies. While InstallShield's engine is very brittle and can break for many reasons - such as damaged COM configuration on the target machine - you won't run into any such issues with InstallAware.

The main reason we have our EXE is to support things like better compression and partial web deployment, which are not available with the standard Windows Installer engine.

[TimMayert]

Okay Thanks again for the replys.

Could I also get some information on the other questions that I asked at the top. Again I am attempting to generate an InstallAware install that performs the same install as one of my InstallShield basic msi projects and I have to see how easy it is to duplicate it in InstallAware and make sure that I can perform the same tasks. This way if I can do the same things and it is easier to work with and deploy then I will be able to present this to my managers to see if we can move over to it.

Thanks again for your help.

[stevew]

Also, it is my understanding that IA uses SPX technology to kick off the running of the exe. This is some kind of standard self exploding zip file type thing. Back in the early days of computers (windows for workgroups 3.11) I believe there was limited support for this therefore IS created their own exe loading technology. I think since windows 95 then SPX has become fully supported. I just think that IS people keep using their proprietary loading technology because then they can keep their jobs. maybe i'm wrong but this is what i think and am curious if i am wrong?

[stevew]

sorry about rambling tim, i am confused with so many questions. i also use multi language capability and it is definately different in IA although you can achieve the same results so long as you can translate yourself.

[TimMayert]

What do you mean by translate yourself?

Now we do translate any new strings that we add to the install, but if the string is already built into the installer - IS standard dialog and error strings then we leave them as is.

Can I build a single installs that supports mutliple languages and therefore if you run the install on German the install is German, but if you run on Japanese then the install runs in Japanese? Or do you actually have to create installs for each language your application supports?

[stevew]

yes you can do these multi-language setups. you ask the user to select the language at the beginning.

you have to figure out how to translate all the standard strings. nobody is going to do this for you.

the snag i have found with multi-lang stuff is that some of the setup uses text from the currently installed O/S on the target machine. So even if you are running a French install, if it is on an English Windows machine then you will see some messages/buttons in english. For me, what i did was avoid all the standard message boxes, and made custom dialogs for message boxes. This way i could avoid any O/S message boxes.

i think you better try the samples.

maybe michael will tell you some more details or correct me where i am wrong.

[TimMayert]

I guess I am still a little confused about the translation part of the question.

In InstallShield they have all the string tables for all their support languages and therefore if I build a basic install with 5 support languages built in, with no translation changes/requirements from me, then you run that install on any of the 5 support language machines the install will always be the language of the OS. So I did not have to do anything to get my installs running in the language of the OS.

So in IA I have to have all standard text strings translated into all languages we support? What are the standard strings? If IA state they support the same amount of languages as IS what are they referring to, is it if you are creating a single language install then you would select that language as the default language and then the install will be in that language, but if you want multiple languages in one install then you can only select one language and then all other languages have to be put in manually and manually translated?

I guess I need more clarification on this as this would be a big issue for us because most of our installs support up to 32-35 languages now and this would be a requirement for any install application that we get.

Thanks,

[TimMayert]

I have not heard back from anyone on this translation issue. Again what strings need to be translated and how do you get your single install to support many languages in the one package?

[MichaelNesmith]

In the IDE, on the Design tab, in the Tools group, click the Localize button.

Then, press F1.

[mr. dizzle]

IA does not have any translated text. You have to export all the languages, and then get them translated yourself, and import them back in. When you import them back, you get the option of which languages you'd like to support (tick boxes), and then in your project settings you choose your default language and there is an option to include a language select in your app (which will use the languages you imported)

[TimMayert]

Well if that is the case then why does it state they can support 34 languages? If you can simply import the language strings then why not just support all languages if it does not actually have any language strings built in.

With InstallShield they support 33 languages and if you create an install and select all supported languages then you automatically get all default language strings already translated. So if you use all default dialog boxes and do not have to add any extra strings then you are good to go on all the support language OS's as the instal will appear correctly.

The only time you have to have the entire string table translated is if you want to support a language that is not currently supported in IS. Meaning you can actually suppport more than the default number of languages as long as you add it and make the correct setting adjustments to support that language.

I guess if this is the case and there is no built in default language strings for all the supported IA languges then that would explain why it is cheaper than IS as they do not have the cost of translation into the product.

Thanks for the info.