Felsöka gRPC på .NET

I det här dokumentet beskrivs vanliga problem när du utvecklar gRPC-appar på .NET.

Matchningsfel mellan klient- och tjänst-SSL/TLS-konfiguration

GRPC-mallen och exemplen använder TLS (Transport Layer Security) för att skydda gRPC-tjänster som standard. gRPC-klienter måste använda en säker anslutning för att anropa skyddade gRPC-tjänster.

Du kan kontrollera att ASP.NET Core gRPC-tjänsten använder TLS i loggarna som skrevs vid appstart. Tjänsten lyssnar på en HTTPS-slutpunkt:

info: Microsoft.Hosting.Lifetime[0]
      Now listening on: https://localhost:5001
info: Microsoft.Hosting.Lifetime[0]
      Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
      Hosting environment: Development

.NET-klienten måste använda https i serveradressen för att göra anrop med en säker anslutning:

var channel = GrpcChannel.ForAddress("https://localhost:5001");
var client = new Greeter.GreeterClient(channel);

Alla gRPC-klientimplementeringar stöder TLS. gRPC-klienter från andra språk kräver vanligtvis den kanal som konfigurerats med SslCredentials. SslCredentials anger det certifikat som klienten ska använda och måste användas i stället för osäkra autentiseringsuppgifter. Exempel på hur du konfigurerar olika gRPC-klientimplementeringar för användning av TLS finns i gRPC-autentisering.

Anropa en gRPC-tjänst med ett ej betrott/ogiltigt certifikat

.NET gRPC-klienten kräver att tjänsten har ett betrott certifikat. Följande felmeddelande returneras när du anropar en gRPC-tjänst utan ett betrott certifikat:

Unhandled exception. System.Net.Http.HttpRequestException: SSL-anslutningen kunde inte upprättas, se inre undantag. >--- System.Security.Authentication.AuthenticationException: Fjärrcertifikatet är ogiltigt enligt valideringsproceduren.

Du kan se det här felet om du testar din app lokalt och HTTPS-utvecklingscertifikatet för ASP.NET Core inte är pålitligt. Anvisningar för hur du åtgärdar det här problemet finns i Lita på ASP.NET Core HTTPS-utvecklingscertifikat i Windows och macOS.

Om du anropar en gRPC-tjänst på en annan dator och inte kan lita på certifikatet kan gRPC-klienten konfigureras för att ignorera det ogiltiga certifikatet. Följande kod används HttpClientHandler.ServerCertificateCustomValidationCallback för att tillåta anrop utan ett betrott certifikat:

var handler = new HttpClientHandler();
handler.ServerCertificateCustomValidationCallback = 
    HttpClientHandler.DangerousAcceptAnyServerCertificateValidator;

var channel = GrpcChannel.ForAddress("https://localhost:5001",
    new GrpcChannelOptions { HttpHandler = handler });
var client = new Greeter.GreeterClient(channel);

GRPC-klientfabriken tillåter anrop utan ett betrott certifikat. ConfigurePrimaryHttpMessageHandler Använd tilläggsmetoden för att konfigurera hanteraren på klienten:

var services = new ServiceCollection();

services
    .AddGrpcClient<Greeter.GreeterClient>(o =>
    {
        o.Address = new Uri("https://localhost:5001");
    })
    .ConfigurePrimaryHttpMessageHandler(() =>
    {
        var handler = new HttpClientHandler();
        handler.ServerCertificateCustomValidationCallback =
            HttpClientHandler.DangerousAcceptAnyServerCertificateValidator;

        return handler;
    });

Anropa osäkra gRPC-tjänster med .NET-klienten

.NET gRPC-klienten kan anropa osäkra gRPC-tjänster genom att http ange serveradressen. Till exempel GrpcChannel.ForAddress("http://localhost:5000").

Det finns några ytterligare krav för att anropa osäkra gRPC-tjänster beroende på vilken .NET-version en app använder:

• .NET 5 eller senare kräver Grpc.Net.Client version 2.32.0 eller senare.
• .NET Core 3.x kräver ytterligare konfiguration. Appen måste ange växeln System.Net.Http.SocketsHttpHandler.Http2UnencryptedSupport till true. Mer information finns i Asp.Net Core 3.x: Anropa osäkra gRPC-tjänster med .NET-klienten:

Det går inte att starta ASP.NET Core gRPC-appen på macOS

Kestrel stöder inte HTTP/2 med TLS på macOS före .NET 8. Mallen och exemplen ASP.NET Core gRPC använder TLS som standard. Följande felmeddelande visas när du försöker starta gRPC-servern:

Det går inte att binda till https://localhost:5001 i IPv4-loopback-gränssnittet: "HTTP/2 via TLS stöds inte på macOS på grund av att ALPN-stöd saknas."

Om du vill undvika det här problemet i .NET 7 eller tidigare konfigurerar du Kestrel och gRPC-klienten att använda HTTP/2 utan TLS. Du bör bara göra detta under utvecklingen. Om du inte använder TLS kommer gRPC-meddelanden att skickas utan kryptering. Mer information finns i ASP.NET Core i .NET 7: Det går inte att starta ASP.NET Core gRPC-app på macOS.

gRPC C#-komponenter genereras inte från .proto-filer

gRPC-kodgenerering av konkreta klienter och tjänstbasklasser kräver att protobuf-filer och verktyg refereras från ett projekt. Du måste inkludera:

• .proto filer som du vill använda i <Protobuf> objektgruppen. Importerade .proto filer måste refereras av projektet.
• Paketreferens till gRPC-verktygspaketet Grpc.Tools.

Mer information om hur du genererar GRPC C#-tillgångar finns i gRPC-tjänster med C#.

En ASP.NET Core-webbapp som är värd för gRPC-tjänster behöver bara den tjänstbasklass som genereras:

<ItemGroup>
  <Protobuf Include="Protos\greet.proto" GrpcServices="Server" />
</ItemGroup>

En gRPC-klientapp som gör gRPC-anrop behöver bara den konkreta klient som genereras:

<ItemGroup>
  <Protobuf Include="Protos\greet.proto" GrpcServices="Client" />
</ItemGroup>

WPF-projekt kan inte generera GRPC C#-tillgångar från .proto filer

WPF-projekt har ett känt problem som hindrar gRPC-kodgenerering från att fungera korrekt. Alla gRPC-typer som genereras i ett WPF-projekt genom att referera till Grpc.Tools och .proto filer skapar kompileringsfel när de används:

fel CS0246: Det gick inte att hitta typen eller namnområdets namn "MyGrpcServices" (saknar du ett användningsdirektiv eller en sammansättningsreferens?)

Du kan lösa det här problemet genom att:

1. Skapa ett nytt .NET-klassbiblioteksprojekt.
2. I det nya projektet lägger du till referenser för att aktivera C#-kodgenerering från .proto filer:
   • Lägg till följande paketreferenser:
     • Grpc.Tools
     • Grpc.Net.Client
     • Google.Protobuf
   • Lägg till .proto filer i <Protobuf> objektgruppen.
3. I WPF-programmet lägger du till en referens till det nya projektet.

WPF-programmet kan använda de gRPC-genererade typerna från det nya klassbiblioteksprojektet.

Anropa gRPC-tjänster som finns i en underkatalog

