Hi,
Based on #7894 work:
Is your feature request related to a problem? Please describe.
App module class's product name and version descriptors are used to obtain name and version of the app associated with the app module class. However, there are cases when this does not work, particularly in regards to Windows Store apps (sometimes called "immersive apps"). For these, a container process is used, which causes file utils to say "invalid file version info".
The best known case is Windows 10 Calculator. Although the executable is unique (not wwahost.exe), product name and version cannot be fetched. Another example is Office 365 apps from Microsoft Store that not only presents a high-level version information (because these are converted desktop apps), but also comes with internal versions as seen through Store app package information (for example, 16.0 for desktop apps versus 16051 for Store apps).
Describe the solution you'd like
Detect and retrieve product name and version for immersive apps via package info functions from kernel32.dll (see #7894 for mechanics of this). If the app is not a hosted (immersive) app (such as on Windows 7 and many apps on Windows 8.x and 10), fall back to version info lookup.
Describe alternatives you've considered
None - leave it as is.
Additional context
Mostly useful for app module writers as they can easily detect versions for hosted apps in order to write workarounds. A proof of concept implementation is under active testing via Windows 10 App Essentials add-on.
Thanks.
Hi,
Based on #7894 work:
Is your feature request related to a problem? Please describe.
App module class's product name and version descriptors are used to obtain name and version of the app associated with the app module class. However, there are cases when this does not work, particularly in regards to Windows Store apps (sometimes called "immersive apps"). For these, a container process is used, which causes file utils to say "invalid file version info".
The best known case is Windows 10 Calculator. Although the executable is unique (not wwahost.exe), product name and version cannot be fetched. Another example is Office 365 apps from Microsoft Store that not only presents a high-level version information (because these are converted desktop apps), but also comes with internal versions as seen through Store app package information (for example, 16.0 for desktop apps versus 16051 for Store apps).
Describe the solution you'd like
Detect and retrieve product name and version for immersive apps via package info functions from kernel32.dll (see #7894 for mechanics of this). If the app is not a hosted (immersive) app (such as on Windows 7 and many apps on Windows 8.x and 10), fall back to version info lookup.
Describe alternatives you've considered
None - leave it as is.
Additional context
Mostly useful for app module writers as they can easily detect versions for hosted apps in order to write workarounds. A proof of concept implementation is under active testing via Windows 10 App Essentials add-on.
Thanks.