Files — Administrator & Developer Guide

This guide is for the people who deploy, secure, build, and extend Files — IT administrators rolling it out across a fleet, security teams assessing its surface, and developers who want to understand or contribute to the codebase. It documents the architecture, the multi-process model, build requirements, configuration internals, security posture, packaging and deployment, telemetry, and developer internals.

For end-user features and workflows, see the companion User Guide.

Note

Files is a client-side Windows desktop application. It is not a server, has no listening network service, no multi-user backend, and no remote-management API. The "operations" concerns here are those of a desktop app: packaging, per-user configuration, OS integration, and update management.

Table of Contents

1. Executive Summary
2. Architecture
3. Process & Component Model
4. Repository Structure
5. System Requirements
6. Dependencies
7. Building from Source
8. Distribution & Packaging
9. Default File Manager Integration
10. Configuration Internals
11. Storage & Interop Subsystems
12. Source Generators
13. Security Analysis
14. Telemetry, Privacy & Crash Reporting
15. Logging & Diagnostics
16. Performance
17. Enterprise Deployment
18. Testing
19. Extending & Contributing
20. Code Quality & Patterns
21. Potential Improvements
22. Quick Reference
23. Appendices

1. Executive Summary

Files is a feature-rich file manager for Windows, built on WinUI 3 and the Windows App SDK. It is written predominantly in C# (targeting modern .NET), with a small amount of native C++ for low-level shell integration. The codebase is organized as a Visual Studio solution of cooperating projects: a main WinUI application, an out-of-process WinRT/COM server, a native launcher, two file-dialog shell extensions, storage abstraction libraries, and a Roslyn source-generator project.

Key facts at a glance:

The architecture's defining trait is its multi-process design: the WinUI app does not perform every privileged operation in-process. A companion server process hosts WinRT activatable classes for operations that must run outside the packaged app's sandbox, while a native launcher and two shell extensions integrate Files into the Windows shell (default-file-manager behavior and the system Open/Save dialogs).

2. Architecture

