48 replies to this topic

[hgaard]

Well what would like to know is how I can determine which kind of project to use. Like when it would be an advantage to use one or the other. It would also be nice to hear some comments on how they are at handling patches and updates, and how they can be customized.

I hope someone can give me some kind of input on this, since I have found I rather hard to find any useable documentation on this..

[Stefan Krueger]

In most cases I would not recommend "InstallScript MSI". If you want to use Windows Installer (MSI) go with "Basic MSI". Otherwise use a pure InstallScript solution.

[Glytzhkof]

I have had a lot of problems with Installscript MSI setups, and have had to convert them to Basic MSI setups. Save yourself a lot of trouble and go with Basic MSI. In certain ways it is clunkier (some technical restrictions in how you declare Installscript custom actions, but nothing major).

[emiii]

Could you guys explain to me why Basic MSI is recommended over InstallScript MSI? I'm pretty new to InstallShield, and right now I have only worked with InstallScript MSI. I do see many problems, but I assume that's because I'm unfamiliar with it.

Seems like it's easier for me to control what and when something happens in InstallScript MSI because you have all these event handlers that you know when each is called. I mean, I do most of the actual work in InstallScript, and I heavily make use of event handlers like OnBegin, OnXXX(feature)Installing/Installed/..., OnAbort, etc. If I switch to Basic MSI right now, I wouldn't know where to put all these stuff. I assume everything has to be custom actions, but I don't know where to insert the custom actions because the sequence is totally confusing to me. And I could not find any good documentation on sequence. If there are two sequences, one for install, one for uninstall, then it would be much easier for me to understand. But now everything is in one sequence and I just don't understand how install and uninstall can be all contained in there.

Anyway, if someone could give me some advise, that would be great!

[Stefan Krueger]

There's nothing wrong with InstallScript itself. The problem is the connection of InstallScript and Windows Installer technology. If you feel more comfortable writing script, go with (pure) InstallScript, without MSI. But if you have a requirement for MSI, prefer Basic MSI over InstallScript MSI.

[Glytzhkof]

THE big problem I had with Installscript MSI setups, is the horrendous "Major upgrade causes system changes to rollback" problem: http://support.insta...ticleid=Q107649.

In short: it is so difficult to hook up Installshield Professional's event model to the Windows Installer technology, that it just doesn't work correctly, and I don't think it ever will. Like it or not you will have to get familiar with Windows Installer silly sequencing system where the same ExecuteSequence is used for install, uninstall, self-repair, patching and repair. I agree that this sequence stuff is the worst part of windows installer. It is absolutely crazy that there is no more documentation where to put custom actions and how to configure them.

If I were you I would locate the help topic "In-Script execution" in Installshield Developer help. This section explains the different "run settings" for custom actions, and this is important to know (I should have read this earlier to avoid some of my mistakes). Then just create a Basic MSI project and insert a script file. The script file contains the information you need to create Installscript custom actions. Create a custom action, point it to your Installscript function and finally insert it into the sequence and you are ready to go.

Edited by Glytzhkof, 16 August 2014 - 01:04.

[emiii]

Thanks a lot for your answers!

Sorry for the silly question, but what is pure InstallScript? I mean, in InstallShield Developer 8, you can either create InstallScript MSI or Basic MSI, how do you have a purely InstallScript project?

I actually read the "In-Script execution" help already. But I'm still confused about the sequence thing. For example, in the execute sequence, you have a bunch of actions called "RemoveXXX" in the beginning half of the sequence. Later in the sequence, then you have the movefiles, installfiles, etc. actions. My only guess is those "RemoveXXX" are called only for uninstallation, and the installfiles, etc. actions for installation. But then when I look at their conditions, none of them has any condition, so they are executed always? Why, how, huh?

But anyway, thanks again for your help!

[Stefan Krueger]

In Developer 8 there is no "pure InstallScript". With oure InstallScript I mean the way that setups used to be created in InstallShield Professional 7.
Now the two product lines, Developer and Professional, have been combined into one product, called InstallShield DevStudio 9. With DevStudio you can create Basic MSI, InstallScript MSI and "pure" InstallScript (with no Windows Installer/MSI at all), plus some additonal types like SmartDevice/Windows CE.

[HappyGod]

Hi, I've been hired by a company to assess their current MSI setup. They're currently using InstallShield DevStudio 7.01.

