Skip to main content

C# SDK Design and Methodology

Introduction

Welcome to liblab's C# SDK guide! This page explores our approach to SDK generation for C#, covering configuration options and best practices to help you generate efficient C# SDKs with liblab. Our C# SDK generation methodology prioritizes performance, strong typing, and idiomatic C# patterns, making the resulting SDKs easy for developers to integrate with any .NET project.

liblab's C# SDK Methodology

liblab's C# SDK is designed with C# principles in mind. We focus on:

  • Strong Typing: Our SDK generator leverages C#'s static typing system to provide compile-time safety and enhanced IDE support.
  • Async-First Design: We prioritize modern asynchronous patterns to ensure scalable and responsive applications.
  • Idiomatic C#: By following C# conventions and best practices, we ensure the generated SDKs feel natural to .NET developers.
  • Minimal Dependencies: SDKs are designed to work with the standard .NET libraries, minimizing external dependencies.

C# SDK Core Features

Our C# SDK generation includes these core features:

  • Adherence to C# Conventions: We generate SDKs that follow standard C# naming conventions and patterns, including PascalCase for public members and async/await patterns for asynchronous operations.

  • Comprehensive XML Documentation: We enhance developer experience with auto-generated XML documentation comments, IntelliSense support, and integration-ready code samples.

  • Native .NET Types: We use built-in .NET types and serialization mechanisms to ensure seamless integration with existing .NET projects.

  • Input and Output Validation: We simplify input handling and ensure data integrity using built-in validation attributes and mechanisms. Input data is automatically validated against rules derived from the OpenAPI spec, such as patterns, ranges, or required constraints.

  • Intuitive Request Building: We construct API requests effortlessly using fluent builders that provide intellisense and compile-time checking, ensuring valid API calls.

  • Exception Handling: We implement standardized exception handling with custom exception types that provide detailed error information and suggested resolutions.

  • Optional Nullable Support: Advanced handling of optional and nullable fields using Optional<T> wrapper types, providing clear distinction between undefined, null, and present values.

Sample Code

Here's a sample C# script demonstrating basic initialization and an API request using an SDK generated by liblab:

using Poke;
using Poke.Config;
using Environment = Poke.Http.Environment;

try
{
var config = new PokeConfig
{
Environment = Environment.Default,
AccessToken = "YOUR_ACCESS_TOKEN",
};

var client = new PokeClient(config);

var response = await client.Pokemon.AbilityListAsync(9, 9, "q");

Console.WriteLine(response);
}
catch (ApiException ex)
{
Console.WriteLine($"API Error: {ex.Message}");
Console.WriteLine($"Status Code: {ex.StatusCode}");
}

This example illustrates setup, basic request handling, and error management, which are essential for using SDKs generated with liblab effectively.

Optional Nullable Support

The C# SDK provides sophisticated support for handling optional and nullable fields through the Optional<T> wrapper type. This allows for precise control over field presence, absence, and null values in your API models.

For comprehensive documentation on optional nullable support across all languages, including detailed examples and best practices, see our Optional Nullable Support guide.

FAQs and Common Pitfalls

Q: Does the SDK support .NET Standard for cross-platform compatibility? A: Yes, SDKs generated with liblab target .NET Standard 2.0, ensuring compatibility with .NET Framework, .NET Core, and .NET 6+. Read more in Automate SDK generation for ASP.NET APIs.

Q: How should errors be handled in production? A: Configure the SDK's error handling to use retries or custom exception handling, as necessary, for a more resilient application. The SDK provides specialized exception types for different error scenarios.