File bag .v. support directory.

[bokkie]

Peter, like I said earlier, the help file discusses how a plug-in is registered (hint: registry), what function exports are required, and so forth.

Also, if you are starting to use $SUPPORTDIR$, be sure to look into File Bag - it is a more flexible, path-recursive version of $SUPPORTDIR$ which is also Web Media Block aware.

Michael, I thought I'd pursue this as a new thread. In the other thread you mentioned the file bag alternative. I tried to use it but I'm not sure how I could use instead of the SUPPORTDIR option. I've got that working ok but I could not see how I'd use the file bag to do the same, namely, take a pathname and launch the referenced executable using the Run Program statement.

That is,

Run Program $SUPPORTDIR$\\ConsoleApplication1.exe 23 5, startup in folder C:\\Temp (WAIT)

Works fine. I'm not sure what the syntax would like if I've got the pathname in a file bag. Maybe you meant that the file bag solves other problems more efficiently but I'm not sure how a Web Media Block would help me in this case when I want to run a program. Can you elucidate it a bit further for me when you have a minute?

[MichaelNesmith]

Its not related to running programs but storing files. You can take a look at some built-in application runtime scripts to get a good idea of how it works.

[bokkie]

Its not related to running programs but storing files. You can take a look at some built-in application runtime scripts to get a good idea of how it works.

Thank you kindly. I shall investigate further.

[bokkie]

Michael,

I'm probably stating what's obvious but let me see if I understand the use of the bag correctly.

1. The folder where the files are temporarily copied - according to the documentation - can or will change during the install or uninstall process?

2. If I have an executable called, say, abc.exe, I'd include that plus any other files it needs in a bag. All the files will be available in the same folder thus preserving the purity of the locations where the executable and other assemblies need to find things.

3. To reference the executable, I'd use an arbitrary variable say, $MYBAG$ and then I can run the program using $MYBAG$\\abc.exe.

4. If I only want to reference a single file, then putting it into a bag will give the same benefit as using the support directory? For multiple files I can see a bag is better perhaps but is it considered best practice then to avoid the support directory?

I'll test this over the weekend.

[ulrichard]

Hi bookie,

Sounds correct.

You can always double check that with the debugger, with messagebox debugging or with a logfile.

Filebags also have further advantages:
- the files don't get copied into the IA project dir
- can be included in web deploy blocks
...

Rgds
Richard

[bokkie]

...
- can be included in web deploy blocks
...

Rgds
Richard

Thanks Richard. I'm not sure I'm going to be able to experiment with web deploy blocks. I think I understand the concept but the specifics will have to wait until I can define a test case to experiment with one. I think there might be a white paper on the IA website that discusses them. So much to do and so little time with the evaluation copy...

[bokkie]

I created a bag in my MSIcode. At runtime when I display the contents of the variable it presents me with this:

C:\\Temp\\InstallAwareTest\\Release\\Uncompressed\\data\\PHSFRED\\mFileBagIDE.dll\\bag\\

and my test application ConsoleApplication1.exe does indeed exist inside it.

I created the bag using this MSIcode:

[DEFINE WEB MEDIA PHSFRED]
Set Variable PHSISABAG to
Define File Bag : C:\\TEMP\\ConsoleApplication1\\bin\\Debug\\ConsoleApplication1.exe, get runtime location of files into variable PHSISABAG

and later I try and run the program using:

Set Variable PHSCODE to
Run Program $PHSISABAG$\\ConsoleApplication1.exe 23 5, startup in folder C:\\Temp (WAIT)
MessageBox: PHSCODE value., The value returned from the executable was $PHSCODE$

Trying to run the application using the bag it returns the value -11.

If I run it using the same application in SUPPORTDIR, it correctly returns the value 28. All my application does is add the two command line numbers, nothing fancy.

So, the same application and parameters work via SUPPORTDIR but I get -11 if run from the bag. This makes me think that -11 is an error number of some kind, possibly indicating it can't find the application (which does exist on the disk in the bag folder) or it's getting spooked at runtime. What do you think?

EDIT: I found the problem and it was my fault. I'd inadvertently created the .Net project solution in the wrong location at home and in the right location at the office. Once I corrected it, the bag reference worked successfully.

EDIT 2: I was wrong being wrong. The pathname was a red herring. I still get the -11 error code. The bag variable PHSISABAG is, if I add a watch duing debugging, is set this pathname: C:\\Program Files\\InstallAware\\InstallAware 8\\Plug-Ins\\File Bag\\bag but there is no such folder on my file system. It looks like -11 really means that the file was not found.

[sontle]

Not sure if I am using the file bag correctly. But What I want to do is to include either 32 bits or 64 bits set of assemblies in my Support files. From the options I can only add 1 set and design time. I tried to use the Define File Bag to dynamically include one of these set of assemblies in my installer depending on the 32 or 64 bits environment. I am not sure if I use correctly or can not be used in this case and how I can overcome this issue ? I am using InstallAware 8.2.

Also, I have another question is if we include the files (assemblies) in using Support Files menu, where are the files copied and how they are using using rune time ?

Can you please advise ?

Regards,
Son

[FrancescoT]

Dear Son,

The File Bag command is typically used when a collection of files are temporarily required at (un)install time, but not by the installed application itself.
The included files are available only while setup is running and are not permanently installed on the target system.

Also, I have another question is if we include the files (assemblies) in using Support Files menu, where are the files copied and how they are using using rune time ?

InstallAware uses support files at several places throughout the installation. Support files are not actually installed onto the target system, but they are part of the installation package. They are available temporarily while the installation is executing and are cleaned up when the installer finishes execution.

Therefore files included in SUPPORT FILE and file added using FILE BAG command are temporarily available.

Instead of adding Assembly in Design view use the InstallAware MSI script code and use the following example as starting point to install specific Assembly in your Installation.

CHECK TARGET SYSTEM AT VERY BEGINNING OF YOUR SCRIPT

Code: Select all

Set Variable CHECKSYSTEM to FALSE
Get System Setting Windows XP into CHECKSYSTEM
if Variable CHECKSYSTEM not Equals TRUE
  MessageBox: $TITLE$ Setup Error, This product requires at least Windows XP.$NEWLINE$$NEWLINE$Setup cannot continue.
  Terminate Installation
end
Set Variable ISWIN64 to FALSE
Get System Setting Windows in 64 bit Mode into ISWIN64
if Variable ISWIN64 Equals TRUE
  Set x64 - Native 64 bit Windows, AMD64 and EM64T Architectures - installation mode
  MessageBox: $TITLE$ Setup Debug, Running setup on a WIN 64 Target
end

SUBSEQUENTLY AND BEFORE "APPLY INSTALL" CALL

Code: Select all

  
if Variable ISWIN64 Equals TRUE
    Install Assembly x64 to Global Assembly Cache
else
    Install Assembly x86 to Global Assembly Cache
end

Hope this helps you.

Regards