[HBartosch]

🚀 Pull Request: Routya.Core

---

📋 Summary

Makes the source generator work in multiple project solutions, which it previously could not, and fixes the type conflicts that arose once it did.

Three things, in dependency order:

1. Handlers in referenced assemblies are now discovered. The generator only ever saw handlers with a syntax tree in the compilation it was generating for. In the usual layered layout, where handlers live in an Application project and the generator runs in the Web or API project, every handler was invisible and AddGeneratedRoutya registered nothing.
2. The generated handler lifetime is now configurable, through AddGeneratedRoutya(ServiceLifetime) and a per handler [RoutyaHandler(ServiceLifetime)] attribute. It was hardcoded to Transient with no way to change it.
3. Only the project that composes the container generates a dispatcher. Fixing item 1 exposed a defect already shipped in 4.0.0: every project referencing the generator emitted its own Routya.Generated.IGeneratedRoutya, and they collide.

Released as 4.1.0. One behavioural change, documented under Upgrade notes in the changelog.

🔍 Related Issues (If Any)

None.

🛠️ Changes Made

• Request/notification handler logic
• Pipeline behavior changes
• Dispatcher performance or safety
• DI registration improvements
• Unit tests added or updated
• Benchmarks updated (if performance-related)

Benchmarks are unchanged because the dispatch path is untouched. Every change here is in generation time behaviour, registration, or documentation.

✅ Checklist

• Code compiles and passes unit tests
• No breaking changes introduced (or documented)
• Docs/readme updated if needed
• Follows Routya code style and conventions
• Scoped vs root resolution behavior remains correct

---

The dispatcher conflict, in detail

Routya.Generated is a fixed, public namespace, so two assemblies in one reference chain cannot both define IGeneratedRoutya. Every project that referenced the generator and declared a handler emitted its own copy, so a layered solution produced CS0436 at every level. The compiler resolves that conflict in favour of the source declaration, which is the part that matters: a caller could silently bind to a dispatcher other than the one the application registers at startup.

This is a defect in released 4.0.0, not one introduced by this branch. Measured on a three project probe, App to Api to Tests, each declaring a handler:

	released main	this branch before the fix	this branch now
CS0436 warnings	16	8	0
what Tests registered	its own handler	all four in the chain	nothing

How it is resolved

Generation is gated on the compilation calling AddGeneratedRoutya. Detection is purely syntactic, which is what makes it self consistent: the method being called is itself generated, so it cannot be bound before the decision to generate has been taken.

RoutyaGenerateDispatcher overrides the decision in either direction. It ships in both build and buildTransitive, because build alone would not reach anyone installing the Routya meta package, which is how most consumers get the generator.

Two diagnostics keep the behaviour discoverable rather than silent. ROUTYA008 (Info) explains that a project with handlers generated nothing because it composes no container, which is the normal shape for a library project. ROUTYA009 (Warning) reports two assemblies in one chain both generating, and names the property that resolves it.

Who this breaks

A project that used IGeneratedRoutya but did not call AddGeneratedRoutya in that same project previously got a dispatcher anyway and now gets nothing, so those injection sites stop compiling. That shape was already producing CS0436 and could bind to the wrong dispatcher, so it was not working correctly before. Both remedies are in the changelog's Upgrade notes table.

This is why 4.1.0 rather than 4.0.1, and the argument against 5.0.0 is that the affected shape was broken rather than supported, and one line of MSBuild restores the old result.

---

🧪 Manual Testing Notes

Reproduced before fixing. A three project probe outside the repository, App to Api to Tests, each referencing the generator and declaring a handler. The same probe was then built against released main to establish whether the defect was pre-existing. It was.

Verified after fixing. Zero warnings, with only the composition root generating and its dispatcher covering all three assemblies' handlers. The ROUTYA009 path and its documented remedy were both exercised, including confirming that the RoutyaGenerateDispatcher property actually reaches the compiler.

Packaging verified. dotnet pack inspected to confirm both build/ and buildTransitive/ props land in the nupkg, and that the meta package pins both dependencies at 4.1.0.

Every demo was run, not merely built. The four console demos exit zero. The generator Web API demo was exercised across all eight of its endpoints. The two lifetime claims in the README were checked against the running API: the Scoped handler behind GET /customers/{id} returned a different instance id on each of three requests, and the Singleton handler behind GET /status returned the same one each time. The .NET Framework 4.8 demo builds.

Tests. 150 passing across the three suites, 64 plus 32 plus 54. Solution builds with 0 errors and 5 warnings, all pre-existing nullable field warnings in Routya.Benchmark.

💬 Additional Context

Two problems found while checking documentation, both predating this work.

The generator README claimed internal handlers are ignored. They are not, and have not been since accessibility filtering was removed from discovery. Internal handlers are registered and dispatched normally; what an internal type cannot have is a typed member on the public IGeneratedRoutya, which is what ROUTYA005 reports.

Routya.SourceGen.Demo still used IRequest<IAsyncEnumerable<T>> for its streaming example, so the demo most people run first taught the shape 4.0.0 replaced. It is ported, and gains a StreamLoggingBehavior so its output interleaves production, observation and consumption with elapsed timings. That makes the reason the two behavior interfaces are separate visible rather than merely asserted.

Three known vulnerabilities cleared, all transitive dependencies of demo and test projects rather than anything Routya ships: Microsoft.AspNetCore.OpenApi to 10.0.12, Microsoft.Data.Sqlite to 8.0.31, and xunit to 2.9.3. dotnet list package --vulnerable --include-transitive now reports nothing across every project.