High-level diagram

                       ┌─────────────────────────────────────────────┐
                       │              Windows Shell                   │
                       │  (Explorer "open folder", Open/Save dialogs) │
                       └───────────────┬──────────────┬──────────────┘
                                       │              │
                  files-dev: URI /     │              │  COM shell-extension
                  IShellWindows hook    │              │  activation
                                       ▼              ▼
        ┌──────────────────┐   ┌──────────────────────────────────────┐
        │ Files.App.Launcher│   │  Files.App.OpenDialog / SaveDialog   │
        │  (native C++ EXE) │   │  (shell extensions: file pickers)    │
        └─────────┬─────────┘   └──────────────────┬───────────────────┘
                  │ ShellExecute(files-dev:)         │ writes selection,
                  ▼                                  │ signals "FILEDIALOG" event
        ┌───────────────────────────────────────────▼───────────────────┐
        │                       Files.App  (WinUI 3)                      │
        │  App.xaml.cs → MainWindow → Shell panes → Layouts/ViewModels    │
        │  DI host (Microsoft.Extensions.Hosting + CommunityToolkit Ioc)  │
        │  Commands/Actions · Settings services · Storage services        │
        └───────────────┬───────────────────────────┬───────────────────┘
                         │ activates                  │ reads/writes
                         ▼                            ▼
        ┌──────────────────────────────┐   ┌────────────────────────────┐
        │      Files.App.Server         │   │  Per-user app data          │
        │ (out-of-proc WinRT/COM host;  │   │  settings/*.json, *.db,     │
        │  RoRegisterActivationFactories)│   │  thumbnail & icon caches    │
        └──────────────────────────────┘   └────────────────────────────┘

        Shared libraries used by Files.App:
          Files.Core.Storage · Files.App.Storage (incl. FTP, legacy native)
          Files.App.CsWin32 (Win32 projections) · Files.Shared (utilities)
          Files.Core.SourceGenerator (build-time codegen)

Design principles

• MVVM throughout. Views (XAML) bind to ViewModels; services hold state and logic. CommunityToolkit.Mvvm provides ObservableObject, commands, and messaging.
• Dependency injection. The app builds a host at startup (AppLifecycleHelper.ConfigureHost()) and resolves services through CommunityToolkit.Mvvm.DependencyInjection.Ioc.Default. A few singletons (QuickAccessManager, LibraryManager, FileTagsManager, AppModel) are still resolved manually with a // TODO: Replace with DI note.
• Command/Action pattern. Every user operation is an IAction wrapped in an IRichCommand (label, description, glyph, hotkeys, executability). This is the backbone of the menus, the toolbar, the Command Palette, and the customizable keyboard shortcuts. See Source Generators and Appendix C.
• Settings as typed services. Each settings domain is a service exposing strongly typed properties over a JSON-backed store (see Configuration Internals).
• Separation of privileged work. Operations that need to run outside the packaged sandbox are hosted in Files.App.Server.

Application lifecycle

Files.App/App.xaml.cs is the entry point. On launch (OnLaunched):

1. Reads activation arguments (normal launch vs. a Windows startup task).
2. Activates MainWindow and shows a splash screen (unless it's a background startup task with "keep running" enabled).
3. Configures the DI host and Ioc.Default.
4. Configures Sentry crash reporting if the build environment is not Dev.
5. Resolves manager singletons and hooks window events.
6. Creates the system tray icon (shown if ShowSystemTrayIcon is enabled).
7. Initializes app components asynchronously.

On close (Window_Closed), Files saves session tabs, optionally keeps running in the background (LeaveAppRunning) by hiding the window and parking the instance on a named semaphore (Program.Pool), preserves clipboard contents, and waits for in-flight file operations to complete before final teardown. Unhandled exceptions from the UI thread, the app domain, and the task scheduler are all routed to AppLifecycleHelper.HandleAppUnhandledException.

3. Process & Component Model

Files is not a single executable. Understanding the cooperating processes is the key to deploying and securing it.

Files.App (WinUI 3 — the main app)

The packaged WinUI 3 application the user interacts with. Single-instance by design: additional activations are routed into the running process (parked on a named semaphore, Files-{Environment}-Instance), so opening many folders does not spawn many processes.

Files.App.Server (out-of-process WinRT/COM host)

Files.App.Server/Program.cs is a headless host that registers WinRT activation factories via RoRegisterActivationFactories for every sealed public class in the Files.App.Server.* namespace. It runs a multithreaded apartment, waits on an ExitSignalEvent, and tears down its factories on exit. AppInstanceMonitor watches the lifetime of the launching process(es) and signals the server to exit when the last one closes.

This pattern lets the WinUI app activate components that need to run outside the app container (full-trust / elevated operations that the packaged sandbox cannot perform directly). First-chance exceptions in the server are logged to debug_server.log in the app's local data folder.

Files.App.Launcher (native C++)

Files.App.Launcher/FilesLauncher.cpp is a native Win32 WinMain executable that implements the "set Files as default file manager" behavior:

• When Windows would open a folder, the launcher receives the request and routes it to Files via the files-dev: (per-channel) URI protocol, encoding the target path/ selection as hex-escaped command arguments (files-dev:?cmd=...).
• It detects whether Files is still installed (%LOCALAPPDATA%\Microsoft\WindowsApps\files-dev.exe); if Files has been uninstalled, it self-uninstalls (re-imports UnsetFilesAsDefault.reg, removes its files) and restores File Explorer.
• It uses IShellWindows / IShellBrowser COM interfaces to reuse an existing shell window when appropriate, and special-cases shell locations (Recycle Bin, This PC, Network, "God Mode") that must still open in Explorer.

Files.App.OpenDialog / Files.App.SaveDialog (shell extensions)

These projects implement shell extensions that let Files act as the Open/Save file picker for other applications. When the dialog completes, the selection is written to an output path and a named event ("FILEDIALOG") is signaled to hand the result back to the requesting app. (You can see the corresponding code in App.xaml.cs, which writes selected item paths to App.OutputPath and sets the FILEDIALOG event on close.)

Supporting libraries

4. Repository Structure

Files/
├─ src/
│  ├─ Files.App/                 Main WinUI 3 application
│  │  ├─ App.xaml.cs             Entry point & lifecycle
│  │  ├─ Constants.cs            App-wide constants (paths, limits, URLs)
│  │  ├─ Actions/               166 IAction command implementations
│  │  │   ├─ FileSystem/         Copy, cut, delete, rename, create…
│  │  │   ├─ Navigation/         Tabs, panes, back/forward/up…
│  │  │   ├─ Open/               Settings, terminal, IDE, palette…
│  │  │   ├─ Content/            Archives, run-as, image, install…
│  │  │   ├─ Display/            Layout, sort, group
│  │  │   ├─ Show/               Toggle panes/sidebar/toolbar/hidden…
│  │  │   ├─ Git/                Clone, init, fetch, pull, push, sync
│  │  │   └─ Global/             Theme, search, undo/redo, fullscreen…
│  │  ├─ Data/
│  │  │   ├─ Commands/           IRichCommand, ActionCommand, HotKey infra
│  │  │   ├─ Models/             App/data models
│  │  │   ├─ Contracts/          Service interfaces (49 files)
│  │  │   ├─ Enums/              Option enums (57 files)
│  │  │   └─ Factories/          Item & menu factories
│  │  ├─ Services/
│  │  │   ├─ Settings/           Typed settings services (the config surface)
│  │  │   ├─ App/                App lifecycle & coordination services
│  │  │   ├─ Storage/            Storage-related services
│  │  │   ├─ DateTimeFormatter/  Locale-aware date formatting
│  │  │   └─ ...
│  │  ├─ ViewModels/             MVVM view models (Settings, Properties, Layouts…)
│  │  ├─ Views/                  XAML pages (Settings, Properties, Shells, Layouts)
│  │  ├─ UserControls/           Widgets, TabBar, StatusCenter, FilePreviews…
│  │  ├─ Utils/                  Storage, Shell, Cloud, Git, Serialization, Win32…
│  │  └─ Strings/                Localized resources (50+ languages via Crowdin)
│  ├─ Files.App.Server/          Out-of-process WinRT/COM host
│  ├─ Files.App.Launcher/        Native C++ default-file-manager launcher
│  ├─ Files.App.OpenDialog/      Open-dialog shell extension
│  ├─ Files.App.SaveDialog/      Save-dialog shell extension
│  ├─ Files.App.Controls/        Reusable WinUI controls
│  ├─ Files.App.CsWin32/         Win32 interop projections
│  ├─ Files.App.Storage/         Storage implementations (native, FTP, legacy)
│  ├─ Files.Core.Storage/        Storage abstraction contracts
│  ├─ Files.Core.SourceGenerator/Roslyn generators
│  └─ Files.Shared/              Shared utilities & attributes
├─ tests/
│  ├─ Files.App.UITests/         UI tests (Appium/WinAppDriver, Axe accessibility)
│  └─ Files.InteractionTests/    Interaction tests
└─ Directory.Packages.props      Central NuGet package version management

Note

Localization lives under Files.App/Strings/<locale>/ with 50+ language folders, managed through Crowdin (https://crowdin.com/project/files-app). Contributors should not edit non-en-US strings by hand — they are synchronized from Crowdin.

5. System Requirements

Important

Files depends on the Windows App Runtime. If it is missing or broken, Files fails fast with a hardcoded startup error ("A required Windows component could not be loaded…") because the resource-loading system itself may be unavailable at that point. Reinstalling from the Store or the official download repairs it.

Windows 11 gets the fullest experience (default font Segoe UI Variable, newer shell integrations). On Windows 10, some features are slower and the standard font falls back to Segoe UI (Constants.Appearance.StandardFont).

6. Dependencies

Package versions are centrally managed in Directory.Packages.props. The most significant runtime dependencies and their roles:

Build/test-only dependencies include Microsoft.CodeAnalysis.* (source generators), PolySharp, Appium.WebDriver, Axe.Windows (accessibility testing), and MSTest.*.

Note

Several capabilities users perceive as "built into Files" are actually these libraries: Git is LibGit2Sharp, FTP is FluentFTP, archives are SevenZipSharp/SharpZipLib, media details are TagLibSharp, and the ACL object picker is Tulpep's Active Directory picker. When triaging a bug in one of these areas, check the library first.

7. Building from Source

Important

This is an overview for contributors. The repository's own contributor docs are the authoritative, version-current source for the exact toolchain and steps.

Prerequisites

• Visual Studio 2022 (latest) with the workloads:
  • .NET Desktop Development
  • Universal Windows Platform / Windows App SDK (C++ and C# tooling)
  • Desktop development with C++ (for Files.App.Launcher and the C++/WinRT dialogs)
• Windows App SDK components matching Microsoft.WindowsAppSDK 2.1.3.
• A modern .NET SDK matching the projects' target framework.
• Windows SDK build tools (Microsoft.Windows.SDK.BuildTools 10.0.28000.x).

Build steps (typical)

1. git clone https://github.com/files-community/Files
2. Open the solution in Visual Studio 2022.
3. Select the build configuration:
     - Debug | Dev      → the FilesDev channel (files-dev: protocol)
     - Release | …      → Stable/Preview channels
   and platform (x64 / ARM64).
4. Set the packaging project (Files.App) as the startup project.
5. Build & deploy (F5). The MSIX is built and sideloaded for debugging.

CI-injected secrets

Three constants in Constants.AutomatedWorkflowInjectionKeys are placeholders replaced by the Files CI pipeline at build time:

Local developer builds run without these secrets; the dependent features degrade gracefully (no Sentry in Dev, no GitHub sign-in, etc.).

8. Distribution & Packaging

Files ships as MSIX packages across three channels. Each channel is a distinct package with its own identity, app tiles, and protocol, so they coexist on one machine.

App-tile assets are organized per channel under Files.App/Assets/AppTiles/{Dev,Preview,Release}/ (including high-contrast variants).

Update model

• Store packages update through the Microsoft Store automatically.
• Sideloaded packages are updated by installing a newer signed MSIX. Files also performs an in-app update check (AppLifecycleHelper.CheckAppUpdate()), surfacing available updates to the user.

9. Default File Manager Integration

Files can register itself as the system's default file manager. The mechanism:

1. Files installs the native launcher (Files.App.Launcher) and registry entries that route Explorer "open folder" requests to it.
2. The launcher encodes the requested path/selection and invokes Files via the channel's URI protocol (files-dev: for Dev, the channel-specific protocol for Stable/Preview).
3. Certain shell locations are deliberately excluded and always open in Explorer: Recycle Bin, This PC, Network, and the "God Mode" control-panel CLSID — because Files does not host those special views.
4. On uninstall, the launcher detects that Files is gone and runs UnsetFilesAsDefault.reg (with an elevation prompt) to restore File Explorer, then removes itself.

Caution

Registering an alternate default file manager modifies shell behavior for the user. In managed environments, validate that this integration is acceptable per policy. The unset path requires elevation (runas) to import the restoring .reg file.

10. Configuration Internals

Where settings live

All configuration is per-user under the packaged app's local data folder:

%LOCALAPPDATA%\Packages\<PackageFamilyName>\LocalState\settings\
    user_settings.json        ← user preferences (the settings surface)
    filetags.json             ← file tags (default: Home, Work, Photos, Important)
    user_settings.db          ← settings database companion
    filetags.db               ← file-tags database companion

These names are defined in Constants.LocalSettings. The settings folder name is settings.

How settings work

The configuration system is a set of typed settings services, each extending BaseObservableJsonSettings over a JSON-backed, cached database (CachingJsonSettingsDatabase → DefaultJsonSettingsDatabase). Each property looks like:

public bool ShowHiddenItems
{
    get => Get(false);   // default supplied inline
    set => Set(value);   // persisted to user_settings.json
}

This means the default value is the literal passed to Get(...), and the JSON key is the property name. Settings raise SettingChangedEventArgs so the UI updates reactively.

The umbrella IUserSettingsService (UserSettingsService) lazily exposes the domain services:

Export / import & migration

• UserSettingsService.ExportSettings() serializes settings to JSON, excluding session-only data (LastSessionTabList, LastCrashedTabList, PathHistoryList, PreviousSearchQueriesList, PreviousArchiveExtractionLocations).
• ImportSettings() merges an imported dictionary and raises change events for each key.
• FoldersSettingsService performs a one-time legacy migration (MigrateLegacySingleClickSettings) from the old OpenItemsWithOneClick / OpenFoldersWithOneClick keys to the new SingleClickOpenMode enum, then removes the obsolete keys so subsequent launches no-op.

A full settings reference (keys + defaults) is in the User Guide; Appendix A summarizes file locations.

11. Storage & Interop Subsystems

Storage abstraction

Files.Core.Storage defines storage contracts and storables (built atop OwlCore.Storage), and Files.App.Storage provides concrete implementations:

• Windows native storage — the default path for local files/folders, with helpers and managers (e.g., TaskbarManager for taskbar progress via ITaskbarList3).
• FTP (Files.App.Storage/Ftp/) — remote browsing via FluentFTP.
• Legacy native storage (Files.App.Storage/Legacy/) — older code paths retained for compatibility (home folder, native storage legacy).

Win32 / shell interop

• Files.App.CsWin32 holds CsWin32-generated P/Invoke signatures; the app calls Win32 APIs directly (e.g., CreateFileFromApp, CreateDirectoryFromApp, object picker, ACL APIs, taskbar COM).
• The Security/ACL editor (ViewModels/Properties/Security*ViewModel.cs) reads and writes NTFS ACLs through an IStorageSecurityService, using the Active Directory object picker to select principals and Win32 calls to add/remove ACEs and change ownership.
• WMI/CIM (Microsoft.Management.Infrastructure) powers device/drive watch events (EventArrivedEventArgs wraps CimSubscriptionResult).

Cloud & WSL detection

• Utils/Cloud/Detector/ implements ICloudDetector (abstract base AbstractCloudDetector) to enumerate installed cloud providers asynchronously.
• WSL distributions are detected and rendered with per-distro icons (Constants.WslIconsPaths).

12. Source Generators

Files.Core.SourceGenerator is a Roslyn incremental-generator project that produces code at build time. Two notable generators:

• CommandManagerGenerator — generates the CommandCodes enum and command-manager wiring from the IAction implementations. This is why there is no hand-written CommandCodes.cs: the command registry is derived from the action classes themselves, keeping the enum and the actions in sync automatically.
• RegistrySerializationGenerator — for classes annotated with [RegistrySerializable], generates BindValues/SaveValues methods that round-trip the object's properties to/from the Windows Registry (mapping C# types to RegistryValueKind, honoring [RegistryIgnore], and recursing into nested types). This underpins registry-backed configuration/integration without manual serialization code.

Note

Because of source generation, a static AST scan of the repository will under-report the command surface — the full list of CommandCodes only exists after a build. The authoritative human-readable list is the set of files under Files.App/Actions/ (see Appendix C).

13. Security Analysis

Files is a local desktop app, so the security model is about local privilege, filesystem access, and OS integration, not network exposure.

Attack surface — what Files does not expose

• No listening network service. Files does not open inbound sockets or run a server users connect to. The Files.App.Server process is a local WinRT/COM activation host, not a network server.
• No authentication backend, no multi-tenant data. Configuration is per-user.
• Outbound network only, and only for opt-in features: Git remotes (LibGit2Sharp), FTP servers you connect to (FluentFTP), cloud-provider detection, update checks, and crash reporting (Sentry, release builds).

Elevation & privileged operations

Warning

The default-file-manager unset path and certain installs trigger UAC elevation and modify machine/registry state. In locked-down environments, restrict or audit these via application control and standard-user policies. Driver (.inf) and certificate installation should be treated as high-impact actions.

Filesystem & data handling

• Settings are written with Win32 file APIs (CreateFileFromApp, WriteStringToFile); invalid JSON in the settings file is handled defensively (falls back to defaults rather than crashing).
• Alternate data streams can be created/shown only when the corresponding settings are enabled (off by default), since ADS is an advanced/abuse-prone NTFS feature.
• Clipboard contents are preserved across app close only for Files' own data package.

Secrets

• Sentry DSN, GitHub client ID, and Bing Maps key are build-time injected (Constants.AutomatedWorkflowInjectionKeys). They are not user secrets and not stored in user configuration. Forks/local builds run without them.

Recommendations for administrators

• Decide whether the default-file-manager integration and ADS/driver/cert actions are permitted; gate with policy if not.
• For privacy-sensitive deployments, communicate the Sentry crash-reporting behavior (release builds) and point users at the privacy policy (files.community/privacy).
• Prefer Store distribution for managed fleets (signed, auto-updating, MSIX isolation).

14. Telemetry, Privacy & Crash Reporting

• Crash reporting via Sentry is configured at startup only when the build environment is not Dev (AppLifecycleHelper.ConfigureSentry()), i.e., in Stable/Preview release builds. The Sentry DSN is CI-injected (sentry.secret).
• There is commented-out support for action metrics (Sentry metrics increment per executed command) in ActionCommand.ExecuteAsync — currently disabled ("Re-enable when Metrics feature is available again"), so per-command usage metrics are not being sent.
• The privacy policy is published at https://files.community/privacy (Constants.ExternalUrl.PrivacyPolicyUrl).

Important

If your organization disallows third-party crash telemetry, evaluate this before a broad rollout. Dev builds do not initialize Sentry at all.

15. Logging & Diagnostics

• The app uses Microsoft.Extensions.Logging (ILogger), with informational logs at key lifecycle points (launch, activation, window activation).
• Users can open the in-app log file (Ctrl+.) and its location (Ctrl+Shift+.) — useful when filing bug reports.
• Files.App.Server writes first-chance exceptions to debug_server.log in the app's local folder.
• Unhandled exceptions across the UI thread, app domain, and task scheduler are centrally handled, enabling crash capture and (in release) Sentry reporting.

16. Performance

Files exposes several knobs that materially affect responsiveness, especially on large folders or slower hardware:

Built-in limits guard against pathological inputs (Constants.PreviewPane): text previews cap at 10,000 characters, PDF previews at 10 pages, and unknown-extension "try as text" at ~500 KB. Drive widgets warn at 90% fullness (Constants.Widgets.Drives.LowStorageSpacePercentageThreshold).

Tip

On Windows 10, the combination of disabling smooth scrolling + folder-size calculation + thumbnails (for problem folders) addresses most reported sluggishness (see User Guide troubleshooting, issue #18536).

17. Enterprise Deployment

Files is an MSIX app and deploys with standard Windows app-management tooling.

• Microsoft Store for Business / Intune (Store app): assign the Store package to users/devices. Updates are automatic. This is the recommended path for managed fleets (signed, sandboxed, auto-updating).
• Sideloaded MSIX: distribute the signed .msix/.msixbundle via Intune (line-of- business app), SCCM, or Add-AppxPackage. You manage updates by pushing new packages. Ensure your tenant trusts the signing certificate.
• Per-user configuration: settings live under each user's LocalState (see Configuration Internals). To pre-seed defaults, stage a user_settings.json in the appropriate LocalState\settings\ path as part of provisioning.

Note

Files has no ADMX/Group Policy templates and no built-in MDM configuration channel. Centralized configuration is achieved by managing the per-user JSON files, not via policy keys. Plan provisioning accordingly.

Policy considerations

• Decide whether to allow the default-file-manager integration (it alters shell behavior and the unset path needs elevation).
• Decide whether driver/certificate install and ADS actions are acceptable; there is no app-level switch to remove them beyond the context-menu visibility toggles, so gate with application control if strict.

18. Testing

The presence of a test project under tests/ does not mean the C# AST tooling will report test coverage — these are WinUI/desktop UI tests driven through automation frameworks, and they require a built, deployed app to run.

Tip

Commands expose an AutomationName and AutomationId (on IRichCommand) specifically so UI tests can locate and invoke them deterministically. When adding a new action, set a stable automation ID.

19. Extending & Contributing

Adding a command (action)

1. Create a class under Files.App/Actions/<Category>/ implementing IAction (or IToggleAction for on/off commands).
2. Provide Label, Description, Glyph (a RichGlyph), and — optionally — default hotkeys via HotKey / SecondHotKey / ThirdHotKey / MediaHotKey.
3. Implement ExecuteAsync and IsExecutable.
4. The CommandManagerGenerator picks it up at build time and adds it to CommandCodes, the Command Palette, and the keyboard-shortcut settings automatically — no manual registration.

Other extension points

• Custom controls live in Files.App.Controls (Omnibar, Sidebar, Toolbar, ThemedIcon, etc.) and are reusable.
• Registry-backed types can opt into generated serialization with [RegistrySerializable] / [RegistryIgnore].
• Localization is contributed through Crowdin, not direct PRs to non-en-US strings.

Contribution workflow

The project uses GitHub with issue templates for bugs (...issues/new?...template=bug_report.yml) and features (...template=feature_request.yml), and a community Discord (discord.gg/files). Follow the repository's CONTRIBUTING guidance and coding conventions (the codebase consistently uses MVVM, CommunityToolkit.Mvvm primitives, file-scoped namespaces in newer files, and the IAction/IRichCommand command pattern).

20. Code Quality & Patterns

Observed conventions across the codebase:

• MVVM + DI end to end; services behind interfaces in Data/Contracts/.
• Command pattern with a rich command abstraction (IRichCommand) that unifies label, description, glyph, hotkeys, toggle state, executability, and automation IDs — and supports modifier-aware commands (ModifiableCommand dispatches to a different command depending on held key modifiers) and a null-object (NoneCommand).
• Strongly typed settings with inline defaults, change notifications, and one-time migrations.
• Defensive interop: SafetyExtensions.IgnoreExceptions, timeouts (WithTimeoutAsync), and DispatcherQueue fallbacks for WinUI threading quirks (EnqueueOrInvokeAsync invokes directly when the dispatcher is unexpectedly null).
• Source generation to eliminate boilerplate and keep the command registry and registry serialization in sync with their sources.
• Localized everything: user-facing strings flow through Strings.*.GetLocalizedResource().

Notable inline TODOs and workarounds (good first issues / cleanup candidates): the manual-singleton // TODO: Replace with DI managers in App.xaml.cs; the #10110 flyout-close crash workaround in Window_Closed; the disabled action-metrics code in ActionCommand.

21. Potential Improvements

Derived from the code and the issue tracker — candidate areas for maintainers:

• Finish the DI migration. Move QuickAccessManager, LibraryManager, FileTagsManager, and AppModel off manual Ioc.Default.GetRequiredService into proper constructor injection (the code already flags this).
• Re-enable usage metrics behind a clear, opt-in privacy control (the metrics path is stubbed out).
• Harden Grid-view rendering (#18543) and thumbnail/icon caching (#14993, #18503) — recurring stability complaints.
• Windows 10 performance pass (#18536) — the experience diverges from Windows 11.
• Resilient column-config loading (#18528) — a bad saved layout should never block startup; load defensively like the settings JSON does.
• Browsable non-ZIP containers (#18533) — .jar and similar could open like .zip.
• Auto-clear completed Status Center tasks (#18523) — frequently requested.
• Enterprise configuration — ADMX/MDM policy support would make managed rollouts far easier than staging JSON files.

22. Quick Reference

Key files

Key paths (per user)

External endpoints

23. Appendices

Appendix A — Configuration File Locations

All under %LOCALAPPDATA%\Packages\<PackageFamilyName>\LocalState\settings\ (folder name settings, from Constants.LocalSettings):

Session-only keys excluded from export: LastSessionTabList, LastCrashedTabList, PathHistoryList, PreviousSearchQueriesList, PreviousArchiveExtractionLocations.

Appendix B — Distribution Package Names

From Constants.Distributions.KnownAppNames:

Appendix C — Action Catalog

The user-facing command surface is implemented as 166 IAction classes under src/Files.App/Actions/, grouped by category. (The generated CommandCodes enum mirrors these.)

Default keyboard bindings for these are tabulated in the User Guide → Keyboard Shortcut Catalog.

Appendix D — Key Constants & Limits

From Constants: