iFeedme Blog

Firstly a disclaimer : I don’t really know what I’m talking about here, this entry is a summary of a series of (hopefully educated) guesswork.

That said, todays task was to make an installer for an AIR application that could reside on CD/DVD, detect if AIR is already installed on the users system (And install it if not), and then install the application. All in a familiar (to users of our products, in any case) style of installer and without any reliance on an internet connection.

You should note that I am a big fan of the AIR “badge” installers, but reliance on the presence of flash player v9.1.1.15 + and an internet connection to download the AIR installer makes it rather unsuitable for our purposes.

Why would I want to do such a thing? Well, our marketing department seem to think (rightly or wrongly) that’s it’s a requirement.

Anyway, on with the tech stuff.

We use NSIS installers for our current product line. Not my decision, I was gifted it by a previous (and now departed) programmer.

Personally I have little experience of it, I normally manage to use an existing install script and change a few variable names, possibly hack in something from their support forums or examples and just about get the job done.

All in a “hack at it till it looks like it works” style (which I will continue here).

No doubt anyone who actually knows what they’re doing with NSIS will be laughing at me here, but hopefully they will kindly correct any glaring errors I may make.

I believe the general approach I take here will hold true for any other windows installer you may use, however.

The first task is really to determine whether AIR is installed or not, which I’ve chosen to do by reading a registry string that the AIR runtime install seems to write when it is installed (I don’t have any information or documentation on this, by the way, I just compared registry settings pre/post install). It would appear to tell the system where the application “Adobe AIR Application Installer.exe” is installed, and lives in HKEY_CLASSES_ROOT/AIR.InstallerPackage/shell/open/command.

In the nsis case, the the code to detect/install the AIR runtime looks something like this (probably! It’s all a bit “GoTo” for me, but it seems to work ok)

ReadRegStr $R0 “HKCR” “AIR.InstallerPackage\shell\open\command” “”

StrCmp $R0 “” airNotInstalled copyApplication

airNotInstalled:

MessageBox MB_YESNO “You first need to install Adobe AIR Runtime to run this product. Would you like to install it?” IDYES yes IDNO done

yes:

DetailPrint “installing AIR RUNTIME”

Push $CMDLINE

Call GetParent

Pop $R0

ExecWait “$R0\adobe_air_installer\AdobeAIRInstaller.exe”

;ReadRegStr $R0 “HKCR” “AIR.InstallerPackage\shell\open\command” “”

;DetailPrint “AIR RUNTIME is installed at: $R0″

;MessageBox MB_OK “AIR is installed at $R0″

Now, if you merely wanted to do an offline CD based installer, then I think that would be more or less all you needed.

If you pass the path to your .air archive as an argument to “Adobe AIR Application Installer.exe” then it will handle the install for you in the usual AIR runtime manner with the same dialogues you’ll no doubt be used to by now. Handy!

However, in my case I need to install a “protected” executable rather than the small “stub” exe that AIR sticks in your programs folder, so I need to get my installer to copy the files for me. (Please don’t start me on this “copy protection” thing, I tend to rant profusely about it, but my hands are tied once again). The “protected” executable is the original with a whole load of super secret gubbins wrapped into it that ties the program to the disk that we supply the product on. Apparently. Somehow. We have 3rd party software that will do that to an existing .exe, once done that .exe will not run without the original DVD being present in the drive of the users pc.

It turns out that if you install an application via AIR in the usual way, then head to it’s folder in “program files” and grab the files straight from there then you can install them on another system and they will work (if the AIR runtime is present).

(I wrapped the air application .exe file with the “copy protection” at this time, before making an installer)

I initially didn’t expect this to work, reckoning that there would be some sort of check of integrity of that file by the runtime, but as far as I can tell (in my limited testing) that’s not the case.

As far as I can tell, you will need the files/folders “your_application_name.exe”, “META-INF”, “mimetype”, “your_application_name.swf” and any of the assets that you may have included when you packaged up your AIR app.

In my case, the lines

———————–

copyApplication:

File /r data

File /r img

File /r META-INF

File /r movies

File /r pics

File /r web

File mimetype

File myApp.exe

File myApp.swf

———————–

will grab those files/folders (the “/r” makes the copy recursive) from the directory in which I make the installer and compresses/packages them into the installer (which will unpack them when run).

(NSIS actually does very good lzma compression, which means that you may get a smaller installer than your original .air archive (if you’re lucky, which I was )).

This all seems to work very well, and once installed the application appears to run as it normally would.

Never the less, I would be careful. For instance, I made a tiny test application that just used AIR’s update mechanism to update itself. In the end, it updated itself to the location from which I’d copied the files for the installer on my machine, rather than where my custom installer had placed them on another. Obviously the original AIR install location is stored somewhere, but I have no idea where. So for updates you’d have to build your own system, and I can only guess where there may be other gotchas that I’ve not discovered as yet.

It’s worth noting that this method avoids the user seeing any warnings about code signing (which they would if they were using the AIR installer, if the app is not signed).

Since drafting this article I’ve very briefly tried the “shu-player” installer, which appears to wrap both your AIR application and the runtime into one .exefile which can be run from DVD without any tedious “install the runtime” dialogues for the user.

My first impressions were good, it’s easy to use and worked well in my quick first use test.

It appears to uncompress the runtime and your application into the users temp folder, then attempt to remove them when the app is shut down.

I do have some concerns with this approach : though I’ve not tested it yet I can see some issues with storing persistent settings due to the varying location of each instance of the application on the users system. In use, it also appeared to not clear the temp folders it created, though it did delete their contents.

I’m also not convinced that it would work all that well with our “copy protection” format, though I have yet to try, test and analyse it.

This entry was posted on Wednesday, April 9th, 2008 at 12:03 am and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.