Running windows service that's a part of a Desktop Bridge WFP app blocks update

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 service

This 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.