5 replies to this topic

[rjones0604]

I'm a longtime user of InstallShield for setup development, having started with version 3. I've seen the progress of IS from a purely script-driven product, through the Windows Installer versions, and now IS 8. I have a setup project that has been upgraded since IS 6 and has always been a 'basic' MSI project. I've never taken the time to convert the project to a standard project, having never enough time. Well, I now have the time. We just shipped the latest version of a product whose setup was built with IS 7 as a basic MSI project. I've just downloaded the IS 8 upgrade and will be converting this setup to IS8. My question is this: I now have enough time to explore not only upgrading to IS8, but potentially converting from a basic MSI project to a standard project. What I'm looking for is other setup author's experiences with developing a standard project vs a basic project - specifically:

1. What are the advantages of a standard project over a basic project?

2. What about converting a basic project to a standard vs simply creating the standard project from scratch?

I understand that the entire operation of a standard project is script-driven, and as a long-time programmer, my instincts tell me that this is always a better choice than the way basic projects operate. For example, whenever I find that I need to have a new dialog appear in my project (only under certain conditions), I cringe, because I know that this is error-prone, what with the complex conditional statements that are necessary to get the new dialog to appear only when required. With a script-driven setup, I would imaging this to be much better.

Anyway, thanks in advance to any and all comments, help, thoughts, etc.

Rob Jones

[Stefan Krueger]

In most cases I would recommend Basic MSI. It's leaner and more robust. Also System Administrators who need to deploy your package in their network will hate you if you use InstallScriptMSI because you can't run the .msi directly (must use the setup.exe launcher) and they can't see the logic inside oyur package (because it's a compiled script)

There are few situations where InstallScriptMSI is better, e.g. if you need specific user interface effects that are not supported by MSI.

BTW in version 8 InstallShield change the name of project type "Standard" to "InstallScript MSI", and made BasicMSI the default type.

[rjones0604]

Thanks for the info, Stefan.

For my current project, running the admin version of my setup is probably not too useful, as the product is not an end-user tool, but rather gets installed on one server within a routable domain / ip mask. One of my big complaints with the Basic MSI is the heartache I must go through every time I need to add a dialog that is conditionally displayed. The conditional logic that must be modified in the previous and next dialogs in the sequence gets an order of magnitude more complicated with each new dialog (and with each new condition that needs to be checked). Handling this problem in script is trivial for me. As for interface 'effects' (billboards, etc) that doesn't matter much. I'm also a little concerned about the conversion process (from Basic to Standard) and how much functionality that currently works properly in my Basic project will get trampled on during the conversion. I don't have any confidence in IS's ability to do this feat properly, having lived with their product for several years! However, I do have the time available now to fix what get's broken, in addition to writing whatever script code is required.

Rob

[Stefan Krueger]

I agree about the dialog logic.

Conversion shouldn't be that hard, because you basically put InstallScript on top of your existing project, i.e. all of your logic should stay. Of course you loose anything you had in the UI sequence, and not all settings will have effect in the Script UI.

The other way (converting from InstallScript MSI to Basic MSI) would be harder.

Remember that InstallScript adds to the overall complexity, and the potential for bugs, and has problems with upgrades.

[Glytzhkof]

Hi, I just want to add my 2cents to this thread, as I think it is a very important issue for people to be aware of.

I will be blunt: Standard projects just don't work! They have major problems for upgrades (standard Installshield 7 projects can't really be updated properly using major upgrades). I have also had a lot of problems with patching (though some of these problems were caused by myself). And finally I get a lot more runtime errors (IDriver.exe etc...) with standard projects.

Ditching standard projects will make the user interface of your setup more "basic". You will lose the event model (OnError, OnBegin, OnUninstall etc...), but all in all this is a small sacrifice for all the headaches you will avoid. I don't even understand why Installshield insists on providing this standard project feature. It must be a "legacy thing" since they want their old script users to be able to "feel at home".

[luke_s]

I just also wanted to add my 2 cents...

I would go with a basic msi. These are a lot easier to debug since they don't use InstallScript and also if you need to create merge modules, you cannot include InstallScript in these either.

My only concern about about basic msi's is the complexity that the dialog logic can get into, but this all comes down to how you have setup your project etc.