cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Muhanned_Maayeh
Level 4

Legacy Objects for InstallShield 2014

Well, recently my company purchased InstallShield 2014 and I am trying to convert setups from previous versions such as, IS 7.0.1 to the InstallShield 2014. However, the applications are old legacy type of applications that utilize VB 6, MDAC and other types of components and dependencies. So, I am looking for legacy objects that can be imported and utilized within the InstallShield 2014 setup. I had installed one object that gave me MFC Runtime but, I had to create my own object for VB 6 runtime files. Hopefully, this will be okay but, I need more objects to include such as other MDAC and dependencies. Is there an InstallShield installer that will return these types of objects to InstallShield 2014? Or, a proper third party source that can help include legacy objects. :confused:

Please note, eventually these legacy applications will be obsolete and updated to utilize current & new technology in our product line but, there is no time frame yet in development for this road map. 🙂
Labels (1)
0 Kudos
(5) Replies
MichaelU
Level 12 Flexeran
Level 12 Flexeran

What scenarios are you targeting that don't have the VB6 runtime and similar files already installed on the system? Both MDAC and VB6's files are protected files on Windows Vista and later (possibly earlier as well, but that's all I have convenient records for in Filters.xml).
0 Kudos
Muhanned_Maayeh
Level 4

MichaelU wrote:
What scenarios are you targeting that don't have the VB6 runtime and similar files already installed on the system? Both MDAC and VB6's files are protected files on Windows Vista and later (possibly earlier as well, but that's all I have convenient records for in Filters.xml).


Well, I have a for example, IS 7 that has the following InstallShield Objects associated:
[LIST=1]
  • InstallShield Object for MDAC 2.6
  • InstallShield Object for MFC 6.2 Runtime
  • InstallShield Object for Visual Basic 6 Runtime Files


    When converting the InstallShield project then, for these InstallShield Objects, starting with MFC 6.2 was able to add to the IS 2014 project when installing the InstallScriptObject from the Flexera site. However, for VB 6 run time, I manually created an object and added this to the project. For the MDAC 2.6 object, I found the merge module file MDAC2.6SP1.msm on the internet and added this to the C:\Program Files\InstallShield\2014\Modules\i386 directory in order to include the merge module into my project. However, the MDAC required module dependency with DCOM95 so when building the project then, the error "ISDEV : error -4072: Error retrieving dependency DCOM95.6FC97963_2511_11D4_BB8A_00C04F20D375 of C:\Program Files\InstallShield\2014\Modules\i386\MDAC2.6SP1.msm" occurred. For now I created my own DCOM95 MSM but the dependency does not point to my own MSM and that's probably due to a difference in GUID, I believe.

    Also, to note with another project, when testing the setup then, I observed that an Access Denied error on the VB 6 run time files occurs for each item (ASYCFILT.DLL, COMCAT.DLL, MSVBVM60.DLL, etc.) to be installed by the object (note, I did not include MDAC just MFC 6.2 & my own build VB 6 run time files) using Win 7 Pro x86 environment.

    So, in the current release of InstallShield 2014 then, do I need to disregard these previous objects or I need to include them or what should be the proper direction with legacy type objects such as these?
  • 0 Kudos
    Muhanned_Maayeh
    Level 4

    MichaelU wrote:
    What scenarios are you targeting that don't have the VB6 runtime and similar files already installed on the system? Both MDAC and VB6's files are protected files on Windows Vista and later (possibly earlier as well, but that's all I have convenient records for in Filters.xml).


    Now I saw a response to another poster with the same similar state for older technology was a reference to the article Removal of Outdated and Obsolete Items in InstallShield 2013 then, is the only option not to convert and keep things as is until such time that the applications are updated with new technology? Or, there is an alternative we can pursue?
    0 Kudos
    MichaelU
    Level 12 Flexeran
    Level 12 Flexeran

    The main premise behind removing these is that the redistributables are not necessary on modern systems, as the files they distribute are already present or are otherwise unneeded. If that's true, it should be safe to remove the objects from your projects entirely; my question was attempting to ascertain whether it's true in your case. The access denied errors indicate the files are already present on and protected by Windows, so at least for that target system you should be fine without the object.
    0 Kudos
    Muhanned_Maayeh
    Level 4

    MichaelU wrote:
    The main premise behind removing these is that the redistributables are not necessary on modern systems, as the files they distribute are already present or are otherwise unneeded. If that's true, it should be safe to remove the objects from your projects entirely; my question was attempting to ascertain whether it's true in your case. The access denied errors indicate the files are already present on and protected by Windows, so at least for that target system you should be fine without the object.


    I see. So, legacy objects don't worry about it if you install on Win 7/2008 or higher. However, if you install on Win XP/20003 or lower then these legacy objects will need to be included some how in the project. Correct?

    And, if I am forced to include them should I just find out the required files that belong to a legacy object and put them in a file group instead of worrying about trying to create or find the merge modules/objects?
    0 Kudos