SOLVED

Differentiating between appx and msix packages

Copper Contributor

Is there a way to differentiate between the appx and msix packages, other than checking the extension of the package?

I was looking for some way to check if the package was actually created as a msix package, or was just renamed from .appx to .msix, but could not find anything in the content which could help me check this.

Please guide if I'm missing something.

6 Replies

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

best response confirmed by Andy Liu (Microsoft)
Solution

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.

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.

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.

1 best response

Accepted Solutions
best response confirmed by Andy Liu (Microsoft)
Solution

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.

View solution in original post