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