Skip to content

Fix bug 616: Not possible to use Serializable transactions - #626

Merged
jeremydmiller merged 1 commit into
JasperFx:masterfrom
tim-cools:616-not-possible-to-use-serializable-transactions-fix
Nov 28, 2016
Merged

Fix bug 616: Not possible to use Serializable transactions#626
jeremydmiller merged 1 commit into
JasperFx:masterfrom
tim-cools:616-not-possible-to-use-serializable-transactions-fix

Conversation

@tim-cools

Copy link
Copy Markdown
Contributor

No description provided.

@jeremydmiller
jeremydmiller merged commit aa90044 into JasperFx:master Nov 28, 2016
@tim-cools
tim-cools deleted the 616-not-possible-to-use-serializable-transactions-fix branch November 29, 2016 08:30
jeremydmiller added a commit that referenced this pull request Aug 6, 2026
…ed-types fix

The generator registers an EventProjection's discovered published document types
(#4166) by writing into the user's partial class. It used to do that by emitting a
parameterless constructor, which fails for exactly the projections that need
dependencies injected -- the ones registered through AddProjectionWithServices.

A primary constructor made it a build break: C# requires every other constructor to
chain through the primary one, so `partial class MyProjection(ILogger logger) :
EventProjection` failed to compile with CS8862 inside the generated
<T>.TypeRegistration.g.cs. That is what #5192 reported.

An ordinary injected constructor made it a silent no-op: the container calls the
dependency-taking constructor, so the generated parameterless one never ran and the
published types went unregistered -- which also left #626's teardown
registration nothing to register.

#637 moves registration onto an override of ProjectionBase.PublishedTypes(),
which does not care how the instance was constructed.

Only the source generator pin moves, 2.41.0 -> 2.42.1. It is analyzer-only, declares
no dependencies, and Marten bundles its dll into Marten.nupkg, so its version is
independent of the runtime family's -- which stays at 2.41.0 until Marten adopts the
strong-typed identity compliance suite from 2.42.0. The generator is byte-identical
from 2.38.0 through 2.42.0, so this is an isolated swap of that one fix.

The regression test covers both shapes. The primary-constructor half is enforced by
compilation itself: against the older generator the test file does not build, with
the same CS8862 the issue reported.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VpDCvJcBDZerieJB4JEHde
jeremydmiller added a commit that referenced this pull request Aug 6, 2026
…ed-types fix (#5196)

The generator registers an EventProjection's discovered published document types
(#4166) by writing into the user's partial class. It used to do that by emitting a
parameterless constructor, which fails for exactly the projections that need
dependencies injected -- the ones registered through AddProjectionWithServices.

A primary constructor made it a build break: C# requires every other constructor to
chain through the primary one, so `partial class MyProjection(ILogger logger) :
EventProjection` failed to compile with CS8862 inside the generated
<T>.TypeRegistration.g.cs. That is what #5192 reported.

An ordinary injected constructor made it a silent no-op: the container calls the
dependency-taking constructor, so the generated parameterless one never ran and the
published types went unregistered -- which also left #626's teardown
registration nothing to register.

#637 moves registration onto an override of ProjectionBase.PublishedTypes(),
which does not care how the instance was constructed.

Only the source generator pin moves, 2.41.0 -> 2.42.1. It is analyzer-only, declares
no dependencies, and Marten bundles its dll into Marten.nupkg, so its version is
independent of the runtime family's -- which stays at 2.41.0 until Marten adopts the
strong-typed identity compliance suite from 2.42.0. The generator is byte-identical
from 2.38.0 through 2.42.0, so this is an isolated swap of that one fix.

The regression test covers both shapes. The primary-constructor half is enforced by
compilation itself: against the older generator the test file does not build, with
the same CS8862 the issue reported.


Claude-Session: https://claude.ai/code/session_01VpDCvJcBDZerieJB4JEHde

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants