Repository navigation
JasperFx 2.75.2
A patch release. One user-facing diagnostic fix that neither 2.75.0 nor 2.75.1 helps with, plus a new build warning.
⚠️ "No source-generated dispatcher found" was telling you the wrong cause
If you hit that exception on a projection registered as Snapshot<T>(), SingleStreamProjection<T, TId> or AggregateStream<T>, the message said:
The JasperFx.Events source generator DID run over assemblies YourApp and Marten, so it saw the aggregate YourApp.MyAggregate and declined it — this is a code-shape problem, not a build configuration one.
For that registration shape the verdict was inverted. The projection type is the store's own generic, so its assembly is Marten.dll — and Marten's build runs the generator, so that assembly always carries the marker #887 introduced. The verdict was therefore pinned to "the generator ran" for the commonest registration shape in the product, and you were sent to audit your aggregate's method shapes while being explicitly told that the cause you actually had was not the cause.
marten#5495 is exactly this shape. #887 was filed out of it, so as shipped it would have misdirected the very reporter it was written for — and for this shape it was worse than the nine-line hedge it replaced, which at least named the csproj cause among the others.
Neither earlier release helps: AggregateApplication.cs is byte-identical across 2.75.0 and 2.75.1. If you are debugging a missing dispatcher, this is the bump you want.
Fixed by excluding constructed generic projection types from the evidence. Deliberately not by requiring confirmation everywhere: a user-declared MyProjection : SingleStreamProjection<Agg, Guid> in its own assembly really does get a projection-specific evolver emitted there, so confirmation in that assembly stays genuine evidence — a fact now guards that case explicitly. #906.
A double-loaded source generator is now reported
Two copies of JasperFx.Events.SourceGenerator in one compilation emit byte-identical file paths, and the file-scoped evolvers mangle to the same name, so the build fails with
error CS0433: The type 'XEvolver' exists in both 'YourAssembly' and 'YourAssembly'
— one assembly named twice, which is the fingerprint. Nothing in that message mentions the generator, the two copies, or the remedy.
2.75.0's MSBuild target already prevented this by keeping one copy, but the states that actually produce the CS0433 are the ones where that target did not run — and there it said nothing. Detection is now separate from the fix: JasperFxEventsDedupeSourceGeneratorAnalyzers=false opts out of the dedupe, not the diagnosis, and a duplicate now warns JFXEVT902 naming both paths, the error to expect, and the remedy (a store package bundles the analyzer, so dropping a direct PackageReference on JasperFx.Events.SourceGenerator usually resolves it).
Stated plainly, because it is a real limit: that covers MSBuild builds only. A consumer on a JasperFx.Events predating the target, or a compilation running no MSBuild targets, reaches the same CS0433 with nothing of ours present to warn. So the generated marker file now carries a header explaining the error — which reaches those cases, because the generator running twice is what a double load is, so that file exists in exactly the states where the CS0433 happens. #902.
Build infrastructure
The shipped JasperFx.Events.targets is now imported and exercised by ./build.sh Test in six arrangements (#908). It ships as buildTransitive, so it reaches every consumer of the stack transitively — but as <None> rather than an <Import>, so our own build never loaded it and could not tell whether it was even well-formed XML. A malformed version passed the entire suite here while breaking every consumer's build, which is not hypothetical: it happened once while writing the JFXEVT902 warning above, and was caught by hand. Now it is caught by CI. No packaged content changed.
Still open downstream
Unaffected by this patch: JasperFx/marten#5517, JasperFx/polecat#682, JasperFx/fisher#336 — enrollment of 2.75.0's DocumentConjoinedTenancyCompliance, plus replaying 2.75.1's new ComplianceStoreConfig.AddCommitListener in each event fixture.