Gengora.Host 2.5.0

Gengora.Host

Gengora.Host runs the generator definition owned by an application. Use it in one small executable project beside the application, together with the selected product generator packages.

Use it

<PropertyGroup>
  <OutputType>Exe</OutputType>
  <GengoraHostProject>true</GengoraHostProject>
</PropertyGroup>

<ItemGroup>
  <PackageReference Include="Gengora.Host" />
</ItemGroup>

using Gengora.Common;
using Gengora.Host;

var builder = GengoraApplicationBuilder.CreateDefaultBuilder();

// Register one or more product generators and their exact projects here.

return await GengoraHost.RunAsync(builder, args);

The same executable supports one-shot generation, --watch, incremental build execution, and the private editor protocol. Always return RunAsync so a generation failure becomes a failing process and build.

The package brings the matching formatter and semantic MCP runtime through a NuGet dependency. Keep the selected Gengora.Host version in the host project; a normal restore fetches its matching tools without a VS Code extension update.

Unchanged one-shot runs reuse validated outputs automatically. The fingerprint includes reference aliases, interop embedding and assembly/module kind as well as source and package inputs. Changed inputs or missing, altered or invalid outputs run generation again; no reuse environment variable is needed. Reuse also restores the complete semantic previews and navigation targets from both pipeline families. Incomplete cache metadata triggers ordinary generation; previous cache shapes are discarded rather than read through a compatibility path.

Boundary

The host loads only declared projects and their required project-reference closure, then publishes a complete candidate atomically. Generator code still runs with the current user's operating-system permissions. Keep this package out of the application runtime project.

Follow the host project example.

Builds now hand generation to a retained process for the marked Host project and configured workspace. Startup and generation are serialized; a changed Host or environment selects a different identity. An unavailable peer triggers ordinary cold generation automatically. Running the executable without arguments remains the one-shot route. No application-code change or reuse switch is needed.

The process has idle, request and resident-memory limits. A cancelled build cancels its request and fails; discovery records never authorize killing an existing IDE or MCP process. See the host reference for configuration and usage.