Community Forums
Results 1 to 4 of 4

Thread: Can multiple versions of ISWiAutomation be registered on the same machine??

  1. #1
    Join Date
    Apr 2007
    Posts
    19

    Question Can multiple versions of ISWiAutomation be registered on the same machine??

    Hi,

    We run automation scripts to update versions numbers, product / package code, add components and other updates within the .ism files. This all works great but one issue I see if depending on what version of .ism file I am trying to update I need to register that particular IS .dll. even though I have all the IS versions installed on the same machine.

    So if I am updating a Spring2012 ism file I need to run this command prior to running my automation script.
    regsvr32.exe "c:\Program Files (x86)\InstallShield\2012Spring\System\ISWiAutomation19.dll"

    If I then want to update a 2014 ism file I would then have to run this command first:
    regsvr32.exe "c:\Program Files (x86)\InstallShield\2014\System\ISWiAutomation21.dll"

    Can, and if so how, do I get different versions registered on the same machine?

    Thanks,
    Erik

  2. #2
    Join Date
    Oct 2001
    Location
    Itasca, IL
    Posts
    2,391
    Each version of InstallShield automation interface has unique COM information. You can instantiate a copy of ISWiProject by an IS version differently with the following VB and VBScript syntax:

    2012 Spring:
    Code:
    Set pISWiProject19 = CreateObject("IswiAuto19.ISWiProject")
    2014:
    Code:
    Set  pISWiProject21 = CreateObject("IswiAuto21.ISWiProject")
    Last edited by hidenori; 12-25-2016 at 06:55 PM.
    Hidenori Yamanishi - Senior Software Engineer - Flexera Software: InstallShield Team

  3. #3
    Join Date
    Apr 2007
    Posts
    19
    This is a chunk of the switch statement in the powershell script I use but I still need to run the commands shown before to register the correct version first.


    switch($schema){
    '776' { #776 = IS2015
    LogWrite "Schema is $schema using IS2015: setting ISwiAuto22.ISWiProject"
    $m_ISWiProj = new-object -comobject IswiAuto22.ISWiProject
    ;break
    }
    '775' { #775 = IS2014
    LogWrite "Schema is $schema using IS2014: setting ISwiAuto21.ISWiProject"
    $m_ISWiProj = new-object -comobject IswiAuto21.ISWiProject
    ;break
    }
    '774' { #774 = IS2013
    LogWrite "Schema is $schema using IS2013: setting ISwiAuto20.ISWiProject"
    $m_ISWiProj = new-object -comobject IswiAuto20.ISWiProject
    ;break
    }
    '773' { #773 = IS2012Spring
    LogWrite "Schema is $schema using IS2012Spring: setting ISwiAuto19.ISWiProject"
    $m_ISWiProj = new-object -comobject IswiAuto19.ISWiProject
    ;break
    }
    '772' { #772 = IS2012
    LogWrite "Schema is $schema using IS2012: setting ISwiAuto18.ISWiProject"
    $m_ISWiProj = new-object -comobject IswiAuto18.ISWiProject
    ;break
    }
    }

  4. #4
    chad.petersen Guest
    For me, installing the Stand-alone build itself - running the installer for each one - registered the various automation interfaces in their respective folders and they did not interfere with one another. Then in our script we just instantiate whichever object we want - by its unique name - and away it goes. I wonder why you would have to keep registering the same items each time? I guess it can't hurt, but I'm curious why that would be necessary?

    Chad

Posting Permissions

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