Sökvägskomponenten för en gRPC-kanals adress ignoreras när gRPC-anrop görs. Till exempel GrpcChannel.ForAddress("https://localhost:5001/ignored_path") används ignored_path inte vid routning av gRPC-anrop för tjänsten.

Adresssökvägen ignoreras eftersom gRPC har en standardiserad, normativ adressstruktur. En gRPC-adress kombinerar paket-, tjänst- och metodnamnen: https://localhost:5001/PackageName.ServiceName/MethodName.

Det finns vissa scenarier när en app behöver inkludera en sökväg med gRPC-anrop. Till exempel när en ASP.NET Core gRPC-app finns i en IIS-katalog och katalogen måste inkluderas i begäran. När en sökväg krävs kan den läggas till i gRPC-anropet med hjälp av den anpassade SubdirectoryHandler som anges nedan:

public class SubdirectoryHandler : DelegatingHandler
{
    private readonly string _subdirectory;

    public SubdirectoryHandler(HttpMessageHandler innerHandler, string subdirectory)
        : base(innerHandler)
    {
        _subdirectory = subdirectory;
    }

    protected override Task<HttpResponseMessage> SendAsync(
        HttpRequestMessage request, CancellationToken cancellationToken)
    {
        var old = request.RequestUri;

        var url = $"{old.Scheme}://{old.Host}:{old.Port}";
        url += $"{_subdirectory}{request.RequestUri.AbsolutePath}";
        request.RequestUri = new Uri(url, UriKind.Absolute);

        return base.SendAsync(request, cancellationToken);
    }
}

SubdirectoryHandler används när gRPC-kanalen skapas.

var handler = new SubdirectoryHandler(new HttpClientHandler(), "/MyApp");

var channel = GrpcChannel.ForAddress("https://localhost:5001", new GrpcChannelOptions { HttpHandler = handler });
var client = new Greeter.GreeterClient(channel);

var reply = await client.SayHelloAsync(
                  new HelloRequest { Name = "GreeterClient" });

Föregående kod:

• Skapar en SubdirectoryHandler med sökvägen /MyApp.
• Konfigurerar en kanal att använda SubdirectoryHandler.
• Anropar gRPC-tjänsten med SayHelloAsync. GRPC-anropet skickas till https://localhost:5001/MyApp/greet.Greeter/SayHello.

Du kan också konfigurera en klientfabrik med SubdirectoryHandler genom att använda AddHttpMessageHandler.

Konfigurera gRPC-klienten att använda HTTP/3

.NET gRPC-klienten stöder HTTP/3 med .NET 6 eller senare. Om servern skickar ett alt-svc svarshuvud till klienten som anger att servern stöder HTTP/3 uppgraderar klienten automatiskt sin anslutning till HTTP/3. Mer information finns i Använda HTTP/3 med ASP.NET Core-webbservernKestrel.

En DelegatingHandler kan användas för att tvinga en gRPC-klient att använda HTTP/3. Om du tvingar HTTP/3 undviker du kostnaden för att uppgradera begäran. Framtvinga HTTP/3 med kod som liknar följande:

public class Http3Handler : DelegatingHandler
{
    public Http3Handler() { }
    public Http3Handler(HttpMessageHandler innerHandler) : base(innerHandler) { }

    protected override Task<HttpResponseMessage> SendAsync(
        HttpRequestMessage request, CancellationToken cancellationToken)
    {
        request.Version = HttpVersion.Version30;
        request.VersionPolicy = HttpVersionPolicy.RequestVersionExact;

        return base.SendAsync(request, cancellationToken);
    }
}

Http3Handler används när gRPC-kanalen skapas. Följande kod skapar en kanal som är konfigurerad att använda Http3Handler.

var handler = new Http3Handler(new HttpClientHandler());

var channel = GrpcChannel.ForAddress("https://localhost:5001", new GrpcChannelOptions { HttpHandler = handler });
var client = new Greeter.GreeterClient(channel);

var reply = await client.SayHelloAsync(
                  new HelloRequest { Name = "GreeterClient" });

Du kan också konfigurera en klientfabrik med Http3Handler genom att använda AddHttpMessageHandler.

Skapa gRPC på Alpine Linux

Paketet Grpc.Toolsgenererar .NET-typer från .proto filer med en paketerad intern binär fil med namnet protoc. Ytterligare steg krävs för att skapa gRPC-appar på plattformar som inte stöds av de interna binärfilerna i Grpc.Tools, till exempel Alpine Linux.

Generera kod i förväg

En lösning är att generera kod i förväg.

1. Flytta .proto filer och paketreferensen Grpc.Tools till ett nytt projekt.
2. Publicera projektet som ett NuGet-paket och ladda upp det till en NuGet-feed.
3. Uppdatera appen för att referera till NuGet-paketet.

Med föregående steg behöver Grpc.Tools appen inte längre skapa eftersom kod genereras i förväg.

Anpassa Grpc.Tools interna binärfiler

Grpc.Tools stöder användning av anpassade interna binärfiler. Med den här funktionen kan gRPC-verktyg köras i miljöer där de inbyggda binärfilerna inte stöds.

Skapa eller hämta protoc och grpc_csharp_plugin inbyggda binärfiler och konfigurera Grpc.Tools för att använda dem. Konfigurera interna binärfiler genom att ange följande miljövariabler:

• PROTOBUF_PROTOC – Fullständig sökväg till kompilatorn för protokollbuffertar
• GRPC_PROTOC_PLUGIN – Fullständig sökväg till grpc_csharp_plugin

För Alpine Linux finns det paket tillhandahållna av communityn för kompilatorn för protokollbuffertar och gRPC-plugin-program på https://pkgs.alpinelinux.org/.

# Build or install the binaries for your architecture.

# For Alpine Linux, the grpc-plugins package can be used.
# See https://pkgs.alpinelinux.org/package/edge/community/x86_64/grpc-plugins
apk add grpc-plugins  # Alpine Linux specific package installer

# Set environment variables for the built/installed protoc
# and grpc_csharp_plugin binaries
export PROTOBUF_PROTOC=/usr/bin/protoc
export GRPC_PROTOC_PLUGIN=/usr/bin/grpc_csharp_plugin

# When dotnet build runs, the Grpc.Tools NuGet package
# uses the binaries pointed to by the environment variables.
dotnet build

Mer information om hur du använder Grpc.Tools med arkitekturer som inte stöds finns i dokumentationen för gRPC-byggintegrering.

gRPC-samtalstimeout från HttpClient.Timeout

HttpClient har konfigurerats med en tidsgräns på 100 sekunder som standard. Om en GrpcChannel har konfigurerats för att använda ett HttpClientavbryts långvariga gRPC-strömningsanrop om de inte slutförs inom tidsgränsen.

System.OperationCanceledException: The request was canceled due to the configured HttpClient.Timeout of 100 seconds elapsing.

Det finns ett par sätt att åtgärda det här felet. Den första är att konfigurera HttpClient.Timeout till ett större värde. Timeout.InfiniteTimeSpan inaktiverar tidsgränsen:

var handler = new HttpClientHandler();
handler.ServerCertificateCustomValidationCallback = 
    HttpClientHandler.DangerousAcceptAnyServerCertificateValidator;

