Pre-Submission MSIX Testing Guide: Catch Packaging Issues Before Store Certification

2026-06-01

Tags: Windows · Microsoft Store · MSIX · Store Pitfalls

---

In Store Pitfalls #4, we ran into an issue where .NET trimming silently broke WinUI 3 functionality — everything worked fine in local Debug builds, but the Release package got rejected during Store certification. These problems share a common theme: if you validate your packaged output locally before submitting, you can catch many of these issues early. Of course, not everything can be caught in advance (for example, the ghost Start Menu entry caused by a dependency is hard to reproduce locally), but you can at least eliminate a large class of problems.

This article outlines a local validation workflow for MSIX packages before Store submission, covering WACK certification, self-signed certificate installation, dependency installation, and clean VM testing.

Step 1: Run WACK (Windows App Certification Kit)

WACK is a local pre-certification tool provided by Microsoft. It runs a series of checks on your package, simulating some of the tests performed during Store certification.

Key points:

• Only works with Release builds, not Debug — this also forces you to test the Release configuration
• WACK has been marked as deprecated by Microsoft (no longer maintained), but it can still be used for optional local pre-submission checks; formal certification runs automatically after you submit to the Store
• Passing WACK does not guarantee passing Store certification, but it helps catch a large number of basic issues (API compliance, performance, security, etc.)

How to use it: In the Visual Studio "Package and Publish" wizard, at the "Select and Configure Package" step, check the option at the bottom that says "Build project to validate app with Windows App Certification Kit." After packaging completes, a "Launch Windows App Certification Kit" button will appear. Alternatively, search for Windows App Certification Kit in the Start menu to launch it manually.

Step 2: Build a Test Package with a Self-Signed Certificate

This step is a bit convoluted.

MSIX packages must be signed to be installed. During development, Visual Studio uses a temporary certificate, but the resulting MSIX package itself doesn't necessarily include a usable certificate. The actual workflow is:

First, package using Sideload mode

1. Right-click the project → Package and Publish
2. Select Sideload (do not select Microsoft Store)
3. Choose the signing certificate and complete packaging

Then, build a Test package using Store mode

4. Run Package and Publish again, this time select Microsoft Store (AppName provided by PublisherName)
5. The resulting Test package (in the _Test folder under the AppPackages directory) will now include the self-signed certificate

If you skip steps 1–3 and go straight to building a Store package, the resulting MSIX will have an empty certificate — a rather frustrating gotcha.

Step 3: Install the Certificate

Once you have the Test package with the certificate:

Install the certificate

1. Right-click the .msix file → Properties → Digital Signatures tab
2. Select the signature → Details → View Certificate
3. Install Certificate → select Local Machine → place it in the Trusted People store

Note: The certificate's Publisher (CN) must match the <Publisher> value in Package.appxmanifest, otherwise installation will fail.

Step 4: Install Dependencies and the MSIX Package

If your Windows App SDK project is in framework-dependent mode (which is the default), the app requires the Windows App Runtime at runtime. Store distribution handles dependencies automatically, but for local testing you need to install them manually.

The good news is that the _Test folder in the Test package includes a Dependencies subdirectory with dependency packages organized by architecture:

AppPackages/
  MyApp_1.0.0.0_x64_Test/
    Dependencies/
      x64/
        Microsoft.WindowsAppRuntime.1.8.msix
        ...
    MyApp_1.0.0.0_x64.msix

Installation order: install the runtime dependencies first, then install the app itself.

If you're using self-contained mode (by setting <WindowsAppSDKSelfContained>true</WindowsAppSDKSelfContained> in .csproj), no additional dependencies are needed — the runtime is already bundled with the app.

Step 5: Full Validation on a Clean VM

Your development machine has all sorts of SDKs, runtimes, and caches installed — the fact that your app runs there doesn't mean it will run for your users. It's highly recommended to go through the full workflow in a clean environment.

VM options

Either of these works:

• Hyper-V Quick Create: Microsoft's recommended approach. Search for "Hyper-V Quick Create" in the Start menu and select the MSIX Packaging Tool Environment to create a VM
• VMware: What I personally use. Create a clean Windows 10/11 VM, take a snapshot, and restore to a clean state before each test cycle

Regardless of which option you choose, the core requirement is the same: get as close as possible to the user's first-install environment.

What to validate on a clean VM

1. Install the self-signed certificate (following the Step 3 procedure)
2. Install the dependency packages (Step 4)
3. Install the app itself
4. Launch the app and verify core functionality works correctly
5. Check that Start Menu entries, taskbar tray, and uninstall all behave correctly

Checklist

Before submitting to the Store, go through this checklist:

• [ ] Build a Test package using Release configuration
• [ ] Run WACK and confirm no critical errors
• [ ] Verify the Test package includes a self-signed certificate (build a Sideload package first)
• [ ] Install the certificate to Local Machine → Trusted People
• [ ] Perform full validation on a clean VM: install certificate → install dependencies → install app → test functionality
• [ ] In framework-dependent mode, confirm dependency packages install correctly
• [ ] App launches normally, core features are functional, Start Menu / uninstall behave as expected

---

This article is supplementary reading for the Store Pitfalls series.