Depends on: existing winapp run folder mode

Summary

Add project-mode support to winapp run so it can accept a .csproj file, or a source directory containing a single buildable .csproj, then build and launch the app in one step.

This is the bridge from the current folder-based “run build output” flow to the WinUI inner loop. Folder mode must remain unchanged.

Related issues

• Project-mode analyzer support ([Feature]: Surface WinUI analyzer diagnostics during winapp run project builds #634)
• winapp run --watch ([Feature]: winapp run --watch: WinUI C#/XAML hot reload #635)
• winapp run --devtools ([Feature]: winapp run --devtools: in-app inspector and shared design-time protocol #636)

Problem

Today winapp run assumes the app is already built and points at a build-output folder. That works for packaged app launch, but it makes the common developer flow awkward:

• users must know the output path
• agents must reason about build output layout
• unpackaged WinUI apps need a separate direct-launch path
• project-specific build properties cannot be passed cleanly through one command

Goals

• Accept .csproj input directly
• Support both packaged and unpackaged WinUI apps
• Preserve existing folder-mode behavior exactly
• Build from source with sensible defaults for inner-loop usage
• Allow first-class passthrough of build properties and configuration

Non-goals

• Rewriting folder mode
• Mutating the project file
• Adding project mode to other commands
• Generalizing beyond .NET/WinUI in this change

Proposed behavior

Input handling

• winapp run <path> should detect:
  • explicit .csproj file
  • directory containing exactly one buildable .csproj
  • existing build-output folder with no top-level .csproj
• If multiple buildable .csproj files are present, fail clearly and ask for the exact file.
• Folder inputs must continue to use the current code path.

Build and launch

• Project mode builds the project with dotnet build
• The command should support:
  • -c/--configuration
  • --arch / -r
  • --framework
  • --no-build
  • --no-restore
  • repeatable -p/--property
• Output resolution must use evaluated MSBuild properties, not path guessing.
• Packaged projects should reuse the existing loose-layout + identity + AUMID launch flow.
• Unpackaged projects should launch the apphost executable directly.

Packaging detection

• Packaging should follow the project’s evaluated WindowsPackageType
• Do not infer packaged/unpackaged mode from manifest presence alone
• The -p:WindowsPackageType=None escape hatch should work for a single run

Key implementation constraints

• Use the app’s resolved architecture, not the CLI process architecture, when installing runtime dependencies
• Reuse the existing WinAppSDK runtime install path for framework-dependent unpackaged apps
• Maintain compatibility with projects that rely on dynamic platform resolution across project references
• Use TargetDir for packaged launch flow and RunCommand for unpackaged launch flow

Success criteria

• winapp run MyApp.csproj builds and launches the app
• Packaged WinUI apps launch with identity using the existing flow
• Unpackaged WinUI apps launch directly without identity
• Existing folder-mode commands behave exactly as before
• Common build and launch failures produce actionable errors

Risks / watchouts

• Multi-project solutions can surface CS0006 if platform handling is too naive
• Runtime install must match the app architecture
• dotnet build --getProperty behavior is subtle and needs careful handling

Why this matters

This is the first step toward a single winapp run inner loop that works from source, supports WinUI development cleanly, and becomes the foundation for analyzer, watch, and devtools improvements.