WP8.1 - Creating/Deploying Appx Packages Using Command-Line

Search This thread

snickler

Retired Forum Mod / Inactive Recognized Developer
Aug 17, 2010
1,320
1,133
Dub V
www.sinclairinat0r.com
To those who are used to grabbing their packaged .XAP file from the Debug/Release directory, things have change with Windows Phone 8.1 (non-silverlight) apps. Instead, we are presented with two ways to create appx packages:

  1. Navigating to Project->Store->Create Store Package within Visual Studio 2013 (if you're looking for a store-ready appx, then this is your option to take)
  2. Using the Command Line tools

This thread will focus on how to use the command line tools rather than use the Visual Studio.

First thing's first, we have two core applications that we're going to use in order to handle package management and deployment:

  • makeappx.exe - C:\Program Files (x86)\Windows Kits\8.1\bin\x86
  • AppDeployCmd.exe - C:\Program Files (x86)\Microsoft SDKs\Windows Phone\v8.1\Tools\AppDeploy

makeappx.exe:

This does as the filename suggests, make appx files.

The easiest way to build an appx file out of the contents of your Debug/Release directory is to run the following command:

makeappx pack /v /d c:\pathtodirectory /p c:\pathtoappx.appx /l

the /v argument enables verbose output, the /d argument is your directory, the /p argument is your output package and the /l argument disables validation checks on manifest data and resource files.

If you are indeed building the appx manually from your Debug/Resource directory, please make sure to include any .dlls and .winmds that you may be referencing in separate projects that aren't in the main output directory.



AppDeployCmd.exe:

This is the command line version of the Windows Phone 8.1 Application Deployment program.

The easiest way to deploy an appx to your phone is to run the following command:

AppDeployCmd /install c:\pathtoappx.appx /targetdevice:de /leaveoptimized

The /install argument provides the path to the appx file you wish to deploy, the /targetdevice argument is the device that you wish to deploy to and the /leaveoptimized argument is an optional parameter to leave the optimized version of the appx package on the filesystem instead of deleting it.


Analyzing the contents of an appx package:

The Appx file is different from a Xap file in that it is ZIP64 compressed instead of using the common ZIP compression. As of now, it isn't possible to deploy a ZIP compressed appx or modify a ZIP64 compressed appx file.

Taking a look a generated appx package, you'll see contents similar to the following:

  • Assets - Assets directory
  • App.exe - Main exe
  • resources.pri - compiled resources
  • App.xbf - Binary XAML file for the App namespace (similar to App.xaml for Silverlight)
  • MainPage.xbf - Binary XAML file fro the Main Page (similar to MainPage.xaml for Silverlight)
  • [Content_Types].xml - XML file containing the content type of every file in the package
  • App.xr.xml - XML file containing the root XAML types of the app
  • AppxBlockMap.xml - XML file containing a crypto hash for each block of data stored in the package
  • AppxManifest.xml - XML file containing the main manifest (similar to WMAppManifest.xml in Silverlight)

When you deploy the appx to your device while using the /leaveoptimized flag, you'll notice a new appx file in the format of nameofappx_Optimized.appx.

This specific appx package is generated every time you sideload an app to your phone and is the version that your phone receives. The deployer runs MDILXapCompile on every file in the package to precompile any managed assemblies into native code.

If you open up the optimized appx file, you'll notice that we have two new files:

  • MDILXapCompileLog.txt - The output log of MDILXapCompile
  • MDILFileList.xml - XML file that contains the assemblies that were successfully converted to native code.


Things to be wary of with Windows Phone 8.1 appx packages and the Store:

I've posted this on twitter earlier this week, but for pure Windows Phone 8.1 applications, it is possible to retrieve their contents from the Store by using the Download and install manually link. The appx files on the Store ARE NOT ENCRYPTED. From my understanding, it has to do with keeping compatibility between Windows 8.1 and Windows Phone 8.1. I'm curious to know when they decide to encrypt the files.

What's this have to do with the topic at hand? Everything. It is also possible to repackage an appx file from the Store.

Before I get into the how-to and the caveats, I'll explain how I even discovered the appx files were unencrypted.

I happened to be researching a particular capability I've been seeing in some files in a ROM dump from one of the newer Lumias and happened to paste it in to Bing. I was shocked to see direct links to the appx packages and noticed some familiar file names in the description of the link (AppxManifest.xml and MDILFileList.xml were the two that caught my eye). The even bigger kicker was the fact that these appx files are indeed searchable, but only from Bing (and DuckDuckGo which happens to use Bing). I decided to make more specific search queries to see if this was legit or if I happened to be losing my mind. It turns out that I wasn't.

"site:windowsphone.com/en-us AppxManifest.xml" happens to be the holy grail and will return any indexed Windows Phone 8.1 apps. The scary part is that you can still download apps that aren't published anymore and side load them. Here's an example Windows Phone 8.1 app that I happened to download (and also happens to be a Microsoft app).

http://www.windowsphone.com/en-us/s...view/299b09ab-207e-441c-9e8e-c8d66c20b76b/xap.

The link is self-explanatory. It's the Microsoft Remote Desktop Preview app. Now for the fun part.

Repackaging an app for development and testing purpose:

Before I begin this, I'm going to put a disclaimer out there, that this is just information to be used for dev purposes and as a way of trying to understand more of the packing process. I am by no means condoning any piracy so do NOT ask any questions or make any statements that involve searching for apps that you can't find, etc. I'm hoping Microsoft fixes this hole soon.


In the contents of the downloaded appx file, you'll notice we have even more files:

  • AppxSignature.p7x - Signature for app.
  • AppxMetadata - folder containing the CodeIntegrity security catalog file

To repackage and deploy an app to your device, the following must be done:

  • Extract the contents of the appx into a blank folder
  • Remove MDILFileList.xml, AppxSignature.p7x, and the AppManifest folder
  • Run the makeappx command above to repackage
  • Run the AppDeployCmd command above to deploy the app to your device


Common issues with redeployment:

  • If it's an update to a System app (Calendar, Podcast), you won't be able to install it because it can't uninstall the app from your phone
  • If it is a Microsoft or OEM app, you're most likely going to be unable to deploy it due to restricted capabilities. Some appx packages will include a WindowsPhoneReservedAppInfo.xml file that will contain the extra capabilities. You're free to remove them, but don't count on it actually working :)
  • If the appx package contains an external DLL reference that isn't from your project (Live SDK dll for instance), you will receive an error deploying with a message stating that the assembly can't be optimized because it is an invalid assembly.

    I've tried two workarounds in order to actually allow the deployment:
    • Remove the strong name key
    • and replace the dll with a version downloaded from the repository.

    I tried this on an app, but the app will still crash when it tries to call functions that use the external dll

"Oh crap! I'm worried about people stealing my code, what do I do?
  • Use Silverlight if you're doing a Windows Phone 8.1 app. Those are still encrypted from the store (Until someone installs the app with an interop-unlocked phone)
  • Use WinRT C++ instead of C#. Yeah, that's the most difficult and crappy way to go, but it will make it a little harder (not impossible) for someone to jack your code


Again, I'm hoping that MS addresses this, but for now it is a nice way to analyze changes done in apps like the Calendar and Files app.

Happy testing folks
 
Last edited:

Sunius1

Senior Member
Aug 9, 2013
71
36
Whoa, I did not expect that security hole to be in place. Hopefully Microsoft sees it, though it might be hard to fix it as the phones probably depend on it being that way.

The deployer runs MDILXapCompile on every file in the package to precompile any managed assemblies into native code.

Actually, it compiles it down to MDIL, machine dependent intermediate language. It's specific to ARM and doesn't exist on x86 (on emulator, for example). That is done because the JIT process on the phone would take a long time for bigger applications. Furthermore, it's totally optional, application will work just fine without compiling to MDIL, just startup will be somewhat slower. Check this:

http://channel9.msdn.com/Shows/Goin...Sollich-Inside-Compiler-in-the-Cloud-and-MDIL

If you open up the optimized appx file, you'll notice that we have two new files:

As of now, it isn't possible to deploy a ZIP compressed appx or modify a ZIP64 compressed appx file.

Makeappx can extract the appx packages just as well as it can compress them, so modification procedure would go like:

Code:
makeappx unpack /o /v <appxPackage> /d <outputDir>
// do whatever modifications you want 
makeappx pack /o /v <appxFolder> /p <appxName>

Actually, that's is exactly how AppDeployCmd is able to run MDIL compiler on the managed assemblies: it extracts the package using makeappx, then runs

Code:
mdilxapcompile /In:"<appxFolder>" /Out:"<SomeOtherFolder>" /Config:"MDILXapCompileInput.xml"

And finally makes a new appx package from "SomeOtherFolder". It would probably be pretty trivial to write an utility to run mdilxapcompile and makeappx manually, so appx could be made directly from a folder without zipping and unzipping twice.

There's one more way of protecting your code: use .NET native. Bonus: you get improved performance :).
 
Last edited:

snickler

Retired Forum Mod / Inactive Recognized Developer
Aug 17, 2010
1,320
1,133
Dub V
www.sinclairinat0r.com
There's one more way of protecting your code: use .NET native. Bonus: you get improved performance :).

Only works for pure Windows Store apps unfortunately :/. You don't even get the option in Windows Phone 8.1 projects.

EDIT: I just figured out how to manually make .NET Native work with WP 8.1 projects!

Will post a guide in a bit
 
Last edited:

WithinRafael

Senior Member
Mar 17, 2010
147
48
Bellevue, WA
www.withinwindows.com
BnAi5M9CEAA2T0a.png:large
 

AshleyT

Senior Member
Oct 26, 2011
157
67
Salerno
Can you help me with this?
I'm trying to repack an appx of an app that has been removed from the store. I've extracted the application folder from "/WindowsApps" on my phone.

I'm using this command:
makeappx pack /v /d AppFolder /p backup.appx /l

When I try to repack the application I get these errors:

Code:
MakeAppx : error: Manifest validation error: Line 24, Column 62, Reason: The file name "AGHost.exe" declared for element "m:Applications/m:Application" doesn't exist in the package.
MakeAppx : error: Failure at (ValidateFilesInManifest( manifestReaderInternal.Get(), rootNode.Get(), payloadFiles->GetFiles(), RequiredFileXPaths, (sizeof(*RtlpNumberOf(RequiredFileXPaths))), MAKEAPPX_I_VALIDATE_FILE_NOT_FOUND)) - 0x80080204 - The specified package format is not valid: The package manifest is not valid.
MakeAppx : error: Failure at (PackageValidator::Validate(manifestReader.Get(), localized, fileList)) - 0x80080204 - The specified package format is not valid: The package manifest is not valid.

There are no AppxSignature.p7x or AppxMetadata.xml in the folder so I cannot remove them, but there are:

MDILFileListAppx.xml
MDILFileListXap.xml
MDILProjectFiles.xml
WMAppManifest.xml
AppxManifest.xml
WMAppPRHeader.xml

Could it be a Silverlight 8.1 application?

EDIT: Nevermind, it was an XAP.
 
Last edited:

HTC_FUZE

Senior Member
May 13, 2009
365
6
OnePlus 5
ASUS ZenFone 6 (2019)
Hello,

Do I need to sign the package? I tried this method to re-pack the UWP app(I am testing on W10PC, so I downloaded x86 UWP, not ARM app), makeappx creates the appx successfully, When I double-click to run the appx, I got installation faiure, it says "Ask the app developer for a new app package. This one isn’t signed with a trusted certificate (0x800B0100)."
 

hooddy

Senior Member
Jan 16, 2008
308
55
Guys when i packing appx with makeapp and sign it I can not deploy it on my W10M phone with 0x800413a0 error. It don't hit W10M appx. It's occured only with WP8.1 appx. How to avoid it?
 

Attachments

  • photo_2021-04-30_11-14-39.jpg
    photo_2021-04-30_11-14-39.jpg
    56.7 KB · Views: 18

Top Liked Posts

  • There are no posts matching your filters.
  • 11
    To those who are used to grabbing their packaged .XAP file from the Debug/Release directory, things have change with Windows Phone 8.1 (non-silverlight) apps. Instead, we are presented with two ways to create appx packages:

    1. Navigating to Project->Store->Create Store Package within Visual Studio 2013 (if you're looking for a store-ready appx, then this is your option to take)
    2. Using the Command Line tools

    This thread will focus on how to use the command line tools rather than use the Visual Studio.

    First thing's first, we have two core applications that we're going to use in order to handle package management and deployment:

    • makeappx.exe - C:\Program Files (x86)\Windows Kits\8.1\bin\x86
    • AppDeployCmd.exe - C:\Program Files (x86)\Microsoft SDKs\Windows Phone\v8.1\Tools\AppDeploy

    makeappx.exe:

    This does as the filename suggests, make appx files.

    The easiest way to build an appx file out of the contents of your Debug/Release directory is to run the following command:

    makeappx pack /v /d c:\pathtodirectory /p c:\pathtoappx.appx /l

    the /v argument enables verbose output, the /d argument is your directory, the /p argument is your output package and the /l argument disables validation checks on manifest data and resource files.

    If you are indeed building the appx manually from your Debug/Resource directory, please make sure to include any .dlls and .winmds that you may be referencing in separate projects that aren't in the main output directory.



    AppDeployCmd.exe:

    This is the command line version of the Windows Phone 8.1 Application Deployment program.

    The easiest way to deploy an appx to your phone is to run the following command:

    AppDeployCmd /install c:\pathtoappx.appx /targetdevice:de /leaveoptimized

    The /install argument provides the path to the appx file you wish to deploy, the /targetdevice argument is the device that you wish to deploy to and the /leaveoptimized argument is an optional parameter to leave the optimized version of the appx package on the filesystem instead of deleting it.


    Analyzing the contents of an appx package:

    The Appx file is different from a Xap file in that it is ZIP64 compressed instead of using the common ZIP compression. As of now, it isn't possible to deploy a ZIP compressed appx or modify a ZIP64 compressed appx file.

    Taking a look a generated appx package, you'll see contents similar to the following:

    • Assets - Assets directory
    • App.exe - Main exe
    • resources.pri - compiled resources
    • App.xbf - Binary XAML file for the App namespace (similar to App.xaml for Silverlight)
    • MainPage.xbf - Binary XAML file fro the Main Page (similar to MainPage.xaml for Silverlight)
    • [Content_Types].xml - XML file containing the content type of every file in the package
    • App.xr.xml - XML file containing the root XAML types of the app
    • AppxBlockMap.xml - XML file containing a crypto hash for each block of data stored in the package
    • AppxManifest.xml - XML file containing the main manifest (similar to WMAppManifest.xml in Silverlight)

    When you deploy the appx to your device while using the /leaveoptimized flag, you'll notice a new appx file in the format of nameofappx_Optimized.appx.

    This specific appx package is generated every time you sideload an app to your phone and is the version that your phone receives. The deployer runs MDILXapCompile on every file in the package to precompile any managed assemblies into native code.

    If you open up the optimized appx file, you'll notice that we have two new files:

    • MDILXapCompileLog.txt - The output log of MDILXapCompile
    • MDILFileList.xml - XML file that contains the assemblies that were successfully converted to native code.


    Things to be wary of with Windows Phone 8.1 appx packages and the Store:

    I've posted this on twitter earlier this week, but for pure Windows Phone 8.1 applications, it is possible to retrieve their contents from the Store by using the Download and install manually link. The appx files on the Store ARE NOT ENCRYPTED. From my understanding, it has to do with keeping compatibility between Windows 8.1 and Windows Phone 8.1. I'm curious to know when they decide to encrypt the files.

    What's this have to do with the topic at hand? Everything. It is also possible to repackage an appx file from the Store.

    Before I get into the how-to and the caveats, I'll explain how I even discovered the appx files were unencrypted.

    I happened to be researching a particular capability I've been seeing in some files in a ROM dump from one of the newer Lumias and happened to paste it in to Bing. I was shocked to see direct links to the appx packages and noticed some familiar file names in the description of the link (AppxManifest.xml and MDILFileList.xml were the two that caught my eye). The even bigger kicker was the fact that these appx files are indeed searchable, but only from Bing (and DuckDuckGo which happens to use Bing). I decided to make more specific search queries to see if this was legit or if I happened to be losing my mind. It turns out that I wasn't.

    "site:windowsphone.com/en-us AppxManifest.xml" happens to be the holy grail and will return any indexed Windows Phone 8.1 apps. The scary part is that you can still download apps that aren't published anymore and side load them. Here's an example Windows Phone 8.1 app that I happened to download (and also happens to be a Microsoft app).

    http://www.windowsphone.com/en-us/s...view/299b09ab-207e-441c-9e8e-c8d66c20b76b/xap.

    The link is self-explanatory. It's the Microsoft Remote Desktop Preview app. Now for the fun part.

    Repackaging an app for development and testing purpose:

    Before I begin this, I'm going to put a disclaimer out there, that this is just information to be used for dev purposes and as a way of trying to understand more of the packing process. I am by no means condoning any piracy so do NOT ask any questions or make any statements that involve searching for apps that you can't find, etc. I'm hoping Microsoft fixes this hole soon.


    In the contents of the downloaded appx file, you'll notice we have even more files:

    • AppxSignature.p7x - Signature for app.
    • AppxMetadata - folder containing the CodeIntegrity security catalog file

    To repackage and deploy an app to your device, the following must be done:

    • Extract the contents of the appx into a blank folder
    • Remove MDILFileList.xml, AppxSignature.p7x, and the AppManifest folder
    • Run the makeappx command above to repackage
    • Run the AppDeployCmd command above to deploy the app to your device


    Common issues with redeployment:

    • If it's an update to a System app (Calendar, Podcast), you won't be able to install it because it can't uninstall the app from your phone
    • If it is a Microsoft or OEM app, you're most likely going to be unable to deploy it due to restricted capabilities. Some appx packages will include a WindowsPhoneReservedAppInfo.xml file that will contain the extra capabilities. You're free to remove them, but don't count on it actually working :)
    • If the appx package contains an external DLL reference that isn't from your project (Live SDK dll for instance), you will receive an error deploying with a message stating that the assembly can't be optimized because it is an invalid assembly.

      I've tried two workarounds in order to actually allow the deployment:
      • Remove the strong name key
      • and replace the dll with a version downloaded from the repository.

      I tried this on an app, but the app will still crash when it tries to call functions that use the external dll

    "Oh crap! I'm worried about people stealing my code, what do I do?
    • Use Silverlight if you're doing a Windows Phone 8.1 app. Those are still encrypted from the store (Until someone installs the app with an interop-unlocked phone)
    • Use WinRT C++ instead of C#. Yeah, that's the most difficult and crappy way to go, but it will make it a little harder (not impossible) for someone to jack your code


    Again, I'm hoping that MS addresses this, but for now it is a nice way to analyze changes done in apps like the Calendar and Files app.

    Happy testing folks
    5
    Whoa, I did not expect that security hole to be in place. Hopefully Microsoft sees it, though it might be hard to fix it as the phones probably depend on it being that way.

    The deployer runs MDILXapCompile on every file in the package to precompile any managed assemblies into native code.

    Actually, it compiles it down to MDIL, machine dependent intermediate language. It's specific to ARM and doesn't exist on x86 (on emulator, for example). That is done because the JIT process on the phone would take a long time for bigger applications. Furthermore, it's totally optional, application will work just fine without compiling to MDIL, just startup will be somewhat slower. Check this:

    http://channel9.msdn.com/Shows/Goin...Sollich-Inside-Compiler-in-the-Cloud-and-MDIL

    If you open up the optimized appx file, you'll notice that we have two new files:

    As of now, it isn't possible to deploy a ZIP compressed appx or modify a ZIP64 compressed appx file.

    Makeappx can extract the appx packages just as well as it can compress them, so modification procedure would go like:

    Code:
    makeappx unpack /o /v <appxPackage> /d <outputDir>
    // do whatever modifications you want 
    makeappx pack /o /v <appxFolder> /p <appxName>

    Actually, that's is exactly how AppDeployCmd is able to run MDIL compiler on the managed assemblies: it extracts the package using makeappx, then runs

    Code:
    mdilxapcompile /In:"<appxFolder>" /Out:"<SomeOtherFolder>" /Config:"MDILXapCompileInput.xml"

    And finally makes a new appx package from "SomeOtherFolder". It would probably be pretty trivial to write an utility to run mdilxapcompile and makeappx manually, so appx could be made directly from a folder without zipping and unzipping twice.

    There's one more way of protecting your code: use .NET native. Bonus: you get improved performance :).