C#/.NET binding
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
Section titled “.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
Section titled “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
Section titled “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
Section titled “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.