Window CAB files?

[TssTE]

Hello,
I'm running IA x15 Studio Admin, and I have for years without issues. When I was compiling manually today (usually it's automated), I noticed that many cab files are being compressed during the process. The Build Progress dialog shows, for example,

Code: Select all

Compressing install: OFFLINE\mFileBagIDE.dl\4BB67435\Windows6.1-KB4019990-x64.cab (12%)

We don't check for a minimum OS and we only have .NET Framework 4.7.2 Application Runtime required. Why is this Windows 7/Windows Server 2008 R2 CAB file being included? Is there anyway to exclude it? We have a 1GB installer, so anything to make it smaller would be useful. We already have compression set to a level our users can deal with.

I already googled trying to find an answer to this, as well as searching the forum and whitepapers. I didn't see any options in the UI that impacted it either.

Thank you in advance,
Matt

[JohnGaver]

That's a great question, Matt!

The default runtime installer scripts are optimized to successfully install everywhere, no exceptions.

If you've dropped support for certain platforms, just edit the runtime scripts to take out the unnecessary bits.

You should be easily able to spot where legacy platforms are handled by just reading the runtime installer scripts.

Simply delete those lines, and rebuild.

[TssTE]

Thank you for the reply. I have one follow-up question:

When you say, "edit the runtime scripts", can you please be more precise, like exactly which UI tab/area and what I should be looking for? I could not find anything by going through the UI myself. I looked in every area of the Design tab, and in the MSIcode tab I searched for CAB and KB to no avail.

If one has to do this outside of the UI, then I'm going to need a lot more direction as I've never done that before.

Thank you,
Matt

[JohnGaver]

My pleasure!

So you would look inside the MSIcode tab for the runtime installation script you suspect to be responsible for the CAB.

The CAB file will most probably be not listed individually by name, as it would be bundled in your setup via a File Bag action (which does not install the files but makes them available temporarily, while setup is running only), using a wildcard (*.*) pattern.

Hope that helps you.

[TssTE]

Thank you. Using your instructions, I dug a little deeper, and I found it. The built-in application runtime for .NET Framework 4.8 is dropping these. The FileBag for it grabs everything from C:\Program Files (x86)\InstallAware X15\runtimes\Microsoft .NET Framework 4.8 (x86 and x64)\, which includes these CAB files.

A suggestion for a future release: If the Design tab>Application Requirements>Minimum Operating System setting is set, then the Application Runtime's FileBag should ignore the Windows CAB files that don't meet that minimum OS setting.

Thanks again,
Matt

[JohnGaver]

That's a great suggestion, but the File Bag plug-in and the Get System Settings command don't work that way.

File Bag literally "bags up" any collection of files, and makes them temporarily available during your setup.

It is like a more versatile implementation of $SUPPORTDIR$ accessible Support Files, in that they can be placed inside Web Media Blocks, and thus conditionally downloaded only when required (ex: in your scenario, when your target OS is missing .NET).

Get System Settings just queries a minimum system capability, and returns a result accordingly.

What you're suggesting would require a hard-coded interaction between these two commands, which given how there's actually nothing hard-coded in your 100% free flowing setup script in InstallAware, is frankly impossible.

File Bag bags any collection of files (not just runtimes), and Get System Settings may be called to query any kind of system capability, anywhere in your script, and at any time - for literally any purpose. Entangling them like this would have unpredictable effects across your entire installation script flow.

Note that the Design views emit script commands in the background for you as you work. These are just some of the commands they emit, amongst others. This way, you can drop down to the script anywhere you like, and inject custom behavior - without losing the capability to enjoy a zero-code setup authoring experience.