InstallAware 16 - runtime files collision in file bag?!

[kink]

Hi,

we have a serious problem with our setup projects which include multiple runtimes, e.g., .NET Framework 4 (Client + Full, x86 + x64), MSVC 11 (Minimum + Additional, x86 + x64), MSI 3.1 etc. We obviously use the built-in InstallAware runtime files and scripts. The setup*.mia scripts put the corresponding runtime files into file bags. The thing is that all file bags seem to be merged into a single output folder (data\OFFLINE\mFileBagIDE.dll\bag), so if the runtime source trees contain entries with the same relative path, they overwrite each other. That can be easily reproduced with just the MSVC 11 runtimes, since each of the 4 runtimes (Minimum x86 + x64, Additional x86 + x64) contains a file named cab1.cab, so there's only a single cab1.cab resulting in data\OFFLINE\mFileBagIDE.dll\bag. The prerequisites installation then obviously fails due to missing files in that cabinet file. The .NET Framework runtime trees for x86 and x64 are pretty similar too, so there would certainly arise issues as well (we don't get there yet though).
Is it possible that noone has encountered this pretty obvious problem before? Our build "number" is 6.7.13, and we've just migrated from InstallAware 9 R2. Switching from MSI to native engine doesn't change anything in that regard, nor does building uncompressed or single file setups, as it seems to be a bug in the file bag plugin. The modification date of both mFileBagIDE.dll and mFileBagEXE.dll is June 5th 2013, so they have got to belong to InstallAware 16.

We have another problem with the checkmsi31.mia script, which seems not to detect a missing Windows Installer 3.1 on WinXP SP3. The checkmsi30.mia script worked fine in InstallAware 9 R2...

Regards,
kink

[FrancescoT]

Dear kink,

let me check it.

Regards

[FrancescoT]

Dear kink,

I have just tried ... but I'm not able to replicate your findings.

As you can see by the attached screenshot, all the required file bags seem to be correctly generated under the project output folder.

output.png (181.8 KiB) Viewed 7693 times

I am using IA 16.03 with my test and if you are using a different release, please update your product and regenerate your personal license file as well.
You can verify your installed IA version, checking the version reported with ARP under Control Panel.

Hope this helps you.

Regards

[kink]

Ciao Francesco,

thank you very much for the quick response. Unfortunately it still doesn't work after updating to 16.03.

A new sample project works as long as I keep the automatically generated Web Media Blocks. As soon as they are removed, the same thing happens - all file bags are merged into data\OFFLINE\mFileBagIDE.dll\bag instead of each file bag being copied to a data\[preceding Web Media Block name]\mFileBagIDE.dll\bag directory. The documentation about Web Media Blocks mentions something like this though.
We got rid of these Web Media Blocks in our projects since they seemed superfluous. Now when I re-add them manually in the main script, nothing changes; nor does re-adding the runtimes via the IA GUI, which then inserts Web Media Blocks and the built-in script includes in some places. Please note that our main script diverges quite a bit from the IA template - e.g., our pre-requisites are checked and installed after the components selection since they depend on the features to be installed, we use different code folding regions and comments etc.

So I'd be grateful if you could investigate further how the file bags and web media blocks interact in detail and why a web media block name apparently isn't used under certain circumstances. I'll try to compose a minimal failing project in the meantime.

Thanks again,
Martin

/edit: sample project uploaded

Filebag.zip

Example project showing that file bags are not put into web media block directories.

(5.35 KiB) Downloaded 456 times

[FrancescoT]

Ciao Martin,

I tried your project and I'm able to replicate the same but I'm not able to find the same, if I use a new project from scratch.

Note that I have tried even to modify your project with reducing it at minimal, as can be a new "BLANK" project from scratch.
In addition, I have reduced the main script file to two File bag calls only (... to include some dummy files).

Doing as above, your modified project continues to produce the error and my new project works always fine.

Obviously, I have also inspect your project file content and apparently, it doesn't contain any error.

I would like to know how you have realized the project you sent and possibly, the exact steps you used.
If you prefer, you can contact me directly at: support@installaware.com.

Regards

[kink]

Ciao,

well the project has evolved over the years, so I can't provide detailed steps. I did some research on my own and eventually found the solution - the culprit is the CACHESOURCES compiler variable, which we set to TRUE in our project. As soon as that variable is removed, the file bags are generated as expected. I found nothing in your docs about that variable, so it probably had a meaning for older InstallAware versions and still affects the current version, although it is not documented! So this issue ought to be fixed.

While the file bags are now correct, we get problems with long paths (for the .NET framework 4 files) since the web media block names aren't extremely short (that seems to apply only for relative output paths though, e.g. ".\output"; using an absolute output path pointing to exactly the same directory strangely works!). So please fix this issue in the future, e.g., you could use the \\?\ prefix for paths >= 260 chars and get rid of the ugly 8.3 names hack...

Regards,
Martin

/edit: the CACHESOURCES compiler variable is set automatically to TRUE if the "Always Cache Setup Sources" checkbox in the project's build settings is checked! We need this cache, so please find a way to use that together with functioning file bags. This has worked in InstallAware 9!

[FrancescoT]

Dear Martin,

we have verified what you reported and currently this behavior is by design.
I perfectly understand that what I'm saying may sound strange, but it is the truth.

I have been able to replicate the same behavior with any previous IA version I used.
Probably, you found a different behavior using some previous IA version, due a different way used to store locally the runtime files with that version.

However, we added to our to-do list a File Bag enhancement ... in order to make this possible in the very next future.

As workaround, you could store those runtime files under a different location, having care to place them within an additional subfolder.
Doing in this way, the File Bag command will replicate the subfolder under the passed directory and the used files are not merged into a sigle folder.
Obviously if you want to proceed in this way, you must update accordingly the File Bag source directory with the runtime script.

Regards