The reason is mundane: an EV code-signing certificate costs €170–300 per year, and that feels like a mandatory barrier. It isn't. There's an official path to publish without your own certificate — through the MSIX format, which the Microsoft Store signs with its own signature. I walked this path from scratch to certification in a week, and below is the full guide with every gotcha that cost me three extra days.

The guide is practical: it applies to .NET WPF, .NET WinUI 3, and Win32 apps. Electron and React Native support the MSIX route too, with their own quirks — covered briefly at the end.

Why the Microsoft Store, not just your own site + GitHub Releases

Before spending a week on packaging, understand the trade-off.

Your own site + GitHub Releases:

• Full control over the landing page, tracking, and updates.

• Needs an EV cert (€170–300/yr) or SmartScreen blocks downloads.

• Distribution = your own traffic.

Microsoft Store:

• Free (for individual developers).

• No need to sign the installer — the Store does it for you.

• Automatic updates through Windows Update.

• Distribution to 240 markets via a built-in Windows feature.

• Limited control: pricing, listing, and updates go through review.

For most indie devs it's worth having both channels in parallel. The Store is the channel for new users and trust; your site is the main one for your active base and marketing.

The barrier: why indie devs fear the certificate

A plain .exe installer without an EV cert triggers a SmartScreen warning: "Windows protected your PC. Microsoft Defender SmartScreen prevented an unrecognized app from starting." The user has to click "More info → Run anyway." That step loses 30–50% of conversions.

The options:

1. EV Code Signing Certificate — €200–300/yr. Bought through DigiCert, Sectigo, Certum. Issued only after identity verification (Ukraine is supported by Certum via a foreign passport).

2. Standard Code Signing Certificate — €170–200/yr, no EV reputation, needs trust accumulation. Certum (PL) works with Ukraine and issues via SimplySign (cloud HSM, no USB token).

3. Microsoft Store MSIX route — €0, but through Store review.

Each path is justified in its own context. For a first release, when you don't yet know whether the product will take off, option #3 is objectively the cheapest.

Step 1. Register a dev account through the new free flow

In 2025 Microsoft moved individual-developer registration to a new portal: storedeveloper.microsoft.com. The old partner.microsoft.com returns "Access restricted" for new indie accounts — that's not a bug, it's a deliberate redesign.

The process:

1. Go to storedeveloper.microsoft.com with your Microsoft account.

2. Choose Individual developer (not Company).

3. Fill in the Publisher Display Name. This is the public name shown in the Store.

4. Pay nothing — for indies the account is free in 2025–26 (it used to be a one-time $19).

Processing time: instant in most cases.

Gotcha #1: The Identity Name (CN=... in the manifest) is generated by Microsoft automatically and bound to the account. If you ever started a registration under "Your Name," it may be "reserved" by a stalled session and unavailable for the new one. In my case I had to use "CapyBro" as the Publisher Display Name instead of my own name.

Step 2. Build MSIX instead of NSIS

If you already have an NSIS installer (.exe), it won't work for the Store. You need the MSIX format — the Microsoft Store supports only that.

The tool: makeappx.exe, part of the Windows SDK. Its typical location on Windows 11:

C:\Program Files (x86)\Windows Kits\10\bin\10.0.26100.0\x64\makeappx.exe

The basic pipeline:

1. Publish the .NET project to a self-contained folder:

dotnet publish -c Release -r win-x64 --self-contained

1. Create AppxManifest.xml — it describes the app (name, version, capabilities, entry points).

2. Pack it:

makeappx pack /d <folder with all files> /p MyApp.msix

1. Verify on your local machine: double-click the .msix — Windows offers to install it.

Gotcha #2: makeappx breaks with no clear message if there's a double dash -- inside the XML comments of AppxManifest.xml. Don't write <!-- HACK -- this is a workaround -->, write <!-- HACK: this is a workaround -->.

Gotcha #3: The project's TargetFramework must include Windows SDK targeting — for example net8.0-windows10.0.17763.0. Without it, the WinRT APIs aren't available, and some Store-route features (like the native autostart below) won't build.

Step 3. Five gotchas that cost me three days

This is the part worth saving the guide for.

3.1. Autostart via the HKCU Run key no longer works

The classic Windows autostart path is to write a shortcut into HKCU\Software\Microsoft\Windows\CurrentVersion\Run. In an MSIX environment this is virtualized: the write lands in an isolated container and doesn't affect the real registry.

The fix is to use a StartupTask through the WinRT API:

<!-- AppxManifest.xml -->
<Extensions>
  <desktop:Extension Category="windows.startupTask" Executable="MyApp.exe" EntryPoint="Windows.FullTrustApplication">
    <desktop:StartupTask TaskId="MyAppStartup" Enabled="true" DisplayName="My App" />
  </desktop:Extension>
</Extensions>

In code, check the state via Windows.ApplicationModel.StartupTask.GetAsync("MyAppStartup"). The user can disable autostart in Settings → Apps → Startup, like any Store app.

3.2. Parameters for a silent launch

If your app shows a splash window or onboarding on first launch but should start silently in the tray on autostart, pass an argument via uap10:Parameters:

<desktop:StartupTask TaskId="MyAppStartup" Enabled="true" DisplayName="My App">
  <uap10:Parameters>--silent</uap10:Parameters>
</desktop:StartupTask>

In code just read Environment.GetCommandLineArgs() and pick the scenario.

3.3. Config files in the user profile are not virtualized

MSIX has a VFS (Virtual File System) concept — part of filesystem writes get isolated. That only applies to folders like C:\Program Files, C:\Windows. Files you write to %USERPROFILE% (e.g. ~/.myapp-config) are not touched by the VFS — they live in the real user profile and are accessible exactly as from the .exe version. This makes a shared config between the Store version and the .exe version of the same app possible.

3.4. PublisherDisplayName ≠ Publisher Identity

AppxManifest.xml has two different "publisher" fields:

<Identity Name="MyApp.MyApp" Publisher="CN=5763E11C-3BC8-..." Version="1.0.0.0" />
<Properties>
  <DisplayName>My App</DisplayName>
  <PublisherDisplayName>My Company</PublisherDisplayName>
  ...
</Properties>

• Publisher in <Identity> — the Subject DN of your dev certificate (issued by Microsoft automatically). This string must exactly match the one in Partner Center.

• PublisherDisplayName — the public name on the Store page. It's arbitrary and you set it yourself.

Don't mix them up — a mismatch on the first one gets your submission rejected with no explanation.

3.5. The "Incomplete" label on Submission options is not a blocker

When you first submit in Partner Center, the Submission options tab shows an Incomplete label demanding a justification for the runFullTrust capability. Don't panic — it doesn't block the submit. Microsoft approves runFullTrust during certification itself, based on the app and the test notes. In my case the label stayed red and the submission passed cleanly in 24 hours.

Step 4. Fill in the listing in Partner Center

This is the longest step. Set aside 2–3 hours.

What to prepare in advance:

1. App description in three or four languages. EN is mandatory, then your target markets. You'll have to type the text by hand from the keyboard: Partner Center has a bug that doesn't save synthetic (programmatic) input from automation.

2. 8 key features as short bullet points. It's a separate field in the listing.

3. Screenshots — at least 4, in 1920×1080 PNG. Include at least one of the main UI, one of settings, one of a real-world use.

4. Hero image 2400×1200 (optional but recommended — the Store shows it at the top of the page).

5. Teaser video (optional) — 30 seconds, MP4, up to 1 GB.

6. Privacy URL — a link to your privacy policy. Without it, review fails.

Property declarations:

• If you have In-App Purchases (via Gumroad/Paddle/your own backend), declare "In-App Purchases."

• If the app uses generative AI, declare it in the relevant item.

• Category: for most indie utilities — Productivity.

Age rating is generated through the IARC questionnaire — a separate form; answer honestly (for a text-rewriting tool you get PEGI 3 / Everyone).

Step 5. Certification: what they test and how to prepare

Certification takes 1–3 days. Humans test it, not bots — that matters for writing the test notes.

What to write in Notes for certification:

1. Which features to check (describe the main scenario in 5 lines).

2. If the app needs third-party credentials (API keys, logins), provide temporary ones in the test notes. For example, if your AI app works through OpenRouter, create a test key, add it to the notes — and don't forget to revoke it right after successful certification.

3. Describe special scenarios (autostart, system-hotkey integration, offline mode).

The certification type for the first submission is the regular one (no Mandatory Update flag). If your app uses runFullTrust (most WPF apps), justify it in two or three sentences in a separate field: why you need full access and which system APIs you use.

Gotcha #6 (bonus): If you need to provide dev-only credentials in the test notes, register them on your personal email outside your brand domain. The Microsoft tester will see the credentials and send reset emails on error — you don't want those landing on support@yourdomain.

After passing certification the listing moves to the In Microsoft Store status and becomes publicly available within 1–2 hours. Google and Bing indexing kick in automatically.

What the result looks like