var httpClient = new HttpClient(handler) { Timeout = Timeout.InfiniteTimeSpan };
var channel = GrpcChannel.ForAddress("https://localhost:5001",
    new GrpcChannelOptions { HttpClient = httpClient });
var client = new Greeter.GreeterClient(channel);

Du kan också undvika att skapa HttpClient och ställa in GrpcChannel.HttpHandler i stället:

var handler = new HttpClientHandler();
handler.ServerCertificateCustomValidationCallback = 
    HttpClientHandler.DangerousAcceptAnyServerCertificateValidator;

var channel = GrpcChannel.ForAddress("https://localhost:5001",
    new GrpcChannelOptions { HttpHandler = handler });
var client = new Greeter.GreeterClient(channel);

I det här dokumentet beskrivs vanliga problem när du utvecklar gRPC-appar på .NET.

Matchningsfel mellan klient- och tjänst-SSL/TLS-konfiguration

GRPC-mallen och exemplen använder TLS (Transport Layer Security) för att skydda gRPC-tjänster som standard. gRPC-klienter måste använda en säker anslutning för att anropa skyddade gRPC-tjänster.

Du kan kontrollera att ASP.NET Core gRPC-tjänsten använder TLS i loggarna som skrevs vid appstart. Tjänsten lyssnar på en HTTPS-slutpunkt:

info: Microsoft.Hosting.Lifetime[0]
      Now listening on: https://localhost:5001
info: Microsoft.Hosting.Lifetime[0]
      Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
      Hosting environment: Development

.NET-klienten måste använda https i serveradressen för att göra anrop med en säker anslutning:

static async Task Main(string[] args)
{
    // The port number(5001) must match the port of the gRPC server.
    var channel = GrpcChannel.ForAddress("https://localhost:5001");
    var client = new Greet.GreeterClient(channel);
}

Alla gRPC-klientimplementeringar stöder TLS. gRPC-klienter från andra språk kräver vanligtvis den kanal som konfigurerats med SslCredentials. SslCredentials anger det certifikat som klienten ska använda och måste användas i stället för osäkra autentiseringsuppgifter. Exempel på hur du konfigurerar olika gRPC-klientimplementeringar för användning av TLS finns i gRPC-autentisering.

Anropa en gRPC-tjänst med ett ej betrott/ogiltigt certifikat

.NET gRPC-klienten kräver att tjänsten har ett betrott certifikat. Följande felmeddelande returneras när du anropar en gRPC-tjänst utan ett betrott certifikat:

Unhandled exception. System.Net.Http.HttpRequestException: SSL-anslutningen kunde inte upprättas, se inre undantag. >--- System.Security.Authentication.AuthenticationException: Fjärrcertifikatet är ogiltigt enligt valideringsproceduren.

Du kan se det här felet om du testar din app lokalt och HTTPS-utvecklingscertifikatet för ASP.NET Core inte är pålitligt. Anvisningar för hur du åtgärdar det här problemet finns i Lita på ASP.NET Core HTTPS-utvecklingscertifikat i Windows och macOS.

Om du anropar en gRPC-tjänst på en annan dator och inte kan lita på certifikatet kan gRPC-klienten konfigureras för att ignorera det ogiltiga certifikatet. Följande kod används HttpClientHandler.ServerCertificateCustomValidationCallback för att tillåta anrop utan ett betrott certifikat:

var handler = new HttpClientHandler();
handler.ServerCertificateCustomValidationCallback = 
    HttpClientHandler.DangerousAcceptAnyServerCertificateValidator;

var channel = GrpcChannel.ForAddress("https://localhost:5001",
    new GrpcChannelOptions { HttpHandler = handler });
var client = new Greet.GreeterClient(channel);

GRPC-klientfabriken tillåter anrop utan ett betrott certifikat. ConfigurePrimaryHttpMessageHandler Använd tilläggsmetoden för att konfigurera hanteraren på klienten:

builder.Services
    .AddGrpcClient<Greeter.GreeterClient>(o =>
    {
        o.Address = new Uri("https://localhost:5001");
    })
    .ConfigurePrimaryHttpMessageHandler(() =>
    {
        var handler = new HttpClientHandler();
        handler.ServerCertificateCustomValidationCallback = 
            HttpClientHandler.DangerousAcceptAnyServerCertificateValidator;

        return handler;
    });

Anropa osäkra gRPC-tjänster med .NET-klienten

.NET gRPC-klienten kan anropa osäkra gRPC-tjänster genom att http ange serveradressen. Till exempel GrpcChannel.ForAddress("http://localhost:5000").

Det finns några ytterligare krav för att anropa osäkra gRPC-tjänster beroende på vilken .NET-version en app använder:

• .NET 5 eller senare kräver Grpc.Net.Client version 2.32.0 eller senare.

• .NET Core 3.x kräver ytterligare konfiguration. Appen måste ange växeln System.Net.Http.SocketsHttpHandler.Http2UnencryptedSupport till true:

  // This switch must be set before creating the GrpcChannel/HttpClient.
  AppContext.SetSwitch(
      "System.Net.Http.SocketsHttpHandler.Http2UnencryptedSupport", true);
  
  // The port number(5000) must match the port of the gRPC server.
  var channel = GrpcChannel.ForAddress("http://localhost:5000");
  var client = new Greet.GreeterClient(channel);
  

Växeln System.Net.Http.SocketsHttpHandler.Http2UnencryptedSupport krävs endast för .NET Core 3.x. Det gör ingenting i .NET 5 och krävs inte.

Det går inte att starta ASP.NET Core gRPC-appen på macOS

Kestrel stöder inte HTTP/2 med TLS på macOS före .NET 8. Mallen och exemplen ASP.NET Core gRPC använder TLS som standard. Följande felmeddelande visas när du försöker starta gRPC-servern:

Det går inte att binda till https://localhost:5001 i IPv4-loopback-gränssnittet: "HTTP/2 via TLS stöds inte på macOS på grund av att ALPN-stöd saknas."

Om du vill undvika det här problemet i .NET 7 eller tidigare konfigurerar du Kestrel och gRPC-klienten att använda HTTP/2 utan TLS. Du bör bara göra detta under utvecklingen. Om du inte använder TLS kommer gRPC-meddelanden att skickas utan kryptering.

Kestrel måste konfigurera en HTTP/2-slutpunkt utan TLS i Program.cs:

var builder = WebApplication.CreateBuilder(args);

builder.WebHost.ConfigureKestrel(options =>
{
    // Setup a HTTP/2 endpoint without TLS.
    options.ListenLocalhost(<5287>, o => o.Protocols =
        HttpProtocols.Http2);
});

• I föregående kod ersätter du portnumret localhost med portnumret 5287HTTP (inte HTTPS) som anges i Properties/launchSettings.json gRPC-tjänstprojektet.

När en HTTP/2-slutpunkt har konfigurerats utan TLS måste slutpunktens ListenOptions.Protocols anges till HttpProtocols.Http2. HttpProtocols.Http1AndHttp2 kan inte användas eftersom TLS krävs för att förhandla om HTTP/2. Utan TLS ändras alla anslutningar till slutpunkten standardmässigt till HTTP/1.1, och gRPC-anrop misslyckas.

GRPC-klienten måste också konfigureras för att inte använda TLS. Mer information finns i Anropa osäkra gRPC-tjänster med .NET-klienten.

gRPC C#-komponenter genereras inte från .proto-filer

gRPC-kodgenerering av konkreta klienter och tjänstbasklasser kräver att protobuf-filer och verktyg refereras från ett projekt. Du måste inkludera:

• .proto filer som du vill använda i <Protobuf> objektgruppen. Importerade .proto filer måste refereras av projektet.
• Paketreferens till gRPC-verktygspaketet Grpc.Tools.

Mer information om hur du genererar GRPC C#-tillgångar finns i gRPC-tjänster med C#.

En ASP.NET Core-webbapp som är värd för gRPC-tjänster behöver bara den tjänstbasklass som genereras:

<ItemGroup>
  <Protobuf Include="Protos\greet.proto" GrpcServices="Server" />
</ItemGroup>

En gRPC-klientapp som gör gRPC-anrop behöver bara den konkreta klient som genereras:

<ItemGroup>
  <Protobuf Include="Protos\greet.proto" GrpcServices="Client" />
</ItemGroup>

WPF-projekt kan inte generera GRPC C#-tillgångar från .proto filer

WPF-projekt har ett känt problem som hindrar gRPC-kodgenerering från att fungera korrekt. Alla gRPC-typer som genereras i ett WPF-projekt genom att referera till Grpc.Tools och .proto filer skapar kompileringsfel när de används:

fel CS0246: Det gick inte att hitta typen eller namnområdets namn "MyGrpcServices" (saknar du ett användningsdirektiv eller en sammansättningsreferens?)

Du kan lösa det här problemet genom att:

1. Skapa ett nytt .NET-klassbiblioteksprojekt.
2. I det nya projektet lägger du till referenser för att aktivera C#-kodgenerering från .proto filer:
   • Lägg till följande paketreferenser:
     • Grpc.Tools
     • Grpc.Net.Client
     • Google.Protobuf
   • Lägg till .proto filer i <Protobuf> objektgruppen.
3. I WPF-programmet lägger du till en referens till det nya projektet.

WPF-programmet kan använda de gRPC-genererade typerna från det nya klassbiblioteksprojektet.

Anropa gRPC-tjänster som finns i en underkatalog

Sökvägskomponenten för en gRPC-kanals adress ignoreras när gRPC-anrop görs. Till exempel GrpcChannel.ForAddress("https://localhost:5001/ignored_path") används ignored_path inte vid routning av gRPC-anrop för tjänsten.

Adresssökvägen ignoreras eftersom gRPC har en standardiserad, normativ adressstruktur. En gRPC-adress kombinerar paket-, tjänst- och metodnamnen: https://localhost:5001/PackageName.ServiceName/MethodName.

Det finns vissa scenarier när en app behöver inkludera en sökväg med gRPC-anrop. Till exempel när en ASP.NET Core gRPC-app finns i en IIS-katalog och katalogen måste inkluderas i begäran. När en sökväg krävs kan den läggas till i gRPC-anropet med hjälp av den anpassade SubdirectoryHandler som anges nedan:

/// <summary>
/// A delegating handler that adds a subdirectory to the URI of gRPC requests.
/// </summary>
public class SubdirectoryHandler : DelegatingHandler
{
    private readonly string _subdirectory;

    public SubdirectoryHandler(HttpMessageHandler innerHandler, string subdirectory)
        : base(innerHandler)
    {
        _subdirectory = subdirectory;
    }

    protected override Task<HttpResponseMessage> SendAsync(
        HttpRequestMessage request, CancellationToken cancellationToken)
    {
        var old = request.RequestUri;

        var url = $"{old.Scheme}://{old.Host}:{old.Port}";
        url += $"{_subdirectory}{request.RequestUri.AbsolutePath}";
        request.RequestUri = new Uri(url, UriKind.Absolute);

        return base.SendAsync(request, cancellationToken);
    }
}

SubdirectoryHandler används när gRPC-kanalen skapas.

var handler = new SubdirectoryHandler(new HttpClientHandler(), "/MyApp");

var channel = GrpcChannel.ForAddress("https://localhost:5001", new GrpcChannelOptions { HttpHandler = handler });
var client = new Greet.GreeterClient(channel);

var reply = await client.SayHelloAsync(new HelloRequest { Name = ".NET" });

Föregående kod:

• Skapar en SubdirectoryHandler med sökvägen /MyApp.
• Konfigurerar en kanal att använda SubdirectoryHandler.
• Anropar gRPC-tjänsten med SayHelloAsync. GRPC-anropet skickas till https://localhost:5001/MyApp/greet.Greeter/SayHello.

Du kan också konfigurera en klientfabrik med SubdirectoryHandler genom att använda AddHttpMessageHandler.

Konfigurera gRPC-klienten att använda HTTP/3

.NET gRPC-klienten stöder HTTP/3 med .NET 6 eller senare. Om servern skickar ett alt-svc svarshuvud till klienten som anger att servern stöder HTTP/3 uppgraderar klienten automatiskt sin anslutning till HTTP/3. Information om hur du aktiverar HTTP/3 på servern finns i Använda HTTP/3 med ASP.NET Core-webbservernKestrel.

HTTP/3-stöd i .NET 8 är aktiverat som standard. HTTP/3-stöd i .NET 6 och .NET 7 måste aktiveras via en konfigurationsflagga i projektfilen:

<ItemGroup>
  <RuntimeHostConfigurationOption Include="System.Net.SocketsHttpHandler.Http3Support" Value="true" />
</ItemGroup>

System.Net.SocketsHttpHandler.Http3Support kan också anges med AppContext.SetSwitch.

En DelegatingHandler kan användas för att tvinga en gRPC-klient att använda HTTP/3. Om du tvingar HTTP/3 undviker du kostnaden för att uppgradera begäran. Framtvinga HTTP/3 med kod som liknar följande:

/// <summary>
/// A delegating handler that changes the request HTTP version to HTTP/3.
/// </summary>
public class Http3Handler : DelegatingHandler
{
    public Http3Handler() { }
    public Http3Handler(HttpMessageHandler innerHandler) : base(innerHandler) { }

    protected override Task<HttpResponseMessage> SendAsync(
        HttpRequestMessage request, CancellationToken cancellationToken)
    {
        request.Version = HttpVersion.Version30;
        request.VersionPolicy = HttpVersionPolicy.RequestVersionExact;

        return base.SendAsync(request, cancellationToken);
    }
}

Http3Handler används när gRPC-kanalen skapas. Följande kod skapar en kanal som är konfigurerad att använda Http3Handler.

var handler = new Http3Handler(new HttpClientHandler());

var channel = GrpcChannel.ForAddress("https://localhost:5001", new GrpcChannelOptions { HttpHandler = handler });
var client = new Greet.GreeterClient(channel);

var reply = await client.SayHelloAsync(new HelloRequest { Name = ".NET" });

Du kan också konfigurera en klientfabrik med Http3Handler genom att använda AddHttpMessageHandler.

Skapa gRPC på Alpine Linux

Paketet Grpc.Toolsgenererar .NET-typer från .proto filer med en paketerad intern binär fil med namnet protoc. Ytterligare steg krävs för att skapa gRPC-appar på plattformar som inte stöds av de interna binärfilerna i Grpc.Tools, till exempel Alpine Linux.

Generera kod i förväg

En lösning är att generera kod i förväg.

1. Flytta .proto filer och paketreferensen Grpc.Tools till ett nytt projekt.
2. Publicera projektet som ett NuGet-paket och ladda upp det till en NuGet-feed.
3. Uppdatera appen för att referera till NuGet-paketet.

Med föregående steg behöver Grpc.Tools appen inte längre skapa eftersom kod genereras i förväg.

Anpassa Grpc.Tools interna binärfiler

Grpc.Tools stöder användning av anpassade interna binärfiler. Med den här funktionen kan gRPC-verktyg köras i miljöer där de inbyggda binärfilerna inte stöds.

Skapa eller hämta protoc och grpc_csharp_plugin inbyggda binärfiler och konfigurera Grpc.Tools för att använda dem. Konfigurera interna binärfiler genom att ange följande miljövariabler:

• PROTOBUF_PROTOC – Fullständig sökväg till kompilatorn för protokollbuffertar
• GRPC_PROTOC_PLUGIN – Fullständig sökväg till grpc_csharp_plugin

För Alpine Linux finns det paket tillhandahållna av communityn för kompilatorn för protokollbuffertar och gRPC-plugin-program på https://pkgs.alpinelinux.org/.

# Build or install the binaries for your architecture.

# For Alpine Linux, the grpc-plugins package can be used.
#  See https://pkgs.alpinelinux.org/package/edge/community/x86_64/grpc-plugins
apk add grpc-plugins  # Alpine Linux specific package installer

# Set environment variables for the built/installed protoc
# and grpc_csharp_plugin binaries
export PROTOBUF_PROTOC=/usr/bin/protoc
export GRPC_PROTOC_PLUGIN=/usr/bin/grpc_csharp_plugin

# When dotnet build runs, the Grpc.Tools NuGet package
# uses the binaries pointed to by the environment variables.
dotnet build

Mer information om hur du använder Grpc.Tools med arkitekturer som inte stöds finns i dokumentationen för gRPC-byggintegrering.

gRPC-samtalstimeout från HttpClient.Timeout

HttpClient har konfigurerats med en tidsgräns på 100 sekunder som standard. Om en GrpcChannel har konfigurerats för att använda ett HttpClientavbryts långvariga gRPC-strömningsanrop om de inte slutförs inom tidsgränsen.

System.OperationCanceledException: The request was canceled due to the configured HttpClient.Timeout of 100 seconds elapsing.

Det finns ett par sätt att åtgärda det här felet. Den första är att konfigurera HttpClient.Timeout till ett större värde. Timeout.InfiniteTimeSpan inaktiverar tidsgränsen:

var handler = new HttpClientHandler();
handler.ServerCertificateCustomValidationCallback = 
    HttpClientHandler.DangerousAcceptAnyServerCertificateValidator;

var httpClient = new HttpClient(handler) { Timeout = Timeout.InfiniteTimeSpan };
var channel = GrpcChannel.ForAddress("https://localhost:5001",
    new GrpcChannelOptions { HttpClient = httpClient });
var client = new Greeter.GreeterClient(channel);

Du kan också undvika att skapa HttpClient och ställa in GrpcChannel.HttpHandler i stället:

var handler = new HttpClientHandler();
handler.ServerCertificateCustomValidationCallback = 
    HttpClientHandler.DangerousAcceptAnyServerCertificateValidator;

var channel = GrpcChannel.ForAddress("https://localhost:5001",
    new GrpcChannelOptions { HttpHandler = handler });
var client = new Greeter.GreeterClient(channel);

I det här dokumentet beskrivs vanliga problem när du utvecklar gRPC-appar på .NET.

Matchningsfel mellan klient- och tjänst-SSL/TLS-konfiguration

GRPC-mallen och exemplen använder TLS (Transport Layer Security) för att skydda gRPC-tjänster som standard. gRPC-klienter måste använda en säker anslutning för att anropa skyddade gRPC-tjänster.

Du kan kontrollera att ASP.NET Core gRPC-tjänsten använder TLS i loggarna som skrevs vid appstart. Tjänsten lyssnar på en HTTPS-slutpunkt:

info: Microsoft.Hosting.Lifetime[0]
      Now listening on: https://localhost:5001
info: Microsoft.Hosting.Lifetime[0]
      Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
      Hosting environment: Development

.NET-klienten måste använda https i serveradressen för att göra anrop med en säker anslutning:

static async Task Main(string[] args)
{
    // The port number(5001) must match the port of the gRPC server.
    var channel = GrpcChannel.ForAddress("https://localhost:5001");
    var client = new Greet.GreeterClient(channel);
}

Alla gRPC-klientimplementeringar stöder TLS. gRPC-klienter från andra språk kräver vanligtvis den kanal som konfigurerats med SslCredentials. SslCredentials anger det certifikat som klienten ska använda och måste användas i stället för osäkra autentiseringsuppgifter. Exempel på hur du konfigurerar olika gRPC-klientimplementeringar för användning av TLS finns i gRPC-autentisering.

Anropa en gRPC-tjänst med ett ej betrott/ogiltigt certifikat

.NET gRPC-klienten kräver att tjänsten har ett betrott certifikat. Följande felmeddelande returneras när du anropar en gRPC-tjänst utan ett betrott certifikat:

Unhandled exception. System.Net.Http.HttpRequestException: SSL-anslutningen kunde inte upprättas, se inre undantag. >--- System.Security.Authentication.AuthenticationException: Fjärrcertifikatet är ogiltigt enligt valideringsproceduren.

Du kan se det här felet om du testar din app lokalt och HTTPS-utvecklingscertifikatet för ASP.NET Core inte är pålitligt. Anvisningar för hur du åtgärdar det här problemet finns i Lita på ASP.NET Core HTTPS-utvecklingscertifikat i Windows och macOS.

Om du anropar en gRPC-tjänst på en annan dator och inte kan lita på certifikatet kan gRPC-klienten konfigureras för att ignorera det ogiltiga certifikatet. Följande kod används HttpClientHandler.ServerCertificateCustomValidationCallback för att tillåta anrop utan ett betrott certifikat:

var handler = new HttpClientHandler();
handler.ServerCertificateCustomValidationCallback = 
    HttpClientHandler.DangerousAcceptAnyServerCertificateValidator;

var channel = GrpcChannel.ForAddress("https://localhost:5001",
    new GrpcChannelOptions { HttpHandler = handler });
var client = new Greet.GreeterClient(channel);

GRPC-klientfabriken tillåter anrop utan ett betrott certifikat. ConfigurePrimaryHttpMessageHandler Använd tilläggsmetoden för att konfigurera hanteraren på klienten:

services
    .AddGrpcClient<Greeter.GreeterClient>(o =>
    {
        o.Address = new Uri("https://localhost:5001");
    })
    .ConfigurePrimaryHttpMessageHandler(() =>
    {
        var handler = new HttpClientHandler();
        handler.ServerCertificateCustomValidationCallback = 
            HttpClientHandler.DangerousAcceptAnyServerCertificateValidator;

        return handler;
    });

Anropa osäkra gRPC-tjänster med .NET-klienten

.NET gRPC-klienten kan anropa osäkra gRPC-tjänster genom att http ange serveradressen. Till exempel GrpcChannel.ForAddress("http://localhost:5000").

