Has anyone successfully used the "prqpath" parameter for ISCmdBld.exe?

[CHOeld]

I'd like to create a stand-alone build machine that can be shared by all of our configuration managers and developers to create a highly-managed, consistent product. I was therefore very excited when I read that InstallShield 2011 supports a new "-prqpath" parameter that "specifies one or more ... folders that contain the InstallShield prerequisite files (.prq) that are referenced by your project." Thus far, however, I haven't been able to make these work to access prerequisites in any location other than the default location (\SetupPrerequisites).
At first, I hoped that all that would need to be done would be adding the "-prqpath" parameter to the ISCmdBld command along with the UNC path to a network location containing all of our accumulated prerequisites, e.g., "ISCmdBld.exe ... -prqpath \\Syoung-pws2\SetupPrerequisites ...". When that resulted in a string of errors like:
"ISDEV : error -6003: An error occurred streaming 'D:\Program Files\InstallShield\2011 SAB\SetupPrerequisites\EntityFramework_CTP4.prq' into setup.exe"
and "ISDEV : error -7066: Your project contains a reference to the InstallShield prerequisite D:\Program Files\InstallShield\2011 SAB\SetupPrerequisites\EntityFramework_CTP4.prq; however, this file cannot be located. Either remove the InstallShield prerequisite from your project, or locate this file.",
I realized it wouldn't be that simple.
Next, I tried using the Prerequisite Editor to open the .prq files at the location referenced by the "-prqpath" parameter and adding the UNC path ("Path to Local File") for the specific files referenced by the .prq file. This, unfortunately, did not change the outcome -- I still get the same errors. (I should probably add that if I command "dir [UNC path]" from the command line on the build machine, the .prq files and subfolders are visible, and that if I copy the "SetupPrerequisites" folder from the network location to the default (local) location, everything works).
I have searched the Flexera knowledge base, the product Help files, and the Web for more details about how this parameter is intended to be used, but have so far been unsuccessful. One good example would probably be sufficient. Has anyone found the key to this? Thanks in advance to all who might have an answer to this.

[CHOeld]