In my case I walked this route for the open-source app CapyBro — its listing is live here: apps.microsoft.com/detail/9N73FHJTW3M7. The first submission passed certification in 24 hours, the second (an update to 2.0.1 plus a native ARM64 build) in 1 day.

The signature Microsoft puts on your MSIX is visible in the file properties: Issued by: Microsoft Code Signing PCA. SmartScreen doesn't block it, because the install comes through the trusted Store channel.

If you're not on .NET

The MSIX format isn't tied to .NET. It works with any Windows app.

• Electron — supports MSIX via electron-builder (target: 'msix'). Similar gotchas: HKCU autostart doesn't work, you need StartupTask.

• React Native Windows — generates MSIX out of the box via the CLI.

• Win32 C++ — packaged the same way via makeappx.exe, you need a hand-written AppxManifest.xml.

• PWA / Java / Python — each has runFullTrust quirks; check Microsoft's official docs for your specific stack.

Conclusion and checklist

The Microsoft Store via the MSIX route is the cheapest way to publish into the Windows ecosystem legitimately, with a signature and distribution to 240 markets. The €170–300/yr for an EV certificate can (for now) be deferred to the stage when the product has found its audience and your own web downloads have become a meaningful share of the metric.

Checklist before your first submission:

• [ ] Dev account on storedeveloper.microsoft.com, Publisher Display Name set.

• [ ] csproj targets net8.0-windows10.0.17763.0 (or higher).

• [ ] dotnet publish -c Release -r win-x64 --self-contained works.

• [ ] AppxManifest.xml is valid, no -- in XML comments.

• [ ] Autostart via StartupTask, not the HKCU Run key.

• [ ] Privacy URL ready on your site.

• [ ] 4+ screenshots 1920×1080, description in 2–3 languages typed by hand.

• [ ] Age rating obtained via IARC.

• [ ] Test notes written, temporary credentials created.

• [ ] makeappx pack produced the .msix, local install works.

Bonus step after publishing: add a Microsoft Store badge to your site and the project README.md. It's a trust signal for visitors and an extra backlink for indexing.

The free core of the app I built along this route is open-source (MIT): github.com/phantasmat2018/capy-bro.

If you have a question about a specific gotcha — drop a comment. This route is still poorly documented publicly, and I'm happy to clarify on concrete cases.

Roman Tykhonenko, .NET developer, Kyiv.

Sounds simple, but plain .NET / WPF can't do it out of the box. The two technical pillars of such a utility are a global hotkey (works even when your window is inactive) and pasting the result into another program (Word, a browser, an IDE — anywhere). Both come down to the Win32 API through P/Invoke.

Below is the full working path on .NET 8 + WPF with real code and the gotchas that only show up in production. I walked this path building CapyBro — a utility that rewrites selected text with AI on a hotkey; the examples are based on its real architecture.

Part 1. Global hotkeys via RegisterHotKey

Why not WPF KeyBinding

The first thing that comes to mind is InputBinding / KeyBinding in WPF. The problem: they only fire when your window has focus. A system utility lives in the tray with no active window, and the hotkey has to be caught while the user is working in Word or Chrome. So you need an OS-level hotkey, not an app-level one.

For that there's the Win32 API RegisterHotKey. It registers the combination globally: as soon as it's pressed anywhere, your process receives a WM_HOTKEY window message.

P/Invoke declarations

In .NET 8 it's better to use source-generated marshalling via [LibraryImport] instead of the old [DllImport] — less runtime overhead and fewer marshalling mistakes:

internal static partial class NativeMethods
{
    [LibraryImport("user32.dll", SetLastError = true)]
    [return: MarshalAs(UnmanagedType.Bool)]
    internal static partial bool RegisterHotKey(IntPtr hWnd, int id, uint fsModifiers, uint vk);

    [LibraryImport("user32.dll", SetLastError = true)]
    [return: MarshalAs(UnmanagedType.Bool)]
    internal static partial bool UnregisterHotKey(IntPtr hWnd, int id);

    internal const uint MOD_ALT      = 0x0001;
    internal const uint MOD_CONTROL  = 0x0002;
    internal const uint MOD_SHIFT    = 0x0004;
    internal const uint MOD_WIN      = 0x0008;
    internal const uint MOD_NOREPEAT = 0x4000;

    internal const int WM_HOTKEY = 0x0312;
}

vk is the virtual-key code of the key (for example 0x45 for E). fsModifiers is a bitmask of modifiers. Note MOD_NOREPEAT — more on that below; it's an important gotcha.

Where WM_HOTKEY arrives if there is no window

RegisterHotKey requires an HWND to send the message to. A tray app may have no main window at all. The solution is a message-only window: an invisible window that exists purely to receive messages. In WPF it's convenient to create one via HwndSource:

