Forum Discussion
Running windows service that's a part of a Desktop Bridge WFP app blocks update
I have a WPF application that has been packaged using DesktopBridge into MSIX and submitted to the Microsoft Store. This application has a WPF UI component, and it also has a windows service component that runs in the background whenever the PC is turned on. The UI component is used for configuring user settings and credentials for the windows service, and the windows service is actually the main component of this app. It's designed this way because of our client's needs.
The problem that I'm running into is that when we publish a newer version to the Microsoft Store, the app fails to update with an error "0x80073D02: The package could not be installed because resources it modifies are currently in use" It looks like this is caused by the running windows service, and the store app update is not able to stop the service before the update replaces the files in the VFS. When the user manually stops the windows service, the update completes just fine and restarts the windows service as expected.
When testing the update using different versions of MSIX files, I noticed that appending the flag -ForceApplicationShutdown to the Add-AppPackage command will achieve what I need, but this doesn't seem to be an option in the windows application packaging project, or in the Microsoft Store submission process.
I know that including a windows service within an MSIX package is a restricted capability, so is this behavior due to the usage of this restricted capability? Also, is there a fix or workaround that will allow the update process to automatically stop the windows service before trying to replace the files?
Thank you for any help or suggestions, and I'm happy to provide any additional information needed.
3 Replies
Interesting issue. I don't think the Microsoft Store folks considered this use case. I think you'll have to tell customers to uninstall/reinstall (or use windows services manager to stop the service before updating). Not what I'd want to tell customers, but for now I do not see a better answer for you.
Thanks for replying to my post, I've forgotten to check on it in a while, sorry about that. What you're saying is also kind of the conclusion that I got searching around the internet on this topic.
This workaround that I've suggested to my team is what have been using so far:
1. When the store checks for updates, it triggers a number of events in the log "Microsoft-Windows-AppxPackaging/Operational"
2. Since our service is already running in the background with a timer worker service, I added another hosted service that listens for events from that event log
3. During an update, when the store picks up an available update and tries to apply it to an app, I noticed that one of the events with an ID of 157 fires once per app update, and specifies the app and publisher information
4. The EventLogWatcher I added as a hosted service listens for events with ID 157, and has logic to check if the update event triggered matches its own
5. Once matched, the app knows that the store is now trying to update it, so it can run code to stop the running windows serviceThis workaround has worked well in our testing so far, but it seems a bit hacky to say the least. The event 157 that I chose to listen for happens towards the beginning of the series of events that the store update triggers, so by the time the update is downloaded and ready to be applied, the service has had enough time to stop itself. I'm still worried about how reliable this is, because if any Windows update ever changes the store behavior to fire different events or with different event data/content, we're kind of screwed again.
Tagging Fiza_Azmi on this issue.