I've always been a big fan of Wise for Windows Installer, just because it provides more pure MSIs.

My question is: Does an MSI with heavy InstallScript reliance cause problems with Active Directory distribution? and Can an InstallScript MSI still be Microsoft logo certified?

Thanks for your input.

[Glytzhkof]

I have never used DevStudio, but I assume it allows you to create "Installscript" and "Basic MSI" setups just like Installshield Developer.

Installscript project
In an Installscript project the user interface sequence of the installation is run as a script whereas the installation is run with the regular MSI InstallExecute sequence. In other words this does make the installation non-standard in terms of windows installer. This project type has a number of problems and is NOT recommended to use.

Basic MSI project
If the Installshield project is a Basic MSI project, this means that windows installer is used to run both user interface and execute sequence. In this case Installscript is ONLY used for custom actions in the setup. Since custom actions can be written in any language, Installscript is just another alternative for use in custom actions. As such the setup can still be a "vanilla MSI setup" even though it uses tons of Installscript code. Installscript code is essentially run as a dll-custom action. Note, however, that the Installscript custom actions requires the Installscript engine to be installed on the system to run. This engine does the job of communicating with the windows installer engine.

Hope that provided at least some useful info.

[Stefan Krueger]

The first project type that Glytzhkof explained is actually called "InstallScript MSI". It has a problem with Active Directory as it can only be launched using setup.exe, but not by running the.msi file directly. I think it's still logo compliant, but not Active Directory friendly. Because of this, anmd some other issues, I generally do not recommend InstallScript MSI.

In DevStudio there is another project type called "InstallScript" (without "MSI") which makes no use of Windows Installer at all. It is purely based on InstallShield's scripting engine, and is basically the same as in InstallShield Professional.

So the basic project types in DevStudio 9 are:
1. Basic MSI
2. InstallScript
3. InstallScript MSI
4. Smart Device

Where 1, 3 and 4 (I think) were available before in InstallShield Developer, and 2 in InstallShield Professional.

[emiii]

Thanks a lot for your explanations. Happy holidays!

[hsong3]

thank you guys. i learn a lot from this.

however, i have one more question that relates to installscript and installshield product, vbuild2.

i hear this product can be used by only professional. is this true?

[Stefan Krueger]

vBuild can only be used with InstallScript projects, including Professional 7 and the "InstallScript" project type in DevStudio 9. It can not be used for Windows Installer (MSI) project types like "Basic MSI" or "InstallScript MSI".

[dsumners]

PLEASE use Basic UI. By creating InstallShield driven installs & requiring setup.exe, your killing us in corporate environments!

Thanks!

[Glytzhkof]

I agree dsumners, much of the benefit of MSI is the open format and hence the "for free customizability" achieved for corporate customers.

So use Basic MSI for the following reasons:

• It is standard and hence better for corporate depoloyment
• It is more light weight than standard
• It is less buggy
• If you don't need Installscript but write all custom actions in VBS you will not need to include the installscript engine in your setup. The installation of this engine is a frequent source of problems for me. As far as I know the Installscript engine is always needed for standard setups
• The event model of standard setups doesn't work properly as far as I can tell
• There are still some events you can use in Basic MSI (about 4 I think)
• Etc...

Edited by Glytzhkof, 16 August 2014 - 01:05.

[luke_s]

I also agree with Glytzhkof and use a basic msi

I believe that they are easier to debug/maintain and do not have to added complexty of Install Script

[Stefan Krueger]

Your choice also depends on your target customers. For corporate customers Basic MSI is what you should use. For home users, (pure) InstallScript may be okay, although in most cases I would prefer Basic MSI here as well. In my opinion you should avoid InstallScript MSI (previously called "Standard Projects") as much as possible.

Remember that VBscripts depend on the scripting runtime on the target machine, which may be disabled to protect from viruses. The safest way for a custom action is a DLL written in C or C++ (no MFC of course!)

[tsquared]

Good stuff here, I just have a couple questions and a comment. Why is InstallScript MSI so bad? What is wrong with it? Is pure Installscript any better or does it have the same problems?

The problem I have with Basic MSI is that it seems you need to know a lot about MSI, specifically the sequence of actions. If I need to really learn MSI, why do I need InstallShield? It seems if I learn MSI, I can create installs myself and InstallShield doesn't buy me much, at least not worth the cost. I bought InstallShield so I wouldn't have to learn MSI.