Det finns några ytterligare krav för att anropa osäkra gRPC-tjänster beroende på vilken .NET-version en app använder:

• .NET 5 eller senare kräver Grpc.Net.Client version 2.32.0 eller senare.

• .NET Core 3.x kräver ytterligare konfiguration. Appen måste ange växeln System.Net.Http.SocketsHttpHandler.Http2UnencryptedSupport till true:

  // This switch must be set before creating the GrpcChannel/HttpClient.
  AppContext.SetSwitch(
      "System.Net.Http.SocketsHttpHandler.Http2UnencryptedSupport", true);
  
  // The port number(5000) must match the port of the gRPC server.
  var channel = GrpcChannel.ForAddress("http://localhost:5000");
  var client = new Greet.GreeterClient(channel);
  

Växeln System.Net.Http.SocketsHttpHandler.Http2UnencryptedSupport krävs endast för .NET Core 3.x. Det gör ingenting i .NET 5 och krävs inte.

Det går inte att starta ASP.NET Core gRPC-appen på macOS

Kestrel stöder inte HTTP/2 med TLS på macOS före .NET 8. Mallen och exemplen ASP.NET Core gRPC använder TLS som standard. Följande felmeddelande visas när du försöker starta gRPC-servern:

Det går inte att binda till https://localhost:5001 i IPv4-loopback-gränssnittet: "HTTP/2 via TLS stöds inte på macOS på grund av att ALPN-stöd saknas."

Om du vill undvika det här problemet i .NET 7 eller tidigare konfigurerar du Kestrel och gRPC-klienten att använda HTTP/2 utan TLS. Du bör bara göra detta under utvecklingen. Om du inte använder TLS kommer gRPC-meddelanden att skickas utan kryptering.

Kestrel måste konfigurera en HTTP/2-slutpunkt utan TLS i Program.cs:

public static IHostBuilder CreateHostBuilder(string[] args) =>
    Host.CreateDefaultBuilder(args)
        .ConfigureWebHostDefaults(webBuilder =>
        {
            webBuilder.ConfigureKestrel(options =>
            {
                // Setup a HTTP/2 endpoint without TLS.
                options.ListenLocalhost(5000, o => o.Protocols = 
                    HttpProtocols.Http2);
            });
            webBuilder.UseStartup<Startup>();
        });

När en HTTP/2-slutpunkt har konfigurerats utan TLS måste slutpunktens ListenOptions.Protocols anges till HttpProtocols.Http2. HttpProtocols.Http1AndHttp2 kan inte användas eftersom TLS krävs för att förhandla om HTTP/2. Utan TLS ändras alla anslutningar till slutpunkten standardmässigt till HTTP/1.1, och gRPC-anrop misslyckas.

GRPC-klienten måste också konfigureras för att inte använda TLS. Mer information finns i Anropa osäkra gRPC-tjänster med .NET-klienten.

gRPC C#-komponenter genereras inte från .proto-filer

gRPC-kodgenerering av konkreta klienter och tjänstbasklasser kräver att protobuf-filer och verktyg refereras från ett projekt. Du måste inkludera:

• .proto filer som du vill använda i <Protobuf> objektgruppen. Importerade .proto filer måste refereras av projektet.
• Paketreferens till gRPC-verktygspaketet Grpc.Tools.

Mer information om hur du genererar GRPC C#-tillgångar finns i gRPC-tjänster med C#.

En ASP.NET Core-webbapp som är värd för gRPC-tjänster behöver bara den tjänstbasklass som genereras:

<ItemGroup>
  <Protobuf Include="Protos\greet.proto" GrpcServices="Server" />
</ItemGroup>

En gRPC-klientapp som gör gRPC-anrop behöver bara den konkreta klient som genereras:

<ItemGroup>
  <Protobuf Include="Protos\greet.proto" GrpcServices="Client" />
</ItemGroup>

WPF-projekt kan inte generera GRPC C#-tillgångar från .proto filer

WPF-projekt har ett känt problem som hindrar gRPC-kodgenerering från att fungera korrekt. Alla gRPC-typer som genereras i ett WPF-projekt genom att referera till Grpc.Tools och .proto filer skapar kompileringsfel när de används:

fel CS0246: Det gick inte att hitta typen eller namnområdets namn "MyGrpcServices" (saknar du ett användningsdirektiv eller en sammansättningsreferens?)

Du kan lösa det här problemet genom att:

1. Skapa ett nytt .NET-klassbiblioteksprojekt.
2. I det nya projektet lägger du till referenser för att aktivera C#-kodgenerering från .proto filer:
   • Lägg till följande paketreferenser:
     • Grpc.Tools
     • Grpc.Net.Client
     • Google.Protobuf
   • Lägg till .proto filer i <Protobuf> objektgruppen.
3. I WPF-programmet lägger du till en referens till det nya projektet.

WPF-programmet kan använda de gRPC-genererade typerna från det nya klassbiblioteksprojektet.

Anropa gRPC-tjänster som finns i en underkatalog

Sökvägskomponenten för en gRPC-kanals adress ignoreras när gRPC-anrop görs. Till exempel GrpcChannel.ForAddress("https://localhost:5001/ignored_path") används ignored_path inte vid routning av gRPC-anrop för tjänsten.

Adresssökvägen ignoreras eftersom gRPC har en standardiserad, normativ adressstruktur. En gRPC-adress kombinerar paket-, tjänst- och metodnamnen: https://localhost:5001/PackageName.ServiceName/MethodName.

Det finns vissa scenarier när en app behöver inkludera en sökväg med gRPC-anrop. Till exempel när en ASP.NET Core gRPC-app finns i en IIS-katalog och katalogen måste inkluderas i begäran. När en sökväg krävs kan den läggas till i gRPC-anropet med hjälp av den anpassade SubdirectoryHandler som anges nedan:

/// <summary>
/// A delegating handler that adds a subdirectory to the URI of gRPC requests.
/// </summary>
public class SubdirectoryHandler : DelegatingHandler
{
    private readonly string _subdirectory;

    public SubdirectoryHandler(HttpMessageHandler innerHandler, string subdirectory)
        : base(innerHandler)
    {
        _subdirectory = subdirectory;
    }

    protected override Task<HttpResponseMessage> SendAsync(
        HttpRequestMessage request, CancellationToken cancellationToken)
    {
        var old = request.RequestUri;

        var url = $"{old.Scheme}://{old.Host}:{old.Port}";
        url += $"{_subdirectory}{request.RequestUri.AbsolutePath}";
        request.RequestUri = new Uri(url, UriKind.Absolute);

        return base.SendAsync(request, cancellationToken);
    }
}

SubdirectoryHandler används när gRPC-kanalen skapas.

var handler = new SubdirectoryHandler(new HttpClientHandler(), "/MyApp");

var channel = GrpcChannel.ForAddress("https://localhost:5001", new GrpcChannelOptions { HttpHandler = handler });
var client = new Greet.GreeterClient(channel);

var reply = await client.SayHelloAsync(new HelloRequest { Name = ".NET" });

Föregående kod:

• Skapar en SubdirectoryHandler med sökvägen /MyApp.
• Konfigurerar en kanal att använda SubdirectoryHandler.
• Anropar gRPC-tjänsten med SayHelloAsync. GRPC-anropet skickas till https://localhost:5001/MyApp/greet.Greeter/SayHello.

