How Far Can a Windows App Be a Single Binary? What Fits in One EXE, Where Windows Dependencies Remain, and a Decision Table for Distribution

The bottom line first

On Windows, “I want a single binary” actually mixes four different goals:

• I want one deliverable file
• I want to drop the prerequisite of a pre-installed .NET or VC++ runtime
• I want it to run by just placing it, with no installer or admin rights
• I don’t want to depend on differences between target Windows versions

You can get pretty close to one EXE for the deliverable, but you cannot drive the dependency on the target Windows itself to zero. That is the practical boundary line.

Four levels of “single binary”

Level A: One deliverable file

This is about the visible unit of distribution. It can still satisfy this even if the EXE unpacks to a temp folder at startup or relies on OS DLLs.

Level B: No language runtime preinstall required

• Static linking for C/C++
• self-contained / single-file / Native AOT for .NET

At this level, it really starts to feel like “I can just carry this around standalone.”

Level C: No installation or registration

This is where it gets hard fast. Shell extensions, Windows services, drivers, and COM registration are not satisfied by “just place it.”

Level D: Independent of the target Windows

Not possible on Windows. The app ultimately runs on top of the Windows API, loader, and security model.

Areas where one EXE is realistic

These kinds of apps lend themselves to a single EXE:

• Standalone desktop tools you launch on their own
• Line-of-business apps where the EXE owns both the UI and the logic
• Networking, file processing, log collection, monitoring, and equipment-control tools
• Anything that does not need to integrate as a host inside Explorer or Office

In practice, an app.exe plus a few neighboring DLLs that you can xcopy-deploy is often easier to maintain than forcing everything into a single compressed EXE.

Windows dependencies that remain even with one EXE

• OS version dependency: minimum supported OS for the APIs you use, x64 vs Arm64
• System DLL dependency: kernel32.dll, user32.dll and friends are the OS’s responsibility
• Security model dependency: UAC, file ACLs, the Service Control Manager, and so on
• Host or runtime dependency: WebView2 Runtime, Windows App SDK, etc.

Realistic landing points by technology

Areas that intrinsically require registration or dependencies

• Shell extensions: must be registered with Explorer; placing the file is not enough
• Windows services: need SCM registration plus a design for permissions and the service account
• Drivers: only complete with INF, signing, and an install procedure; they don’t really fit on the single-binary playing field

A practical decision table

Decisions to make up front for distribution

1. Decide which “one” you actually want - one deliverable, no runtime prerequisite, or no installer
2. Pin the minimum supported Windows version and arch from the start - leaving this vague will burn you at the end
3. Write down what you bundle and what you leave to Windows
4. If single-binary is the priority, reduce host integration - the less you rely on shell extensions or services, the closer you get

Summary

• You can make the app a single EXE, but you cannot fold the Windows it depends on into that EXE
• For a plain standalone EXE, you can get quite close to one-file distribution
• Dependencies on OS version, arch, system DLLs, and the security model do not go away
• Shell extensions, services, drivers, WebView2, and WinUI 3 are really about OS registration and additional runtimes
• If single-binary is a hard priority, design with low OS coupling from the technology-selection stage

References

• Microsoft Learn, Create a single file for application deployment
• Microsoft Learn, Native AOT deployment overview
• Microsoft Learn, C runtime (CRT) and C++ standard library (STL) lib files
• Microsoft Learn, Dynamic-link library search order
• Microsoft Learn, Targeting your application for Windows
• Microsoft Learn, Creating Registration-Free COM Objects
• Microsoft Learn, Registering Shell Extension Handlers
• Microsoft Learn, CreateServiceW function
• Microsoft Learn, Overview of INF Files
• Microsoft Learn, Windows driver signing tutorial
• Microsoft Learn, Distribute your app and the WebView2 Runtime
• Microsoft Learn, Windows App SDK deployment guide for self-contained apps