That is such an old version it would be hard to say for sure, but generally speaking you can have almost any combination of multiple versions co-installed. If you have a test computer available, and the old original 6.30 media, I'd recommend putting them both on the test computer first, just to make sure. ... View more

If your project is an InstallScript Msi project, allowing you to use *.rul InstallScript files, you can modify the following code snippet, taken from the InstallShield Help editor: /*--------------------------------------------------------------*\ * * InstallShield Example Script * * Demonstrates the ExistsDir function. * * AskPath is called to get a directory name from the user. * Then, ExistsDir is called to determine whether the directory * exists. * \*--------------------------------------------------------------*/ #define TITLE_TEXT "ExistsDir Example" // Include Ifx.h for built-in InstallScript function prototypes. #include "Ifx.h" export prototype ExFn_ExistsDir(HWND); function ExFn_ExistsDir(hMSI) STRING svPath; begin // Get the path to be created. AskPath ("Please enter a path:", "", svPath); // Check for the existence of the directory. if (ExistsDir (svPath) = EXISTS) then SprintfBox (INFORMATION, TITLE_TEXT, "%s already exists.", svPath); else SprintfBox (INFORMATION, TITLE_TEXT, "%s does not exist", svPath); endif; end; ... View more

Might want to use the repackager, or take a look at this link: http://community.flexerasoftware.com/showthread.php?t=194781 ... View more

What version of InstallShield was the old project developed with? If it's really old (several versions) you might have to convert it in two steps. E.g., if the old project was created with InstallShield 12, and you have a version of InstallShield 2010, first convert it to 2010, then try going from 2010 to 2012 ... a stepwise conversion. ... View more

Are you using Visual Studio 2010? I can add InstallShield projects by right-clicking the solution node in VS2010, Add / Existing Project / navigate to the project. I can add *.ism or *.issuite projects that way. You don't need the Enterprise version of VS2010, the cheaper Professional version will work. But I don't know if earlier versions (Visual Studio 2008, 2005, 2003) can do this. ... View more

DebbieL wrote: The ReadMe First sticky has a link to the SP1 KB article: Q201298: InstallShield 2012 Service Pack 1 The SP1 patch does not update the Standalone Build. An SP1 version of the Standalone Build is available for download and installation. It's a full installation, not a patch. It's a replacement for the RTM version. The KB article has some information on how to obtain it. Good, then one follow-up question -- I downloaded the 2012 Standalone Build this morning from the License Center. I saw only one link to download it (no "new" vs. "original" links), so is it safe to assume that I downloaded the latest Standalone version, i.e., the one that has SP1? Hope so, please let me know, thanks! ... View more

looeee wrote: At plugin uninstall the costing fails beacuse the main package has already been removed. If they were removed in reverse-order to installation then it would not fail I have an issue very similar to this. My current custom C#-based Install Wizard (which serves the same purpose as the Suite style project) takes care of uninstall order, but we want to get away from customized code like that. Glad someone has already requested this functionality. :cool: ... View more

Big discovery !! I've been steadily adding features to my Suite project, and now that I have finally added so many that they cannot all display at the same time, scroll bars have magically appeared! I sort of suspected this would happen. And not only that, I can now see top-level features only (collapsed) or top-level and subfeatures (expanded), and can select or de-select the subfeatures at will. This is exactly what I wanted! What I think happend is this ... when the form view needed to be scrolled, the scrollbars were painted on the form, and I think that must have also enabled some other form properties as well, i.e., the ability to expand a node on the feature tree. Just guessing, but that's probably standard behavior for a Windows form when implementing in C#. Anyway, it works now! 😄 ... View more

MichaelU wrote: Ah, yeah that looks like a problem case. I can work around it by adding a 64-bit MSI package and putting an extra backslash in the path, making it look like [ProgramFiles64Folder]\MyPathHere. Neither of these steps should be necessary, so I'm filing IOA-000067153 to track this. MichaelU, just a little more info. that might be useful for you: I now have a workaround, but the only way I got it to work was to spell out the path in the Detection condition (C:\Program Files\MY APPS\App One\TheFile.exe), and avoid [ProgramFiles64Folder] altogether -- even when I inserted the trailing backslash it still could not find the file. Since 99% of our customers install to drive C:\ and use 64-bit Win7, this workaround is painless. By the way, the automated uninstall of the app also worked (i.e., uninstalling the top-level Suite correctly auto-uninstalled the 64-bit app ... hooray!:) ) ... View more

MichaelU wrote: The other thing I would verify, based on looking at the earlier project you sent me, is to make sure your detection condition is accurate. As John talked about in Mode Condition..., the detection conditions are used to figure out the mode condition. What I don't think he mentioned is that they are also used to determine whether the package was installed, and that's what controls whether the suite creates an ARP entry. So I would check the detect condition for Feature4. If it evaluates to false and it was the only package you installed, the Suite will think nothing is installed and omit the ARP entry. (Did you get my email about the detect conditions on the other package? I haven't seen a response and lost track of the community thread it was related to.) MichaelU, long story short, I believe you're right about the detect conditions. I have applied SP1 and the hotfix from the link you gave me, rebooted, recompiled, but it made no difference. I also set the Eligibility Condition for the 64-bit package (OS Version = 6.1- Architecture = x64). That made no difference either. I can sort of "fake out" the install by selecting a pre-existing file on the test computer as the detection condition, which throws the install into Maintenance Mode when I kick it off, and that gives me the key that it "knows" it's installed. I think this is the key to problem: the Path I'm using for my "File Exists" detection condition (the only clause in the detection condition, by the way) is: [ProgramFiles64Folder]MY APPS\App One\TheFile.exe This should correspond to C:\Program Files\MY APPS\App One\TheFile.exe, and that file DOES get installed, but the detection fails, so no entry is made in Add/Remove Programs for the suite app (it does make the entry for App One). Thinking the blanks might be causing the problem, I enclosed the Path in double quotes like this: "[ProgramFiles64Folder]MY APPS\App One\TheFile.exe" Recompiled with the quotes, but still no good. Can't get anything to work. Is [ProgramFiles64Folder] the right variable? I'm Windows 7 64-bit. I believe it just can't find or see the file associated with the detection condition. ... View more

As a follow-up, the feature that is causing the problem has the only 64-bit installation package. That's one difference. Are there any special rules in the creation of a Suite project that has a mixture of 32-bit and 64-bit packages? Could that be causing the problem I've described, and maybe others as well? Something tells me this is the root of the problem. :confused: ... View more