Setup Windows App

This documentation was generated with the assistance of AI. Please report any inaccuracies.

Generate a complete, buildable Windows desktop app on .NET 10 and C# 14: a solution with a UI-free Core library holding all testable logic, a WPF, WinUI 3 or Windows Forms app project composed with the Generic Host, an MSTest 4 Core test project at 100% line coverage, optional FlaUI UI tests, DocFX API docs and optional MSIX packaging, written from templates in the skill’s reference/ files.

Purpose

iru-setup-windows-app is the scaffold step of the Windows chain run by iru-setup-windows-repository, and it also works standalone. It writes global.json, Directory.Build.props (the app <Version> x.y.z[-dev], nullable, warnings as errors, EnableWindowsTargeting so WPF and WinForms build on Linux and macOS, one SARIF analyzer log per project), central package management, .editorconfig, stylecop.json, an <AppName>.slnx solution, src/<AppName>.Core (models and services, plus ViewModels/ for MVVM or Controllers/ and a passive-view interface for MVC), the src/<AppName> UI project per ui, MSTest tests with tests/coverlet.runsettings, an optional FlaUI tests/<AppName>.UITests project, a root .ui-quality.yml, a DocFX docfx.json, generated placeholder icons and, for WPF/WinForms with msix: yes, a packaging/ folder with AppxManifest.xml and build-msix.ps1.

The layout is the scaffold contract that iru-windows-code-one-task, iru-windows-code-one-task-group, the iru-dotnet-* gate skills, iru-dotnet-bump-version and iru-setup-windows-github-workflows rely on; Step 8 of the skill lists the confirmed names, commands and paths. It announces whether it is scaffolding from scratch or updating, and for each existing file group asks Update / Keep as is / Replace / Stop (unless on-existing decides). It never overwrites hand-written source and treats a foreign layout (a single-project dotnet new wpf app, a .sln with other projects, a .wapproj packaging project) as foreign. Toolchain versions are looked up at run time with a recorded fallback table.

The FlaUI project follows the catalog’s UI contract (see Building user interfaces): the app reads --ui-direction/--ui-theme launch arguments through a UiTestOptions class, and the tests render the main screen in every left-to-right/right-to-left x light/dark combination, capture it into .ui-screenshots/ with the shared UiScreenshots helper, and run an Axe.Windows accessibility scan at the level recorded in .ui-quality.yml. The helpers (UiQuality, UiScreenshots, AccessibilityCheck) come from reference/uitest-templates.md.

Purpose group

Windows Desktop Bootstrap

Plugin

Shipped by the iru-dotnet plugin of the ai-catalog marketplace (install with /plugin install iru-dotnet@ai-catalog; see Plugins).

Invocation

/iru-setup-windows-app

Inputs

Argument Required Description Default

ui

No

wpf, winui or winforms.

Asked when absent and not detectable

architecture

No

mvvm or mvc. WPF and WinUI are mvvm only; mvc with them is rejected with an explanation.

mvvm for WPF/WinUI; asked for WinForms

app-name, display-name, root-namespace

Yes (app-name)

PascalCase solution, project and assembly name; window title and MSIX display name; root namespace.

display-name and root-namespace default from app-name

publisher, publisher-display-name, package-name

No

MSIX identity: CN=…​ publisher distinguished name (must match the signing certificate), display name and package name.

Asked when MSIX is produced

version, rids

No

App version and runtime identifiers.

1.0.0-dev (gitflow) or 1.0.0; win-x64;win-arm64

msix, ui-tests

No

yes/no for the packaging/ folder (WinUI is always packaged); flaui/none for the UI test project.

Derived from distribution; flaui

branching, distribution

No

gitflow/main-only (selects the default version); none/internal/store (drives the msix default).

Asked or supplied

accessibility

No

enforce/report/off/none: the automated accessibility level written to .ui-quality.yml (enforce fails the UI tests on Axe.Windows violations, report lists them in .ui-screenshots/a11y-report.txt, off skips the scan, none opts out entirely: no Axe.Windows tooling and no accessibility attributes in the templates). Only used with ui-tests: flaui.

enforce

license, developer-name, developer-email, organization-url

No

Recorded for the report and license headers.

Asked

open-source, visibility, ci, sonar (+ coordinates)

No

Used only for the Sonar recommendation; Sonar produces no file here.

Asked

mode, on-existing

No

new/existing; ask/keep/update/replace for existing file groups.

Detected; ask

Outputs

  • Build foundation: global.json, Directory.Build.props, Directory.Packages.props, .editorconfig, stylecop.json, <AppName>.slnx, and .ui-quality.yml (accessibility, directions: [ltr, rtl], themes: [light, dark]; written for every ui).

  • src/<AppName>.Core (UI-free, net10.0), src/<AppName> (WPF, WinUI 3 or WinForms app), app.manifest, UiTestOptions.cs (the UI-test launch-argument hook) and, for WinUI, Package.appxmanifest and publish profiles.

  • tests/<AppName>.Core.Tests (MSTest 4 plus coverlet), tests/coverlet.runsettings, and optionally tests/<AppName>.UITests (FlaUI, [TestCategory("UI")], Windows only) with the UiQuality, UiScreenshots and AccessibilityCheck helpers and a matrix capture test that writes .ui-screenshots/screen/<MainWindow|MainForm>/<state>--<direction>--<theme>.png (8 captures) and scans with Axe.Windows.

  • docfx.json for the Core API, generated icon and tile PNGs, and, with msix: yes for WPF/WinForms, packaging/.

  • A verification pass (restore, build with analyzers, dotnet format, Core tests and coverage, DocFX; Windows-only stages reported as unverified off Windows) and a report with the action per file group, versions used (live versus fallback) and the scaffold contract table.

Execution flow

flowchart TD A[Start /iru-setup-windows-app] --> B["Step 0: Parse args\n(ui, architecture, identity, msix, ui-tests,\naccessibility, branching, distribution, mode)"] B --> C["Step 1: Survey the repository\nfrom scratch, or update with\nUpdate / Keep / Replace / Stop per file group"] C -- user chose stop --> STOP[Stop and report] C --> D["Step 2: Collect required inputs\n(architecture matrix: WPF/WinUI mvvm only)"] D --> E["Step 3: Infer repository information"] E --> F["Step 4: Look up toolchain versions\n(NuGet, .NET releases; fallback table)"] F --> G["Step 5: Select reference templates\nfor ui and architecture"] G --> H["Step 6: Scaffold the project\n(apply per-group decisions, generate assets)"] H --> I["Step 7: Verify via iru-gate-runner\nrestore, build, format, Core tests + coverage, DocFX;\nWindows-only stages unverified elsewhere"] I --> J["Step 8: Report actions, versions,\nscaffold contract, quirks"]

Dependencies

Invokes

None — iru-setup-windows-app invokes no other catalog skill; it writes files from its own reference/ templates and runs dotnet, docfx, pwsh and python3 directly. Its Step 7 verification and the documented gate commands mirror those of .NET Test, .NET Coverage, .NET Code Quality and .NET DocFX, and the Core/UI layout it writes is the contract for Windows Code One Task, .NET Bump Version and Setup Windows GitHub Workflows, but it does not call them.

Invoked by

  • Setup Windows Repository — Step 4 runs iru-setup-windows-app (through an isolated skill executor) first in the chain, passing the resolved shared inputs as args.

  • Setup Repository — reaches it indirectly by delegating to iru-setup-windows-repository. It can also be run directly by a person.

Related agents

  • Gate Runner — runs Step 7’s restore, build, format, test, coverage and DocFX verification commands so their long logs stay out of the caller’s context.

Source

SKILL.md on GitHub — the file this page was generated from.