Runtime Stack Packages

This guide explains the runtime-side package split, what lives in the neutral runtime layer versus the Avalonia layer, and when to stay on the umbrella package.

Stack layout

Layer Packages Purpose
App-facing runtime surface XamlToCSharpGenerator.Runtime composition package for normal installs
Neutral runtime contracts XamlToCSharpGenerator.Runtime.Core registries, source info, hot reload/runtime contracts
Avalonia runtime integration XamlToCSharpGenerator.Runtime.Avalonia loader, resource resolution, inline-code runtime, hot reload, hot design, and runtime MCP hosting

Recommended entry points

Normal application usage

Use:

This is the default install story. It keeps the runtime stack aligned with the build/generator stack without making you compose the pieces manually.

Runtime host or infrastructure work

Use:

when you need only neutral registries/contracts and do not want the Avalonia layer.

Avalonia runtime customization

Use:

when you need Avalonia loader behavior, resource/include resolution, inline-code runtime helpers, or hot reload integration directly.

Responsibilities by layer

Runtime.Core

Owns:

  • source and type registries
  • source-info and URI tracking
  • hot reload/runtime coordination contracts
  • framework-neutral descriptor/state helpers

Primary API entry points:

Runtime.Avalonia

Owns:

  • generated loader integration
  • runtime XAML fallback hooks
  • include/resource lookup in Avalonia hosts
  • inline CSharp runtime helpers
  • hot reload and hot design integration
  • runtime MCP server for live hot reload, hot design, and studio inspection

Primary API entry points:

Runtime

Is intentionally narrative-first. It is the package-level install surface, not the public API destination. When you need member-level API, go to the subpackages.