InstallAware

OK,

I'm evaluating IA and am having some issues with media blocks, etc.

I have some app runtimes not supported by IA. I have gotten their detection/installation scripts to work if the runtime's installers are included as creatives in SUPPORTDIR.

Fine.

But now I want to make these runtimes web media blocks to they don't bloat the installer so much. So I added an .rtm file and the 2 working .mia files (one check, one setup) to the Runtimes directory as explained by the "Extending the Application Runtimes View" pdf document.

Now I can see the runtimes properly listed in the IDE, but the installer doesn't work. The build doesn't fail, but I never get a .7zip file for the new runtime, probably because there isn't any content for it. I don't understand how I'm supposed to define what goes into the .7zip file.

Do I have to create plugins for the new runtimes? That seems like a lot of bother just to call another installer. Can I 7-zip the .exe by hand and put it where the IA installer expects to find it? Or can I define the contents of the media block in the IDE without having to create a feature for it?

Also, where do the media blocks go when they are downloaded? To SUPPORTDIR? I can't find that behavior documented anywhere.

Suggestion/comments/examples appreciated!

Keith

Hi Keith!

You are correct, you are most likely not seeing a new 7zip file, because there is no new content.

I recommend the Bundle Files plug-in (just check the Plug-Ins section of this forum) instead of using $SUPPORTDIR$. Bundle Files works great to web-media-block-enable content that would otherwise be a part of support files.

You can also hand-create the 7zip files, and manually download them using the Download File command. But the Bundle Files approach would work just as well. Either way, remember to decompress your data files using the Setup Decompressor, so you'll see maximum benefits from InstallAware's own compression.

As for your last question, media blocks are downloaded and extracted to temporary locations on the system (not $SUPPORTDIR$). This is all managed by the installer and you don't need to worry about it!

Please let me know if you have any more questions...

Here's a sample check script for the Visual C++ Runtime. This is from the product team - part of the upcoming runtime update pack.

File Attached:

checkvc8.mia

And here's the install script for the Visual C++ Runtime. Note how Bundle Files is used to place the runtime files inside a web media block, and how (Un)Install MSI Setup is used to launch the native installer and capture its progress inside the main InstallAware setup itself.

File Attached:

setupvc8.mia

Finally, here is the RTM file. It illustrates that Windows Installer 3.0 is required for this update to install successfully on WinNT systems (NT4, 2000, XP, 2003). Note that Windows Installer 3.0 is not available for Win9X systems (95, 98, ME) but setups that require MSI 3.0 run well on Win9X systems using MSI 2.0.

So while we'd have a potentially difficult situation here, with different MSI requirements by NT/9X platforms, all of these are very easily handled in the RTM file that just lists the requirement, and InstallAware handles the rest for us automatically.

File Attached:

Microsoft Visual C++ Runtime 8.0 (includes ATL and MFC).rtm

OK,

That helped quite a bit. Using the Bundle Files plugin does the trick for me, although I doubt I'll be writing my own plugins anytime soon. The process still feels a bit funky, but hey, I'm new.

I had a question about the Setup Uncompressor. I'm not sure what is supposed to happen. I've tried it on the 2 redist installers I'm using and nothing happens other that a backup (which I asked for) gets created; no folder or directory tree is created. Also, both the original and the backup are the same size. Both installers are .exe's distributed by Microsoft.

Any ideas?

k

Hi Keith

It sounds to me like the Setup Decompressor was unable to process the Microsoft EXE supplied to it. Not all Microsoft EXEs are decompressed, because we do not reverse engineer or "hack" the EXEs in any way. Where documented information is available publicly so we can process in a way that we know is 100% safe and preserves the original data, we do it. Otherwise, we do not, I believe this is what happened here.