[ConfigControl]

I am new to the Dev9, which I am getting soon so I can localize my installs, I currently use the InstallShield Professional - Windows Installer v2.03. I have some custom actions written in Installscript but I don't use the events to trigger the custom actions. With that in mind would I want to upgrade my installs to Basic MSI or Installscript MSI type install.


Thanks,
Jim

[Stefan Krueger]

Basic MSI

[ConfigControl]

So with a Basic MSI I will be able to include the Installscript engine so I can continue to use my current Installscript funcitons in the Custom Actions?

Thanks,
Jim

[Stefan Krueger]

yes, Basic MSI is essentially the same project type that you know from InstallShield Professional - Windows Installer Editon 2.03. You can use InstallScript in custom actions, and install the InstallScript engine using the setup.exe launcher, or alternatively using a merge module.

[Arcangel_666]

Hmmm... I wish I would have read this before commiting a bunch of Installs to InstallScript MSI.

Does anyone know if I can convert an InstallScript MSI project to a Pure InstallScript project in Dev 9? This might be enough to get a budget to upgrade to Dev 9...

Thanks for the info

Nick

[Stefan Krueger]

I think there's a conversion tool for download from InstallShield (not built into DevStudio 9) but of course it can't convert hte logic you coded in your script to MSI entries.

[Glytzhkof]

Converting an Installscript setup to Basic MSI can be done manually in a few hours of intensive work provided the setup doesn't have thousands of components.

What I did was to create a new Basic MSI project. Then I opened the Installscript project and used the "Export into..." feature available when you right click a compoent. You then navigate to the Basic MSI project and select it. The component is then copied with the same GUID etc.. as in the original setup.

I know for a fact that there is a tool available for download that will zap an Installscript project into a Basic MSI project. But this resets all sequencing and you need to recreate all your custom actions, so it is essentially just a transfer of component and features.

[Glytzhkof]

[Zweitze]

I happen to know a bit or two about Active Scripting (even wrote an alternative script debugger)...

Active Scripting is introduced with IE4, although available through a separate download. This means that on Win95 and WinNT4 you may run into a system without scripting possibilities. Active Scripting adds scripting technology to any 'host' program. Well-known hosts are Internet Explorer, WScript.exe, Cscript.exe and Windows Installer.
The DLLs Vbscript.dll and JScript.dll merely implement the VB and Java script languages. They are installed by Active Scripting, which itself consists of more DLLs (eg. Scrobj.dll). Scrrun.dll contains some run-time objects commonly used in scripts, including FileSystemObject. This object was used by many viruses. As a result, some anti-virus companies started to redirect these coclasses to their own objects.
It's quite impossible to disable Active Scripting, and keep your system healty at the same time. However, disabling FileSystemObject is really easy: Just install a product like Norton AntiVirus and turn "Script blocking" on. Doing this keeps FileSystemObject behave as it should, until a potential dangerous method is called (eg. CreateTextFile), in which case NAV kicks in and shows a message about dangerous scripts.

Reading the quotes from Bob Bakers book, I think that he means by "Windows Scripting Host" just WScript.exe and CScript.exe. In that situation, you cannot run a VBS file. You can still run scripts, of course: just add some headers etc. to turn the file in an HTML file, and IE is more than happy to execute your script.

Turning your CAs into C/C++ dlls (or Delphi, as I use) is a good alternative. However, the downside is that scripts allow administrators or other developers to learn and change the functionality. For example, take a look at the MDAC 2.6 MSM from InstallShield: it failed on Win2003, and we could all correct the mistake.

[vladb]

Can someone tell me what are big the bugs/problems with InstallScript MSI in DevStudio? I'm about to start a project, and I need customized UI, multiple setup types, but also the convenience of MSI (I don't want to write all in code). So please tell me in what precise bugs or problems have you encountered with the InstallScript MSI project type in DevStudio 9?

[vladb]

[luke_s]

From my experience and reading it is hard to point out individual bugs with Install Script, but there have been quite a few posts about the install script engine not installing properly, and errors in starting the engine up.

Can somone else provide any more specific details?

[Glytzhkof]

