Managedcode Communication

ManagedCode.Communication

Trigger On

• integrating ManagedCode.Communication into services or APIs
• replacing exception-driven result handling with explicit results
• reviewing service boundaries that return success or failure payloads
• documenting result-pattern usage across ASP.NET Core or application services
• mapping application errors to RFC 7807 problem details, Minimal API results, SignalR filters, or Orleans call filters

Install

Use the package that matches the boundary. Current upstream release reviewed: v10.0.4.

dotnet add package ManagedCode.Communication
dotnet add package ManagedCode.Communication.AspNetCore
dotnet add package ManagedCode.Communication.Extensions
dotnet add package ManagedCode.Communication.Orleans

For pinned project files:

Workflow

1. Confirm the boundary where the library belongs:

• service result contracts
• application manager boundaries
• API endpoints that translate results into HTTP responses

1. Keep result creation and error mapping explicit instead of mixing exceptions, nulls, and ad-hoc tuples.
2. Pattern-match result objects at the boundary that converts them into user-facing responses.
3. Do not hide domain failures behind generic success wrappers.
4. Configure framework integration only where it removes manual translation:

• ConfigureCommunication() for ASP.NET Core logging and converters
• WithCommunicationResults() for Minimal API endpoint or group conversion
• Orleans or SignalR packages only when those runtime filters are actually in use

1. Validate positive, negative, and error-path handling after integration.

flowchart LR
  A["Domain or service operation"] --> B["ManagedCode.Communication result"]
  B --> C["Application or API boundary"]
  C --> D["HTTP response or caller-visible contract"]

Practical Usage

Read path with explicit failures

public sealed class OrderService(IOrderRepository orders)
{
    public async Task> GetAsync(Guid id, CancellationToken ct)
    {
        var order = await orders.FindAsync(id, ct);

        return order is null
            ? Result.FailNotFound($"Order {id} was not found.")
            : Result.Succeed(OrderDto.From(order));
    }
}

Use this shape when absence, validation, authorization, or domain rejection is an expected outcome. Reserve exceptions for unexpected infrastructure faults.

Write path through Minimal APIs

var builder = WebApplication.CreateBuilder(args);

builder.Services.ConfigureCommunication();

var app = builder.Build();

app.MapGroup("/orders")
   .WithCommunicationResults()
   .MapPost(string.Empty, async (CreateOrder command, OrderService orders, CancellationToken ct) =>
        await orders.CreateAsync(command, ct));

Handlers can return Result or Result and let the extension package map failures to HTTP results and problem details at the API boundary.

Compose validation and domain steps

public async Task> CreateAsync(CreateOrder command, CancellationToken ct)
{
    var validation = Validate(command);
    if (validation.IsFailed)
    {
        return Result.Fail(validation.Problem!);
    }

    return await Result.From(() => BuildOrder(command))
        .ThenAsync(order => SaveAsync(order, ct))
        .Then(order => Result.Succeed(new OrderReceipt(order.Id, order.CreatedAt)));
}

Use railway-style composition when each step can return a result and the caller should stop at the first real failure.

Options And Constraints

• Result, Result, CollectionResult, and Problem are the core surfaces. Keep them at service/API boundaries rather than leaking framework-specific HTTP results into domain code.
• CollectionResult plus PaginationRequest / PaginationOptions should own paged API metadata instead of ad-hoc (items, total) tuples.
• Minimal APIs can use WithCommunicationResults() on one endpoint or an entire group. Prefer the group form only when every child endpoint follows the same result contract.
• ManagedCode.Communication.Orleans is for grain-call integration and serialization boundaries; use it with the Orleans skill when reviewing grain APIs.
• v10.0.4 release notes call out error-handling fixes and dependency maintenance. Re-test negative paths after upgrading.

Deliver

• guidance on where explicit result objects improve clarity
• usage boundaries for translating results into API or caller responses
• validation expectations for success and failure flows
• package and integration choices for the actual runtime boundary

Validate

• result handling is consistent across the boundary that uses the library
• callers do not fall back to exception-only logic for normal failure cases
• negative and error scenarios are documented and tested
• Minimal API endpoints return expected success and RFC 7807 failure shapes
• pagination metadata is stable when CollectionResult is used
• Orleans or SignalR integration is covered by runtime-level tests when those packages are installed

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: managedcode
• Source: managedcode/dotnet-skills
• License: MIT
• Homepage: https://skills.managed-code.com

Install and usage instructions live in the source repository linked above.