File bag and Run Program

[Guest]

My understanding of File Bag is that it can be used as a replacement for Support Files when the file to be included might change (if it is built as part of a daily build script). So I add this code (Run Program returns a value to the variable Code:

Code: Select all

Set Variable Path to
[DEFINE WEB MEDIA FileBag]
Define File Bag : #RelativePath#\\#Branch#\\project\\bin\\#ConfigurationType#\\Executable.exe, get runtime location of files into variable Path
Run Program $Path$\\Executable.exe -u $username$ -p $password$ -A (WAIT)
MessageBox: Setup, Path = $Path$$NEWLINE$$NEWLINE$Code = $Code$

I appropriately set the compiler variables. When the code runs the MessageBox always shows:

Path =

Code = 0

Executable.exe will never return zero. The build output doesn't show the file Executable.exe being copied. I know that File Bag might not work in Debug mode (learned from a different post) so I tried it both in Debug and in the real world with the same result. So what am I doing wrong? Do I not understand the intent or usage of File Bag? Does Run Program automatically return 0 if it can't find the file? This code is before the interview (UI); does that matter?

[MichaelNesmith]

Define Path before using it in the plug-in with Set Variable. Variables must always be pre-defined before used in plug-in commands.

[Guest]

Is the first line of the code I posted not Defining Path? Just to be sure I changed the first line of the code to "Set Variable Path to something" and the Messagebox showed "Path = something".

I do realize that I forgot to include the line that initializes the variable Code. It was two lines up: "Set Variable Code to".

[MichaelNesmith]

Ah, right. I didn't notice the first line - sorry!
I'm not sure why File Bag fails. You are not running inside the IDE, and you are not doing a debug build either, right?
Try to use all capitals in your File Bag variable names and see if that helps...

[Guest]

I changed the variable to all caps and made sure it was not in debug mode before building. After building I closed InstallAware before I ran the setup. The same problem occured.

I'm using version 5.3 (purchasing takes forever). Is there a known issue in version 5.3?

Is there another way that I could include this file that is built daily so that I can use it before the main install?

[MichaelNesmith]

Hmm, leads me to think its a 5.3 issue...any chance you can try with a 6.0 trial and see if it works? If it does, just copy the File Bag plug-in over to your existing installation - that should take care of it!

[Guest]

I think I got it. I installed the latest version (6 sp2) and it gave me an error message when building. The RelativePath compiler variable is set to "C:\\SVN dev" and it gives the error message "No files matching wildcard pattern c:\\SVN". Apparently it parses by space and doesn't like my folder names. I tried putting quotes around the whole path and the error message changed to "No files matching wildcard pattern "c:\\SVN Dev\\branches\\dev\\project\\bin\\Debug\\Executable.exe""

So, is there a way to get it to recognize a path with spaces in it, or could you make it that way and post an update?

[MichaelNesmith]

No, it does not parse by spaces. Double-check all your paths and values, your compiler variables; use MessageBox to help you find out what happens after compiler variable substitution if necessary.

[Guest]

If it doesn't parse by spaces then I'm really confused. Just to double check I created a brand new default installer and added the code I posted. I set the compiler variables so it would give me "C:\\tmp\\branch\\project\\bin\\Debug\\Executable.exe" (without quotes). It built and ran just fine. Then I did a copy/paste of the tmp directory (so it made "Copy of tmp"). I changed the RelativePath variable to "C:\\Copy of tmp" from "C:\\tmp" (again, without quotes). When I tried to build I got an error that it couldn't find the file "C:\\Copy" (without quotes).

I even tried eliminating the other compiler variables so the path would be C:\\tmp\\Executable.exe or C:\\Copy of tmp\\Executable.exe with the same result.

On your suggestion I used a message box to show what the path would resolve to. It resolved exactly as I expected and matched the actual path to the real file.

I'm quite sure that the plugin interface is delivering the path to the plugin in chuncks because there are spaces (just like a command line would). If I use quotes then the interface sends what is in quotes as a single chunk (single argument) but leaves the quotes on it. Then the plugin doesn't strip off the quotes.

[MichaelNesmith]

Shouldn't be happening, really. Can you send a minimum reproducible test case?

[Guest]

If I remember correctly you just need the .mia and .mpr files. I included a simple hello world program.

File Attached:

New Project.zip

[MichaelNesmith]

Rename your compiler variable to Relative Path instead of RelativePath - that should fix it for you

[Guest]

Call me stupid but I don't understand why that works. I tried it and, sure enough, it does work. Could you please explain why?

Also, does Run Program return "0" if the file is not found? That's what appears to happen.

[MichaelNesmith]

It works, because there is a space in the compiler variable, just like the space in the final path you used. If you entered your path with the space directly, without using a compiler variable, that would work too.

The problem was, the original path you entered was without a space (the compiler variable would later "inject" the space), but this confused the plug-ins storage for its own data, because it stored it in a way without accomodating for a possible space, since it saw no space at the time of data entry.

So the fix was to use a space in your compiler variable instead! This way the plug-in saw a space and stored its data properly - properly, as in a way that allows for a space substitution at build time.