Windows configuration is not launched after update when app is started via shourcut.

[Muhomorik]

Hello,

I am using Wix installer and encountered a strange problem after I update the software. I can also reproduce that problem in the Windows Sandbox.

Setup:
MyApp v 2.0 -> MyApp v2.1
SomeDll v 1.2 -> SomeDll v1.3, component GUID is not changed.

Wix creates two shortcuts: desktop and start menu.
The problem appears after the updating the app.

When I run app for the first time after the update via the desktop shortcut I see the famous "Please wait while Windows configures MyApp" window. And it works, SomeDll v1.3 is present.

But, when I run it for the first time from the start menu I see not configuration window and SomeDll is missing i the app folder (old one i deleted).
The only difference I can see between the shortcuts is that on on the desktop has Target greyed out and on start menu is the regular shortcut. And windows says following:

These shortcuts are special. The target of these shortcuts is not a file path or folder. It is registered in the system application (simplifying). Say, they link to PIDLs, not files.

Visually, I can see in explorer that old SomeDll is deleted during the update. And new SomeDll is copied during the "Windows if configuring" stage.

I, obviously, want it to work in both cases and have no idea why the dialog now shown when app is started via the shortcut.

Log:

MSI (s) (C8:88) [09:35:08:706]: Component: cmp_SomeLib_dll; Installed: Absent; Request: Local; Action: Null
MSI (s) (C8:B8) [09:35:09:316]: Component: cmp_SomeLib_dll; Installed: Local; Request: Absent; Action: Absent
MSI (s) (C8:B8) [09:35:11:878]: Executing op: FileRemove(,FileName=SomeLib.dll,,ComponentId={6FC8351B-0070-4DD4-8855-728DBCFF4298})
RemoveFiles: File: SomeLib.dll, Directory: C:\Program Files\MyApp
MSI (s) (C8:B8) [09:35:11:878]: Verifying accessibility of file: SomeLib.dll
MSI (s) (C8:B8) [09:35:11:878]: Note: 1: 2318 2:
MSI (s) (C8:B8) [09:35:11:878]: Note: 1: 2318 2:
MSI (s) (C8:88) [09:35:15:097]: Executing op: ComponentRegister(ComponentId={6FC8351B-0070-4DD4-8855-728DBCFF4298},KeyPath=C:\Program Files\SMyApp\SomeLib.dll,State=3,,Disk=1,SharedDllRefCount=0,BinaryType=1)
1: {15F5BE9D-8139-4DC0-B261-8935304EA318} 2: {6FC8351B-0070-4DD4-8855-728DBCFF4298} 3: C:\Program Files\MyApp\SomeLib.dll

2318 code means File does not exist: [2].

[joelbudreau]

Can you give some more details about your MSIs: is your update a major upgrade? How do you install the 2.0 app and the 2.1 update?

[robmen]

This line (the Action: Null part):

MSI (s) (C8:88) [09:35:08:706]: Component: cmp_SomeLib_dll; Installed: Absent; Request: Local; Action: Null

Suggests the new lib has a lower version than what was installed or some Condition kicked in to prevent the install of the new lib file. The net result is the existing file was removed but the new lib was not installed.

There will be more information in the log file to show this. Look up from that line.

[Muhomorik]

Hello,

Can you give some more details about your MSIs: is your update a major upgrade? How do you install the 2.0 app and the 2.1 update?

When I am testing I am installing it in the Windows Sandbox, it should be a clean install.
I am doing a major update, 1.2 to 1.3.

The net result is the existing file was removed but the new lib was not installed.

Seems to be correct, I can see it on log by the GUID.
Seems that Please wait while Windows configures "Application name" describes exactly the same problem, but there is no solution.

I have Advertise="yes" on desktop shortcut and if I delete it there is no way to trigger MSI repair, except for running it manually via Add/Remove program and my app can never start :/

I also have AllowSameVersionUpgrades="yes" because we need to make micro-patches sometimes.

I've checked the DLL version (one that is missing after update):

Original: 1.2.0.246
Updated: 1.2.0.8

So I guess it happens because MSI doesn't handle the patch part of version, right?

MSI (c) (20:94) [09:35:01:628]: Disallowing installation of component: {6FC8351B-0070-4DD4-8855-728DBCFF4298} since the same component with higher versioned keyfile exists
Action ended 9:35:01: CostFinalize. Return value 1.

MSI (c) (20:94) [09:35:01:675]: Disallowing installation of component: {6FC8351B-0070-4DD4-8855-728DBCFF4298} since the same component with higher versioned keyfile exists
Action ended 9:35:01: MigrateFeatureStates. Return value 1.

MSI (s) (C8:88) [09:35:08:691]: Disallowing installation of component: {6FC8351B-0070-4DD4-8855-728DBCFF4298} since the same component with higher versioned keyfile exists
Action ended 9:35:08: CostFinalize. Return value 1.

MSI (s) (C8:B8) [09:35:09:909]: Executing op: UnregisterSharedComponentProvider(Component={6FC8351B-0070-4DD4-8855-728DBCFF4298},ProductCode={DB1C06C6-CE61-4155-B7AF-xxx})

MSI (s) (C8:B8) [09:35:09:909]: Executing op: ComponentUnregister(ComponentId={6FC8351B-0070-4DD4-8855-728DBCFF4298},,BinaryType=1,)
1: {DB1C06C6-CE61-4155-B7AF-xxx} 2: {6FC8351B-0070-4DD4-8855-728DBCFF4298}

[robmen]

Yeah, basically as I suspected, 1.2.0.8 is smaller than 1.2.0.246. The Windows Installer doesn't like to downgrade files in an upgrade.

[Muhomorik]

Well... it seems to be a common problem and as far as I can see. I've found those posts:

wix major upgrade not installing all files and
Wix major upgrade, replace files regardless of newer file version

and the last one is my case, file version of dll in NuGet got wrong and is now corrected, but I can't get it into the installation.

Also tried suggested solutions, Schedule="afterInstallExecute" and Schedule="afterInstallFinalize" and changing GUID of thr component.

I mean... I explicitly tell to copy the file and file is not there after the operation.
This is not a good user experience either:
"Dear User, every time you install the update, you should go to the Program and Features and repair the program or it will not work because some files are missing."

There seems to be no working solution to the problem :(

[robmen]

I don't know that it is a common problem but some developers do hit the problem. Unfortunately, downgrading files is not something the Windows Installer does well. The best fix is to always increase file versions (time travel is hard). But if you don't control the file, then probably the next easiest workaround is to install to a different folder (or change the name of the file, if that's possible).

Note: Changing the Component GUID without changing all the contained resources just breaks the reference counting more.