cCoder.CodeAnalysis.Contracts 2026.9.30.859

cCoder.CodeAnalysis

View the latest code coverage report

cCoder.CodeAnalysis analyses C# projects against the architectural and coding conventions defined by The Standard. It reports findings through normal compiler diagnostics and produces a portable architecture document for tooling and visualisation.

Installation

Add one package reference to each project that should be analysed:

<PackageReference Include="cCoder.CodeAnalysis" Version="2026.7.22.0000" />

No separate analyzer or build-task package is required. Building the project activates the compiler analyzer and, for non-test projects, generates project.stxjson beside the project file.

The package currently requires the .NET 10 SDK for its build integration.

Runtime libraries that implement IUtilityBroker or ICompositionExposure must also reference the lightweight contracts package directly:

<PackageReference Include="cCoder.CodeAnalysis" Version="2026.7.22.0000" PrivateAssets="all" />
<PackageReference Include="cCoder.CodeAnalysis.Contracts" Version="2026.7.22.0000" />

The contracts package contains only the runtime marker interfaces. Keeping it separate prevents applications from loading the Roslyn-based analyzer assembly to resolve a marker implemented by a runtime library.

Build behaviour

During a normal build the package:

1. Analyses the Roslyn compilation.
2. Emits each analysis item as an STX compiler diagnostic, making it visible in build output and the Visual Studio Error List.
3. Generates project.stxjson after a successful non-test build.
4. Avoids rewriting an unchanged architecture document.

Projects with IsTestProject set to true are still analysed, but do not produce an architecture document.

Generation can be disabled or redirected when required:

<PropertyGroup>
  <cCoderCodeAnalysisGenerateArchitecture>false</cCoderCodeAnalysisGenerateArchitecture>
  <cCoderCodeAnalysisArchitecturePath>$(MSBuildProjectDirectory)\architecture\project.stxjson</cCoderCodeAnalysisArchitecturePath>
</PropertyGroup>

Architecture document

The generated document contains:

• Classes and their Standard element types.
• Properties, methods, inputs, and fully qualified type names.
• Directed links between internal types.
• Analysis items including rule code, description, type, and source line.

Enum values are serialized as readable strings. Source paths are relative to the project containing project.stxjson, allowing the document to be moved with the project and consumed directly by Visual Studio or browser-based diagramming tools.

Standard element types

The model recognises the principal layers used by The Standard, including:

• Brokers and dependencies
• Foundation services
• Processing services
• Orchestration services
• Coordination services
• Management services
• Aggregation services
• Exposures and controllers
• Models
• Tests

Rules cover architectural dependencies, public contracts, exception handling, validation, naming, asynchronous operations, controller behaviour, test structure, source layout, and formatting.

Cardinality-aware method names

STX0028 requires a method that names its returned cCoder model or contract to use the singular subject for one result and the plural subject for a sequence. The rule resolves return types semantically, unwraps Task<T>, ValueTask<T>, and ActionResult<T>, and recognises arrays and standard collection/query contracts. Framework and third-party subjects, string, byte[], and methods that do not name their returned subject are outside its scope.

Plural names use a deterministic English inflection policy, including common irregular forms such as Person/People and unchanged terms such as Metadata.

Models are data carriers only. STXM001 rejects every explicitly declared method-like member, including instance and static constructors, destructors, operators, conversions, and overrides.

Runtime use

The architecture builder can also be resolved through dependency injection when analysis is needed programmatically:

ServiceCollection services = new ServiceCollection();
services.AddCodeAnalysis();

using ServiceProvider serviceProvider = services.BuildServiceProvider();
IArchitectureBuilder architectureBuilder = serviceProvider
    .GetRequiredService<IArchitectureBuilder>();

Architecture architecture = architectureBuilder.Generate(
    path: projectPath);

Building the repository

dotnet restore src/cCoder.CodeAnalysis.slnx
dotnet build src/cCoder.CodeAnalysis.slnx -c Release --no-restore
dotnet test src/cCoder.CodeAnalysis.Tests/cCoder.CodeAnalysis.Tests.csproj -c Release --no-build
dotnet test src/cCoder.CodeAnalysis.Sample.Tests/cCoder.CodeAnalysis.Sample.Tests.csproj -c Release --no-build
dotnet pack src/cCoder.CodeAnalysis.Contracts/cCoder.CodeAnalysis.Contracts.csproj -c Release --no-restore
dotnet pack src/cCoder.CodeAnalysis/cCoder.CodeAnalysis.csproj -c Release --no-restore

The sample projects provide known valid and deliberately invalid code used to verify every analysis rule. Deliberate rule violations are expected to appear as compiler warnings during repository builds.