Migrating gRPC services from C-core to ASP.NET Core

By John Luo

Due to the implementation of the underlying stack, not all features work in the same way between C-core-based gRPC apps and ASP.NET Core-based apps. This document highlights the key differences for migrating between the two stacks.

gRPC service implementation lifetime

In the ASP.NET Core stack, gRPC services, by default, are created with a scoped lifetime. In contrast, gRPC C-core by default binds to a service with a singleton lifetime.

A scoped lifetime allows the service implementation to resolve other services with scoped lifetimes. For example, a scoped lifetime can also resolve DbContext from the DI container through constructor injection. Using scoped lifetime:

  • A new instance of the service implementation is constructed for each request.
  • It isn't possible to share state between requests via instance members on the implementation type.
  • The expectation is to store shared states in a singleton service in the DI container. The stored shared states are resolved in the constructor of the gRPC service implementation.

For more information on service lifetimes, see Dependency injection in ASP.NET Core.

Add a singleton service

To facilitate the transition from a gRPC C-core implementation to ASP.NET Core, it's possible to change the service lifetime of the service implementation from scoped to singleton. This involves adding an instance of the service implementation to the DI container:

public void ConfigureServices(IServiceCollection services)
{
    services.AddGrpc();
    services.AddSingleton(new GreeterService());
}

However, a service implementation with a singleton lifetime is no longer able to resolve scoped services through constructor injection.

Configure gRPC services options

In C-core-based apps, settings such as grpc.max_receive_message_length and grpc.max_send_message_length are configured with ChannelOption when constructing the Server instance.

In ASP.NET Core, gRPC provides configuration through the GrpcServiceOptions type. For example, a gRPC service's the maximum incoming message size can be configured via AddGrpc:

public void ConfigureServices(IServiceCollection services)
{
    services.AddGrpc(options =>
    {
        options.ReceiveMaxMessageSize = 16384; // 16 MB
    });
}

For more information on configuration, see gRPC for ASP.NET Core configuration.

Logging

C-core-based apps rely on the GrpcEnvironment to configure the logger for debugging purposes. The ASP.NET Core stack provides this functionality through the Logging API. For example, a logger can be added to the gRPC service via constructor injection:

public class GreeterService : Greeter.GreeterBase
{
    public GreeterService(ILogger<GreeterService> logger)
    {
    }
}

HTTPS

C-core-based apps configure HTTPS through the Server.Ports property. A similar concept is used to configure servers in ASP.NET Core. For example, Kestrel uses endpoint configuration for this functionality.

Interceptors and Middleware

ASP.NET Core middleware offers similar functionalities compared to interceptors in C-core-based gRPC apps. Middleware and interceptors are conceptually the same as both are used to construct a pipeline that handles a gRPC request. They both allow work to be performed before or after the next component in the pipeline. However, ASP.NET Core middleware operates on the underlying HTTP/2 messages, while interceptors operate on the gRPC layer of abstraction using the ServerCallContext.

Additional resources