Graphtia documentation · reference
.NET framework analysis: ASP.NET Core, DI, EF Core and gRPC
See how Explorer recognizes ASP.NET Core, Built-in .NET dependency injection, Entity Framework Core, gRPC .NET, which source relationships it exposes, and what remains outside static coverage.
These adapters add framework structure to the language index. The sections below separate detection, supported relationships, required source context and limits.
Explore an example: ASP.NET Core · Built-in .NET dependency injection · Entity Framework Core · gRPC for .NET
Official .NET-enabled Explorer builds include Graphtia’s Roslyn-backed C# analyzer. No separate analyzer installation is needed. Framework analysis uses the C# symbols and project/source context produced by that included analyzer.
ASP.NET Core
Connect supported controllers and Minimal API declarations to their handlers, with static groups, endpoint metadata and middleware registrations.
What endpoint does this Minimal API group declare?
Evidence to inspect- MapGroup /api to GET /api/ordersstatic prefix
- GET /api/orders to ListOrders handlerhandler binding
- GET /api/orders to Produces metadatadeclared response metadata
Inspect a literal group and route, its exact handler and source-declared response metadata before changing an API.
Dynamic routes, runtime model binding and effective authorization remain unverified. Endpoint metadata states what the source declares; it does not verify the response or access policy.
How it is recognized
Web SDK/package/namespace or WebApplication source evidence.
Relationships you can inspect
Controller attributes, verb/path alternatives and parameter roles.
MapGet/Post/Put/Delete/Patch/Methods, named/lambda handlers and nested literal MapGroup.
WithName/WithTags, authorization declarations, Produces/Accepts and lexical middleware registrations.
Required source context
Literal route data and exact accepted handler evidence.
Coverage limits
Authorization metadata is partial and does not prove access decisions.
Dynamic paths/transformers, convention-only discovery, runtime model binding and control-flow-dependent middleware remain unresolved.
Built-in .NET dependency injection
Inspect service registrations, lifetimes and constructor dependencies without running the container.
Does this constructor dependency have one supported static binding?
Evidence to inspect- IClock constructor parameter to Static binding evidencedepends on
- Static binding evidence to Clock implementationunique binding
- AddSingleton registration to Static binding evidenceregistration evidence
Follow a constructor parameter through a uniquely matching registration. Multiple matching registrations remain unresolved rather than becoming a confirmed choice.
Factories, keyed services, replacements and disposal behavior remain partial or unevaluated. One matching registration supports the binding; the runtime container is not executed.
How it is recognized
Recognized DI package/using or IServiceCollection/builder.Services source evidence.
Relationships you can inspect
Singleton/scoped/transient, TryAdd/enumerable, hosted-service and open-generic declarations.
Supported keyed/options/factory/instance metadata; constructor dependencies bind only to a unique exact static registration.
Required source context
Exact registration and constructor/service identities.
Coverage limits
Factories, keyed services and options are partial.
Ambiguous registrations do not become many-to-many confirmed bindings; factory execution, replacement and disposal behavior are not inferred.
A supported constructor dependency can bind to one recognizable registration. Several candidates remain unresolved.
builder.Services.AddSingleton<IClock, Clock>();Constructor parameter: IClock clock
services.AddScoped<IClock, FirstClock>();
services.AddScoped<IClock, SecondClock>();Constructor parameter: IClock clock
These are static relationships, not observed calls or a simulation of the running dependency-injection container.
Inspect these relationships through the existing graph and source evidence. A unique supported constructor binding can identify an implementation; several matching registrations remain unresolved candidates. There is no separate dependency-injection tab or simulation of the running container implied here.
Entity Framework Core
Explore explicit DbContext/DbSet and entity-model declarations, including supported annotations, Fluent API mappings and relationships.
Which entity and relationship does this context declare?
Evidence to inspect- Store DbContext to DbSet of Orderdeclared set
- DbSet of Order to Order entityentity type
- Order entity to Customer relationship targetmodel relationship
- Order entity to Declared orders mappingmapping metadata
Inspect explicit DbSet and model mappings, including supported relationships, while separating model structure from database behavior.
No LINQ-to-SQL execution, applied migration state, query plan or general ORM-to-DDL linking is established. These boxes describe the EF model; the mapping box is not proof of a deployed or indexed SQL table.
How it is recognized
Recognized Microsoft.EntityFrameworkCore project or namespace evidence.
Relationships you can inspect
Contexts, DbSet<T>, entity annotations, Fluent API, mappings, owned types and relationships.
Partial inheritance/migration declarations; raw-SQL API boundaries and converter registrations where explicitly visible.
Required source context
Entities need explicit EF evidence; unrelated C# classes remain ordinary language facts.
Coverage limits
Inheritance and migration coverage are partial; migrations are not executed.
No live schema, SQL translation/execution, applied migration state, provider behavior or query-plan proof; not general ORM-to-DDL reconciliation.
gRPC .NET
Inspect supported generated service/client declarations, registration and statically visible streaming shapes.
Which generated service is registered and which method overrides its RPC?
Evidence to inspect- Generated OrdersBase to OrdersService implementationgenerated base
- OrdersService implementation to GetOrder overrideRPC override
- MapGrpcService registration to OrdersService implementationregistration evidence
Review generated-base inheritance, accepted RPC overrides and explicit service registration.
Message schemas, runtime addresses, interceptors and observed streaming behavior are not proved. Registration supports the declared provider; an override alone is not a running service.
How it is recognized
Recognized gRPC project/namespace, MapGrpcService or GrpcChannel source evidence.
Relationships you can inspect
Generated *Base inheritance and RPC overrides; MapGrpcService<T> registration.
Generated client uses and AddGrpcClient<T> declarations.
Static unary/client-stream/server-stream/bidirectional signatures as declaration evidence.
Required source context
Generated binding source and exact service/RPC identity; registration is required to promote a provider.
Coverage limits
Standalone Proto parsing, message schemas and runtime calls are unavailable.
Runtime addresses, channels, interceptors and observed stream delivery are not proved.
How to interpret a result
Inspect the source location, revision and relationship kind. A recognized registration is static evidence; it does not establish runtime behavior or compatibility with every framework release. Unresolved or ambiguous targets should remain part of your review.