Du kan också konfigurera en klientfabrik med SubdirectoryHandler genom att använda AddHttpMessageHandler.

gRPC-samtalstimeout från HttpClient.Timeout

HttpClient har konfigurerats med en tidsgräns på 100 sekunder som standard. Om en GrpcChannel har konfigurerats för att använda ett HttpClientavbryts långvariga gRPC-strömningsanrop om de inte slutförs inom tidsgränsen.

System.OperationCanceledException: The request was canceled due to the configured HttpClient.Timeout of 100 seconds elapsing.

Det finns ett par sätt att åtgärda det här felet. Den första är att konfigurera HttpClient.Timeout till ett större värde. Timeout.InfiniteTimeSpan inaktiverar tidsgränsen:

var handler = new HttpClientHandler();
handler.ServerCertificateCustomValidationCallback = 
    HttpClientHandler.DangerousAcceptAnyServerCertificateValidator;

var httpClient = new HttpClient(handler) { Timeout = Timeout.InfiniteTimeSpan };
var channel = GrpcChannel.ForAddress("https://localhost:5001",
    new GrpcChannelOptions { HttpClient = httpClient });
var client = new Greeter.GreeterClient(channel);

Du kan också undvika att skapa HttpClient och ställa in GrpcChannel.HttpHandler i stället:

var handler = new HttpClientHandler();
handler.ServerCertificateCustomValidationCallback = 
    HttpClientHandler.DangerousAcceptAnyServerCertificateValidator;

var channel = GrpcChannel.ForAddress("https://localhost:5001",
    new GrpcChannelOptions { HttpHandler = handler });
var client = new Greeter.GreeterClient(channel);

I det här dokumentet beskrivs vanliga problem när du utvecklar gRPC-appar på .NET.

Matchningsfel mellan klient- och tjänst-SSL/TLS-konfiguration

GRPC-mallen och exemplen använder TLS (Transport Layer Security) för att skydda gRPC-tjänster som standard. gRPC-klienter måste använda en säker anslutning för att anropa skyddade gRPC-tjänster.

Du kan kontrollera att ASP.NET Core gRPC-tjänsten använder TLS i loggarna som skrevs vid appstart. Tjänsten lyssnar på en HTTPS-slutpunkt:

info: Microsoft.Hosting.Lifetime[0]
      Now listening on: https://localhost:5001
info: Microsoft.Hosting.Lifetime[0]
      Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
      Hosting environment: Development

.NET-klienten måste använda https i serveradressen för att göra anrop med en säker anslutning:

static async Task Main(string[] args)
{
    // The port number(5001) must match the port of the gRPC server.
    var channel = GrpcChannel.ForAddress("https://localhost:5001");
    var client = new Greet.GreeterClient(channel);
}

Alla gRPC-klientimplementeringar stöder TLS. gRPC-klienter från andra språk kräver vanligtvis den kanal som konfigurerats med SslCredentials. SslCredentials anger det certifikat som klienten ska använda och måste användas i stället för osäkra autentiseringsuppgifter. Exempel på hur du konfigurerar olika gRPC-klientimplementeringar för användning av TLS finns i gRPC-autentisering.

Anropa en gRPC-tjänst med ett ej betrott/ogiltigt certifikat

.NET gRPC-klienten kräver att tjänsten har ett betrott certifikat. Följande felmeddelande returneras när du anropar en gRPC-tjänst utan ett betrott certifikat:

Unhandled exception. System.Net.Http.HttpRequestException: SSL-anslutningen kunde inte upprättas, se inre undantag. >--- System.Security.Authentication.AuthenticationException: Fjärrcertifikatet är ogiltigt enligt valideringsproceduren.

Du kan se det här felet om du testar din app lokalt och HTTPS-utvecklingscertifikatet för ASP.NET Core inte är pålitligt. Anvisningar för hur du åtgärdar det här problemet finns i Lita på ASP.NET Core HTTPS-utvecklingscertifikat i Windows och macOS.

Om du anropar en gRPC-tjänst på en annan dator och inte kan lita på certifikatet kan gRPC-klienten konfigureras för att ignorera det ogiltiga certifikatet. Följande kod används HttpClientHandler.ServerCertificateCustomValidationCallback för att tillåta anrop utan ett betrott certifikat:

var handler = new HttpClientHandler();
handler.ServerCertificateCustomValidationCallback = 
    HttpClientHandler.DangerousAcceptAnyServerCertificateValidator;

var channel = GrpcChannel.ForAddress("https://localhost:5001",
    new GrpcChannelOptions { HttpHandler = handler });
var client = new Greet.GreeterClient(channel);

GRPC-klientfabriken tillåter anrop utan ett betrott certifikat. ConfigurePrimaryHttpMessageHandler Använd tilläggsmetoden för att konfigurera hanteraren på klienten:

services
    .AddGrpcClient<Greeter.GreeterClient>(o =>
    {
        o.Address = new Uri("https://localhost:5001");
    })
    .ConfigurePrimaryHttpMessageHandler(() =>
    {
        var handler = new HttpClientHandler();
        handler.ServerCertificateCustomValidationCallback = 
            HttpClientHandler.DangerousAcceptAnyServerCertificateValidator;

        return handler;
    });

Anropa osäkra gRPC-tjänster med .NET-klienten

.NET gRPC-klienten kan anropa osäkra gRPC-tjänster genom att http ange serveradressen. Till exempel GrpcChannel.ForAddress("http://localhost:5000").

Det finns några ytterligare krav för att anropa osäkra gRPC-tjänster beroende på vilken .NET-version en app använder:

• .NET 5 eller senare kräver Grpc.Net.Client version 2.32.0 eller senare.

• .NET Core 3.x kräver ytterligare konfiguration. Appen måste ange växeln System.Net.Http.SocketsHttpHandler.Http2UnencryptedSupport till true:

  // This switch must be set before creating the GrpcChannel/HttpClient.
  AppContext.SetSwitch(
      "System.Net.Http.SocketsHttpHandler.Http2UnencryptedSupport", true);
  
  // The port number(5000) must match the port of the gRPC server.
  var channel = GrpcChannel.ForAddress("http://localhost:5000");
  var client = new Greet.GreeterClient(channel);
  

Växeln System.Net.Http.SocketsHttpHandler.Http2UnencryptedSupport krävs endast för .NET Core 3.x. Det gör ingenting i .NET 5 och krävs inte.

Det går inte att starta ASP.NET Core gRPC-appen på macOS

Kestrel stöder inte HTTP/2 med TLS på macOS före .NET 8. Mallen och exemplen ASP.NET Core gRPC använder TLS som standard. Följande felmeddelande visas när du försöker starta gRPC-servern:

Det går inte att binda till https://localhost:5001 i IPv4-loopback-gränssnittet: "HTTP/2 via TLS stöds inte på macOS på grund av att ALPN-stöd saknas."

Om du vill undvika det här problemet i .NET 7 eller tidigare konfigurerar du Kestrel och gRPC-klienten att använda HTTP/2 utan TLS. Du bör bara göra detta under utvecklingen. Om du inte använder TLS kommer gRPC-meddelanden att skickas utan kryptering.

