[updater] Updating Windows app from Tauri 1 to 2 repeats update dialog

[calejvaldez]

I had an app built with Tauri 1. When I transitioned and published the app with Tauri 2, I got the update dialog as usual. I install the new update, but the app restarts in the version it tried to replace. I selected download again, and it goes on as a loop.

I checked my installed programs, and I had two versions of my program installed, one 1.3.2, and another 1.3.4.

[FabianLars]

Just to be sure, did you test msi -> msi or setup.exe -> setup.exe ?

Assuming we're talking about https://github.com/calejvaldez/YouAreTyping/releases/tag/v1.3.4 then latest.json points to the .msi which means that if you install the first app instance via setup.exe the update will fail.

(setup.exe -> msi updates are somewhat supported but not the other way around)

[calejvaldez]

Thanks for the quick response!

When I first noticed it, I wasn't sure how I originally installed it. However, the second time around (redownloaded to make sure) it was msi -> msi.

[calejvaldez]

Came back with more information.

The Updater installed the v2 version (1.3.4), but also keeps the v1 version installed (1.3.2).

When I open the file location of the program, I'm sent to this folder:

Where You Are Typing.exe is 1.3.2, but you-are-typing.exe is 1.3.4, again keeping both installed. When the Updater restarts the program, it restarts using You Are Typing.exe.

My workaround is just instructing users to delete 1.3.2.

[FabianLars]

Ah okay, this one is tracked here tauri-apps/tauri#10355 - i'll keep your issue open though so it's tracked on both repos.

[krlvi]

We hit the same issue at GitButler, so over the weekend I toyed a bit with implementing a compatibility mode here: gitbutlerapp/tauri#1
However, I have put development of it on pause since I wasn't sure how to test the Linux bundles correctly

[dwosk]

FWIW we encountered this as well and it was because the upgrade code in the MSI installer is different between the Tauri v1 and Tauri v2 generated MSIs. As mentioned above, it boils down to the executable name change (upgrade code comes from a v5 UUID namespace derived from the executable name).

As a workaround we started using our own template.wxs (copied verbatim from what Tauri v2 uses) and simply hardcoded the upgrade code to what it was in the Tauri v1 MSI.

IMO the upgrade code should be set via tauri.conf.json as in theory it should never change/be tied to something that could possibly change.

[lucasfernog]

Closed by tauri-apps/tauri#10962 and tauri-apps/tauri#10967