If you read this entire thread you will find very clear and explicit advice as to why you should not use Installscript MSI. However, I do agree that one of the major problems with Basic MSI is the poor dialog support. In this particular case Installscript MSI is better, but this does not in any way make up for all the problems you will have with Installscript MSI. Really.

To add entries to a combo box in Basic MSI you need to temporarily change the MSI database using SQL. See this thread: http://forum.install...?showtopic=6634

If you find you need more advanced dialogs than you can accomplish using Basic MSI, I would actually recommend not using Windows Installer at all, but use a regular Installscript project.

[vladb]

Thanks, I had already found the solution for the combo box. I still find it complicated for what it does.

Of course, I thought about InstallScript only, especially because my install project will then be maintained by programmers. However, I don't want to install DSNs by writing to the registry, and some other stuff like starting/stoping NT services, writing to ini files and registering objects is pretty convenient with MSI. So my first question is, can you do this easily with InstallScript? By "easily", I mean I don't want to write keys in the registry and keep track of them for uninstall(I have hundreds of them in one project) or upgrades. So call me hard-headed but untill someone points out a precise reproduceable problem, the logical solution is still InstallScript MSI. And I already read the whole thread, but I'm not satisfied with explanations like : it's a mix of two technologies so it's not good. In itself, that's not a problem, is it? If you mix a text editor and a compiler you get an IDE, and i don't know about you, but I don't write code in notepad and then compile and link it in command prompt anymore, if you get my point.

[vladb]

[luke_s]

Well Stefan has probably posted the only really precise details on a problem involved with using Install Script, but if I was you, I would have a browse through the Install Script forumns, and possibly do a search on google to see the issues that other people hav raised.

From my experience, I have seen HEAPS of issues regarding the installalation of the Install Script engine - Windows Installer - Error 1607 : Unable to install Installscript using scripting runtime

With a basic MSI, almost ANY problem can be worked around, either it be by a custom action, or some changes to the msi table, but with install script problem like the engine not installing cannot be fixed by writing code yourself.

But in saying that, if you still go ahead and only base your decision on *precise* details, then you have been warned

[Glytzhkof]

Apart from many small details during development that I cannot recall, here is why we had to scrap Installscript MSI altogether: "Major upgrade causes system changes to rollback" problem: http://support.insta...ticleid=Q107649.

This bug in Installshield Developer caused any system changes. ANY system changes done through Installscript to be rolled back at the end of a major upgrade. This is not a problem if you don't use Installscript at all, but as soon as you do problems result, and there is NOTHING you can do to fix it. I am not even sure if this issue is fixed in Installshield X.

Finally Installscript is not real Windows Installer, so it does not really make sense to use it. The benefits of the open Windows Installer for system administrator customization is basically lost, and the whole setup will run slower because you have the complex windows installer combined with the Installscript event model. This sums up to more complexity, more things that can go wrong, and slower execution. And bugs.

Basic MSI is leaner, faster, standard, less buggy. Your choice .

Edited by Glytzhkof, 16 August 2014 - 03:24.

[mishka]

I just wanted to share our experience with "InstallShield MSI" project. We have chosed it because it allows a more rapid development (at least for a programmer) and allows a greater control over the user interface. Anyway it took a long time to develop our installation package..

When the time has came and we had to install our product at customers' sites problems started to appear. For example at the very beginning of installation a message "1607: Unable to install InstallShield Scripting Runtime" or "1608: Unable to create InstallDriver instance". Or at the very end of installation the process stuck in "Removing backup files" stage with IDriver.exe taking almost all CPU time. When a customer sees such cryptic messages you will not start to explain him that "this is known bug of InstallShield" or "something is wrong with your account" etc..

We've purchased a gold (!) support plan from InstallShield and the only answer that we've received (at least for first two problems) was "Move to Basic MSI project and the problem will disappear". They're still researching the third problem (it has been a month now).

So please take my advice: if you're starting a new project AND you don't mind to learn MSI a little AND you don't mind that your UI will be less striking - chose "Basic MSI" and use InstallShield product only as IDE for developing MSI projects..

[Glytzhkof]

Hi mishka, did you migrate to basic msi yet? If not there are some tricks to speed up this process a little (no magic, just small things to speed things up).

[Stefan Krueger]

Please note that I don't say that InstallScript is bad. The problem arise from the combination of InstallScript and MSI which used to be two distinct installation technologies. So if you don't want to learn MSI and prefer a script language, then I suggest you use the InstallScript project type. That means the "pure" InstallScript, without any MSI, not the "InstallScript MSI" which is InstallScript on top of MSI.