Kestrel måste konfigurera en HTTP/2-slutpunkt utan TLS i Program.cs:

public static IHostBuilder CreateHostBuilder(string[] args) =>
    Host.CreateDefaultBuilder(args)
        .ConfigureWebHostDefaults(webBuilder =>
        {
            webBuilder.ConfigureKestrel(options =>
            {
                // Setup a HTTP/2 endpoint without TLS.
                options.ListenLocalhost(5000, o => o.Protocols = 
                    HttpProtocols.Http2);
            });
            webBuilder.UseStartup<Startup>();
        });

När en HTTP/2-slutpunkt har konfigurerats utan TLS måste slutpunktens ListenOptions.Protocols anges till HttpProtocols.Http2. HttpProtocols.Http1AndHttp2 kan inte användas eftersom TLS krävs för att förhandla om HTTP/2. Utan TLS ändras alla anslutningar till slutpunkten standardmässigt till HTTP/1.1, och gRPC-anrop misslyckas.

GRPC-klienten måste också konfigureras för att inte använda TLS. Mer information finns i Anropa osäkra gRPC-tjänster med .NET-klienten.

gRPC C#-komponenter genereras inte från .proto-filer

gRPC-kodgenerering av konkreta klienter och tjänstbasklasser kräver att protobuf-filer och verktyg refereras från ett projekt. Du måste inkludera:

• .proto filer som du vill använda i <Protobuf> objektgruppen. Importerade .proto filer måste refereras av projektet.
• Paketreferens till gRPC-verktygspaketet Grpc.Tools.

Mer information om hur du genererar GRPC C#-tillgångar finns i gRPC-tjänster med C#.

En ASP.NET Core-webbapp som är värd för gRPC-tjänster behöver bara den tjänstbasklass som genereras:

<ItemGroup>
  <Protobuf Include="Protos\greet.proto" GrpcServices="Server" />
</ItemGroup>

En gRPC-klientapp som gör gRPC-anrop behöver bara den konkreta klient som genereras:

<ItemGroup>
  <Protobuf Include="Protos\greet.proto" GrpcServices="Client" />
</ItemGroup>

WPF-projekt kan inte generera GRPC C#-tillgångar från .proto filer

WPF-projekt har ett känt problem som hindrar gRPC-kodgenerering från att fungera korrekt. Alla gRPC-typer som genereras i ett WPF-projekt genom att referera till Grpc.Tools och .proto filer skapar kompileringsfel när de används:

fel CS0246: Det gick inte att hitta typen eller namnområdets namn "MyGrpcServices" (saknar du ett användningsdirektiv eller en sammansättningsreferens?)

Du kan lösa det här problemet genom att:

1. Skapa ett nytt .NET-klassbiblioteksprojekt.
2. I det nya projektet lägger du till referenser för att aktivera C#-kodgenerering från .proto filer:
   • Lägg till följande paketreferenser:
     • Grpc.Tools
     • Grpc.Net.Client
     • Google.Protobuf
   • Lägg till .proto filer i <Protobuf> objektgruppen.
3. I WPF-programmet lägger du till en referens till det nya projektet.

WPF-programmet kan använda de gRPC-genererade typerna från det nya klassbiblioteksprojektet.

Anropa gRPC-tjänster som finns i en underkatalog

Sökvägskomponenten för en gRPC-kanals adress ignoreras när gRPC-anrop görs. Till exempel GrpcChannel.ForAddress("https://localhost:5001/ignored_path") används ignored_path inte vid routning av gRPC-anrop för tjänsten.

Adresssökvägen ignoreras eftersom gRPC har en standardiserad, normativ adressstruktur. En gRPC-adress kombinerar paket-, tjänst- och metodnamnen: https://localhost:5001/PackageName.ServiceName/MethodName.

Det finns vissa scenarier när en app behöver inkludera en sökväg med gRPC-anrop. Till exempel när en ASP.NET Core gRPC-app finns i en IIS-katalog och katalogen måste inkluderas i begäran. När en sökväg krävs kan den läggas till i gRPC-anropet med hjälp av den anpassade SubdirectoryHandler som anges nedan:

/// <summary>
/// A delegating handler that adds a subdirectory to the URI of gRPC requests.
/// </summary>
public class SubdirectoryHandler : DelegatingHandler
{
    private readonly string _subdirectory;

    public SubdirectoryHandler(HttpMessageHandler innerHandler, string subdirectory)
        : base(innerHandler)
    {
        _subdirectory = subdirectory;
    }

    protected override Task<HttpResponseMessage> SendAsync(
        HttpRequestMessage request, CancellationToken cancellationToken)
    {
        var old = request.RequestUri;

        var url = $"{old.Scheme}://{old.Host}:{old.Port}";
        url += $"{_subdirectory}{request.RequestUri.AbsolutePath}";
        request.RequestUri = new Uri(url, UriKind.Absolute);

        return base.SendAsync(request, cancellationToken);
    }
}

SubdirectoryHandler används när gRPC-kanalen skapas.

var handler = new SubdirectoryHandler(new HttpClientHandler(), "/MyApp");

var channel = GrpcChannel.ForAddress("https://localhost:5001", new GrpcChannelOptions { HttpHandler = handler });
var client = new Greet.GreeterClient(channel);

var reply = await client.SayHelloAsync(new HelloRequest { Name = ".NET" });

Föregående kod:

• Skapar en SubdirectoryHandler med sökvägen /MyApp.
• Konfigurerar en kanal att använda SubdirectoryHandler.
• Anropar gRPC-tjänsten med SayHelloAsync. GRPC-anropet skickas till https://localhost:5001/MyApp/greet.Greeter/SayHello.

Du kan också konfigurera en klientfabrik med SubdirectoryHandler genom att använda AddHttpMessageHandler.

gRPC-samtalstimeout från HttpClient.Timeout

HttpClient har konfigurerats med en tidsgräns på 100 sekunder som standard. Om en GrpcChannel har konfigurerats för att använda ett HttpClientavbryts långvariga gRPC-strömningsanrop om de inte slutförs inom tidsgränsen.

System.OperationCanceledException: The request was canceled due to the configured HttpClient.Timeout of 100 seconds elapsing.

Det finns ett par sätt att åtgärda det här felet. Den första är att konfigurera HttpClient.Timeout till ett större värde. Timeout.InfiniteTimeSpan inaktiverar tidsgränsen:

var handler = new HttpClientHandler();
handler.ServerCertificateCustomValidationCallback = 
    HttpClientHandler.DangerousAcceptAnyServerCertificateValidator;

var httpClient = new HttpClient(handler) { Timeout = Timeout.InfiniteTimeSpan };
var channel = GrpcChannel.ForAddress("https://localhost:5001",
    new GrpcChannelOptions { HttpClient = httpClient });
var client = new Greeter.GreeterClient(channel);

Du kan också undvika att skapa HttpClient och ställa in GrpcChannel.HttpHandler i stället:

var handler = new HttpClientHandler();
handler.ServerCertificateCustomValidationCallback = 
    HttpClientHandler.DangerousAcceptAnyServerCertificateValidator;

var channel = GrpcChannel.ForAddress("https://localhost:5001",
    new GrpcChannelOptions { HttpHandler = handler });
var client = new Greeter.GreeterClient(channel);