AdvAI Search not looking in USB

[SteveS]

Greetings,
I've tried to find old posts but I'm not seeing a working solution to one tiny issue I have.

In AdvAI is add a seach and tell it to find "DLSSoftware" at level zero (0)and set that letter to my APPDIR. It works great on local drived but does not look on removable drives. I read the post about Dialog and the combo setting to display removable drives but I am forcing an install and want it to be as silent at possable.

Sample: A USB drive containing my application (I made the stick and gave it to the user) connects to a srv and pulls an MSI if available and saves it to the USB in a subfolder called Updates. I need to unpackage my payload starting at the drive letter. Say it's H: but my msi is in H:\DLSSoftware\DLSClient\Transfers\Updates. I don't want to move my MSI to root to use SourceDir.

Can search be made to look at removable drives?

Thanks.

[Cosmin]

Hi,

I'm afraid that the Windows Installer searches cannot use removable drives. However, what you need can be done by using a custom action. Here is some sample code which extracts the root from the SourceDir path:

Code: Select all

dim source
dim tokens
dim sourceRoot
source = Session.Property("SourceDir")
tokens = Split(source, ":")
sourceRoot = tokens(0) & ":\"
Session.Property("SOURCEDIR_ROOT") = sourceRoot

After this custom action runs, the property SOURCEDIR_ROOT will be set to the root of source directory.

Regards,
Cosmin

[erik_nMT]

We too are having trouble with an .msi that we want to run as an update to an application installed on a USB drive. (Our primary post is topic 20091.) We're resuming our efforts to solve this problem, and searching the forums led to this thread.

We are by no means experts in Windows installations, and we rely on AI ver.8.9 (currently) Enterprise edition to make our deployments as easy as we can. I would like to ask what exactly is meant by the statement "the Windows Installer searches cannot use removable drives". Does that mean that there is an inherent conflict between the Windows Installer and any application that is installed *on* a removable drive (which then needs periodically to be updated)?

We have a situation similar to what SteveS has posted, where we have an app that users can download and install on a USB stick ... we update the major releases of this app two or three times a year, so we need the app to use the built-in AI updater feature to query our server for available updates, download the newest version if one is found, and launch it to install it, all on the same USB stick (which means its drive letter could vary). Right now the second installation (the update, in other words) fails for machines on Windows 7 and Vista.

Is our best hope to try something similar to the custom-action approach described in this thread? Or is it even possible to automatically update a Windows application that had originally been installed on a removable USB device? Like I said, we're not developer-level Windows experts...

[mihai.petcu]

Hello,

Unfortunately, the Advanced Updater doesn't currently support installing on USB stick. This happens because the detection criteria searches the registry or the file system on a certain drive.

We added this improvement on our TODO list and we'll consider its implementation in a future version. Until then, you can try to develop your own custom .EXE that performs the Installed Detection search.

All the best,
Mihai

[mihai.petcu]

Hello,

It seems our development team had already implemented this possibility.

Here's what you can try:
- go to Update Properties Tab in your updates configuration project
- select "File Version" in "Installed Detection" section and then use the ProductCode and ComponentId method described in the above user guide article
- you can get the package product code (ProductCode) from Product IDs Tab
- then you should choose an ID component (ComponentId) which doesn't get changed from one version to the next from the Organization Page -> Component Properties

This combination should resolve to a valid path and you should be able to install on any drive including a USB drive.

All the best,
Mihai

[erik_nMT]

I need more explanation of what you mean by "choose an ID component (ComponentId) which doesn't get changed from one version to the next from the Organization Page -> Component Properties"

What component wouldn't "get changed" from one version to the next?

[mihai.petcu]

Hello,

What component wouldn't "get changed" from one version to the next?

Not a component that wouldn't get changed. I meant the ID of a component (ComponentID or GUID) which doesn't get changed from one version to the next.

All the best,
Mihai

[erik_nMT]

Here's a more complete explanation of the exact problem we are encountering, and why we posted in this particular forum topic.

Our main product, in its standard version for Windows, installs on the user's hard drive and gets registered with Windows. We then use Advanced Updater, and the Installed Detection section as noted above, to discover the new version and install it on top of the old version. The installed detection points to the product ID:component ID for the main program in our product. All of that works fine.

We also have deployed a similar product with a slightly different configuration -- instead of installing to a hard drive, the product must be installed on a removable/USB drive, and it is *not* registered with Windows. The USB can then be ported from machine to machine and the user will be able to open it and use all the features. That configuration, too, works fine, and we have the Enterprise edition of Adv.Installer so that we can prompt the user for a USB drive letter during the install.

The problem comes when we try to devise an Advanced Updater project for the USB-only version. We have taken the same approach as before, of pointing to the Product ID:Component ID values to detect an installed version, and the old version will find and download the new .msi. The updater .ini file will even detect the drive where it is installed and create an \updates folder inside it and save the new .msi package there, and launch it. The update process fails, however, when it attempts to over-write the updater executable itself. What we are getting is an message that says "Error writing to file: E:\(productnamefolder)\updater.exe. Verify that you have access to that directory." The user then has no choice but to stop the update, which then automatically rolls back.

We are not sure if we have interpreted the error message properly or not. It does not seem as though it is an issue of the directory's availability but rather the fact that the updater is running (open) and thus that's a conflict with the file system. We need to know if there is any way around the problem of having the updater executable running during the update itself. Does this problem mean there is no practical way to automatically update a package that has been installed on a removable drive?

[Daniel]

Hello,

I'm not sure why you are encountering this behavior. Please keep in mind that when the updater.exe is launched it is copied in a temporary location and then it's running from there, so there should be no problem when updating. Can you please make sure that updater.exe file it is not used by another process during product update? For example you can use the Process Explorer tool from Microsoft.

Also, you should make sure you have write permissions on the related install location.

All the best,
Daniel