Remove All Ads from XDA

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

1,277 posts
Thanks Meter: 1,076
Post Reply Email Thread
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


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.


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.

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

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
The Following 10 Users Say Thank You to snickler For This Useful Post: [ View ]
7th July 2014, 07:11 AM |#2  
Thanks Meter: 37
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.

Originally Posted by snickler

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:

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

Originally Posted by snickler

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:

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

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 .
The Following 5 Users Say Thank You to Sunius1 For This Useful Post: [ View ] Gift Sunius1 Ad-Free
9th July 2014, 07:15 PM |#3  
snickler's Avatar
OP Forum Moderator / Recognized Developer
Flag Dub V
Thanks Meter: 1,076
Donate to Me
Originally Posted by Sunius1

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
9th July 2014, 10:05 PM |#4  
Senior Member
Bellevue, WA
Thanks Meter: 48
The Following 2 Users Say Thank You to WithinRafael For This Useful Post: [ View ] Gift WithinRafael Ad-Free
17th March 2015, 02:22 PM |#5  
Senior Member
Flag delhi
Thanks Meter: 49
I did everything upto extracting the files and removing the mentioned files but I can't understand where to write the commands. Plz help
22nd October 2015, 06:40 PM |#6  
AshleyT's Avatar
Senior Member
Flag Salerno
Thanks Meter: 60
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:

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:


Could it be a Silverlight 8.1 application?

EDIT: Nevermind, it was an XAP.
9th May 2017, 08:24 PM |#7  
Senior Member
Thanks Meter: 3

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)."
Post Reply Subscribe to Thread

appx, windows phone 8.1, wp8.1

Guest Quick Reply (no urls or BBcode)
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes