Overview
C# and the .NET ecosystem occupy a specific position in our technology stack — the language and framework we reach for when the problem involves complex business logic, enterprise system integration, Windows-hosted services, or the rich library ecosystem that .NET provides for specific domains. Where Rust handles the performance-critical data processing and real-time computation layers, C# handles the layers above: the API services that expose business functionality, the integration code that connects to ERP systems and broker APIs, the document generation that produces formatted outputs, and the complex workflow logic that orchestrates multi-step business processes.
ASP.NET Core is a mature, high-performance web framework that produces reliable, maintainable API backends and services for the business systems we build. The .NET ecosystem provides production-quality libraries for virtually every enterprise integration requirement — AFAS and Exact Online connectivity, HL7 FHIR and v2 for healthcare, FIX protocol for institutional trading, OpenXML for document generation, and the cryptographic and data processing libraries that production systems depend on. These are not capabilities we build from scratch — they are battle-tested ecosystem components that .NET provides, allowing us to focus on the business logic rather than the infrastructure.
C# is also the language in which MetaTrader DLL bridges are most naturally built — the C++ ABI-compatible interface that MetaTrader's DLL mechanism requires is most cleanly implemented in C# with P/Invoke, extending MetaTrader's capabilities with external system connectivity that MQL alone cannot provide.
Where We Use C# and .NET
ERP and business system integration. The majority of ERP integrations we build — AFAS, Exact Online, SAP, Microsoft Dynamics — are implemented primarily in C#. The .NET HTTP client ecosystem provides clean, type-safe REST API consumption. The AFAS .NET SDK, the Exact Online API client libraries, and the SAP .NET Connector (NCo) are all native .NET components that integrate naturally with C# application code. Complex integration logic — the data transformation, the field mapping, the business rule application that converts data from one system's model to another — is implemented in C# where the type system and the testing framework make it verifiable.
Complex business logic and workflows. Multi-step workflows with conditional branching, approval processes, document lifecycle management, and the orchestration of multiple system interactions are naturally expressed in C#. The language's strong typing, its support for async/await patterns, and its rich standard library make it well-suited for the kind of procedural and object-oriented business logic that enterprise applications require. Where Rust's strengths are in performance and systems programming, C#'s strengths are in expressive, maintainable business logic — the code that non-performance-critical but correctness-critical business rules are most clearly expressed in.
Document generation. OpenXML for Word and Excel document generation, iTextSharp and PDFsharp for PDF creation, EPPlus for Excel spreadsheet generation — these are all .NET ecosystem components that C# consumes directly. The invoice generation that produces a correctly formatted PDF from a trade record, the contract generation that populates a Word template with tenancy data, the Excel report that produces a formatted spreadsheet from a query result — all naturally implemented in C# with the rich document generation library ecosystem that .NET provides.
Healthcare and regulated industry integrations. HL7 FHIR and HL7 v2 processing — NHapi for HL7 v2 message parsing and construction, the HL7 FHIR .NET SDK for FHIR resource handling — are .NET libraries that make C# the natural implementation language for healthcare data integrations. The MLLP transport layer for HL7 v2, the FHIR server implementation with its complex resource management and search parameter handling — these are implemented in C# where the healthcare-specific library ecosystem is most mature.
Institutional trading connectivity. The Interactive Brokers .NET API (IBApi) for TWS connectivity, the FIX protocol implementation for institutional broker connectivity, and the MetaTrader Manager API bridge for prop firm risk monitoring — these are all naturally implemented in C# where the relevant SDK or protocol implementation is most complete and most actively maintained in the .NET ecosystem.
Windows service hosting. For applications that need to run as Windows services — the monitoring agent that watches MetaTrader accounts and reports to a central risk system, the scheduled data synchronisation service that runs as a background Windows service, the integration service that processes incoming EDI messages — C# with .NET's hosting infrastructure provides the cleanest implementation. The Generic Host pattern in .NET provides the service lifecycle management, the configuration infrastructure, and the dependency injection that production Windows services require.
ASP.NET Core for API Backends
ASP.NET Core is our primary framework for C# API backends — the REST APIs that serve the business logic to frontend applications, the webhook receivers that process incoming events from external systems, the integration APIs that expose business functionality to connected platforms.
Minimal APIs and controller-based APIs. ASP.NET Core's minimal API model for lightweight, high-performance HTTP endpoints where the overhead of the full MVC controller infrastructure is unnecessary. The controller-based API model for applications with complex routing, action filtering, and the full ASP.NET Core middleware pipeline that more sophisticated API backends require. The choice between minimal and controller-based is made per application based on its complexity and the features of the full MVC pipeline that it needs.
Dependency injection and service architecture. ASP.NET Core's built-in dependency injection container provides the service registration and resolution infrastructure that clean application architecture requires. Services registered with appropriate lifetimes — singleton for stateless services, scoped for per-request services, transient for short-lived operations — with the dependency graph that the container resolves automatically at runtime. Interface-based service definitions that allow test doubles to be injected in test environments.
Authentication and authorisation. ASP.NET Core's authentication middleware for JWT bearer token validation, API key authentication, and the OAuth 2.0 / OpenID Connect flows that Auth0 and other identity providers use. Policy-based authorisation that defines access control rules in terms of claims and requirements rather than roles alone. The authentication and authorisation infrastructure that every production API needs to handle correctly.
Middleware pipeline. The ASP.NET Core middleware pipeline that processes requests through a configurable sequence of components — the HTTPS redirection middleware, the request logging middleware, the exception handling middleware, the rate limiting middleware — before they reach the application's endpoint handlers. Custom middleware for application-specific cross-cutting concerns: request correlation ID propagation, audit logging, tenant resolution in multi-tenant applications.
Background services. Hosted services and background workers in ASP.NET Core for long-running background processing — the message queue consumer that processes incoming webhook events, the scheduled job runner that executes periodic data synchronisation tasks, the data pipeline stage that continuously processes incoming records. The IHostedService and BackgroundService base classes that provide the clean lifecycle management that production background services require.
C# in the Broader Stack
C# rarely operates in isolation — it is the integration and business logic layer in systems where Rust handles performance-critical processing, React/Next.js handles the frontend, and various external systems handle their specific domains.
Rust/C# boundary. In systems where Rust provides the high-performance computation and C# provides the business logic, the Rust/C# boundary is typically an HTTP API or a message queue. The Rust service exposes a REST API or publishes to a message queue; the C# service consumes the API or subscribes to the queue. This boundary keeps the two components independently deployable and testable while allowing each to handle the layer it is best suited for.
C# as the integration hub. In many of the systems we build, C# is the integration hub — the component that receives data from one system, applies business logic, and delivers results to another. The AFAS integration service that reads new employee records, applies the transformation to the target format, and posts to the downstream system. The HL7 message processor that receives an HL7 v2 ADT message, parses it using NHapi, applies the patient identity matching logic, and writes the result to the patient database. The document generation service that receives a template data model, generates the formatted document using OpenXML, and returns the byte stream for storage or delivery.
Testing. xUnit and MSTest for unit and integration testing of C# code. Moq for mock object creation in unit tests. The ASP.NET Core test host for integration testing of API endpoints without requiring an actual HTTP server. The test infrastructure that makes C# business logic and integration code verifiable before deployment.
Specific .NET Libraries We Use
The .NET ecosystem's breadth is one of the primary reasons C# is our choice for integration and business logic work. Libraries we regularly depend on:
Integration and protocols. NHapi (HL7 v2), HL7 FHIR .NET SDK (FHIR R4/R5), IBApi (Interactive Brokers TWS), QuickFIXn (FIX protocol), AFAS and Exact Online REST client libraries, SAP .NET Connector (NCo).
Document generation. OpenXML SDK (Word and Excel), EPPlus (Excel), iTextSharp / iText7 (PDF), PdfSharp (PDF), SixLabors.ImageSharp (image processing).
Data access and ORM. Entity Framework Core (ORM for SQL databases), Dapper (lightweight micro-ORM for performance-sensitive queries), Npgsql (PostgreSQL driver), MySql.Data / MySqlConnector (MySQL driver), Microsoft.Data.SqlClient (SQL Server driver).
Serialisation and parsing. System.Text.Json (primary JSON serialisation), Newtonsoft.Json (complex serialisation scenarios), CsvHelper (CSV parsing and generation), YamlDotNet (YAML processing), AngleSharp (HTML parsing).
HTTP and messaging. HttpClientFactory (managed HTTP client lifecycle), Refit (type-safe HTTP client generation), MassTransit (message bus abstraction for RabbitMQ and Azure Service Bus), Azure.Messaging.ServiceBus, Confluent.Kafka (.NET Kafka client).
Cryptography and security. BouncyCastle (cryptographic operations beyond the standard library), Microsoft.IdentityModel.JsonWebTokens (JWT handling), BCrypt.Net-Next (password hashing).
Technologies Used
- C# 12 / .NET 8 — current language version and runtime for new development
- ASP.NET Core — web framework for API backends and web services
- Entity Framework Core — ORM for database access
- xUnit / MSTest — testing frameworks
- NHapi — HL7 v2 message processing
- HL7 FHIR .NET SDK — FHIR resource handling
- OpenXML SDK / EPPlus — document generation
- IBApi / QuickFIXn — trading platform connectivity
- Npgsql / MySqlConnector — database drivers
- MassTransit — message bus abstraction
- Docker / containerisation — deployment packaging
C# Where the Ecosystem Earns Its Value
The case for C# is not raw performance — Rust handles the performance-critical layers. The case for C# is the combination of a productive, type-safe language and the deepest enterprise library ecosystem available in any programming language. When the integration target is an ERP system with a .NET SDK, when the document format is Office XML with a .NET generation library, when the protocol is HL7 with mature .NET parsing libraries, when the broker API is a .NET assembly — C# is the language where the ecosystem pays its cost in the most direct way. The integration that would require building the protocol handling from scratch in another language uses a production-quality library in C#. The productivity benefit is real, and it shows up in delivery time and in the reliability of the resulting implementation.