Detect if an application is in use before updating
kestaskal opened this issue · comments
The request
It would be beneficial to avoid updating an application if it’s currently running to prevent unexpected closures. For instance, if a user is in a Zoom meeting and the update initiates, the meeting could be unexpectedly closed. One workaround for this would be to check if the application process is running, and if it is, skip the update for that specific program. Process names could be manually populated in a separate ".txt" file, or the "included_apps.txt" file could be utilized in conjunction with the applications’ IDs.
Is your feature request related to a problem?
I tested several apps listed in the ‘included_apps.txt’ file using Intune deployment. All the apps, except for 7-Zip, were closed during the update process, which was not ideal.Additional information
No response
Idea
Process names could be manually populated in a separate ".txt" file, or the "included_apps.txt" file could be utilized in conjunction with the applications’ IDs.
An interesting idea, but full implementation is economically unfeasible within WAU.
Let me explain why (I will elaborate further, perhaps someone will come back with this idea one day when the winget reaches the maturity that allows it).
Problem with consistency of data relations
WAU is a "wrapper" on top of the winget.
Winget itself is a wrapper on top of random setups using various technologies.
Sometimes those setups are wrappers themselves (F.ex. Oracle JRE pre-8u402).
The solution would require a connection of a consistent and unambiguous package ID relationship with the metadata of the final setup.
Missing connection in schema
Let stake a look at the Zoom.Zoom case. The manifest file of the manifest of the latest version is there:
https://github.com/microsoft/winget-pkgs/blob/master/manifests/z/Zoom/Zoom/5.17.7.31859/Zoom.Zoom.installer.yaml
There is no information which could allow anyone to link package ID of any given package (operation level of WAU) with INSTALLDIRs (operation level of setups which kill processes).
INSTALLDIRs are not be defined in manifests, but are internal and individual logic of each setup. Each vendor has own idea how to manage those. Often defined using various parameters even stored under different names in the registry.
As of now there is no place for such data in the official YAML schema.
If metadata with information about where processes are to be killed is not provided by the manufacturer, it will be reactive tilting at windmills, at best.
implementation (system solution)
WAU could be expanded to look for such list, in WYSIWYG form, most likely an empty file + readme instruction how to fill it by You.
User may be greeted with a popup asking him/her to allow installation, that would be an another WYSIWYG generic "one-size fits all" solution. Customization of UX most likely would not be permitted. In the end most likely You would be forced to write your own popup routine anyway.
example
In a company I work for, each new application package has that metadata field populated manually. and each installation is preceded by a "selective process killer" task which does exactly that, terminates processes in defined paths.
If process is evaluated as business critical, then users are given a choice to postpone the install/uninstall a couple of times before action is finally enforced and the process(-es) is/are killed.
That is a completely custom solution written in PowerShell and triggered via task scheduler just like the Toast notification.
You may find a better one, more suitable to your needs.
implementation (user-side actions)
If such TXT file would be maintained outside of automated process on GitHub, then consistency would have to guaranteed by You.
extra workload/maintenance/support of such feature
For individual consideration:
Who would maintain something like this if not the sellers/manufacturers themselves?
If WAU kills/doesn't kill/kills the wrong processes, who will be at fault?
- WAU maintainers?
- A manufacturer who changed his path because he could?
- IT support in the company where the incident occurred?
hopefully a wrong prediction
if everything is automated, what's the point of keeping us as software delivery specialists?
In addition, you can still use MODs to customize a bit more your WAU implementation.
By experience, a lot of apps are always running (or even start with Windows). If you implement this, it will be similar to put these apps in the blacklist.
From my point of view, I hope one day to have the program to "close if running" inside the Winget manifests. This way, it would be easier for us to propose a manageable solution to force the kill or prompt user to close the app for instance.
This issue is stale because it has been open for 30 days with no activity.
This issue was closed because it has been inactive for 14 days since being marked as stale.