Cannot create new gRPC project on macOS

[cecilphillip]

I’m unable to run a new gRPC server project on macOS Mojave (10.14.5). I get that ALPN isn’t supported in macOS but is there something that can be added to the template to help with the
developer experience in the templates or via documentation?

Steps

dotnet new grpc
dotnet new run

Results

warn: Microsoft.AspNetCore.Server.Kestrel[0]
      Unable to bind to https://localhost:5001 on the IPv4 loopback interface: 'HTTP/2 over TLS is not supported on OSX due to missing ALPN support.'.
warn: Microsoft.AspNetCore.Server.Kestrel[0]
      Unable to bind to https://localhost:5001 on the IPv6 loopback interface: 'HTTP/2 over TLS is not supported on OSX due to missing ALPN support.'.
crit: Microsoft.AspNetCore.Server.Kestrel[0]
      Unable to start Kestrel.
System.IO.IOException: Failed to bind to address https://localhost:5001.
 ---> System.AggregateException: One or more errors occurred. (HTTP/2 over TLS is not supported on OSX due to missing ALPN support.) (HTTP/2 over TLS is not supported on OSX due to missing ALPN support.)
 ---> System.NotSupportedException: HTTP/2 over TLS is not supported on OSX due to missing ALPN support.
   at Microsoft.AspNetCore.Server.Kestrel.Https.Internal.HttpsConnectionMiddleware..ctor(ConnectionDelegate next, HttpsConnectionAdapterOptions options, ILoggerFactory loggerFactory)
   at Microsoft.AspNetCore.Hosting.ListenOptionsHttpsExtensions.<>c__DisplayClass12_0.<UseHttps>b__0(ConnectionDelegate next)
   at Microsoft.AspNetCore.Server.Kestrel.Core.ListenOptions.Build()
   at Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServer.<>c__DisplayClass21_0`1.<<StartAsync>g__OnBind|0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.AddressBinder.BindEndpointAsync(ListenOptions endpoint, AddressBindContext context)
   at Microsoft.AspNetCore.Server.Kestrel.Core.LocalhostListenOptions.BindAsync(AddressBindContext context)
   --- End of inner exception stack trace ---
 ---> (Inner Exception #1) System.NotSupportedException: HTTP/2 over TLS is not supported on OSX due to missing ALPN support.
   at Microsoft.AspNetCore.Server.Kestrel.Https.Internal.HttpsConnectionMiddleware..ctor(ConnectionDelegate next, HttpsConnectionAdapterOptions options, ILoggerFactory loggerFactory)
   at Microsoft.AspNetCore.Hosting.ListenOptionsHttpsExtensions.<>c__DisplayClass12_0.<UseHttps>b__0(ConnectionDelegate next)
   at Microsoft.AspNetCore.Server.Kestrel.Core.ListenOptions.Build()
   at Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServer.<>c__DisplayClass21_0`1.<<StartAsync>g__OnBind|0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.AddressBinder.BindEndpointAsync(ListenOptions endpoint, AddressBindContext context)
   at Microsoft.AspNetCore.Server.Kestrel.Core.LocalhostListenOptions.BindAsync(AddressBindContext context)<---

Workaround

 webBuilder.UseStartup<Startup>()
   .ConfigureKestrel(options =>
   {
       options.Limits.MinRequestBodyDataRate = null;

       options.ListenAnyIP(50050,
             listenOptions => { listenOptions.Protocols = HttpProtocols.Http1; });

       options.ListenAnyIP(50051,
          listenOptions => { listenOptions.Protocols = HttpProtocols.Http2; });
  });

[JamesNK]

The only option for users is to setup HTTP/2 without TLS. That could be added as a comment to docs or the template @shirhatti

[shirhatti]

@cecilphillip We decided against making the gRPC template platform-specific and as such this is expected behavior. Per your suggestion, I've filed a docs bug to improve the documentation around this scenario.

As an aside, we're also looking at improving the docker tooling experience (integrated in VS Code) which may provide another viable solution for developing grpc-dotnet on MacOS

[JamesNK]

