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.
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.
