As it may not be intuitive, I am finding it necessary to explain the markings that exist within MSIX packages that relate to the OS version that the package is installed/run on.
Contained in the AppXManifest file inside of every MSIX package is an element that looks like this:
<Dependencies>
<TargetDeviceFamily Name="Windows.Desktop" MinVersion="10.0.16299.0" MaxVersionTested="10.0.19044.0" />
</Dependencies>
The two important fields to understand are the MinVersion and MaxVersionTested.
1) The MinVersion is pretty straightforward. It marks the minimum OS version that this package will be allowed to be installed on. The assumption here is that there is something important within the package that won’t work on older OS versions. Microsoft’s MSIX Packaging tool originally set this to the first version that supported MSIX at all (1609) but each time the tool is released they update it to the latest OS version under support by Microsoft. This is apparently done without looking at what is actually in the package, and might not be the best setting. It can always be changed.
MSIX is an evolving thing, and each new OS version currently brings us more and more features. Generally, the new features are exposed in other parts of the AppXManifest file and are silently ignored is the OS you install/run against doesn’t have the feature. So unless you really need the feature it may be OK to specify an older MinVersion.
2) The MaxVersionTested is less obvious. It really has nothing to do with testing, and is infuriating if you run afoul of it. The Microsoft MSIX Packaging Tool routinely sets this value to somewhere around the Latest OS version released by Microsoft, but sometimes it is the latest insider build at the time the tool was released.
This setting is used to limit package functionality to no more than what was supported by the designated OS version. But it only affects certain of those features, and which ones are affected are “under-documented”. Sometimes there is something, somewhere, on some documentation page about that feature that mentions a minimum OS version and typically that means that if the MaxVersionTested in the manifest is not set to at least that version you don’t get the feature, even if it is requested in your AppXManifest file.
To me this is, eh, “not well thought out”. For example, Microsoft recently added support for an improved declaration for certain kinds of Context Menu shell extensions which had not been working. The documentation page for this element is desktop9:FileExplorerClassicContextMenuHandler – Windows UWP applications | Microsoft Docs and fails to mention any OS restrictions. Yet buried in the text of that page is a link to this page Support legacy context menus – MSIX | Microsoft Docs which does. Fortunately, in this case they actually did document the need to set the MaxVersionTested field:
<Dependencies>
<TargetDeviceFamily Name="Windows.Desktop" MinVersion="10.0.17763.0" MaxVersionTested="10.0.21301.0" />
</Dependencies>
So if you include your context handler in the AppXManifest like this:
<desktop9:Extension Category="windows.fileExplorerClassicContextMenuHandler">
<desktop9:FileExplorerClassicContextMenuHandler>
<desktop9:ExtensionHandler Type="*" Clsid="<GUID-for-the-com-server>" />
</desktop9:FileExplorerClassicContextMenuHandler>
</desktop9:Extension>
And include the obligatory Com:SurrogateServer definition for that GUID, if you didn’t have the MaxVersionTested set to at least 10.0.21301.0, you don’t get that feature. Keep in mind that this currently means Windows 11. But what happens if Microsoft back-ports the feature to a new Windows 10? Especially if Windows 10 builds remain in the 10.0.19xxx range?
To my thinking, if I ask for the feature and the feature exists on the OS I install/run the package on it should not depend upon this MaxTestedVersion field!
So while it would be wrong for me to simply recommend to you that you always set the MaxTestedVersion to some large number, I still might not be wrong in doing it myself.
