Hi there,

I think we hit against the same issue since today.

This is our situation:
We have a main application which is responsible to install the AUP Windows Service. During the installation of this service the path of our main exe will be registered as a trusted path in the AUP service. In the registry on each PC we can see check this by looking under KineticJump/AppLifeUpdate/ServiceKeys. All future updates run without a problem.

The problem arrises when we try to install a second client. At our company we have a test environment and a deploy environemnt (an imitation of a production environment).
The first isntalled client on our test PC's gets it AUP packages from the test environment webserver. When we now try to install a second client next to the other one, the setup itself works like it should be... that's what we initially thought. When an update becomes available on the deploy environment, our main application sees that there is an update available but we get the error as posted in the initial post.

We examined this further and noticed that in the registry only the first client is registered as a trusted update location. The second client, which gets it AUP packages from the deploy environment, is not registered as a trusted update location. The AUP Windows service is trying to tell us that the location of our exe is not trusted.

We also have a clue why this is happening but aren't shure: in our MSI project we use the provided MSM file (version 3.2.0.0. i think) which accepts a "Path" and a "Public Key" key. Those 2 keys and values are stored in the registry. During the installation of our 2 clients we use the same MSI. To by installing the second client, the AUP already is in place and does nothing anymore. Result: only the first installed client is registeren.
If we run the msi in "repair" mode, we overwrite the settings of our first client in the registry. That way the second client can update itself but the first one now gets the error. Why overwrite, probably because the "UpgradeCode" key is used as name for the Service Key in the registy.

If reusing the "UpgradeCode" key is the problem, we don't have a decent solution, the only not decent solution are 2 different MSIs... .

In real life we will also have a situation like this. At our customers site there will be a test environment and a production environment. Our customers probably want for both environments the auto update mechanism so on each client 2 clients must be installed.

Any ideas how to solve this?

Thx!

Hello,

Absolutely, mutliple exe paths can be registered with the service.  The service is a shared resource and multiple applications can utilize the service, providing they are properly registered.

 

I really dont understand your scenario.  You are using the same msi, installing side-by-side the same application in two different locations on the same pc?

 

The merge module properties adds the exe path and public key path that you provide under a key named after the msi upgrade code.  This is because the msi upgrade code never changes for the same application, and is available to the merge module.  That parent key name is arbitrary though.  The AppLife Update process will iterate all service keys looking for a match for the host executable path requesting to use the service.  You could add your registration keys through your main application msi, though this is rarely ever necessary, and I am not sure I understand why it would be necessary in your case.  If doing so might solve your issue, it is certainly a viable option.

I see.  You are using AppLife Update to actually "install" the main application. This gets you around the fact that an MSI will not let you install the same version of an application side-by-side.

 

The information in that forum post is what you need to add the necessary registry keys during an update.  Good to hear that you have found a solution.