Installing AIR Help through another Installer?

[Jared Hess]

We're developing a WPF application and according to our devs, they'd like to install the AIR help through our own installer rather than use a separate setup process. Their concerns are:

1) It's a pain to have the user have to go through another setup process.

2) We'd like to be able to control through our installer where the help ends up as well as control the uninstalling

of the AIR help when the app is uninstalled.

So is there a way to package an AIR help install through our own setup process, and bypass Adobe's installer? If so, how?

It looks like back in 2009 another user was considering doing this in this post here: http://forums.adobe.com/message/2286578#2286578 and it didn't look like this was recommended or possible, but maybe things have changed in 2011?

My second question is if we must use Adobe's Installer, is there a way to run it silently in the background without any user interaction?

Thanks in advance.

Jared

RH 9, Local AIR Help.

[Jeff_Coatsworth]

Yes, you can package the AIR installer along with your product and run it silently. You need to apply for a -free- license to redistribute the installer. Check out http://www.adobe.com/products/air/runtime_distribution_faq.html

for info

[Jared Hess]

Thanks Jeff. Would that let us uninstall the help too when our product is uninstalled?

[Jeff_Coatsworth]

Not sure; I've never tried it ;>)

[Peter Grainge]

So is there a way to package an AIR help install through our own setup process, and bypass Adobe's installer?

If you are referring to the .AIR file, you have to use that to install the AIR help, assuming you want it to work.

However, why is that a pain for the user? Your developers can build running that into their installation routine. Our developers built it into an MSI.

Remember you have to check for the installation of the AIR runtime and install that as well if needed. To do that you have to get a distribution licence from Adobe.

This is all covered on my site. See the RoboHelp 9 version of the AIR topics as well as it contains later information.

I guess you can build in uninstalling as well but think twice about uninstalling the runtime. It is used for many other things as well, TweetDeck is a common example and no one will give you prizes for screwing up their AIR applications.

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

[Jared Hess]

Thanks for responding Peter.

If you are referring to the .AIR file, you have to use that to install the AIR help, assuming you want it to work.

