Closed agronatur closed 3 months ago
I agree, using wildcards in the path would allow real "process-enablement". Currently even selecting a process creates a file rule limited to the exact and complete file path. And since more and more applications have it's version in the path (e.g. UltiMaker Cura, MSEdge, etc), it would allow to enable them without the need of modifying the rule after each update. Also it would cover UWP-Apps, that are not correctly placed in the group, like winget, which in theory should reside in the "DesktopAppInstaller"-UWP-Package but cannot be enabled by enabling this package. For this a simple
*\winget.exe
as file path could solve anything
Yeah, a much-needed future. As it stands now every time an app that has a stupid version string in the path needs its firewall rule updated...
This issue is a duplicate of #4, where the author has pitched in with the conversation. I see the first step you could take is to download, if possible, a version of the program where the installation path doesn't change. For example, if you download directly from Spotify and not use the Microsoft Store version, you could avoid the hassle of needing to adjust the firewall rules on each update.
The second step you could take is to direct your complaints to the authors of the programs that violate the path preservation contract. This may accelerate the process of them fixing this issue like JetBrains has done with their Toolbox App.
Duplicate of #4.
Some applications update on daily basis and like to change paths changing the folder name with their versions like: C:\Program Files (x86)\Microsoft\EdgeWebView\Application\120.0.2210.133\msedgewebview2.exe C:\Program Files\WindowsApps\SpotifyAB.SpotifyMusic_1.226.1187.0_x64__zpdnekdrzrea0\Spotify.exe
so if we could do something like this: C:\Program Files (x86)\Microsoft\EdgeWebView\Application*\msedgewebview2.exe C:\Program Files\WindowsApps\SpotifyAB.SpotifyMusic_*\Spotify.exe
The * would allow anything.