InstallScrip, MSI or InstallScript-MSI project

[vanyans]

I haven't found ant recent conversation on this topic so I figured I start one :).
Some time ago InstallScript-MSI was not recommended as it had some problems combining two engines. I am interested to know if that changed with InstallShiled 2008.
Also if anyone is willing to add a comment on the experience with any of InstallShiled 2008 project types it would be greatly appreciated.
There are also some rumors that InstalScript projects would be dropped at some point. Does anybody know anything about this?
Thanks in advance.

[KathyMorey]

I would recommend using either InstallScript (if you don't need the Windows Installer functionality) or Basic MSI. There were definite improvements in the script engine in IS12, but it still can be tricky supporting upgrades, reinstalls, modifies and the like with InstallScript MSI, in my experience.

If you do use InstallScript MSI, I would recommend that you only use scripting for the UI itself. Don't make any changes to the system through the standard scripting events. All system changes should be made through the MSI (including InstallScript custom actions running deferred in system context).

[Kelter]

In my experience, i've found that you can do anything you need to in any type of project. Installscript installations don't make use of MSI, so i'd pretty much leave them out alltogether.

Installscript-MSI is good in that you can configure your files, reg entries, and other system modifications organized into components, keep your components organized into features, and leverage MSI for it's handling of optimized patches, upgrades, and installation modifications, while still handling the behavior of your installation in code.

Basic MSI offers a few distinct advantages despite the learning curve. Once a project is built, it's relatively easy to manage. A well designed (and documented) project should only require small tweaks to maintain throughout the lifetime of the product when new features are added, or some additional functionality is required. Someone with installshield experience should be able to pick up the project and maintain it with little ramp-up. Also, if all the functionality is done in the MSI tables, the transition to another MSI product (can i say that on this forum? 😉 ) would be much easier, so you won't be tied to IS...just in case.

That's my 2 cents. Don't spend 'em all in the same place.

[jedimaster_mark]

InstallScript MSI was designed for and intended for InstallScript engineers who wanted to move to MSI back when MSI was in its infancy (InstallScript is much older than the MSI format). I have never heard a truly valid argument for ever creating a NEW project as an InstallScript MSI project these days.

Generally, you'll want to either go with a Basic MSI, or an InstallScript project, but which it really a preference issue. Since either one can call into an external DLL or EXE to perform non-standard functions, they can both effectively do whatever you want them to do.

[Christopher_Pai]

jedimaster_mark wrote:
InstallScript MSI was designed for and intended for InstallScript engineers who wanted to move to MSI back when MSI was in its infancy (InstallScript is much older than the MSI format). I have never heard a truly valid argument for ever creating a NEW project as an InstallScript MSI project these days.

I don't know if I really buy that but then again, I never sat in the business meetings when these decisions were made. Regardless, I'll give you one really solid reason for InstallScript MSI projects: When you want to leverage the capabiliteis of MSI and have an external UI handler for an exceptional user experience.

I personally don't have that requirement in my installs, but I could see a lot of ISV's ( think game companies ) that do and native MSI UI just isn't that cool looking for them. So for my needs, I still with Basic MSI projects with InstallScript CA's.

[jedimaster_mark]

That's just what I was told when I was at Macrovision for InstallScript training. So it's third hand, and may only be half true.

But I do custom dialogs in MSI all the time. Not all of which are MSI dialogs. We sometimes use DLLs to create them, and have never had a problem. Admittedly, InstallScript makes doing custom UI stuff easier, but then you have the complexities of that mixed-mode installer to deal with.

[Christopher_Pai]

Sure, and I've seen people implement UI's using .NET Forms inside an Installer Class CA from within the installation transaction. Scary heh?

My point isn't that it's the only way to create a UI, it's just the way provided by InstallShield. If you want to roll your own external UI handler it's entirely possible. But if your looking for a valid reason to use InstallScript MSI projects, there it is.

[vanyans]

Thank you all for your comments. It was really helpful.
Our decision was to go with InstallScript projects.