A DocumentDbContext whose class name does not end in "Context" gets no generated code and no diagnostic; its collections stay null #300
Description
The source generator only looks at classes whose name ends in Context. A DocumentDbContext subclass named anything else (Shop, AppDb, Store, CatalogDb) gets no generated code, and the build reports nothing. Its collection properties stay null, and the first call throws NullReferenceException, far from the cause.
The README used such a name itself until #298 (new AppDb(...) in the master-key and multi-process samples), which is how this was found.
Repro
public class Customer { public ObjectId Id { get; set; } public string Name { get; set; } = ""; }
public partial class ShopContext : DocumentDbContext
{
public DocumentCollection<ObjectId, Customer> Customers { get; set; } = null!;
public ShopContext(string path) : base(path) { }
}
public partial class Shop : DocumentDbContext // same body, different name
{
public DocumentCollection<ObjectId, Customer> Customers { get; set; } = null!;
public Shop(string path) : base(path) { }
}
await using var ok = new ShopContext("a.db"); // ok.Customers is set
await using var db = new Shop("b.db"); // db.Customers is null
await db.Customers.InsertAsync(new Customer { Name = "Ada" }); // NullReferenceExceptionBuild with -p:EmitCompilerGeneratedFiles=true: the generator emits GenCheck.ShopContext_Program.Mappers.g.cs and nothing for Shop; no BLITE diagnostic.
Expected: a class that derives from DocumentDbContext is generated whatever its name, or the build says why it is not.
Actual: silently skipped.
Where in the code (0450b97)
MapperGenerator.IsPotentialDbContext(src/BLite.SourceGenerators/MapperGenerator.cs:492-499) filters onclassDecl.Identifier.Text.EndsWith(BLiteConventions.DbContextClassSuffix), withDbContextClassSuffix = "Context"(src/BLite.SourceGenerators/Helpers/BLiteConventions.cs:13). The filter has been there since the generator's first version (219efaa, v1.0.0).GetDbContextInfo(MapperGenerator.cs:805-813) then checks semantically that the class inherits fromDocumentDbContext, so the name filter is only a cheap pre-filter, and it drops real contexts.- Neither the README nor the XML docs of
DocumentDbContextmention the naming rule.
Suggested fix
- Drop the name condition from the syntax predicate (
ClassDeclarationSyntaxwith aBaseListis cheap enough; the semantic check already decides), or - keep it as a fast path, and report a warning (BLITE00x) for any class that derives from
DocumentDbContextbut was skipped, naming the rule. - Test: a context named without the suffix is generated (or the diagnostic is reported), in the generator tests.
Related: #152 (contexts in the global namespace, the same kind of silent skip), #298.
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsDone
Activity
mrdevrobot commentedon Oct 18, 2026
Reproduced on 0450b97: a context named
Shopbuilds with no diagnostic and its collections are null. Medium.fix(generator): discover a DocumentDbContext whatever its class name (#…