C#/.NET binding

This content is for 2026. Switch to the latest version for up-to-date documentation.

The C#/.NET surface is a downstream adapter, not a calculator engine. It exists to consume the shared public calculator contract and present the results in a .NET-friendly shape.

.NET strategy

Keep the .NET layer thin and contract driven.
Use the shared calculator contract for request and response shapes.
Do not duplicate formula logic, validation rules, or pricing-year semantics inside C#.
Treat the .NET surface as a packaging and integration concern, not a source of calculator authority.

Power Platform adjacency

Power Platform sits next to the .NET surface as an orchestration channel, not inside the calculator boundary.

Power Platform should call a secured service boundary or custom connector.
Any .NET component used alongside Power Platform must still respect the same contract boundary.
Do not let Power Platform or .NET become a second implementation of the calculator rules.

Contract boundary

The contract boundary is the stable interface between the calculator core and downstream runtimes.

C#/.NET consumes the public contract rather than owning it.
Shared request and response schemas stay runtime neutral.
Boundary failures should surface as structured contract errors, not as language-specific exceptions in public docs.

See the canonical contract in Public calculator contract.

NuGet packaging posture

NuGet packaging is future-gated.

Do not claim a public NuGet package until the dependency model, versioning, and release gates are explicit.
Treat package publication as a later milestone, not the baseline delivery surface.
For now, keep the documented posture focused on the contract and service boundary.