Following extensive testing of the new prerequisite search functionality as it is explained in the InstallShield 2011 Release Notes, Flexera Software Knowledge Base article Q208910 (http://kb.flexerasoftware.com/selfservice/viewContent.do?externalId=Q208910), we have concluded that some of the limitations of this new functionality that we have encountered are so difficult to work with that they must be categorized as problems. Our findings are described below, and may be useful in devising work-arounds to these problems until a solution is available.

There are several distinct (although interdependent) new features incorporated into InstallShield 2011 that are needed to implement relocatable prerequisites:
[LIST=1]

The ability to configure the InstallShield 2011 development environment to search one or more non-default locations for prerequisite files, using a new “Prerequisites” tab in the “Tools”, “Options” configuration window.

The ability to store prerequisite requirements in project (.ism) files in relative form, so that the actual location of prerequisite (.prq) files can be supplied either by the development environment (ISDev.exe) during development or by the build environment (ISCmdBld.exe) at build time.

The ability to pass a prerequisite path to the standalone build program, ISCmdBuild.exe, via the new “-prqpath” switch. (This feature depends on the following one).

The ability to incorporate relative paths to prerequisite install packages into prerequisite specification (.prq) files. Previously, such paths either had to be absolute or had to incorporate a path variable. These files are used by both the InstallShield 2011 development environment and by the standalone build program, ISCmdBuild.exe.

Of these new features, only the -prqpath switch appears to work without limitations. The problems with the other features, however, make it very difficult to use the one that does. The problems we have experienced are listed below. These problems are categorized by according to whether they’re related to creating or using relative paths in project (.ism) files or prerequisite (.prq) files.

Creating a project (.ism) file with a relative path to a prerequisite file

The path to a prerequisite (.prq) file embedded in an InstallShield 2011 project file (NOT a .prq file) is only set relative when the .prq file is in its default location (\SetupPrerequisites), even though the circumstance for which it’s needed is when the .prq file is remote.

If the “Prerequisite File Locations” is set to something other than the default location using the new “Prerequisites” tab in the “Tools”, “Options” configuration window, the “Path to Local File” stored in the .ism file by default will not be the relative path (required for the -prqpath switch to work for standalone builds), but an absolute path.

Using a project (.ism) file with a relative path to a prerequisite file

If the “Prerequisite File Locations” is set to something other than the default location (\SetupPrerequisites), prerequisite files at the specified location will be displayed in the Redistributables list (good), but if the “Path to Local File” within the .prq file is relative (as required for the -prqpath switch to work for standalone builds), then the prerequisite “Location” in the “Redistributables” list will be shown as “Needs to be downloaded”, and further builds of the install project will fail.

Creating a prerequisite (.prq) file with a relative path to prerequisite files

According to the InstallShield 2011 Release Notes, Flexera Software Knowledge Base article Q208910,

“When you are using the Files to Include tab in the InstallShield Prerequisite Editor to add files to an InstallShield prerequisite, the editor now uses predefined path variables such as and if appropriate. In addition, if the files that you are adding are stored in the same folder as the InstallShield prerequisite's .prq file—or a subfolder of the folder that contains the .prq file—the InstallShield Prerequisite Editor uses a relative path for the file in the .prq file. Note that if you view the file's path on the Files to Include tab, the InstallShield Prerequisite Editor lists the full path, not the relative path.” [Note: italics and bolding added for emphasis]

This new feature can’t be demonstrated. If a prerequisite file at a “Prerequisite File Location” other than the default location (\SetupPrerequisites) is edited using the Prerequisite Editor, and a file is “Add”ed to the “Files to Include” using the browse button in the “New File” window, an absolute (full) path will be specified in the “Path to Local File”, even when the redistributable file is located in a subfolder of the “Prerequisite File Location”. If the “Prerequisite File Location” IS the default location, then a file “Add”ed to a prerequisite file using the Prerequisite Editor will be specified within the .prq file via a path of “\SetupPrerequisites”. Prerequisite files with any explicit, non-relative path (i.e., either of the situations just described) will fail to work when used with the -prqpath switch for standalone builds.

Using a prerequisite (.prq) file with a relative path to prerequisite files

Even though prerequisite files incorporating the relative paths which are required to work with the prqpath switch for standalone builds apparently cannot be created using the Prerequisite Editor, it is easy enough to modify them using an XML editor or a simple text editor, such as Notepad.exe. Thereafter, however, these files effectively cannot be used by the InstallShield development environment. The prerequisite that such a file represents will be displayed in the “Redistributables” view in the Installation Designer, but in the “Location” column beside it, “Needs to be downloaded” will be displayed, indicating that InstallShield doesn’t know how to find the referenced redistributable package. If you attempt to build a project for which such a prerequisite is required (indicated by a check in the box beside the prerequisites name in the list), the build will fail with Error Code -1007,

“Cannot copy source 'WindowsPowerShell\WindowsXP-KB968930-x86-ENG.exe' to target 'D:\MAS\Processes\Installs\PrqpathTest\PrqpathTest\Product Configuration 1\Release 1\DiskImages\DISK1\ISSetupPrerequisites\{9974D7FF-0E12-40DC-A82A-F7D35347E204}\WindowsXP-KB968930-x86-ENG.exe'.”

If you edit such a prerequisite (containing a relative path) with the Prerequisite Editor and attempt to save the file preserving the relative path, a warning will be displayed:

“The specified file does not exist, … Are you sure you want to continue?”

Summary

The key to understanding all of the problems listed above is the requirement to share a single copy of the prerequisites library with multiple software developers and multiple installation designers. This means that the library cannot be local to the computers of all those developers, but must reside on a remote network location. Installation designers need to be able to store prerequisite packages and edit prerequisite files in the remote library using the the InstallShield development environment, and they should be able develop and build installation projects that reference and use that same remote prerequisite library. Software developers should be able to use such projects unaltered to build installation packages for their products using ISCmdBld.exe to perform standalone builds with the same remote prerequisite library. The issues/problems described above are all serious obstacles to using a single prerequisites library.

[Christopher_Pai]

I haven't played with the new 2011 functionality but I can tell you what I've done for years with previous versions.

I use the direct editior to update the ISSetupPrerequisites table and replace all references of with . I keep my PRQ files checked into source control and place the larger binaries in a CM controlled system and make it the responsibility of my Build Automation to pull them in at build time.

The result is a very repeatable build process with no "magic build machine" dependencies.

[CHOeld]

Thanks, Christopher. I did experiment with using a path variable (I used ""), and it all seemed to work. You can even use a path variable in 2011's new “Prerequisite File Locations” in the "Options" "Prerequisites" configuration tab. The biggest down side I saw to this is that you would need to define that unique path variable in every project, wouldn't you, so as to be able to build the install projects in the development environment?

(I didn't mention this before because I didn't want to take the focus off a new feature that I think is important, but which is -- so far, I believe -- flawed in its implementation).

[Christopher_Pai]

Just my opinion, but I'd set that to and make it part of your build automation to bring your PRQ/BINARIES to your installer not point your installer to the location of your PRQ/BINARIES.

I like building up a tree that has every single file the installer needs to build. I don't like having my dependencies scattered all over the file system.

[CHOeld]

Problems caused by installing Hotfix A required me to uninstall InstallShield 2011 (with Hotfix A) and re-install the program. I decided to download the latest version from their website rather than the copy I originally installed last year, even though the "Upgrade" I had run from the Help window reported that I had the latest version. After downloading, I found that the filesize of the new installer is slightly larger than the original install, even though the "File Version" of the two files was identical (17.0.0.0) and the "ProductVersion"s were identical (17.00.0000). The only difference advertised in the file headers was the "LegalCopyright": 2010 vs. 2009.

After installing the "new" 2011, I tried editing a .prq on a remote network folder, and it worked just as the release notes say it should work. What I have been struggling with for the past three weeks is apparently a configuration management failure -- on the part of Flexera. I had a product that had been superseded by a newer version that fixed known flaws, but since there had been no progression of file or product versions, there was no way for their customer support or me to know I was using an obsolete version of the product.

This is unconscionable on the part of Flexera. Even though InstallShield has full and comprehensive support for product versioning and reporting, clearly the development department hasn't a clue as to why that's important. If there had been properly functioning configuration management and problem-tracking systems in place, they would have searched for the symptoms I originally reported and found that those were issues that were fixed in a newer version of the product. They would confirmed the diagnosis by asking me which build (or version) I had installed, instructed me where to get the latest version, and we would have both been done after perhaps an hour of time each. As it is, I have lost three weeks of development, and Flexera customer support has lost probably many hours (based on the quality of their answers) because, apparently, every single release of InstallShield 2011 is labelled with exactly the same version, "17.00.0000".

[Christopher_Pai]

I'd love to see evidence of this. Do you mind posting screen shots of the properties page along with file size and MD5 checksums?

I agree, this is horrible SCM if it's found to be true. Thank goodness we have extremely tight SCM controls where I work.

[CHOeld]

To Christopher Painter:

I'll try. I've never attached any screenshots here before. Since paste (Ctrl-V) didn't work, I've attempted to attach a .jpg (2011 InstCmp.jpg) of a screenshot of a program we use called BeyondCompare, comparing the headers of the two .exe files -- the one I downloaded last year vs. the one I got yesterday. Comparing the file "Properties" screens of the two files would take more screenshots to give you pretty much the same info -- EXCEPT -- the "Internal Build Number" of the old file is 97317, while that of the new one is 99584. I'm afraid I don't know what an "MP5 Checksum" is.

Oh, the other thing I can tell you is that if you select "Help", "About InstallShield" in either program, the "About InstallShield" window reports

"InstallShield(R) 2011 - Premier Edition
Version 17"

and nothing else about the version or build.

[CHOeld]

One other item revealed by the file "Properties" that BeyondCompare missed is "ISInternalVersion", which is 17.0.611 for the older file, 17.0.714 for the newer one.

[aThompson]

So I do realize that I'm totally trying to hijack this thread; but has anyone tried using a non-relative filepath in this parameter? I'm running into a similar problem just trying to use an absolute path; the error logs of my builds still indicate that iscmdbld.exe is still looking in the default directory. I am trying to us the stand alone build version (which really shouldn't matter but worth noting anyways). Just in case i'm being a complete idiot, got some sample syntax below.

iscmdbld.exe -x -s -p "C:\InstallShieldProjects\AnInstallShieldProject.ism" -prqpath "Z:\InstallShieldPrerequisiteFolder"

[CHOeld]

If you attempt to use a project created with an earlier version of InstallShield, you encounter the same pitfall that trapped me for quite a while: an absolute path to the .prq file is stored in the project file (.ism), and that will override the prerequisite path you pass in to ISCmdBld.exe.

To fix it, you first need to configure IS 2011 to use your new .prq path by selecting "Tools" (in the development environment), "Options", "Prerequisites" tab, then adding your new path to the "Prerequisite File Locations (Current User):". Then, you have to open up the project in question, select "Redistributables" (under "Application Data" on the "Installation Designer" tab), find each of your prerequisites, de-select (uncheck) them, then re-select them.

I found it helpful to save all of my old projects in XML format (selected on "General Information"). That way, you can edit the project with a text editor, search for "prerequisites" and see what is stored as a path to the .prq files. You can even fix it directly there if you're bold (back up early and often). The path stored in the project itself needs to be relative for the ISCmdBld switch to work.

[aThompson]

Thanks CHOeld! That got me on track (but didn't quite solve my problem unfortunately). What I'm running into now is that I'm trying to put the prerequisites in one centralized network location so multiple users with the standalone build version of IS can use the prerequisite files. In the .prq file there are filepaths to the actual prerequisite file which are now broken because moved them from their home in the IS install folder to their network location. I tried changing the prerequisite folder in the IS development environment and when I try to re-download the prerequisites, all IS wants to do is yell at me that it can't find them. Did I miss something here?

[CHOeld]

I finally succeeded in doing what you're trying to do, so you can get there. I assume that you've now fixed the absolute paths in the InstallShield project file (.ism), so now you need to get rid of the absolute path in the .prq files. The way that InstallShield recommends is to open up each one using the Prerequisites editor (if you're in the "Redistributables" view, you can right-click on each prerequisite and select "Edit Prerequisite"), select each of the "Files to Include", "Modify", browse to the file and select it. This may result in two references to the same file, in which case you need to delete the old reference. Select "File", "Save" to update the .prq file.

.prq files are in XML format, so you can use a text editor to open them up and make sure they've got no absolute paths in them. Note that the Prerequisite Editor stores relative paths slightly differently than they're stored in the project files. A relative path will look like ".\", as in

"

Good luck!

[aThompson]

CHOeld, I want to thank you very much for your expertise and willingness to help out. After all these shenanigans we're not even going to use the -prqpath flag when building. The only prerequisite we're using so far is the .net framework 4, and that has 7 other perquisites that it depends on (which thankfully don't have dependencies of their own!). We realized this can very rapidly turn into a rabbit hole, which we don't have the resources to peruse. So instead we have a .bat file that copies the entire prerequisite file to a network location (for when a new prerequisite gets downloaded) and since we build releases from a .bat file already, it was easy to get them all to get the prerequisite files from their network location. We shouldn't be downloading any new prerequisite files with any regularity, so hopefully this won't become a problem. *fingers crossed*

[man]

Sorry for reviving this thread, but i am completely stuck on this problem, is there any update on this problem? havent made any progress for 4 days now.

[CHOeld]

Dear man@dis.cc,

You're not giving us much to go on. If you've read through all of the posts, you'll find that the root cause of most of my difficulties was that I was using an obsolete version of IS 2011. Once I upgraded to the current version, I was able to get the prqpath parameter and relative paths in .prq files to work -- even if not everything about this feature works as slick as it could. What are the particulars of your difficulties?

[man]

Well i guess i would like to know what version of installshield it works on. as of right now im using:
InstallShield 2011 - Professional Edition
Version 17
Hotfix A

[CHOeld]

Dear man@dis.cc,

That's answered on the next page over in this thread.

[man]

I realize i should perhaps introduce my problem a bit better, but i've just been handed this InstallShield project 2 weeks ago, because our installshield man left.

I dont want to ask too many questions right now, since im a total newbie still, but i do have one major gripe with the Prerequisites editor that i just simply cannot understand. Ill give an example:

say i have a prerequisite msChart.prq
in my project that has an exclamation next to it, because the IDE cant find it, but says it should have been at:
C:\Program Files\InstallShield\2011\SetupPrerequities\msChart.prq

So i edit the prerequisite msChart.prq and select to ADD files to include, and navigate to the correct location:
C:\projects\InstallShield\SetupPrerequities\msChart.prq

press ok, and close the window, im now prompted to save my changes and I click yes. HOWEVER the IDE wants to save my changes in the file located at:
C:\Program Files\InstallShield\2011\SetupPrerequities\msChart.prq

which was the file it couldn't find to begin with(saving is denied), so i cant do anything, with this prerequisite, except find it, and move it to a location where the IDE expects it to be.

I cant figure out if this is correct behaviour or if my project got smashed up somewhere along the road.

[CHOeld]

Dear man@dis.cc,

I'm not sure, but it sounds like you may need to fix InstallShield's search path to prerequisite files. Look on the “Prerequisites” tab in the “Tools”, “Options” configuration window (from the IDE main menu), and set the path in “Prerequisite File Locations” to whatever you need it to be.

I urge you to go to the oldest post in the thread and read through them all -- i.e., in chronological order -- it might ring some bells. You might also want to look at the InstallShield 2011 release notes that explains the "Ability to Specify a Search Path for InstallShield Prerequisites; Path Variable and Relative Path Support for Source Locations of Prerequisite Files":
http://kb.flexerasoftware.com/selfservice/viewContent.do?externalId=Q208910&sliceId=1

One of my biggest gripes about this new feature from the start has been the paucity of documentation, so that means it takes a lot of trial and error. I can tell, though, it can be made to work if you're persistent.

[Sairen]

Ah, the issue that won't die. Me and my build management team are trying to tackle this, and I'd like to echo my thanks to CHOeld for being so willing to help out on this.

I've read the advice you give, and I admit to not having tried quite all of it yet. I'm getting stuck where you talk about modifying the ISM to use a relative location for the prqs. In the Direct Editor view, ISSetupPrerequisites table, the ISBuildSourcePath has only the name of the prq with no path at all!

It would seem that with no path, it should look in the paths we give it -- from the Options menu in the IDE and from the prqpath parameter for the CmdBld.

In my Tools, Options, Prerequisites, I have no paths listed for the Current User and the ProductFolder location (C:\Program Files (x86)\InstallShield\2011\SetupPrerequisites) listed for All Users.

On our build machine, we are attempting to pass -prqpath "some directory under our version control system" but it is giving us an error that it cannot find the file under the ProductFolder location.

SURELY you're not telling me that what I put into the options of my IDE affects how the ISCmdBld parameters work!


I do also notice one additional thing. In my project, I specify two prq files, and only two rows appear in the ISSetupPrerequisites table. However, one of those prereqs is .NET, so it has a couple of dependencies. It is one of these dependencies that ISCmdBld cannot find. However, these dependencies are not specified anywhere in my ism, so therefore I cannot change their paths! At least, not directly. How should I be dealing with that?

Thanks in advance.