Copyright (c) 2019 Microsoft Corp. All rights reserved.
The MSIX SDK project is an effort to enable developers on a variety of platforms to pack and unpack packages for the purposes of distribution from either the Microsoft Store, or their own content distribution networks.
The MSIX Packaging APIs that a client app would use to interact with .msix/.appx packages are a subset of those documented here.
The MSIX SDK project includes cross platform API support for packing and unpacking of .msix/.appx packages
| msix | A shared library (DLL on Win32, dylib on macOS, SO on Linux and Android) that exports a subset of the functionality contained within appxpackaging.dll on Windows. See here for additional details. On all platforms instead of CoCreating IAppxFactory, a C-style export: CoCreateAppxFactory is provided. Similarly, the CoCreateAppxBundleFactory export is equivalent as CoCreating IAppxBundleFactory. The 'UnpackPackage' and 'UnpackBundle' exports that provide a simplified unpackage implementation. Similarly, PackPackage provides a simplified package implementation. See the samples directory for usage of the SDK. |
| makemsix | A command line wrapper over the MSIX library entrypoints. makemsix supports pack and unpack. Use the -? to get information about the options supported. |
| MSIX Core | A client app that uses installs .msix/.appx packages on Windows 7 SP1 and later versions of Windows. Go to the MSIX Core project page, to get more details. |
Guidance on how to package your app contents and construct your app manifest such that it can take advantage of the cross platform support of this SDK is here.
Release notes on the latest features and performance improvements made to the SDK are listed here
- Clone the repository:
git clone [URL]
If you are using Visual Studio 2017 and you run into errors about not being able to find the v140 toolset:
- Install the Microsoft Build Tools (https://chocolatey.org/packages/microsoft-build-tools)
- Start -> visual studio installer -> Visual Studio Build Tools 2017 -> Modify the 2014 toolset -> individual components
- Make sure that VC++ 2015.3 v140 toolset for desktop is selected and then unselect VC++ 2017 141 toolset
- Close, then re-open the solution.
Depending on the platform for which the MSIX shared library (MSIX.DLL | libmsix.dylib | libmsix.so) is compiled, one or more of the following dependencies may be statically linked into the binary:
- ZLib Tag v1.2.12 Commit 21767c654d31d2dccdde4330529775c6c5fd5389
- Xerces-C Tag v3.2.1 Commit 9ac2984508eff312585b86b2a89850a439b5650b
- OpenSSL Tag OpenSSL_1_1_1t Commit 830bf8e1e4749ad65c51b6a1d0d769ae689404ba
- Android NDK
For convinience, Zlib, Xerces-C and OpenSSL are git-subtrees that are mapped in under the lib folder of this project. Edits on top of these subtrees for build related optimizations are tracked within this repository.
The Android NDK is only required for targeting the Android platform.
The project uses git-lfs to store some large binary test files. You can find out more and install it from here:
https://git-lfs.github.com/
Make sure that you have CMAKE installed on your machine
One or more of the following prerequisites may also be required on your machine:
https://github.com/ninja-build/ninja/releases
https://developer.android.com/ndk/downloads/index.html
http://releases.llvm.org/download.html
Open Visual Studio 2017 File->Open Folder->navigate to project root and select "CMakeLists.txt"
See cmake-support-vs for details regarding how to configure your environment.
open terminal, from project root: mkdir build && cd build && cmake -DMACOS=on -G"Xcode" .. open xcode File->Open->navigate to project root/build and select "Project.xcodeproj"
See cmake-Xcode-integration for additional details
makewin.cmd <x86|x64> [options]
This will start MSVC environment calling vcvarsall.bat , clean the output directory, call cmake and nmake. The latest Visual Studio version is obtained by calling vswhere.exe
./makemac [options]
./makeios [options]
./makelinux [options]
./makeaosp [options]
- Unpack the latest Android NDK to c:\android-ndk
- Unpack Ninja-build to c:\ninja
- Add c:\ninja to the path environment variable
- Create a folder under the root of the enlistment called "android", cd into that folder, then run the following command to create ninja build files:
cmake -DCMAKE_ANDROID_NDK=c:/android-ndk ^
-DCMAKE_ANDROID_NDK_TOOLCHAIN_VERSION=clang ^
-DCMAKE_SYSTEM_NAME=Android ^
-DCMAKE_SYSTEM_VERSION=19 ^
-DCMAKE_ANDROID_ARCH_ABI=x86 ^
-DCMAKE_ANDROID_STL_TYPE=c++_shared ^
-DCMAKE_BUILD_TYPE=Release ^
-DAOSP=on ^
-G"Ninja" ..
To compile, run the following command from the android folder:
ninja
By default, pack is NOT turned on in the build scripts and is not supported for mobile devices. Use the --pack option in the build scripts or pass -DMSIX_PACK=on to the CMake command to enable it. You will have to set also -DUSE_VALIDATION_PARSE=on in the build script, otherwise the build operation will fail.
The following native platforms are in development now:
| master | |
|---|---|
| Debug x32 | |
| Debug x64 | |
| Release x32 | |
| Release x64 | |
| Release x32 Without Bundle support | |
| Release x64 Without Bundle support | |
| Release x32 With Validation Parser | |
| Release x64 With Validation Parser | |
| Debug x32 With Pack | |
| Debug x64 With Pack | |
| Release x32 With Pack | |
| Release x64 With Pack | |
| Release x32 Xerces With Pack | |
| Release x64 Xerces With Pack |
Built in the Azure Pipelines windows-latest pool. See specifications here
| master | |
|---|---|
| Debug | |
| Release | |
| Release Without Bundle support | |
| Debug With Pack | |
| Release With Pack | |
| Debug arm64 | |
| Release arm64 | |
| Release Without Bundle support arm64 | |
| Debug With Pack arm64 | |
| Release With Pack arm64 | |
| Release Universal | |
| Release Without Bundle support Universal | |
| Release With Pack Universal |
Built in the Azure Pipelines macOS pool. See specification here
| master | |
|---|---|
| Debug Emulator | |
| Release Emulator | |
| Release Emulator Without Bundle support | |
| Release arm64 |
Built in the Azure Pipelines macOS pool. See specification here
| master | |
|---|---|
| Debug Emulator | |
| Release Emulator | |
| Release Emulator Without Bundle support | |
| Release arm | |
| Release arm Without Bundle support |
Built in the Azure Pipelines macOS pool. See specification here
| master | |
|---|---|
| Debug | |
| Release | |
| Release Without Bundle Support | |
| Release With Validation Parser | |
| Debug With Pack | |
| Release With Pack |
Built in the Azure Pipelines Hosted Ubuntu 1604. See specification here
The MSIX SDK is fully supported and tested on Windows 7. However, an Application Manifest MUST be included to any executable that is expected to run on Windows 7 and uses msix.dll. Specifically, the Application Manifest MUST include the supportedOS flags for Windows 7. The manifest is not included on msix.dll because the compat manifest doesn't matter on DLLs. See the manifest that is used for makemsix and samples of this project as example. The Windows 7 machine might also require the Microsoft Visual C++ Redistributable binaries installed to run properly. Alternatively, build msix.dll with makewin.cmd <x86|x64> -mt [options] to use static version of the runtime library and don't require the redistributables.
The MSIX SDK minimum supported for Android is API Level 19.
We also produce msix-jni.jar which acts as a helper to get the languages from the Android device. Because of it, we expect either a -DANDROID_SDK and -DANDROID_SDK_VERSION on the cmake command and, if not present, we default to $ANDROID_HOME and 24 respectively. The default level for the SDK level is 24 because we use the Configuration class and, depending on the version of the device, we either use the locale attribute (deprecated as of API level 24) or getLocales. We recommend using the makeaosp script to build for Android on non-Windows devices.
To enable building the MSIX SDK to run on Apple Silicon do the following:
- Install Xcode beta 12 (https://developer.apple.com/download/)
- Change active developer directory
sudo xcode-select -switch /Applications/Xcode-beta.app/Contents/Developer - Build using makemac.sh
./makemac.sh -arch arm64 --skip-tests
msixtest uses Catch2 as testing framework. msixtest is either an executable or a shared library, depending on the platform. It has a single entrypoint msixtest_main that takes argc and argv, as main, plus the path were the test packages are located. The shared library is used for our mobile test apps, while non-mobile just forwards the arguments to msixtest_main. It requires msix.dll to be build with "Release" or "RelWithDebInfo" CMake switch.
First build the project, then:
Go to the build directory and run msixtes\msixtest.exe. You can run an specific test by running msixtest [test name]. By default, the test will only output the failling tests, use -s to output successfull tests.
First build the project for iOS, then launch xCode and load src/test/mobile/iOSBVT.xcworkspace, compile the test app, and then launch the iPhone simulator. You can also run "testios.sh -p iOSBVT/iOSBVT.xcodeproj" from src/test/mobile.
From within bash, navigate to src/test/mobile, and run "./testaosponmac.sh".
If you are the current maintainer of this project:
- Pull latest payload to release in master
- Confirm that all platforms/architectures/flavors build and all BVTs pass
- From a windows cmd prompt: release_master.cmd
- Confirm that new branch called "release_v1.xxx" where "xxx" is the next incremental version is created
This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.microsoft.com.
When you submit a pull request, a CLA-bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., label, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repositories using our CLA.
If you have any questions or comments, you can send them our team directly!
This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.
If you are a security researcher and believe you have found a security vulnerability that meets the definition of a security vulnerability that is not resolved by the 10 Immutable Laws of Security, please send e-mail to us at secure@microsoft.com. To help us to better understand the nature and scope of the possible issue, please include as much of the below information as possible.
- Type of issue (buffer overflow, SQL injection, cross-site scripting, etc.)
- Product and version that contains the bug, or URL if for an online service
- Service packs, security updates, or other updates for the product you have installed
- Any special configuration required to reproduce the issue
- Step-by-step instructions to reproduce the issue on a fresh install
- Proof-of-concept or exploit code
- Impact of the issue, including how an attacker could exploit the issue
Microsoft follows Coordinated Vulnerability Disclosure (CVD) and, to protect the ecosystem, we request that those reporting to us do the same. To encrypt your message to our PGP key, please download it from the Microsoft Security Response Center PGP Key. You should receive a response within 24 hours. If for some reason you do not, please follow up with us to ensure we received your original message. For further information, please visit the Microsoft Security Response Policy and Practices page and read the Acknowledgment Policy for Microsoft Security Bulletins.
For additional details, see Report a Computer Security Vulnerability on Technet