We were originally wondering if there was a way of ending up with the final locally installed AIR help file without using the .AIR file (let our own installer package the needed components on a user's system) since we didn't want to run a second installer if we could at all help it. But that doesn't sound like it's possible currently. Too bad.

However, why is that a pain for the user? Your developers can build running that into their installation routine. Our developers built it into an MSI.

Unless it's done silently, it's a second set of redundant steps where users have to decide for a second time where to install something. Some will likely wonder, "I just chose C:\program files\ in the install wizard earlier, why do I have to do it again?" I agree it's not a huge deal, and I would personally consider it a minor annoyance. But our devs want our product installation to be as simple as possible. Hence the desire for handling the installation internally and if that doesn't work at least have a silent installer approach.

I guess you can build in uninstalling as well but think twice about uninstalling the runtime. It is used for many other things as well, TweetDeck is a common example and no one will give you prizes for screwing up their AIR applications.

Regarding uninstalling, it sounds like there's not a way to uninstall just the Help content but leave the AIR runtime intact?

[Peter Grainge]

You do have to use the .AIR. I cannot say how silently though, that is something your installation developer should be able to experiment with. You wouldn't want the user changing the path if the help is context sensitive.

Re uninstalling, surely your developers can uninstall the help as well as the software? I would leave the runtime.

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

[Jeff_Coatsworth]

We have ours running silently - both the initial install of the AIR runtime and the AIRHelp file. I'm not sure exactly how our developers are doing it, but they figured it out from the documentation that came with the runtime.

[Jared Hess]

Alright. Thanks guys. We'll play around with it and see what we come up with.

[Jared Hess]

Just a follow-up to explain our thoughts on how we're currently approaching this.

We've decided to launch the install of the AIR runtime from our product's installer (silent install). Our installer will then put the files from a post .air help installation (the .exe and data folder, and so on) directly onto the users' systems. That's the plan anyway. From our initial round of tests, this seems to work.

My Tests:

• I copied the help data from the program files directory following an .air help install as it's own folder onto the virtual machine (running Vista), and ran the exe there. It opened the help fine (the runtime was already previously installed).
• I tested user commenting back and forth between systems, and that worked as well. My Vista system was able to send and receive user comments just fine.
• I tested over-the-internet help file updating on the Vista system, and it pulled down the latest help without problems.

This would allow our installer to better control the location, install, and uninstall of help content.

I'm wondering if anyone has experienced problems (or foresees any) going this route?

[Jeff_Coatsworth]

I don't think you need to install an "unpacked" AIR installation when you do everything in silent mode. I know our install of "locally-installed" flavoured AIRHelp is all done behind the scenes. The installer checks to see if the AIR runtime is already installed & installs it if it isn't, then installs our .net product and its accompanying .air file into the location that the developers wanted it placed. The only interaction I seem to remember seeing was the initial screen suggesting the default location for our product.

[Peter Grainge]

If I follow correctly you are using Adobe's installer for the runtime but for the help itself you are just copying the files installed on one PC to every PC that is going to have the help. I don't quite follow why you want to do things in such a non standard way but that's up to you as long as you accept it is non standard and something could break in the future. Have you had your developers check whether installing from the .AIR files create any registry entries?

You say "This would allow our installer to better control the location, install, and uninstall of help content" but when creating the AIR file you can determine where the help is installed. I'm not sure but I would have thought that you can then run a silent install so that the location cannot be changed.

Please preface any future posts about the help not working as expected with a note about this way of installing!

I hope it all works for you.

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

[Jared Hess]

Thanks Peter and Jeff.

I don't know why exactly they want to do it this way and not use the .air installer. Still trying to figure that out. I think part of the reason is that the .air installer always sends the extracted help content to a directory off of Program Files, right? At least when I define the .AIR layout, you can only change what subfolder it goes to there. (See Program Menu Folder field below).

What if the user installs our product to a non-standard location? Like to C:\MyStuff\. If the .AIR installer makes the help always go to the defined subdirectory off of C:\Program Files\ I don't know if our context mapping would work in that case, since it needs to reside in the same folder as our product's .exe.

Does anyone know if the silent install can change pathways on the fly so it matches what the user picks if he changes from our product's default install location? Or if that even matters?

Anyway, Peter you are correct. There is at least one problem with our approach. Everything works fine it seems, except for the auto update feature. That seems to work if you're not carefully watching. Here's what I found:

• If the copied content is in a directory with a name different from the help title's name, it pulls down the help into an entirely new folder based on the help's title (see the "Help Title" field in the above image). At first I didn't notice this and thought everything was good because the update reopens the help from the newly created folder... It was only later when I saw a new folder on the desktop that I said, "What's this...?".
• If the copied content is in a directory with the same name as the help title's name, auto updating pretends to work but nothing is updated when the help re-opens.

When I get time, I'll do some more in-depth testing to see if that's the only issue and if there's some way around it. But personally, I'd just like to use the .air file to install. I just wish we had a little more freedom from our product's installer over where the .air file is installed.

[Peter Grainge]

I thought the practice was to put programs into Program Files so that the OS could then "protect them".

As to the user changing the path, I think the point that Jeff and I are both trying to get across is that to the best of our belief your developers can run a silent install so that they do not get that option.

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

[Jared Hess]

You misunderstand. I know we can lock the silent install so that they can't change the .AIR help directory. The issue is that if the help is locked into place and they change where our product goes, what happens to context mapping? Maybe we can tell our product to always look in c:\program files\installed air directory\ and it'll work.

[Peter Grainge]

OK. Yes either remove the option or make it so that the AIR help is always installed somewhere relative to you application. Not sure how that would be done but sounds like something your developers should be able to manage.

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

[Jeff_Coatsworth]

I just tested our app installer & steered it to another location (c:\temp\) - it installed there, but it seems my assumption that the help install would follow was wrong - it didn't seem to get installed at all.

I checked the SSL settings of the project and found that I had given it a folder name in the Program Menu Folder field - the help says this about that field:

Program Menu Folder

Specify the program menu folder name. For example, on Windows, the string that you specify is appended to form the path Start > Programs > [Program Menu Folder] > [help project title].

I'm not sure what would happen if I left it blank - would it float along with the app installer location then? I can't really test that on my system because I don't control the build process for the app (sorry).

Edit - fixed help text (somehow it tried to come in as a hyperlink). I spoke too soon - I found the help installer (the .air file) buried within the c:\temp location I was test installing into. It looks like our installer didn't know how to launch it to install within the app's sub-folders like it normally does when you accept the default location (which is one of those c:\program files\ folders). So close!

[Jared Hess]

Thanks Jeff. That's something we'll have to look into I guess.

[Peter Grainge]

The AIR installer assumes Program Files. It will always install in a folder with your Help Title as the folder name. If you put something in the field when configuring the SSL, that becomes the parent.

We install to CoName/HelpTitle. Help for a second product would go to CoName/HelpTitle2. That way all our help is in one folder in Program Files.

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

[Guest]

We have another issue that we need to resolve.

Question: Is the AIRHelp application 32bit only?

We´re using the AIR Help Installer with the bundled AIR as per the Adobe runtime distribution documentation, and have set it up with the command line switch -location "C:/Program Files/WinApp/Help".

However, on Windows 7 64bit I cannot get our AIR Help to install into the ´proper´ "Program Files" directory. It seems Windows forces our application to live in the "Program Files (x86)" folder. I´ve been told that Windows 7 does this for all 32bit applications.

Has anyone else seen this and know of a resolution?

[The_Real_Mike73]

FSjursaether,

When you create an installation package, you need to use variables for folders like "Program Files" because they're different for many systems and even locals.  Check the documentation for whatever installer your using for the correct variables to use.

[Guest]

@The Real Mike73 - yes, we´re doing this now using Installshield.

However, in our tests we´ve used the bundled AIR runtime installer, and one of the command line options is -location, and even when we do put in "C:\Program Files\WinApp\Help" as the directory to install into, it insists on installing into "C:\Program Files (x86)\WinApp\Help" folder.

Another related question: considering that AirHelp installs itself as an application, should we avoid installing the AirHelp into a sub-folder of another program? They´ll both get entries into the Control Panel and registry. The WinApp is the "master" app, and by that extension, we do want the AirHelp to be uninstalled if the user wants to uninstall the WinApp program.

More testing remains it seems.

Thanks for your replies.

[Mo_Arora-xkWzcj]

AIR apps are 32 bit only, which means that you won’t be able to make them sit in the ‘usual’ Program Files folder on a 64 bit Windows.

For the latter question, I think that would depend on WinApp’s uninstaller. It can choose to uninstall both the WinApp and AIRHelp. But, as Peter too suggested in one of the replies above, AIR (Runtime) should be kept intact as uninstalling it will impact other existing AIR Apps on user’s machine.

~Mohit Arora