IndtallScript MSI vs. InstallScript
Posted 31 October 2003 - 15:43
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..
Posted 01 November 2003 - 11:18
Posted 12 November 2003 - 17:56
Posted 13 November 2003 - 17:06
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!
Posted 13 November 2003 - 17:39
Posted 13 November 2003 - 19:49
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.
Posted 17 November 2003 - 19:13
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!
Posted 17 November 2003 - 19:32
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.
Posted 18 November 2003 - 07:17
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.
Posted 18 November 2003 - 07:28
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.
Posted 18 November 2003 - 08:40
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
3. InstallScript MSI
4. Smart Device
Where 1, 3 and 4 (I think) were available before in InstallShield Developer, and 2 in InstallShield Professional.
Posted 16 December 2003 - 19:58
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?
Posted 16 December 2003 - 22:06
Posted 29 March 2004 - 19:35
Posted 30 March 2004 - 03:10
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)
Edited by Glytzhkof, 16 August 2014 - 01:05.
Posted 30 March 2004 - 04:26
I believe that they are easier to debug/maintain and do not have to added complexty of Install Script
Posted 30 March 2004 - 08:11
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!)
Posted 30 March 2004 - 17:59
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.
Posted 13 April 2004 - 18:22
Posted 13 April 2004 - 21:09
Posted 13 April 2004 - 21:27
Posted 14 April 2004 - 21:25
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
Posted 15 April 2004 - 21:04
Posted 18 May 2004 - 03:12
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.
Posted 18 May 2004 - 03:19
|...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!)|
According to Bob Baker's new book "Practical Windows Installer Solutions for Building Installshield setup applications" Windows Scripting Host is not required to be enabled on the target system in order to run VBScript actions. Apparently Windows installer is its own scripting host. However, you need the scripting engine files vbscript.dll or jscript.dll to be present on the system and the runtime file scrrun.dll. All of these files are installed with Windows 2000 as protected operating system files. In other words people must really go under the hood to disable script actions from running. A C/C++ custom action could check for the existence of these files before a script action is attempted.
Edited by Glytzhkof, 18 May 2004 - 03:20.
Posted 19 May 2004 - 08:46
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.
Posted 02 June 2004 - 18:32
Posted 02 June 2004 - 18:50
|QUOTE (ConfigControl @ 2004-04-13 21:09)|
|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?|
Yes, everything works beautifully in theory! When you actually start coding your custom actions and see that you can't use installscript functions like CtrlSetList to fill your combo box (which seem very basic to me), and you need a whole new function, Dll call or who knows what else, then you'll start swearing...
So why not InstallScript MSI?!
Posted 02 June 2004 - 23:32
Can somone else provide any more specific details?
Posted 03 June 2004 - 03:28
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.
Posted 03 June 2004 - 14:22
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.
Posted 03 June 2004 - 14:26
|QUOTE (Stefan Krueger @ 2004-03-30 18:30)|
|InstallScript MSI combines two technologies that sometimes don't work very well together. Also you lose a lot of the important MSI functionality. For instance system administrators cannot deploy InstallScript MSI setups using Group Policy. This only worls with Basic MSI. So InstallScript MSI isn't better than pure InstallScript, but adds the complexity of MSI.|
This is the only precise example of a problem with IS/MSI in this thread. Can you point out others? (This one doesn't affect me)
Posted 03 June 2004 - 23:46
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
Posted 04 June 2004 - 01:03
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.
Posted 06 June 2004 - 13:47
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..
Posted 07 June 2004 - 00:44
Posted 07 June 2004 - 08:31
Posted 07 June 2004 - 14:18
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
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.
Posted 07 June 2004 - 23:25
Otherwise this would indeed be a reason to use Basic MSI and not pure InstallScript.
Posted 07 October 2004 - 20:27
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.
Posted 08 October 2004 - 16:21
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.
Posted 10 March 2005 - 21:29
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.
Posted 14 March 2005 - 23:46
Posted 07 October 2008 - 10:13
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?
Posted 07 October 2008 - 16:12
|They won't know what my custom actions are doing will they?|
|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?|
Posted 17 October 2008 - 19:22
Posted 17 October 2008 - 22:13
|Can I use an InstallScript project if I have dll's that need to be installed in the GAC?|