[mishka]

To Glytzhkof:
No, we did not migrated to "Basic MSI" yet. Its a huge job considering that we also want to get rid of InstallScript engine at all. Currently we have a lot of logic developed with InstallScript and moving all this to C/C++ DLLs for using in CA will be a lot of work. Also learning MSI will take much time. And of course thorough QA after that.. But we will have to do it someday

To Stephan:
If you're using "pure InstallScript" project you're loosing you compliancy with Microsoft. So if you will ever want to be eligible for Microsoft Logo - you will have to rewrite your installation package anew..

Edited by mishka, 07 June 2004 - 14:20.

[Stefan Krueger]

I believe the current version of the logo guidelines "recommend" the use of MSI but doesn't "require" MSI anymore. (Please double check)
Otherwise this would indeed be a reason to use Basic MSI and not pure InstallScript.

[aviswanathan]

This is a very interesting thread and has been very useful to me. We currently have a "pure" Installscript project and the experience has been satisfactory. But now when we have to plan for applying some patches to the product, I don't see any support for developing patches for an already created pure Installscript project. I use Devstudio 9 and the only option I see is Media --> Update Service

Th Update service seems to be a good Installshield marketing strategy. So is there any way to create patches using a pure Installscript project or do we have to start thinking about migrating to Basic MSI projects over a period of time?

Would really appreciate your comments / help.

[Stefan Krueger]

In a pure InstallScript project you cannot create BINARY patches, which only includes the changed bytes of a file. But you can create DIFFERENTIAL updates which only include the updated files. To do this, create the new version of your setup (from the same project file). Then run the Release wizard. On the Update panel change selection to "Differential".

InstallShield Update Service does NOT create updates. Instead it is a means to notify your customer that a new update is available, similar to Windows Update. InstallShield X includes a free "Starter Edition" of the Update Service.

[mse3]

Does anyone know if the major issues discussed here (major upgrades problem, installscript engine install problem) have been fixed in 10.5? I looked on the IS support website and it is hard to tell if the bugs are actually fixed in 10.5 or just not yet reproduced in 10.5.

Personally, I have to migrate a medium-sized server installer from pure InstallScript over to MSI. The existing setup uses tons of custom DLLs to accomplish rather complex database setup, IIS setup, etc. so I want to reuse as much as I can.

My prior experience is on the MSI side, so I'm ok with the MSI sequences... but my basic problem is not understanding how to migrate the existing InstallScript call into the MSI databases. Is there some reference somewhere that would guide me in this? Like you guys have said, the two installation models don't line up that well.

My hope was to use the InstallScript MSI project type as a way to preserve a lot of the existing functionality of the installer, while moving it over to MSI -- sort of a transitional approach -- but it sounds like I should be staying away from this project type at all costs. The installer will be for a commercial software release so the last thing I need is bugs like you guys are talking about. Can someone offer another alternative -- hopefully other than "start from scratch with Basic MSI and re-write all the setup DLLs"?

P.S. And, of course, the requirements state that I need to have the cute billboard support. Is there any way to do billboards in Basic MSI? I haven't found one yet.

[mse3]

Regarding the billboard postscript on my last post... I mean InstallShield-style background billboards, not the MSI Billboard control on the dialogs.

[andyguest13]

Hi,
Having scoured through all the posts and being a newcomer to MSI, i made a decision based on what i read to go for Basic MSI in my IS2008 Premier. I now need to do some actions which the IS IDE doesn't seem to offer though - namely -

1. Install some Excel XLA addins (and tell user to quit Excel if it's running, first)

2. Clean up some files on the target hard disk from a previous (non-MSI) installation that are pointed to by an ini file in \windows folder.

I already have pure C/C++ code to do the above and so i could call out to a small executable(s) at the appropriate points I guess. But i want my MSI to be completely reauthorable by corporate customers. They won't know what my custom actions are doing will they?

And finally, at uninstall time, do i need to write complementary custom actions in C/C++ that undo my installer custom actions, or is Windows Installer clever enough to record those actions?

thanks
andy

[Stefan Krueger]

[sljslj]

Can I use an InstallScript project if I have dll's that need to be installed in the GAC?

[Stefan Krueger]