Multi-Instance Setup and Update Service

[CChong]

I’m testing ISPRO 7 in combination with Update Service. In the new ISPRO version it’s possible to use a Multi-Instance Setup. But you can’t use the Update Service in combination with the Multi-Instance?! What I see is that when you use the multi-instance setup it creates for each new copy a new GUID. But I assume that you can still use the PRODUCT_GUID for the InstallShield Update Service ? So when you install a new copy of the Setup it makes a PRODUCT_GUID.ini file and no a INSTANCE_GUID.ini for the Update Service ?

Does anyone know a workaround for this ?

[Chris_Woerner]

The core issue is that you can't call the Update Service with the instance_guid, because it will never be registered with the Update Service server. The second issue is that you may have different versions of your application on the same machine, so the Update Service needs to know which version is being updated.

The 'real' solution is one that we haven't implemented. In that solution, you will call the Update Service with the instance_guid. The Update Service Agent will translate that to the product_guid before calling the Update Service server. However, the Update Service will store information about the application by instance_guid (version/ last check date/ scheduled interval).

As a workaround, try the following:
1. Manually add the object to your project. You can't use the project settings as the Pro IDE doesn't allow you to select the Update Service and Multi-Instance

2. Each time before you call the Update Service you need to call another API, Register() with the product_guid and version.

3. After Register(), you can call your normal API like AppUpdate() using the product_guid. The Update Service will use the version that you just registered when calling the Update Service server.

Limitations:
The last check date used for prompting a user every 'n' days to look for updates won't work. It will be shared between instances of your application.

[CChong]

Chris,

I don’t want to call the UpdateService with the INSTANCE_GUID but with the PRODUCT_GUID. On the machine where several versions are installed the latest version must be registered for the UpdateService.

This is what I want:
I install version 1.0. In the registry a new INSTANCE_GUID is created. For the Update Service a PRODUCT_GUID.ini file is created with version 1.0. I install version 1.0 again but in a different directory. In the registry a new INSTANCE_GUID is created. For the Update Service a PRODUCT_GUID.ini file is created with version 1.0 (this one doesn’t change). I install version 2.0 but in a different directory. In the registry a new INSTANCE_GUID is created. For the Update Service a PRODUCT_GUID.ini file is created with version 2.0. etc etc.

[CChong]

Chris,

It’s working now the way I want. This is what I did.

For the ISPRO 7 Project I enabled the Multi-Instance Setup. I tried to add the UpdateService Object with “Insert InstallShield Object” but the UpdateService Object was not in the Gallery. So I copied the “InstallShield Update Service Object” directory of ISPRO 6.3 to the D:\Program Files\InstallShield\Professional 7\Objects directory. I registered the object in the registry the way all other objects are registered (this is different as in ISPRO 6.3). Now I was able to add the UpdateService Object with “Insert InstallShield Object” because it was now in the Gallery. I add the runtime of the UpdateService in the OnBegin function the way we used to do in ISPRO 6.3. And voila it's working !!!

[Chris_Woerner]

So lets run with your example. You have 3 instances installed on your machine.

version 1; directory A
version 1; directory B
version 2; directory C

Now when your application calls the Update Service, the Update Service will look in the product_GUID.ini file to determine which version is being updated. It will always find version 2.0, as that was the last installed.

But if you were calling the Update Service from version 1; directory A, you will need to make the Update Service understand that you are trying to update version 1 > not version 2 which the Update Service will ready from the product_GUID.ini file.

That is why I suggested that you will need to call Register() before invoking the Update Service from your application. You will be reseting the product_guid.ini file before each call with the correct version.

Does that make sense. Am I telling you something you already figured out? Did you find another way around the issue?

[CChong]

Chris,

I already find a workaround for this problem:

For the ISPRO 7 Project I enabled the Multi-Instance Setup. I tried to add the UpdateService Object with “Insert InstallShield Object” but this one was not in the Gallery. So I copied the “InstallShield Update Service Object” directory of ISPRO 6.3 to the D:\Program Files\InstallShield\Professional 7\Objects directory. I registered the object in the registry the way all other objects are registerd. Now I was able to add the UpdateService Object with “Insert InstallShield Object” because it was now in the Gallery. I add the runtime of the UpdateService in the OnBegin function the way we used to do in ISPRO 6.3. And voila it’s working !!!

[divanova]

Hey Guys,

I am trying to do something very similar to the scenario described in this thread. I have a product that needs to be installed in per instance and also to be updated with the Update Service. Is everthying still the same i.e. the description below holds true or there are any changes to the mutiple instances module so that they can be updated automatically?

And if not, say I choose to go that way with Registering every instance of the product then I can generate up to as many as 5 or 6 calls (i.e. customers) for the same product if I have 5-6 instances, right? Since the update service is paid per customer I don't want to mutiply the customer base by a factor of 5, 6 or even more just so that all instances can be correctly updated. Do you see any way out?

Thanks!
Dannie

Chris Woerner wrote:
The core issue is that you can't call the Update Service with the instance_guid, because it will never be registered with the Update Service server. The second issue is that you may have different versions of your application on the same machine, so the Update Service needs to know which version is being updated.

The 'real' solution is one that we haven't implemented. In that solution, you will call the Update Service with the instance_guid. The Update Service Agent will translate that to the product_guid before calling the Update Service server. However, the Update Service will store information about the application by instance_guid (version/ last check date/ scheduled interval).

As a workaround, try the following:
1. Manually add the object to your project. You can't use the project settings as the Pro IDE doesn't allow you to select the Update Service and Multi-Instance

2. Each time before you call the Update Service you need to call another API, Register() with the product_guid and version.

3. After Register(), you can call your normal API like AppUpdate() using the product_guid. The Update Service will use the version that you just registered when calling the Update Service server.

Limitations:
The last check date used for prompting a user every 'n' days to look for updates won't work. It will be shared between instances of your application.