Forum Discussion
Winforms .exe in MSIX Package Does Not Startup After Auto Update
MicrosoftThank you,
Roy MacLachlan
- I'm losing hope that they will ever fix this bug.
Sushant_Bansal Any update?
Hi,
We are actively looking into this issue. We were able to repro it, but the repro is not 100%.
We are still analysing what can be causing this and what can be done to fix it.
I will share an update, once I have it. Thanks for your feedback and patience.
Regards,
Sushant
MSIX PM
- Is there any news?
- Hi Christophe,
For apps packaged with Conveyor [1] we have a workaround:
1. We default to background updates, which don't have this issue.
2. We have a tiny Win32 app that drives the package manager via the WinRT/C++ API and then starts the app once complete. If a packaged program wishes to force an update and knows one is available e.g. from a server poll, it simply invokes the bundled EXE and then quits. The stub EXE then drives the install/upgrade process whilst showing a progress bar and app logo, and relaunches the app when done.
This gives a similar experience to the built-in "check on start" mode, but with these caveats:
1. It's a feature of Conveyor, not MSIX. Therefore you must use Conveyor to package your app to get it.
2. It's not yet a fully launched/documented feature. You'd probably want our help to activate it. We should launch it soon though.
3. It's up to your app to notice there's a new version available and trigger the update process. For example by doing a quick poll whilst showing a splash screen. We don't block startup like the AppInstaller integration will do, because you may wish to overlap the update check with things like logging in to a server, instead of adding app latency every single time.
You can see a short looping video of what the installer EXE looks like on our website: https://hydraulic.software/ In case that helps: we have the exact same problem but only on some computers: for some the problem always reproduces, for other it never happens.
That's on the exact same application, so the problem seems to be either on the computer itself or some interaction between the computer and the application.
We have not seen any obvious difference between the computers but we're not sure what to look for.
@Roy_MacLachlan any news on this?
Has someone been able to work around this problem? (for example with a custom update process like alluded to here):
https://github.com/MicrosoftDocs/msix-docs/issues/59
??- We are having a similar issue as well. We distribute the app via our website having users download and open the appinstaller file. The app installs & launches fine. After that even just trying to launch from the Start menu icon which is created doesn't launch the app until you click the Search icon in the taskbar. This has been happening ever since we moved to MSIX, on Windows 10, continued after updating to Win11, and still continues after I reformatted and reinstalled Win11 fresh.
Thanks to Lars for repro steps. Roy_MacLachlan - to get everyone on the same page, can you find out what exact version of Windows and AppInstaller your developer is using? Let's rule out the possibility that you've already got it fixed in a build we're not using. Or better, ask your dev to come here directly so we can iterate faster?
I haven't tried to repro it lately, but I'll try to get an independent set of repro steps next week.
I deploy an MSIX app to a shared folder from where my users will install from.
I have 2 versions, the old .3501 and the new, 3504.
MasterData.appinstaller points to the new version.I make 2 copies of the .appinstaller file, one called New and the other called Old.
Then I modify the MasterData - Old.appinstaller file to point at an old version (.3501).
It should look like this:
<?xml version="1.0" encoding="utf-8"?>
<AppInstaller
Uri="file://XXX/MasterData/Test/MasterData.appinstaller"
Version="2022.329.1519.3501" xmlns="http://schemas.microsoft.com/appx/appinstaller/2018">
<MainBundle
Name="067d1aa7-6a9d-4195-b04c-4dc1f12837c1-test"
Version="2022.329.1519.3501"
Publisher="CN=XXX"
Uri="file://XXX/MasterData/Test/MasterData_2022.329.1519.3501/MasterData_2022.329.1519.3501_x64.msixbundle" />
<UpdateSettings>
<OnLaunch ShowPrompt="true" UpdateBlocksActivation="true"
HoursBetweenUpdateChecks="0" />
<AutomaticBackgroundTask />
<ForceUpdateFromAnyVersion>true</ForceUpdateFromAnyVersion>
</UpdateSettings>
</AppInstaller>Then I delete MasterData.appinstaller and copy MasterData - Old.appinstaller, and rename it to MasterData.appinstaller.
Then I install the app by clicking MasterData.appinstaller.Then I close the app.
Now I want to simulate an upgrade of the app.
First I delete MasterData.appinstaller. Then I copy MasterData - New.appinstaller and rename it to MasterData.appinstaller.
Then I go to Windows->Start and run MasterData. The upgrade dialog appears:I click on Update and the update finishes. The dialog closes, but nothing happens. <- This is the bug.
Then I click on the Windows button, and the upgraded app opens.- Roy_MacLachlan
Hi MikeH,
The developer that is working on this is unable to re-create the experience and is asking for a further, more explicit breakdown of steps that re-trigger this experience. Looking at previous comments I do not see an exact list of steps.
Can you or someone following this discussion please provide this?
Thank you,
Roy
- Roy_MacLachlan
Hi MikeH,
I've re-opened the Bug and have included additional information shared by yourself and Lars_Pedersen regarding this negative experience.
Hopefully they will be able to re-produce and identify the problem.
I appreciate the time taken to provide the descriptive information that has been shared in this post, as it'll help us to find and resolve what is happening. Thank you everyone!
Thanks,
Roy
- Oh, sorry, I just realized that this is the thread where we're reporting it.
@Roy - that isn't the right set of reproduction steps indeed. Can you please try again?
1. Try the instructions provided by Lars. App not running at the time.
2. Try the instructions provided by me. Specifically, what I reported was that this happens when the appinstaller is configured to check for an update on every single launch, and then you start the app from the start bar with a pending update. You may also need to fiddle around with this quite a bit because it seems like you have to do something specific to get Windows into such a state.
It might also be worth just asking the developers to read the code carefully and see if they can spot any way in which this can happen. - That's a bug that's been around for a long time, I think it's in the task bar. People have been reporting it for years but Microsoft don't seem able to repro/fix it.
- Hmm, that's not how I repro the error.
I only have one .appinstaller file.
I Install the app, then close it.
Then I modify the .appinstaller file to point to a different version in order to simulate an upgrade.
Then I click the .appinstaller file. The app asks to upgrade and the upgrade dialog finishes and closes.
Then nothing happens until I click the Windows button, or inside the search field in the taskbar, then suddenly the upgraded app starts up. - Roy_MacLachlan
Hi,
The development team has been unable to re-produce the experience you are describing in this thread, providing the following comment:Tested app upgrade with appinstaller files. Unable to reproduce described experience.
- Tested with Virtual Machine running Windows 10 1903.
- Upgrade settings configured in the appinstaller file.
- App installed using the appinstaller files.
- Blank winforms application
- Used the Desktop Bridge to make the appinstaller files and packages.
Steps taken to re-produce experience:
- Modify both URI fields in both appinstaller files to work on your machine. (URIs must be absolute paths).
- Double-click on PackAppThatHasABug1010.appinstaller.
- Check "Launch when ready".
- Click "Install"
- While the app is open, double-click on PackAppThatHasABug2020.appinstaller.
- Check "Launch when ready".
- Click "Upgrade".
** The progress bar might stay at 55% for a moment or two.
- The app closes and reopens with no user intervention.
If the problem is still happening please re-open the ticket with both appinstallers and the packages so I can test locally.
Please let me know if the above is helpful, and if possible please share the appinstaller file and MSIX packaged app that is resulting in this negative experience.
Thank you,
Roy MacLachlan
Roy_MacLachlan Any updates?
Roy_MacLachlan Any update? Our customers have been experiencing this same issue ever since we added the MSIX install.
- Roy_MacLachlanHi,
The development team is still working on this issue.
Thank you,
Roy - It's a shame. I went through all the trouble of setting up build pipelines for MSIX and documenting it. Now my team will probably continue using ClickOnce because of this bug...
- @Roy was there any progress on this?
