Forum Discussion
Differentiating between appx and msix packages
From a packaging perspective you don't really need to differentiate. The runtime will pick up currently based on the manifest declarations. It won't affected deployment since they share a common deployment stack. Think of a .appx as a really restrictive MSIX file. MSIX will light up new feature sets and includes out of band items like the package support framework.
John.
What specifically would you like to determine if it was an .appx vs an MSIX package? From a functionality perspective all of .appx was inherited by MSIX. However, MSIX is not fully backward compatible to .appx.
As per the https://docs.microsoft.com/en-us/windows/msix/msix-1709-and-1803-support, MSIX is supported on Win 10 1709 and above. However APPX was supported on versions earlier than 1709 as well. Now there is no option to the manual tool (makeappx.exe) that guides it to generate MSIX or APPX.
How can I be indeed sure that I have generated a MSIX package and not an APPX package.
> Now there is no option to the manual tool (makeappx.exe) that guides it to generate MSIX or APPX.
In fact, there is. It's `MinVersion` attribute of `TargetDeviceFamily` element in AppxManifest.xml. If it's high enough, MSIX is generated, otherwise APPX.
mikekaganski In retrospect, I gave the wrong answer to the original question.
Rather than filename, one should look for the RunFullTrust capability in the AppXManifest file. This is the one thing that allows Win32 and .Net Framework code to be able to run inside the container. Yes, the MinVersion also needs to be at a given level, but even that level is now out of support, and AppX/UWP apps can use the latest minversion as well.
I think that given the design, the intent is that you would look directly at the MIN version and Max Test version associated with the package rather than directly looking at the question "is it appx or msix".
This might not meet all the situations (challenges like the new deployment possibilities to back rev OS come to mind), and I think checking the manifest for references to the msix schema would be the most reliable method for someone to determine. But in the end if it doesn't meet the min/max info above, the point might just be moot.
From a packaging perspective you don't really need to differentiate. The runtime will pick up currently based on the manifest declarations. It won't affected deployment since they share a common deployment stack. Think of a .appx as a really restrictive MSIX file. MSIX will light up new feature sets and includes out of band items like the package support framework.
John.