public sealed class HotkeyManager : IDisposable
{
    private readonly HwndSource _source;
    private int _nextId = 1;
    private readonly Dictionary<int, Action> _callbacks = new();

    public HotkeyManager()
    {
        var parameters = new HwndSourceParameters("CapyBroHotkeyWindow")
        {
            // HWND_MESSAGE = -3: the window becomes message-only,
            // never appears on screen or in Alt+Tab.
            ParentWindow = new IntPtr(-3),
        };
        _source = new HwndSource(parameters);
        _source.AddHook(WndProc);
    }

    private IntPtr WndProc(IntPtr hwnd, int msg, IntPtr wParam, IntPtr lParam,
        ref bool handled)
    {
        if (msg == NativeMethods.WM_HOTKEY)
        {
            int id = wParam.ToInt32();
            if (_callbacks.TryGetValue(id, out var action))
            {
                action();           // your hotkey handler
                handled = true;
            }
        }
        return IntPtr.Zero;
    }
}

Registration and conflict detection

RegisterHotKey returns false if the combination is already taken by another program. That's a free conflict-detection mechanism — always surface it to the user, because "nothing happens when I press it" is the worst possible UX:

public bool TryRegister(uint modifiers, uint vk, Action callback)
{
    int id = _nextId++;
    bool ok = NativeMethods.RegisterHotKey(
        _source.Handle, id, modifiers | NativeMethods.MOD_NOREPEAT, vk);

    if (!ok)
    {
        // Usually ERROR_HOTKEY_ALREADY_REGISTERED (1409).
        int err = Marshal.GetLastWin32Error();
        return false;   // → highlight the hotkey field red in the UI
    }

    _callbacks[id] = callback;
    return true;
}

public void Dispose()
{
    foreach (var id in _callbacks.Keys)
        NativeMethods.UnregisterHotKey(_source.Handle, id);
    _source.Dispose();
}

Gotcha: without MOD_NOREPEAT the hotkey "chatters"

If you don't pass MOD_NOREPEAT, then while the user holds the combination down, Windows will send WM_HOTKEY dozens of times per second (auto-repeat). For a utility that kicks off a heavy action (a network request, text processing), that means a flood of parallel calls from a single press. MOD_NOREPEAT guarantees exactly one message per physical key press.

Part 2. Read the selection and paste the result back

Now the interesting part. The hotkey fired — you need to take the text the user selected in another program, process it, and put it back in the same place.

You can't read the selected text directly

Windows doesn't give you a "give me the active window's selected text" API for arbitrary apps. The universal trick is to simulate Ctrl+C and read what landed in the clipboard. Likewise, pasting the result is simulating Ctrl+V after you put the new text on the clipboard.

The sequence:

• save the current clipboard contents (to restore them politely afterward);

• simulate Ctrl+C → wait for the clipboard to update;

• read the selected text;

• process it (your logic / an AI call);

• put the result on the clipboard;

• simulate Ctrl+V → the text gets pasted into the still-active target program;

• restore the original clipboard.

Simulating keys via SendInput

The modern way to send synthetic keystrokes is SendInput (legacy keybd_event still works, but SendInput is more atomic and handled more correctly by the system):

[StructLayout(LayoutKind.Sequential)]
internal struct INPUT
{
    public uint type;          // 1 = INPUT_KEYBOARD
    public KEYBDINPUT ki;
    // (for keyboard the union can be simplified to KEYBDINPUT;
    //  for full mouse/hardware compatibility, add padding)
}

[StructLayout(LayoutKind.Sequential)]
internal struct KEYBDINPUT
{
    public ushort wVk;
    public ushort wScan;
    public uint dwFlags;       // 0 = keydown, 2 = KEYEVENTF_KEYUP
    public uint time;
    public IntPtr dwExtraInfo;
}

[LibraryImport("user32.dll", SetLastError = true)]
internal static partial uint SendInput(uint nInputs,
    [In] INPUT[] pInputs, int cbSize);

To send Ctrl+V, the four-event sequence is: Ctrl down → V down → V up → Ctrl up. The keyup order matters — release the letter first, then the modifier, otherwise the target may receive a "bare" V.

Gotcha #1: another program is holding the clipboard

The Win32 clipboard is a global resource under a lock. Clipboard managers (Ditto, Punto), RDP channels, some antivirus software periodically open it for themselves. At that moment your OpenClipboard / read fails with CLIPBRD_E_CANT_OPEN.

The fix is a retry loop with small pauses. Critically: the pauses must be asynchronous, otherwise you freeze the UI thread for the duration of the wait:

