Jump to content


This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Photo

IndtallScript MSI vs. InstallScript


48 replies to this topic

hgaard

hgaard
  • Members
  • 1 posts

Posted 31 October 2003 - 15:43

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..
sad.gif

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 01 November 2003 - 11:18

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

Glytzhkof
  • Moderators
  • 1,447 posts

Posted 12 November 2003 - 17:56

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).
Regards
-Stein Åsmul

emiii

emiii
  • Members
  • 4 posts

Posted 13 November 2003 - 17:06

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. blink.gif

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

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 13 November 2003 - 17:39

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

Glytzhkof
  • Moderators
  • 1,447 posts

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.

Regards
-Stein Åsmul

emiii

emiii
  • Members
  • 4 posts

Posted 17 November 2003 - 19:13

laugh.gif
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? ph34r.gif

But anyway, thanks again for your help!

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 17 November 2003 - 19:32

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

HappyGod
  • Members
  • 7 posts

Posted 18 November 2003 - 07:17

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

Glytzhkof
  • Moderators
  • 1,447 posts

Posted 18 November 2003 - 07:28

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.
Regards
-Stein Åsmul

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 18 November 2003 - 08:40

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

emiii
  • Members
  • 4 posts

Posted 24 November 2003 - 23:11

wink.gif
Thanks a lot for your explanations. Happy holidays!

hsong3

hsong3
  • Members
  • 89 posts

Posted 16 December 2003 - 19:58

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

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 16 December 2003 - 22:06

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

dsumners
  • Members
  • 1 posts

Posted 29 March 2004 - 19:35

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

Thanks!

Glytzhkof

Glytzhkof
  • Moderators
  • 1,447 posts

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)
  • Etc...

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

Regards
-Stein Åsmul

luke_s

luke_s
  • Full Members
  • 532 posts

Posted 30 March 2004 - 04:26

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 smile.gif



Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 30 March 2004 - 08:11

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

tsquared
  • Members
  • 6 posts

Posted 30 March 2004 - 17:59

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

ConfigControl
  • Full Members
  • 34 posts

Posted 13 April 2004 - 18:22

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
ConfigControl

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 13 April 2004 - 19:32

Basic MSI

ConfigControl

ConfigControl
  • Full Members
  • 34 posts

Posted 13 April 2004 - 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?

Thanks,
Jim
ConfigControl

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 13 April 2004 - 21:27

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

Arcangel_666
  • Members
  • 12 posts

Posted 14 April 2004 - 21:25

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

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 15 April 2004 - 21:04

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

Glytzhkof
  • Moderators
  • 1,447 posts

Posted 18 May 2004 - 03:12

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.
Regards
-Stein Åsmul

Glytzhkof

Glytzhkof
  • Moderators
  • 1,447 posts

Posted 18 May 2004 - 03:19

QUOTE
...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.

Regards
-Stein Åsmul

Zweitze

Zweitze
  • Full Members
  • 522 posts

Posted 19 May 2004 - 08:46

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

vladb
  • Members
  • 15 posts

Posted 02 June 2004 - 18:32

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

vladb
  • Members
  • 15 posts

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?

Thanks,
Jim

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?!

luke_s

luke_s
  • Full Members
  • 532 posts

Posted 02 June 2004 - 23:32

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

Glytzhkof
  • Moderators
  • 1,447 posts

Posted 03 June 2004 - 03:28

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.
Regards
-Stein Åsmul

vladb

vladb
  • Members
  • 15 posts

Posted 03 June 2004 - 14:22

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

vladb
  • Members
  • 15 posts

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)

luke_s

luke_s
  • Full Members
  • 532 posts

Posted 03 June 2004 - 23:46

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

Glytzhkof
  • Moderators
  • 1,447 posts

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 smile.gif.


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

Regards
-Stein Åsmul

mishka

mishka
  • Full Members
  • 21 posts

Posted 06 June 2004 - 13:47

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

Glytzhkof
  • Moderators
  • 1,447 posts

Posted 07 June 2004 - 00:44

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).
Regards
-Stein Åsmul

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 07 June 2004 - 08:31

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

mishka
  • Full Members
  • 21 posts

Posted 07 June 2004 - 14:18

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 smile.gif

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

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 07 June 2004 - 23:25

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

aviswanathan
  • Members
  • 18 posts

Posted 07 October 2004 - 20:27

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

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 08 October 2004 - 16:21

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

mse3
  • Members
  • 4 posts

Posted 10 March 2005 - 21:29

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. ph34r.gif

mse3

mse3
  • Members
  • 4 posts

Posted 14 March 2005 - 23:46

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

andyguest13

andyguest13
  • Full Members
  • 21 posts

Posted 07 October 2008 - 10:13

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

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 07 October 2008 - 16:12

QUOTE
They won't know what my custom actions are doing will they?
You could document what your custom actions are doing (for the Vista logo this is a requirement).

QUOTE
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?
Windows Istaller will not record and undo what your custom actions are doing, so you will have to take care of this yourself. Note that this is also true for rollback in case of failed or aborted install.

sljslj

sljslj
  • Full Members
  • 2 posts

Posted 17 October 2008 - 19:22

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

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 17 October 2008 - 22:13

QUOTE
Can I use an InstallScript project if I have dll's that need to be installed in the GAC?
If I recall correctly, installing to the GAC is not supported by pure InstallScript projects.