Docs added - https://docs.microsoft.com/aspnet/core/grpc/aspnetcore#grpc-and-aspnet-core-on-macos

[layomia]

Docs added - https://docs.microsoft.com/aspnet/core/grpc/aspnetcore#grpc-and-aspnet-core-on-macos

I couldn't find the information needed from this url.
This one helped though: https://docs.microsoft.com/aspnet/core/grpc/troubleshoot?view=aspnetcore-3.0&branch=master#unable-to-start-aspnet-core-grpc-app-on-macos.

[JamesNK]

Yes, the section moved to a dedicated troubleshooting page.

[dichaos]

Is this something you will be adding in the future? Removing security is not an acceptable workaround.

[JamesNK]

ASP.NET Core uses the operating system for HTTP/2 TLS support. macOS may support hosting servers with HTTP/2 TLS in the future, Windows 7 will not.

Like the troubleshooting documentation says - this is just for development. In production you should host your apps on an OS that does support HTTP/2 TLS.

[entropitor]

I want to explore a terraform provider in f#. However, that would mean that there needs to be local mac os x support for HTTP/2 "in production" (because production means running locally and talking to another binary, locally). I guess this is completely not possible to do then? Not even with newer versions of .net?

[JamesNK]

https://docs.microsoft.com/en-us/aspnet/core/grpc/troubleshoot?view=aspnetcore-3.1#unable-to-start-aspnet-core-grpc-app-on-macos

[entropitor]

But what if you need the security because you are writing a plugin for a program that wants to communicate over HTTPS (with TLS)? I guess that's not an option? Is there a ticket internally / externally to track this?

[JamesNK]

dotnet/runtime#27727

[razfriman]

Is there any update on this given the new Mac OS Big Sur update?

[JamesNK]

I don't know. Ask at dotnet/runtime#27727

[Zoney]

Does anyone encountered this? Testing out things locally on MacOS.

      System.ArgumentException: CallCredentials can't be composed with InsecureCredentials. CallCredentials must be used with secure channel credentials like SslCredentials.
         at Grpc.Core.ChannelCredentials.CompositeChannelCredentials..ctor(ChannelCredentials channelCredentials, CallCredentials callCredentials)
         at Grpc.Core.ChannelCredentials.Create(ChannelCredentials channelCredentials, CallCredentials callCredentials)
         at GrpcTester.Services.GreeterService.CallGreeter(CallGreeterRequest request, ServerCallContext context) in /Users/oyvindbs/code/github/egdeconsulting/egde-communication/src/GrpcTester/Services/GreeterService.cs:line 32
         at Grpc.Shared.Server.UnaryServerMethodInvoker`3.AwaitInvoker(Task`1 invokerTask, GrpcActivatorHandle`1 serviceHandle)
         at Grpc.Shared.Server.UnaryServerMethodInvoker`3.AwaitInvoker(Task`1 invokerTask, GrpcActivatorHandle`1 serviceHandle)
         at Grpc.AspNetCore.Server.Internal.CallHandlers.UnaryServerCallHandler`3.HandleCallAsyncCore(HttpContext httpContext, HttpContextServerCallContext serverCallContext)
         at Grpc.AspNetCore.Server.Internal.CallHandlers.ServerCallHandlerBase`3.<HandleCallAsync>g__AwaitHandleCall|8_0(HttpContextServerCallContext serverCallContext, Method`2 method, Task handleCall)

The workarounds only fits if I don't set Credentials

var credentials = CallCredentials.FromInterceptor((_, metadata) =>
{
    metadata.Add("Authorization", $"Bearer {token}");
    return Task.CompletedTask;
});

var channel = GrpcChannel.ForAddress("http://localhost:5176", new GrpcChannelOptions
{
    Credentials = ChannelCredentials.Create(ChannelCredentials.Insecure, credentials),
});

Really picky on the https – good thing, but not when I'm playing around on localhost.

[JamesNK]

There is a new UnsafeUseInsecureChannelCallCredentials setting. It allows call credentials to be used with HTTP.

Unfortunately, right now, it doesn't work with ChannelCredentials.Create. See #1802 for the upcoming fix.