private static async Task<string?> ReadClipboardTextAsync(
    Dispatcher dispatcher, CancellationToken ct)
{
    const int maxAttempts = 10;
    for (int attempt = 0; attempt < maxAttempts; attempt++)
    {
        try
        {
            // Clipboard access must be on the UI thread (STA).
            return await dispatcher.InvokeAsync(() =>
                Clipboard.ContainsText() ? Clipboard.GetText() : null);
        }
        catch (COMException)   // CLIPBRD_E_CANT_OPEN
        {
            await Task.Delay(50, ct);   // NOT Thread.Sleep — don't block the UI
        }
    }
    return null;
}

Apply the same retry pattern to writing the result to the clipboard. The rookie mistake here is Thread.Sleep(50) inside the UI thread: the window "freezes" for half a second and the user sees a hang. Only await Task.Delay.

Gotcha #2: focus and the "focused child"

Between Ctrl+C and Ctrl+V, focus must stay on the target program. If you show your own window in between (for example, a result preview) and don't return focus — Ctrl+V goes "nowhere" or into your own window.

Returning focus via SetForegroundWindow on the target's top-level window is necessary, but sometimes not enough. Some editors (the classic example is Notepad++ built on Scintilla) have an internal focused child window that actually receives input. SetForegroundWindow activates the top-level, but the caret stays in the child control, and the paste doesn't work. Then you have to find the focused element via GetGUIThreadInfo and call SetFocus on it specifically:

[StructLayout(LayoutKind.Sequential)]
internal struct GUITHREADINFO
{
    public int cbSize;
    public uint flags;
    public IntPtr hwndActive;
    public IntPtr hwndFocus;   // here it is — the real input receiver
    public IntPtr hwndCapture;
    public IntPtr hwndMenuOwner;
    public IntPtr hwndMoveSize;
    public IntPtr hwndCaret;
    public RECT rcCaret;
}

// 1. GetForegroundWindow → 2. GetWindowThreadProcessId →
// 3. GetGUIThreadInfo(threadId, ...) → hwndFocus →
// 4. AttachThreadInput + SetFocus(hwndFocus)

AttachThreadInput is needed because SetFocus only works within its own thread's input state — to set focus in another thread's window, you temporarily attach the input queues.

Gotcha #3: sandboxes block synthetic input

UWP apps, Windows Subsystem for Android (WSA), and any process running with higher privileges than yours reject synthetic keystrokes via UIPI (User Interface Privilege Isolation). Your SendInput is simply ignored, and the paste silently doesn't happen.

The honest UX here is not to pretend everything worked, but to detect the failure and tell the truth: "The result is already in your clipboard — paste it manually with Ctrl+V." The user doesn't lose their work, and you don't leave them wondering why nothing pasted.

Part 3. The consolidated gotcha checklist

• WPF KeyBinding is not global — for a hotkey on top of the system you need RegisterHotKey + a message-only window via HwndSource.

• MOD_NOREPEAT — without it, holding the key fires the action dozens of times.

• Conflict detection — RegisterHotKey == false means "taken"; show it in the UI, don't swallow it silently.

• The selection is read by simulating Ctrl+C, the paste by simulating Ctrl+V; there's no direct API.

• The clipboard is under a lock — a retry loop with await Task.Delay, never Thread.Sleep on the UI thread.

• Restore the original clipboard after the operation — the user doesn't expect your utility to wipe the text they copied earlier.

• Focused child — for Scintilla-like controls, return focus via GetGUIThreadInfo.hwndFocus + AttachThreadInput + SetFocus, not just SetForegroundWindow.

• UIPI blocks synthetic input in UWP/elevated windows — detect it and offer manual paste as a fallback.

• Timing — a short pause is needed between Ctrl+C and reading the clipboard; for Ctrl+V the keyup order is letter first, then modifier.

What it looks like in a real app

I assembled all of these mechanisms in CapyBro — a Windows utility that, on a global hotkey, rewrites the selected text with AI and pastes the result back, in any program. Hotkeys there are registered through the RegisterHotKey route described above with MOD_NOREPEAT and conflict detection, and paste-back runs the full "save clipboard → Ctrl+C → process → Ctrl+V → restore clipboard" cycle with a retry loop and a manual-paste fallback for sandboxes.

The free core is open-source (MIT): github.com/phantasmat2018/capy-bro.

If you're building a similar utility and you're stuck on a specific gotcha — drop a comment. This path is still poorly documented publicly, and I'm happy to go into detail.

Roman Tykhonenko, .NET developer, Kyiv.