Community Forums
Page 1 of 2 12 LastLast
Results 1 to 5 of 9

Thread: Is Installscript to be depreciated?

  1. #1
    Join Date
    Apr 2006
    Location
    Peterborough, England
    Posts
    221

    Is Installscript to be depreciated?

    I did a Basic MSI course at Macrovision earlier this year and there it was mentioned that Installscript projects would be dropped at some point. This was not an official comment I might add, just some speculation. Does anybody have any knowledge of whether this is going to happen in the near future or not.

    I have inherited a major Installscript project and I'm thinking I either need to do the Installscript course or restart the project as a basic MSI one, but I don't want to do the first only to have to do the second in the near future anyway.

  2. #2
    Join Date
    Apr 2006
    Posts
    48
    Nick, I think that question can only be answered completly by Macrovision. However, looking at the new features for IS 12.0 for Windows, one sees:

    Major InstallScript and InstallScript MSI Engine Overhaul
    If it's going out, at least it's going out in style.
    JP

  3. #3
    Join Date
    Jul 2003
    Location
    Austin, TX
    Posts
    4,430
    You just inspired a blog!

    The use of the word `InstallScript` is overloaded these days. I can think of atleast three possible meanings

    1) Basic MSI with InstallScript Custom Actions

    2) InstallScript MSI ... an MSI installation which uses InstallScript as it's External UI handler

    3) InstallScript project .. no MSI at all. Completly script/InstallShield framework driven.

    #1 is my favorite. Lean and mean, using InstallScript CA's only where needed.

    #2 gives a nice framework for people who want a fancier, more extensible UI. It also support Setup Types alot easier then #1

    #3 is particularly useful for situations that MSI doesn't support well. Two examples would be multipleinstance installation and another would be you don't want resilency. ( In certain server based situations the overhead of scanning keyfiles can have a negative effect on application performance )

    Personally I doubt `InstallScript` ( in either context ) is going away anytime soon.
    Last edited by Christopher Painter; 07-28-2006 at 03:21 PM.
    Christopher Painter
    ISWIX, LLC.
    Visit iswix.com for contact information

  4. #4
    Join Date
    Apr 2006
    Location
    Peterborough, England
    Posts
    221
    Thanks for the replies.

    To jbeaudry, I agree that only Macrovision can answer that question which is why when I was at Macrovision earlier this year I asked it. There was some debate after I posed my question but the official line is that they are continuing to support it for now and you can’t really expect anything more from them. Macrovision like any other business will continue to support a product for as long as there is a commercial reason for doing so and they would be foolish to speculate on it’s shelf life, so that is why I posted this question here.

    I’m trying to gauge what the perceived need is for this project because this is what will drive Macrovision’s future support for it. Chris’ response was on the button, it is the InstallScript project I am talking about. To me I think there is a question mark over the way forward, it seems it has to be msi eventually? So why do people continue to use Installscript projects?

    Chris names 2 reasons. Resiliency can be turned off in an msi project, just ‘Clear the Key file’ from each component surely? So that just leaves multiple instance installation, please define what that means if I have misunderstood, but this I think relates to my project.

    In the project that I have inherited, it installs a client / server application. It has been designed with 3 child msi’s, one each for the Client, Server and Console (configuration and control utility). The administrator need to be able to distribute particularly the much smaller Client msi, but obviously wants everything on his own machine installed as part of the main installer process. As I understand one msi cannot run a child msi, so the original designer had the choice of duplicating the Client msi functionality in the main installer and then providing the Client msi as simply a file for distribution or going down the route he took of building a main Installscript project which installs the separate Client, Server and Console msi’ as required and which an administrator could perform an administrator install on and extract the Client msi for distribution if he wanted. If it all worked fine I wouldn’t be complaining now, but the upgrading process in particular is a nightmare.

    To me it seems that if there was a way of allowing one msi project to contain and run another, the Installscript project would be gone in very short order. Would anybody like to add to this debate?

  5. #5
    Join Date
    Oct 2001
    Location
    Here and there
    Posts
    16,243
    I don't have any inside information about plans, but another motivation for using InstallScript is the richer UI it provides, with dialog skins, more supported dialog box controls, full-screen background windows with billboards (for that old-fashioned look), and all that kind of thing. Many developers also seem to prefer the procedural programming style of InstallScript projects to the table-driven MSI architecture.

    There are also the less restrictive file-overwrite and upgrade rules.
    Last edited by RobertDickau; 07-31-2006 at 10:47 AM. Reason: and another thing...

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •