The renderer package hands every consumer the runtime it generates code for

[woksin]

Cratis.Stage.Rendering.Cratis hands every consumer the Arc + Chronicle + MongoDB runtime it generates code for, and cannot simply stop.

The renderer is a text generator. Its own csproj says so, in a comment that is currently untrue:

<!--
    Specs compile the rendered output in memory against the real Cratis assemblies … These are private
    assets: the renderer itself does not depend on Cratis at runtime, only its specs do.
-->
<PackageReference Include="Cratis" ExcludeAssets="analyzers" />
<PackageReference Include="Cratis.Arc.MongoDB" ExcludeAssets="analyzers" />

PrivateAssets is not set on either, so both flow to every consumer.

Measured

The published package declares them. From cratis.stage.rendering.cratis.2.3.0.nupkg's nuspec:

<dependency id="Cratis" version="21.13.0" exclude="Build,Analyzers" />
<dependency id="Cratis.Arc.MongoDB" version="21.13.0" exclude="Build,Analyzers" />

What that costs a consumer. Adding Cratis.Stage.Rendering.Cratis to the CLI — which is the whole of Cratis/cli#62, cratis render — produces:

• 160 compilation errors, all ambiguity. The Cratis package contributes GlobalUsings.cs through its Cratis.props, so every consuming project silently gains 28 global usings. User becomes ambiguous between Cratis.Arc.Identity.User and Cratis.Chronicle.Contracts.Security.User, AppendedEvent between Cratis.Chronicle.Events and Cratis.Chronicle.Contracts.Events, and so on.
• error MSBL001 — the template engine brings NuGet.Frameworks transitively, and Microsoft.Build.Locator refuses to run when a copy sits beside the executable. The CLI uses MSBuildLocator for screenplay generate.
• A version collision. The CLI pins Cratis.Chronicle.Contracts 16.19.3 deliberately (Chronicle 16.20.0 validates TLS by default, so the CLI can no longer connect to a local server out of the box cli#67 — Chronicle 16.20.0's TLS default). This package wants the 16.28.0 line through Arc 21.13.0.

PrivateAssets="all" alone does not fix it

Tried, and reverted: it produces a clean nuspec (both dependencies gone, everything still builds, all 254 specs pass), but the assembly it packages would then have unsatisfiable references.

Reading the AssemblyRef table of the Release build — specs stripped — with System.Reflection.Metadata:

Cratis.Arc            Cratis.Arc.Chronicle   Cratis.Arc.Core     Cratis.Arc.MongoDB
Cratis.Arc.Swagger    Cratis.Chronicle       Cratis.Chronicle.AspNetCore
Cratis.Chronicle.Connections                 Cratis.Chronicle.Infrastructure

and 557 type references into them — AggregateRoot, AggregateRootMutatorFactory, EventsCommandResponseValueHandler, the whole surface, in alphabetical sweeps. That is the shape of a type-discovery registration, not of code anyone wrote: no production file in Rendering.Cratis names an Arc or Chronicle type. The only mentions are string literals the renderer emits into generated files (builder.Using("Cratis.Chronicle.Events")), and those live in the #US heap as UTF-16 — Cratis.Arc.MongoDB appears twice as ASCII metadata and zero times as a literal, which is how you tell the two apart.

So ExcludeAssets="analyzers" on the two direct references is not stopping the generator: it still runs — presumably reaching the compilation through another contributor — and bakes the registration in. The csproj comment above already anticipates exactly this ("Cratis' type-discovery source generator would bake a registration into this assembly that binds the Cratis runtime at startup, which the renderer — a text generator — has no reason to do"); it just is not achieving it.

What closing this needs

1. Stop the generator running for this assembly — find which reference still contributes the analyzer and exclude it there too, then confirm the AssemblyRef table holds only Cratis.Screenplay, Cratis.Stage.Contracts, the template engine and the BCL.
2. Then mark Cratis and Cratis.Arc.MongoDB PrivateAssets="all", so the package declares only what the renderer needs to run.
3. Guard it: read the AssemblyRef table in a spec and assert on the set. It is four lines with System.Reflection.Metadata and it would have caught this the day it appeared.

Worth pairing with a decision on the template engine: Cratis.Templates + three Microsoft.TemplateEngine.* packages exist only to scaffold a target project on first render. A consumer that renders into a project it already has pays for all four, and pays MSBL001 if it also hosts MSBuild. Splitting scaffolding out of Rendering.Cratis would leave the renderer as what it claims to be — a text generator with no runtime.

[woksin]

Consumed it for real, and the cost is higher than the dependency list suggests — the two engines the package brings have opposite requirements about the same assembly.

Taking Cratis.Stage.Rendering.Cratis into the CLI (Cratis/cli#62, branch feat/render-root-command):

• the template engine brings NuGet.Frameworks, and Microsoft.Build.Locator — which the CLI hosts for screenplay generate — fails the build with MSBL001 while a copy of it sits beside the executable;
• applying the prescribed fix (ExcludeAssets="runtime" PrivateAssets="all") builds green and passes all 446 specs, and then rendering fails at runtime with Failed to install 'Cratis.Templates': … cannot be installed, because the template engine needs the assembly that was just excluded.

There is no third setting. A consumer can host MSBuild or scaffold from a template, not both.

It also moves Cratis.Chronicle to 16.26.0 behind Arc 21.13.0 while the consumer's own Cratis.Chronicle.Contracts pin holds at 16.19.3 — a mismatch that builds clean and passes every spec.

This is the strongest argument for the split floated at the end of the issue: scaffolding does not belong in the renderer. Rendering into a project that already exists needs no template engine at all, and that is the common case for regenerating from a document. A Rendering.Cratis carrying Cratis.Screenplay, Cratis.Stage.Contracts and the BCL would be consumable anywhere; today it is consumable only by something that hosts nothing else.

[woksin]

Related: #18 is the owner decision this measures. That issue asks whether Cratis.Stage.Rendering.Cratis should depend on Cratis publicly at all and lists three options; this one is what the status quo costs a real consumer, plus two corrections to that issue's framing — PrivateAssets="All" fails for a different reason than recorded there, and option 2 alone does not remove the template engine, which is what causes the runtime conflict. Posted the summary on #18 so the decision has the evidence beside it.

[einari]

@woksin If only the dependencies are used for running specs, we can conditionally include them only when compiling with Debug.

[woksin]

@einari Confirmed on #18 with the measurement — the Debug condition works, and it closes more of this issue than I credited it with.

Correcting myself on the second bullet above: I wrote that ExcludeAssets="analyzers" "is not stopping it — whatever contributes that analyzer reaches the compilation another way", and treated the generator as needing its own fix first. It reaches the compilation transitively, and ExcludeAssets on a direct reference does not cover that, so gating the references on Debug removes the generator with them. Release goes from nine Arc/Chronicle assemblies and 698 Cratis.* type references to zero and 90 — the 90 being Cratis.Screenplay and Cratis.Stage.Contracts, which are real.

Package validation also names what the generator was emitting: CP0001: Type 'Cratis.Arc.Generated.GeneratedMarker' exists on [Baseline] … but not on …. It is a public type in the published 2.3.0, so removing it registers as an API break and needs either a regenerated suppression or a deliberate acceptance.

So two of this issue's three costs are gone with that one condition: the global-usings leak (160 ambiguity errors in the CLI) and the baked-in runtime references. What remains is the template engine — NuGet.Frameworks against Microsoft.Build.Locator — which is the runtime conflict, and the reason Cratis/cli#62 still cannot land. That one is the "does render scaffold?" question rather than a packaging fix.

[woksin]

@einari Ran the whole thing end to end rather than leaving the last part as an argument, and it settles the scaffolding question.

The Debug condition, verified against a real consumer

I had claimed the narrowing removes the CLI's 160 ambiguity errors by reading which packages ship build props. Now measured: packed the branch to a local feed, pointed Cratis/cli#62 at it, and deleted the workaround it needed against the published package. Builds clean, zero warnings. The claim holds.

MSBL001 still fired, from the template engine, exactly as expected — so I traced where NuGet.Frameworks actually enters:

NuGet.Frameworks <- NuGet.Common <- NuGet.Configuration <- Microsoft.TemplateEngine.Edge <- Cratis.Stage.Rendering.Cratis

One path, and the whole NuGet. subtree hangs off it.* Nothing else in the CLI brings it.

So I built the renderer without the template engine, and rendered with it

Removed the four template packages and TemplateEngineProjectScaffolder, left IProjectScaffolder alone, and gave CreateDefault() a scaffolder that only creates the directory. The package becomes:

<dependency id="Cratis.Stage.Contracts" … />
<dependency id="Cratis.Screenplay" … />

Two dependencies. The CLI then builds with no workarounds at all — no Cratis reference, no NuGet.Frameworks exclusion, nothing in the spec project — and:

$ cratis render invoicing.play --target ./Invoicing
{"target":"…/Invoicing","documents":1,"notCarried":44}

33 C# files on disk, exit 0, and 44 lines on stderr naming everything the rendered application does not carry — constraints, specifications, queries, screens, the $context.tenant mapping whose declared type cannot hold a string. That is the first time the render arrow has run outside a spec.

What that says about "does render scaffold?"

It does not need to. Rendering placed 33 files into an empty directory perfectly well; scaffolding a .csproj around them is a separate job with a separate audience, and it is the only reason this package is unhostable. Splitting it out — wherever it lands, a …Rendering.Cratis.Scaffolding package or a cratis new — takes the renderer to two dependencies and unblocks #62 completely.

The three things standing between here and that, in order:

1. the Debug condition (done, on experiment/narrow-spec-references);
2. the CP0001 call — regenerate the ApiCompat suppression or accept removing Cratis.Arc.Generated.GeneratedMarker, plus the semver;
3. the scaffolding split.

I have not touched (3) beyond measuring it — the shape is yours to pick, and I did not want to build the wrong one. Say which and I will open it.

[einari]

@woksin Unclear if there is anything I need to give as input here

[woksin]

@einari No — nothing needed from you. That was me over-asking, twice; you'd already given the direction and I turned it back into questions. Proceeding, with the two calls made and both cheap to reverse at review:

One major, not two. The Debug condition and the scaffolding split both remove things from the package, so they go in together as a single deliberate Stage major rather than dribbling out as separate breaks. CP0001 gets a regenerated ApiCompat suppression — the tooling's own prescribed answer, and Cratis.Arc.Generated.GeneratedMarker is generator debris nobody can meaningfully consume.

The split shape I'm building, since one of the three had to be picked: IProjectScaffolder stays in Rendering.Cratis as the seam, TemplateEngineProjectScaffolder and its exceptions move to a new Cratis.Stage.Rendering.Cratis.Scaffolding package, and CratisRenderer.CreateDefault() keeps working but scaffolds nothing beyond the target directory. A caller that wants a project scaffolded takes the second package and passes the template-engine scaffolder in.

That keeps the capability, costs the renderer nothing, and is the reason render can be hosted beside screenplay generate at all. If you'd rather scaffolding leave the repo entirely and become cratis new, say so on the PR and I'll move it there instead — the seam is the same either way.