Hi @moodya , have you checked out the docs at https://docs.microsoft.com/en-us/aspnet/core/tutorials/grpc/grpc-start?view=aspnetcore-3.0&tabs=visual-studio ?

If you're running into a problem, please let us know and we can investigate.

Yeah I've already built a service that's running as a generic hosted service. I've ported it to the new asp net core 3 template and got it working running on self hosted kestrel, but currently looking at hosting it behind iis and hopefully deploying it as an app service in Azure. I can't get the former (iis) to work.

Get Outlook for Androidhttps://aka.ms/ghei36

From: Eilon Lipton notifications@github.com
Sent: Wednesday, April 3, 2019 6:06:17 PM
To: aspnet/AspNetCore
Cc: moodya; Mention
Subject: Re: [aspnet/AspNetCore] Host grpc service in iis or as an app service? (#9020)

Hi @moodyahttps://github.com/moodya , have you checked out the docs at https://docs.microsoft.com/en-us/aspnet/core/tutorials/grpc/grpc-start?view=aspnetcore-3.0&tabs=visual-studio ?

If you're running into a problem, please let us know and we can investigate.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/aspnet/AspNetCore/issues/9020#issuecomment-479575937, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AlUvPONL4H1tZ-pHOakDspdkXLLgThWbks5vdN-JgaJpZM4cZ2SG.

I can't find any examples of how to do this, so maybe it's not supported yet

Get Outlook for Androidhttps://aka.ms/ghei36

From: Alain Moody alainmoody@hotmail.com
Sent: Wednesday, April 3, 2019 6:11:06 PM
To: aspnet/AspNetCore; aspnet/AspNetCore
Cc: Mention
Subject: Re: [aspnet/AspNetCore] Host grpc service in iis or as an app service? (#9020)

Yeah I've already built a service that's running as a generic hosted service. I've ported it to the new asp net core 3 template and got it working running on self hosted kestrel, but currently looking at hosting it behind iis and hopefully deploying it as an app service in Azure. I can't get the former (iis) to work.

Get Outlook for Androidhttps://aka.ms/ghei36

From: Eilon Lipton notifications@github.com
Sent: Wednesday, April 3, 2019 6:06:17 PM
To: aspnet/AspNetCore
Cc: moodya; Mention
Subject: Re: [aspnet/AspNetCore] Host grpc service in iis or as an app service? (#9020)

Hi @moodyahttps://github.com/moodya , have you checked out the docs at https://docs.microsoft.com/en-us/aspnet/core/tutorials/grpc/grpc-start?view=aspnetcore-3.0&tabs=visual-studio ?

If you're running into a problem, please let us know and we can investigate.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/aspnet/AspNetCore/issues/9020#issuecomment-479575937, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AlUvPONL4H1tZ-pHOakDspdkXLLgThWbks5vdN-JgaJpZM4cZ2SG.

@shirhatti - any idea on this?

Can't host gRPC in IIS/Azure App Service.
The HTTP/2 implementation of Http.Sys does not support HTTP response trailing headers which gRPC relies on.

Thanks for the prompt response. How would you recommend hosting a grpc service in a production scenario at the moment? Also, are you aware of any timescales when a grpc service will be host-able on iis / app service?

Get Outlook for Androidhttps://aka.ms/ghei36

From: Sourabh Shirhatti notifications@github.com
Sent: Wednesday, April 3, 2019 7:13:23 PM
To: aspnet/AspNetCore
Cc: moodya; Mention
Subject: Re: [aspnet/AspNetCore] Host grpc service in iis or as an app service? (#9020)

Can't host gRPC in IIS/Azure App Service.
The HTTP/2 implementation of Http.Sys does not support HTTP response trailing headers which gRPC relies on.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/aspnet/AspNetCore/issues/9020#issuecomment-479600486, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AlUvPNHH4-HhNsSAtugTw0MzzNco6c76ks5vdO9DgaJpZM4cZ2SG.

The recommended approach is to host your gRPC service on AKS.

As far as App Service timelines go, I'd defer to @stefsch

Thanks for getting back to me. In terms of aks Vs service fabric in terms of hosting the grpc service is aks the better choice? If so, why?

Get Outlook for Androidhttps://aka.ms/ghei36

From: Sourabh Shirhatti notifications@github.com
Sent: Monday, April 8, 2019 7:31:45 AM
To: aspnet/AspNetCore
Cc: moodya; Mention
Subject: Re: [aspnet/AspNetCore] Host grpc service in iis or as an app service? (#9020)

The recommended approach is to host your gRPC service on AKS.

As far as App Service timelines go, I'd defer to @stefschhttps://github.com/stefsch

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/aspnet/AspNetCore/issues/9020#issuecomment-480701227, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AlUvPLwQW8HCp-YXsz6yNaK_RH7jbZzWks5veuJRgaJpZM4cZ2SG.

I'm currently expecting issues to do this. I got a gRPC service running well using aspnetcore 3 preview 3 and Kestrel. But, an error about trailers appears using IIS when the service send the response (the request is well received) :
gPRC error => 2 UNKNOWN: No status received)
Dotnet error => "Trailers are not supported for this response" in Microsoft.AspNetCore.Http.ResponseTrailerExtensions.AppendTrailer(HttpResponse response, String trailerName, StringValues trailerValues) at Grpc.AspNetCore.Server.Internal.HttpResponseExtensions.ConsolidateTrailers...

As per messages above don't think iis supports hosting a grpc service

Get Outlook for Androidhttps://aka.ms/ghei36

From: alustrement notifications@github.com
Sent: Thursday, April 25, 2019 10:57:42 AM
To: aspnet/AspNetCore
Cc: moodya; Mention
Subject: Re: [aspnet/AspNetCore] Host grpc service in iis or as an app service? (#9020)

I'm currently expecting issues to do this. I got a gRPC service running well using aspnetcore 3 preview 3 and Kestrel. But, an error about trailers appears using IIS when the service send the response (the request is well received) :
gPRC error => 2 UNKNOWN: No status received)
Dotnet error => "Trailers are not supported for this response" in Microsoft.AspNetCore.Http.ResponseTrailerExtensions.AppendTrailer(HttpResponse response, String trailerName, StringValues trailerValues) at Grpc.AspNetCore.Server.Internal.HttpResponseExtensions.ConsolidateTrailers...

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/aspnet/AspNetCore/issues/9020#issuecomment-486607635, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AJKS6PEAJ2UKKH2QIKNTCZDPSF6BNANCNFSM4HDHMSDA.

Following this exchange https://forums.iis.net/p/1241598/2147837.aspx?p=True&t=636917571046786374, it seems that is not the responsibilty of the web server to handle gRPC. gPRC use HTTP/2, IIS supports HTTP/2, so it must works. If it's not, it's a bug from IIS or, more possible, from dotnetcore.

According to do the Microsoft guys in the messages above iis doesn't support the trailing headers required to host a grpc service. This means you can't host one in iis or as an app service at the moment.

Get Outlook for Androidhttps://aka.ms/ghei36

From: alustrement notifications@github.com
Sent: Thursday, April 25, 2019 11:39:08 AM
To: aspnet/AspNetCore
Cc: moodya; Mention
Subject: Re: [aspnet/AspNetCore] Host grpc service in iis or as an app service? (#9020)

Following this exchange https://forums.iis.net/p/1241598/2147837.aspx?p=True&t=636917571046786374, it seems that is not the responsibilty of the web server to handle gRPC. gPRC use HTTP/2, IIS supports HTTP/2, so it must works. If it's not, it's a bug from IIS or, more possible, from dotnetcore.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/aspnet/AspNetCore/issues/9020#issuecomment-486620151, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AJKS6PBQO4427EYN67SI7A3PSGC4ZANCNFSM4HDHMSDA.

Thanks, I missed it and it makes sense with my issue.
@shirhatti the support is planned on the roadmap ?

We (IIS) are currently evaluating whether to support HTTP response trailers. No roadmaps/commitments I can speak to yet.

@shirhatti Given gRPC seems to be a major feature of .NET Core 3 (https://github.com/grpc/grpc-dotnet), it would be a real shame if it's not hostable in IIS/App Service given so many .NET web applications are hosted on those. I hope the availability of that feature in .NET Core helps drive your roadmap.

I fully agree with @jbrantly. gRPC is advertised as one of the main features of .NET Core 3.
It should be hostable in IIS/Azure App Services.
@shirhatti please consider adding this to the roadmap

I also agree.

Get Outlook for Androidhttps://aka.ms/ghei36

From: Tomasz Jagusz notifications@github.com
Sent: Friday, April 26, 2019 9:42:58 AM
To: aspnet/AspNetCore
Cc: moodya; Mention
Subject: Re: [aspnet/AspNetCore] Host grpc service in iis or as an app service? (#9020)

I fully agree with @jbrantlyhttps://github.com/jbrantly. gRPC is advertised as one of the main features of .NET Core 3.
It should be hostable in IIS/Azure App Services.
@shirhattihttps://github.com/shirhatti please consider adding this to the roadmap

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/aspnet/AspNetCore/issues/9020#issuecomment-486977989, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AJKS6PENWT46GCJ7GQGEGPTPSK6BFANCNFSM4HDHMSDA.

I couldn't agree more.

We're looking into it. It requires both Windows kernel changes and IIS changes.

@davidfowl will this be possible when .NET Core 3 is released?
Ability to host GRPC in App Services is a blocker for me.

Well is May 29 of 2019, and yet there is not signal that this will be possible. I'm looking for host a GRPC service in IIS and add a certificate to use HTTPS :(

No it's not possible on IIS, we're working on getting changes but it will be a slow process (as it requires a windows update).

I roughly lost about 3 days... thanks iis

Hi @davidfowl
Any update?

@davidfowl any chance this might get added before .NET Core 3.0 gets released? Or should we wait for 3.1 or 5.0?

No as it requires windows changes. It’s not going to be part of 3.0 and it will require the latest version of Windows (whatever that is at the time) to get these features. There’s no ETA

Hmm, I'm in the middle of planning a service fabric implementation that is going to be using gRPC based stateless services and reliable actors, on top of dotnet core 3. Is this going to bite me in the ass? If I host on SF, I guess I'm going to be using kestrel at the core? Time to prototype.

@oising same boat here - but we're slowly rolling towards k8s + linux containers, so this kind of helps push us that way anyhow.

I'm just plus 1'ing this as I have been playing around with gRPC now for a while and want to finally start adopting it in some my client projects so was looking at deployment work flows. I'm a little disheartened by the amount of operational overhead this would be to deploy in production with .net core.

Also took me days to figure out IIS was the problem. Really looking for a fix. Any workarounds?

@bingoo without Windows support and IIS You are out of luck. You can use Service Fabric but I have no experience with it. I hope that it will be possible to host it on IIS or in Azure in a simple way.
For current projects Grpc isn't an option for me because of this issue.

Would be nice if this was a big bold warning on the docs...

IIS hosting isn't supported yet. App Services do use Windows Server 2016 + IIS as it's backend by default, but now it also supports Linux / Containers. If you just want to deploy GRPC on Azure App Service, you can do it now with a Linux Container. But the App Service Plan can't be shared with a Windows hosting plan. You will need to spend extra money for a new App Service Plan backed by Linux Container.

The best way is to use AKS then use Ambassador. Ambassador is an Envoy based api gateway that runs as a container inside Kubernetes. It allows you to proxy both grpc and grpc-web, eg. browser to grpc server and also a grpc client, perhaps a c# one to a grpc server. If you want frontend js to receive gRPC calls you need grpc web and a proxy because browsers also do not support the http2 response trailing headers properly. Grpc Web uses Envoy by default so that is why Ambassador is best.

If you just want to deploy GRPC on Azure App Service, you can do it now with a Linux Container

@EdiWang This is currently not supported on App Service for Linux. We are currently working with App Service to enable this, but I don't have any ETA to share

Hello good people
Im a bit confused, so we cant have grpc service in azure.
But azure itself is using grpc, the Azure Functions Languge Worker Protobuf.
https://github.com/Azure/azure-functions-language-worker-protobuf
Or am I missing something here?
Trying to understand :confused:

@GoranHalvarsson You can have gRPC services in Azure, you just can't run them in Azure App Services yet.

@markrendle Thanks for answering. So how can I use/setup a gRpc service in Azure?

Would be nice if this was a big bold warning on the docs...

https://github.com/aspnet/AspNetCore.Docs/issues/14684

@markrendle Thanks for answering. So how can I use/setup a gRpc service in Azure?

By not using IIS, which means using Service Fabric, or AKS - both using raw Kestrel. SF and AKS have different characteristics. Google for "Service Fabric vs AKS" and grab a big coffee.

I have created step by step guide to create test and deploy grpc service using .NET Core 3.0
https://github.com/rupeshtech/k8s-grpc-dotntecore

I just looked into this issue, so I haven't tried anything yet; but has anyone tried using Azure Web App for (Container https://azure.microsoft.com/en-us/services/app-service/containers/)?

I'm running a bunch of docker based microservices on Azure App Services and have had very little issues and have allowed me to work around other limiting characteristics of the OOB App Service offering.

@ikemtz gRPC works when using kestral (ie: when running in containers).

@rupeshtech Thank you, but your article is not related to the issue.

This issue is for hosting gRPC (or any app using trailing headers) in IIS or Azure App Service.

Would be nice if this was a big bold warning on the docs...

aspnet/AspNetCore.Docs#14684

This is now implemented.

@ikemtz I've attempted to run a basic test for using gRPC in a Linux container running in a Azure Web App for Containers and it wouldn't work for me. Couldn't find any errors reported anywhere, but the container wouldn't even respond to HTTP pings.
It's a shame. I'm not prepared to move to AKS just to get this functionality, so I guess I'll stick with good old fashioned HTTP services for now.

@searus if you use a virtual machine instead(running in azure)

@GoranHalvarsson I'm not prepeared to move from PaaS to IaaS just to make use of this technology. I'll just wait until Azure App Service can support this.

@davidfowl Any roadmap on this?

Deploying to a container using Kestral is fine but its the ease of say
using Lets Encrypt in IIS or an app service that's really holding me back.
If there are any concise guides on how to run a custom domain with lets
encrypt on kestrel in a container then I'm jumping into gRPC head first
else it's very tough to justify the overhead of creating some custom
deployment just to accommodate the new stack.

On Wed, Oct 16, 2019 at 6:46 AM Russell Seamer notifications@github.com
wrote:

@GoranHalvarsson https://github.com/GoranHalvarsson I'm not prepeared
to move from PaaS to IaaS just to make use of this technology. I'll just
wait until Azure App Service can support this.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/aspnet/AspNetCore/issues/9020?email_source=notifications&email_token=AMNAZYUWLYLGC5ZGB4GAFITQO2TCFA5CNFSM4HDHMSDKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBLFDDI#issuecomment-542527885,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AMNAZYTKUYYBWKSW6AMQDHTQO2TCFANCNFSM4HDHMSDA
.

With this, Azure Functions and anything else that sits on top of App Service can't really use gRPC and HTTP/2. A timeline would be nice, even for private/public previews.

We’re currently working on the changes in http.sys. After that we need to react to those changes in IIS and ARR. Then we need to update the version of Windows running in app service to take advantage of those changes in IIS.

Work has stated but it’s really hard to estimate how long it’ll take for customers to get it. We’ll keep you posted as things progress.

I feel like this is something I'm sadly not surprised about (that implementing new http functionality requires kernel updates). Obviously IIS doesn't exist on Linux / macosx but I'd be surprised if adding support for grpc to other we servers for other operating systems... need much in the way of kernel updatea.

Maybe this is a decent argument/example for decoupling... Just saying

I feel like this is something I'm sadly not surprised about (that implementing new http functionality requires kernel updates). Obviously IIS doesn't exist on Linux / macosx but I'd be surprised if adding support for grpc to other we servers for other operating systems... need much in the way of kernel updatea.

Maybe this is a decent argument/example for decoupling... Just saying

I agree. This probably something to do with IIS running some low level protocal that's tied directly too the kernal. It does seem strange but at least we've got confirmation this is being worked on and that adopting isn't completely blue sky.

Remember when you had to upgrade to Windows 8 to get WebSocket support? I do too 😄

Yes, we remember! Here is the scoop: gRPC is released in .NET-Core and we use Azure App Services so it is important to have some option, at least to test, ASAP. Can anyone tell us when this sync to the released .NET-Core capabilities will happen in Azure App Services? Or a feasible workaround. Thanks

Thank you for contacting us. Due to no activity on this issue we're closing it in an effort to keep our backlog clean. If you believe there is a concern related to the ASP.NET Core framework, which hasn't been addressed yet, please file a new issue.

@anurse how do we keep this issue open?

It got put in Discussions and tagged question. Reopened.

Is there any ETA on this yet?

Are there any viable alternatives to get gRPC working in a production environment?
I've looked at some stuff and it seems like hosting it on AKS is an option, I just want to make sure that we're not doing stuff that will not help us solve our problem.

We've currently been trying to get some kind of production environment running for these project:
IdentityServer project that talks to an API over gRPC
5 web portals that talk to an API over gRPC
The API that talks to a Discord Bot (ASP.NET Core) over gRPC.

We tried hosting them on a VPS but I don't know if we can actually host them in a production environment by just using kestrel if we want all of these applications to live on the same VPS.

Does anyone have an option for us so we can have multiple domains (1 domain, the rest are sub domains) with 1 IP address on 1 VPS runnning all the projects by only using Kestrel (because of the limitations in IIS, Http.Sys, windows).

(Or any other method that will enable us to host all of this ASAP)

Thanks in advance!

(EDIT)

We use Let's Encrypt ( https://github.com/natemcmaster/LetsEncrypt ) to get an SSL certificate

(EDIT 2)
We also tried contacting @davidfowl about this on twitter
https://twitter.com/DapperDino4/status/1204119195765682177 and
https://twitter.com/DapperDino4/status/1204119695344971778

Is there any ETA on this yet?

Adding @shirhatti and @Tratcher who have been working on this.

The timing of this is tricky to pin down right now. IIS is a Windows component, and depends upon http.sys, which is also a Windows component. Neither IIS, nor http.sys have sufficient HTTP/2 features to support gRPC. We have been working very closely with those teams to get the changes in, and they are all well on track for an upcoming release but won't be available until a Windows Server release with the appropriate changes goes live.

@JamesNK can you speak to the availability of alternatives like gRPC-web?

Context for people who don't know what gRPC-Web is: https://grpc.io/blog/state-of-grpc-web/. Because it uses HTTP/1.1, the Azure App Service restrictions won't apply to it. The downside is no HTTP/2 benefits (multiplexing, header compression), and no client or bidirectional streaming.

The gRPC-Web envoy reverse proxy is available now, but that's not easy to setup. And there is no .NET gRPC-Web client.

The ASP.NET Core team hasn't decided yet whether we're going to commit to support gRPC-Web officially. I'm looking at gRPC-Web now, and what it could look like in .NET Core. In a couple of weeks I can say more, and perhaps have an experimental preview for people to try out in January.

Since IIS doesn't support this, can netcore gRPC service be hosted behind Nginx?

@Dennis-Petrov I do exactly this. I followed this document https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/linux-nginx?view=aspnetcore-3.1 and gRPC runs great

Can I ask a stupid question: Why doesn't this work in an Azure App Service on linux App Service Plan?

Is IIS involved in that somewhere in the pipeline as well?

@searus There's common layers between frontend and App services regardless Linux/Windows. I.e. currently the App Service frontend receive the HTTP/2 connections, and then internally connections are proxied as "old" HTTP to individual app service workers. I'm sure it's in the works to fully support gRPC, but it takes some effort as internal components needs to be updated, tested and released.

Thanks @devlead.
I (perhaps naively) thought that a Linux App Service Plan was all Linux throughout.
I fully appreciate the effort involved here, and thanks for taking the time to explain.

I'm sure it's in the works to fully support gRPC

It definitely is in the works. We are actively working on it but can't guarantee a timeline (there are multiple independent teams that need to coordinate here). @devlead is correct about the Azure App Service Linux support. The front-end proxy is running IIS. It supports receiving HTTP/2 from the client, but when it proxies traffic to your app, it downgrades to HTTP/1.1. This was OK (though not ideal) for normal apps, but since gRPC requires HTTP/2 features, it's not suitable for those.

Yeah I've already built a service that's running as a generic hosted service. I've ported it to the new asp net core 3 template and got it working running on self hosted kestrel, but currently looking at hosting it behind iis and hopefully deploying it as an app service in Azure. I can't get the former (iis) to work.

@moodya can you share with us how you did that??

Yeah I've already built a service that's running as a generic hosted service. I've ported it to the new asp net core 3 template and got it working running on self hosted kestrel, but currently looking at hosting it behind iis and hopefully deploying it as an app service in Azure. I can't get the former (iis) to work.

@moodya can you share with us how you did that??

The gRPC template is self hosted kestrel by default. It's not going to work in app service for the reasons outlined in this thread.

While it cant be hosted in app service, lets say we host grpc service on aks, is there any problem to call grpc from app service? Will grpc client at least working on app service?

While it cant be hosted in app service, lets say we host grpc service on aks, is there any problem to call grpc from app service? Will grpc client at least working on app service?

Yes, clients should work. The limitation is only on inbound requests, not outbound.

Maybe stupid question, but why does it work if I am running the gRPC service in Debug with IIS Express? E.g. I have a web app (Razor Pages, .net core 3.1) that makes calls to a gRPC service [upgraded from a framework mvc app talking to a wcf service, if anyone cares]. If I debug them both on my workstation, with the gRPC service in IIS Express, the webapp can talk to the service just fine. Because of the proxying behavior @anurse described above, when the service is hosted in IIS, I get the exception that gRPC requires HTTP/2. Does IIS Express proxy to Kestrel differently than IIS?

Also, maybe not the place for this but I'd like to humbly ask that the page below be given a small explanation of the IIS/App Service proxying behavior. I (perhaps foolishly) spent an entire day trying to outsmart IIS because I thought I could force it to proxy in HTTP/2 if the app was running out-of-process in Kestrel https://docs.microsoft.com/en-us/aspnet/core/grpc/aspnetcore?view=aspnetcore-3.1&tabs=visual-studio#integration-with-aspnet-core-apis

IIS Express shouldn't work for all the same reasons IIS doesn't.

@Tratcher Ah yes you are correct. I was running the gRPC service as self hosted, not IIS Express. Thanks!

Does anyone have a tutorial on how to get this working in AKS? (bonus points for debugging with vs code in aks locally without having to rebuild containers so that we have the entire stack with .net core dev, through to deploy to azure using azure devops and aks).

Most importantly what are you using in AKS to proxy the web traffic to the AKS pods without having to use ngix in the pod itself (i.e. azure load balancer or something?)

While it cant be hosted in app service, lets say we host grpc service on aks, is there any problem to call grpc from app service? Will grpc client at least working on app service?

Yes, clients should work. The limitation is only on inbound requests, not outbound.

Unfortunately this does not seem to be the case with .Net Core 3.1 based Web App calling a grpc service (in this case Pyhton code running on a VM) when hosted on Azure Web Apps - times out. When running the exact same code from localhost the call goes through (same service VM).

@lyulyok can you collect diagnostics and open a separate issue? There are no known problems with the client here.

Does anyone have a tutorial on how to get this working in AKS?

Please open a new issue to discuss this or ask on Stack Overflow. Let's keep this thread on-topic, especially as there are many people interested in the status of gRPC on IIS and HTTP.sys and every comment pings every person who's on it. I'm going to hide off-topic comments, please feel free to post new issues if you have further questions.

Yeah I've already built a service that's running as a generic hosted service. I've ported it to the new asp net core 3 template and got it working running on self hosted kestrel, but currently looking at hosting it behind iis and hopefully deploying it as an app service in Azure. I can't get the former (iis) to work.

Experimental support for gRPC-Web in .NET is now available. gRPC-Web works with HTTP/1.1 and HTTP/2, and it runs in IIS and Azure App Service.

We're continuing to work towards HTTP/2 gRPC running in Azure App Service, but gRPC-Web is something you can use today. When work to support HTTP/2 in IIS and Azure App Service is complete it will be a simple process to switch a .NET app from gRPC-Web to HTTP/2 gRPC.

Blog post: https://devblogs.microsoft.com/aspnet/grpc-web-experiment
Documentation: https://docs.microsoft.com/aspnet/core/grpc/browser

I have grpc client running in app service and service running just fine in aks, in case anyone else want to try too

@andrew-vdb Can you post config please?

Hi @JamesNK,
related to your comment https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-579597202 and to the fact that gRpc-Web currently seems to be _an experimental project, not a committed product._

• Do I need gRpc-Web to deploy to IIS? Otherwise, isn't it possible at all?
• Do you have an ETA about when it will be possible to deploy to IIS without gRpc-Web?
• Do you have an ETA when gRpc-Web will be officially supported by Microsoft?

Do I need gRpc-Web to deploy to IIS? Otherwise, isn't it possible at all?

Currently gRPC over HTTP/2 doesn't work in IIS. gRPC-Web does work.

Do you have an ETA about when it will be possible to deploy to IIS without gRpc-Web?

No. It takes time for changes to be made to Windows and released to the public.

Do you have an ETA when gRpc-Web will be officially supported by Microsoft?

Not at the moment.

FYI
I have an application (ASP.Net Core 3.2.0-Preview1) in which I changed out a REST API DAL for a gRPC-Web DAL. I followed the guidance of the Steve Sanderson blog post. My solution can be run as either CSB or SSB and I was successful with gRPC-Web in both configurations (I did have to advance to a newer version of the gRPC.* nuget packages).

I mistakenly did further updates from the nightly builds and currently my gRPC packages are all at version 2.28.0-dev202003020801. I say mistakenly because my two working solution deployments each fail.

SSB - The client reports an error of "Unhandled exception rendering component: Could not load file or assembly 'System.Text.Json, Version=4.0.1.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. The system cannot find the file specified."
By simply adding an explicit nuget package of System.Text.Json (4.7.1) to my web server project this error goes away and everything functions.
[EDIT] Returning to versions 2.27.0/2.27.0-Pre1 for all of the gRPC.* packages from the NuGet feed resolves this issue.

CSB - At the same point in the client when receiving the first gRPC-Web response I am getting an error of "WASM: Grpc.Core.RpcException: Status(StatusCode=Internal, Detail="Bad gRPC response. Response protocol downgraded to HTTP/1.1.")". I don't have a workaround for this, but it isn't critical since we are shipping SSB until CSB is released.
[EDIT] Returning to versions 2.27.0/2.27.0-Pre1 for all of the gRPC.* packages from the NuGet feed resolves this issue.

Sorry for the verbosity, but finally, two questions:

• Is it possible to use another json serializer/deserializer in gRPC/gRPC-Web?
• Will the gRPC/gRPC-Web packages be 'aligned' with the ASP.Net Core 3.2-Preview 2 or will accessing nightly builds be required?

Hi @JamesNK,
My customer has migrated to gRpcWeb, but we have found an important limitation (from which I haven't found any documentation): the max message size is 3067 characters.
If from the usual client-service from the basic gRpc service, converted to gRpc-Web, this line will fail (because the string is 3068 characters, 1 over the limit):

// Configure a channel to use gRPC-Web
var handler = new GrpcWebHandler(GrpcWebMode.GrpcWebText, new HttpClientHandler());
// The port number(5001) must match the port of the gRPC server.
using var channel = GrpcChannel.ForAddress("https://localhost:5001", new GrpcChannelOptions
{
HttpClient = new HttpClient(handler)
});
var client = new Greeter.GreeterClient(channel);
var reply = await client.SayHelloAsync(new HelloRequest { Name = new string('A', 3068) });
Console.WriteLine("Greeting: " + reply.Message);
Console.WriteLine("Press any key to exit...");
Console.ReadKey();

I attach a repro solution containing client and server.
GrpcWeb.zip

The equivalent project with normale gRpc was able to handle messages of 20k without any problems.
Can you please advice me if I can configure something to remove this limit?

@curia-damiano can you file a new issue with this? Let's keep this thread to discussing the specific feature of supporting gRPC (without gRPC-Web) on IIS/Azure App Service. gRPC-Web was raised earlier on this thread because it's a good alternative, but I'd like to keep this thread focused on the primary goal of native gRPC support.

@MarkStega can you also file a new issue with your question? Let's try to avoid this thread getting overloaded with multiple possible topics (even if they are related). This issue is tracking native gRPC support on IIS/Azure App Service

Can we have an ETA when gRPC will be available on Azure App Service please?

We don't have any ETA updates. We will update this thread when we do have an ETA. This requires Windows changes and we're working with that team to try and get them in place as soon as possible, but their schedule isn't in our direct control.

Can we build a gRPC service which is packaged as a container and runs in a Web App for Containers in Azure ?

@fgheysels Nope. It's still behind IIS as a proxy which can't handle the required HTTP/2 functionality.

There are 3 ways of doing this right now:

1. Expose a public IP and use a VM.
2. Use Kubernetes with Azure Application Gateway Ingress (which the instructions fail because the helm script is out of date thus can't be used right now) or use nginx ingress (You lose the firewall and DoS Mitigations)
3. Use Azure Container services and expose it to a public IP or use nginx to reverse proxy it or use Azure Application Gateway to reverse proxy it.

Nothing else will work.

@JohnGalt1717

Use Azure Container services and expose it to a public IP or use nginx to reverse proxy it or use Azure Application Gateway to reverse proxy it.

Azure Application Gateway will currently not work. It has the same limitation

i guesd we could runit on gpogle cloud with our .net code?

On Wed, 1 Apr. 2020, 7:26 am Sourabh Shirhatti, notifications@github.com
wrote:

@JohnGalt1717 https://github.com/JohnGalt1717

Use Azure Container services and expose it to a public IP or use nginx to
reverse proxy it or use Azure Application Gateway to reverse proxy it.

Azure Application Gateway will currently not work. It has the same
limitation

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-606855605,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABCSC7LVZJTQ2QPRHVB5G5TRKJGYLANCNFSM4HDHMSDA
.

@shirhatti Ok, so this just keeps getting worse. Microsoft effectively made it so .NET with gRPC can't be run on Microsoft Azure. If it wasn't so sad it would be FUNNY AS HELL.

So here's the updated list:

1. Expose a public IP and use a VM (put haproxy, nginx or something on the VM to Reverse proxy it)
2. Use Kubernetes (AKS) with nginx ingress.

I don't believe ACS will work because it still puts IIS in front of it if memory serves.

And #2 might not work either because the load balancer might be IIS on Windows too... Anyone actually get this to work anywhere in Azure?

I think this github ticket defines what I've been saying for months about the .NET team and what's going on.

Microsoft effectively made it so .NET with gRPC can't be run on Microsoft Azure. If it wasn't so sad it would be FUNNY AS HELL.

There's nothing here that's specific to .NET, the limitation is in the Windows and Azure infrastructure related to HTTP/2. You'd have the same issue with other webstacks in Azure. Windows and Azure are working to unblock us but it requires changes to fundamental components which take long time to redeploy.

This is all directly related to .net. it literally says on the azure and .net websites that .net is the language of azure.

But you can't use that language with Azure but can use it on AWS and Google cloud easily.

It's an embarrassment as with so many massive screw ups from the .net team lately, yet their arrogance is at an all time high without reason.

And they haven't even given us work arounds of any type other than to use gRPC web which is a poc not a real product.

Yes but we can run all of out .net stack on google cloud, .net supports
gRPC all fine. So I don't mind running on GPC until they can get this fixed
on Azure.
I develop app services or serverless apps, I am not interested in any
container solutions as they are too costly for the large scale deployments
I have.

On Wed, Apr 1, 2020 at 9:57 AM James Hancock notifications@github.com
wrote:

This is all directly related to .net. it literally says on the azure and
.net websites that .net is the language of azure.

But you can't use that language with Azure but can use it on AWS and
Google cloud easily.

It's an embarrassment as with so many massive screw ups from the .net team
lately, yet their arrogance is at an all time high without reason.

And they haven't even given us work arounds of any type other than to use
gRPC web which is a poc not a real product.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-606927717,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABCSC7MRPFQBH52XDHUNP63RKJYMVANCNFSM4HDHMSDA
.

First Microsoft should be terrified by what you just said.

Second, I just got our web stuff switched to azure kubernetes using virtual nodes and it costs us about half of what app services was costing us and has double the performance.

Aks is a mess of stuff that doesn't work right and out of date documentation but once you get managed identities, and a public IP in place the rest is straight forward.

Yes but this is a really big change for microsoft! and I like the
simplicity of gRPC although I might switch to http Rx. I could not get my
websocket to solution to work as it seemed to have SSL/TLS issues.
Looks like I can get azure kubs at the same cost as my S1 app services,
have to check the performance.

On Wed, Apr 1, 2020 at 10:13 AM James Hancock notifications@github.com
wrote:

First Microsoft should be terrified by what you just said.

Second, I just got our web stuff switched to azure kubernetes using
virtual nodes and it costs us about half of what app services was costing
us and has double the performance.

Aks is a mess of stuff that doesn't work right and out of date
documentation but once you get managed identities, and a public IP in place
the rest is straight forward.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-606933338,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABCSC7O3N4XVCWM5MGCTS33RKJ2I7ANCNFSM4HDHMSDA
.

This is all directly related to .net. it literally says on the azure and .net websites that .net is the language of azure.

This is plainly not true. The underlying TCP and HTTP stacks are not written using .NET. Microsoft are working to adapt their foundation for gRPC. This is a complex delivery that has knock-on effects for everything that runs on Windows servers, including Azure itself.

It's an embarrassment as with so many massive screw ups from the .net team lately, yet their arrogance is at an all time high without reason.

This manner of unproductive, childish nonsensical whining is completely unnecessary. This has nothing to do with the .NET team. They got most of gRPC ported natively so we can work on our PoCs and use workarounds where necessary, and like mature adults, we'll wait until the base platform is ready to deliver the final parts.

@oising

.NET is the language of Azure. Microsoft Markets it as such. .NET gRPC can't be understood by Azure. It's 100% true. It's a complete fail that it wasn't available at release and even worse a year later. It's irrelevant that the stacks aren't writing by the .NET team inside Microsoft. Microsoft is Microsoft. I don't care about their little fiefdoms and artificial boundaries and non-aligned priorities. I care about the best possible products that actually work. I don't care that Microsoft claims that because .NET is open sourced that somehow doesn't make it a paid product anymore. It is a paid product. I just pay for it indirectly by using Azure, Office and Windows.

And nope, we won't wait. We'll move to another cloud provider where it does work. Which is what Microsoft is endlessly pushing. Hell I had a Microsoft support person, say and I quote "If you don't like [the fact that we broke this at run-time by design] you can go use someone else's product" To about 100 customers. Yes, well I know of 8 that did exactly what they suggested so far and 30-40 more that are investigating doing so. Estimated lost revenue for MS from that one support agent is about 2.8 million USD and counting.

Yes, that's exactly what we're all going to do. Thanks for the advise Microsoft. We'll leave Azure, and we'll leave .NET if the leadership doesn't get their heads screwed on straight soon.

What they have to worry about is when people like myself stop complaining about these massive public failures where they don't take responsibility for them, and instead they hear nothing and everyone doesn't care. It happened about a year ago when Xamarin Forms went 18 weeks without being able to build to the Apple Store, Android Store and Windows Store with the same build of Xamarin Forms and Xamarin in general. I posted, they admitted it, and 18 weeks later, only 1 person had followed the bug report despite it being a full break, not just an edge case. Why? No one cares about Xamarin Forms and left and started using non-Microsoft tools and Microsoft lost the desktop and cell phone. (and keeps trying the same failed approach to winning it back even with Neo and Duo) Right now people still think that they have a voice in .NET and that their complaints won't go on deaf ears and this stuff will be fixed. The .NET leadership is working really hard to make clear that that isn't the case and the result will be identical to Xamarin Forms.

The trailer headers piece is something we find ourselves needing more urgently than thought for Stack Overflow as well. Can we help with the prioritization here?

Use case

We do timings via server headers to capture them in our HTTP logs (in HAProxy). We have several headers like X-Sql-DurationMs, X-Sql-Count, X-Reds-DurationMs, etc. so that we can capture them log them, and aggregate metrics on them. If more detail helps, there's a section in this blog post. This worked well enough in ASP.NET MVC 5 (full framework) because the entire response was buffered. Since we do very little querying in views, it was a ~99% accurate timing strategy that worked well overall.

Now we're running on .NET Core and everything is streaming. The problem with this is that the timing headers are sent before they are complete, because of the lack of buffering. It's a harsh trade-off. This would be quickly fixable if we could send and capture those timings as trailer headers. But it seems like we're at an IIS blocker here and we're at the mercy of that being upgraded (or us moving off IIS) to get this functionality to work.

Personally, I have other uses as well, like MiniProfiler sending the Server-Timing header (it's been ready and waiting about 3 years now).

How can we help with the priority on this? Is there any chance additional use cases would help shift it?

Thanks @NickCraver. This work is already high priority and in progress, but getting it deployed to services like AppService is complicated and still going to take a while.

Is there a possibility it will be supported in IIS soon, irrespective of Azure roll-out? -- I really only need a client in IIS - if that matters at all. So can IIS be a http2 client?

I must agree, that it is worrying, that it seems Impossible for Microsoft employees, to take their legs (Or phone at this time) and go over to that other team. And just annoy them so much that they deploy a hotfix in a day.
If asp / .net team hadn’t pushed for grpc this waiting period would be fine. But since you are marketing a product that can’t be used in production, it sadly is time for desperate measures and breaking ranks.

If you care you will make it happen.

Edit: I know “a day” is exaggerated but it has been a year!

Is there any docs at all explaining how to deploy gRPC to Azure? at least using AKS? Would be nice to have something.

Is there any docs at all explaining how to deploy gRPC to Azure? at least using AKS? Would be nice to have something.

@lumogox I have created a Step by step guide to deploy gRPC to Azure.
https://github.com/rupeshtech/k8s-grpc-dotntecore

@rupeshtech I actually took a look to your guide, however, it does not work if you want to show a message in the root path in port 80.

Great stuff but I want to deploy on app services and we still have no ETA.
It was claimed by one of the other guys that AKS was cheaper than app
services, I find that hard to believe?
Anyway I only want to use app services or serverless infrastructure.

On Tue, May 12, 2020 at 5:51 PM Luis Molina notifications@github.com
wrote:

@rupeshtech https://github.com/rupeshtech I actually took a look to
your guide, however, it does not work if you want to show a message in the
root path in port 80.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-627175783,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABCSC7MUWWWYCGMEK2FH663RRD5YPANCNFSM4HDHMSDA
.

AKS: b12, 2 node cluster is $176 / month and gets you perf like a p3.

You'll need the following to make this work:

1. nginx ingress as reverse proxy.
2. Dockerized .net core app
3. Deployment templates for your .net core app
4. Service templates for those deployments
5. The ingress template that maps your dns entries
6. cert bot for k8s or your own cert to map to the ingress.
7. Turn off SSL only in your .net app, it will screw with the RP and turn on the proxy support in .net core.
8. Public IP
9. Azure Container Registry

It's a 30 part process to configure this in Azure right now and virtually none of it can be done via the GUI portal. They're missing associating container registries, configuring ingress providers (Azure Application Gateway nor nginx nor haproxy etc. have any gui to set it up. None of the Service principal stuff with other resources, nor managed identity stuff is properly automated either (and you need both for unfathomable reasons).

If you're doing a wildcard cert then you'll also need access to your DNS through one of the certbot k8s service supported dns providers.

Here's our script for setting up an environment that might help you get started:

Azure Configuration

1. Create AKS
2. az aks install-cli (if you haven't already)
3. az aks get-credentials --resource-group RGL-\ --name XX-AKS-\
4. az network public-ip create --resource-group MC_RGL-\_XX-AKS-\_eastus --name PIP-AKS-\ --sku Standard --allocation-method static --query publicIp.ipAddress -o tsv
5. Map api, www, admin to the public ip in DNS (i.e. beta.XX.com)
6. az identity create -g RGL-\ -n XX-MI-AKS-\ -o json (Record the ClientId, PrincipalId, Id and Name)
7. az role assignment create --role Reader --assignee \ --scope /subscriptions/\/resourcegroups/RGL-\
8. Get Service Principal info from Azure Active directory apps: XX-AKS-\SP-xxxx (Record name, client id)
9. Create a client secret with no expiration and record it
10. az role assignment create --role "Managed Identity Operator" --assignee \ --scope "\"
11. Get the dns zone id: az network dns zone list --query "[].{ id: id, name: name}"
12. az role assignment create --assignee \ --role Contributor --scope \
13. az role assignment create --assignee \ --role Contributor --scope \
14. az aks update -n XX-AKS-\ -g RGL-\ --attach-acr clcr\
15. Add Managed Identity (XX-MI-AKS-\) to Key Vault

Kubernetes Let's encrypt (If not production)

1. kubectl create namespace ingress-basic
2. helm repo add stable https://kubernetes-charts.storage.googleapis.com/
3. helm install nginx-ingress stable/nginx-ingress --namespace ingress-basic --set controller.replicaCount=2 --set controller.nodeSelector."beta.kubernetes.io/os"=linux --set defaultBackend.nodeSelector."beta.kubernetes.io/os"=linux --set controller.service.loadBalancerIP="\"
4. Verify it took: kubectl --namespace ingress-basic get services -o wide -w nginx-ingress-controller
5. kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v0.14.3/cert-manager.yaml
6. Update issuer.yaml with subscription, and Service Principle ClientId
7. Update certificate.yaml to dns address
8. Update ingress.yaml with domain information etc.
9. Make Base64 version of Service Principal Secret: echo \ | openssl base64
10. Update secure-dazuredns.yaml with the secret

OR Kubernetes Azure Application Gateway

1. Doesn't work. Complete mess

Complete Kubernetes Configuration

1. kubectl apply -f https://raw.githubusercontent.com/Azure/aad-pod-identity/master/deploy/infra/deployment-rbac.yaml
2. Update deploy-api with registry, keyvault, Environment and instrumentation key
3. Update registry in deploy-portal and deploy-admin
4. Update values in identity-binding.yaml (ClientId is also from the managed identity above)
5. kubectl create namespace XX
6. kubectl config set-context --current --namespace=XX
7. kubectl apply -k ./\
8. Verify cert is available: kubectl describe certificate XX-tls-secret

Yes, it's really that hard. And no there isn't an easier way in k8s. Your only other option is a VM with a public IP and use a RP infront of your app. You can use an Linux VM and run docker on it, and install HAproxy and your app in a docker container with a single docker-compose file pretty easily.

Otherwise you're screwed until they start rolling out the kernel from Windows 2004 (spring 2020) to Azure. (assuming it made it in there and isn't delayed until November)

Wow mate that is incredible thank you but as I am also a really big fan of
Azure Dev Ops with a NoOps approach I really feel that AKS is just not in
my league.
Especially when I can probably run a decent app service for a fair bit less
than that. Or switch it to an Azure function. I could not get my websocket
solution to deploy to Azure.
I am also a huge fan of Reactive Extensions and there is some nice Rx
tools out there like this
https://github.com/lucassklp/Rx.Http
Not sure about the scalability of this though

On Tue, May 12, 2020 at 10:09 PM James Hancock notifications@github.com
wrote:

AKS: b12, 2 node cluster is $176 / month and gets you perf like a p3.

You'll need the following to make this work:

1. nginx ingress as reverse proxy.
2. Dockerized .net core app
3. Deployment templates for your .net core app
4. Service templates for those deployments
5. The ingress template that maps your dns entries
6. cert bot for k8s or your own cert to map to the ingress.
7. Turn off SSL only in your .net app, it will screw with the RP and
   turn on the proxy support in .net core.
8. Public IP
9. Azure Container Registry

It's a 30 part process to configure this in Azure right now and virtually
none of it can be done via the GUI portal. They're missing associating
container registries, configuring ingress providers (Azure Application
Gateway nor nginx nor haproxy etc. have any gui to set it up. None of the
Service principal stuff with other resources, nor managed identity stuff is
properly automated either (and you need both for unfathomable reasons).

If you're doing a wildcard cert then you'll also need access to your DNS
through one of the certbot k8s service supported dns providers.

Here's our script for setting up an environment that might help you get
started:
Azure Configuration

1. Create AKS
2. az aks install-cli (if you haven't already)
3. az aks get-credentials --resource-group RGL- --name XX-AKS-
4. az network public-ip create --resource-group MC_RGL-_XX-AKS-_eastus
   --name PIP-AKS- --sku Standard --allocation-method static --query
   publicIp.ipAddress -o tsv
5. Map api, www, admin to the public ip in DNS (i.e. beta.XX.com)
6. az identity create -g RGL- -n XX-MI-AKS- -o json (Record the
   ClientId, PrincipalId, Id and Name)
7. az role assignment create --role Reader --assignee --scope
   /subscriptions//resourcegroups/RGL-
8. Get Service Principal info from Azure Active directory apps:
   XX-AKS-SP-xxxx (Record name, client id)
9. Create a client secret with no expiration and record it
10. az role assignment create --role "Managed Identity Operator"
    --assignee --scope ""
11. Get the dns zone id: az network dns zone list --query "[].{ id:
    id, name: name}"
12. az role assignment create --assignee --role Contributor --scope
13. az role assignment create --assignee --role Contributor --scope
14. az aks update -n XX-AKS- -g RGL- --attach-acr clcr
15. Add Managed Identity (XX-MI-AKS-) to Key Vault

Kubernetes Let's encrypt (If not production)

1. kubectl create namespace ingress-basic
2. helm repo add stable
   https://kubernetes-charts.storage.googleapis.com/
3. helm install nginx-ingress stable/nginx-ingress --namespace
   ingress-basic --set controller.replicaCount=2 --set
   controller.nodeSelector."beta.kubernetes.io/os"=linux --set
   defaultBackend.nodeSelector."beta.kubernetes.io/os"=linux --set
   controller.service.loadBalancerIP=""
4. Verify it took: kubectl --namespace ingress-basic get services -o
   wide -w nginx-ingress-controller
5. kubectl apply --validate=false -f
   https://github.com/jetstack/cert-manager/releases/download/v0.14.3/cert-manager.yaml
6. Update issuer.yaml with subscription, and Service Principle ClientId
7. Update certificate.yaml to dns address
8. Update ingress.yaml with domain information etc.
9. Make Base64 version of Service Principal Secret: echo | openssl
   base64
10. Update secure-dazuredns.yaml with the secret

OR Kubernetes Azure Application Gateway

1. Doesn't work. Complete mess

Complete Kubernetes Configuration

1. kubectl apply -f
   https://raw.githubusercontent.com/Azure/aad-pod-identity/master/deploy/infra/deployment-rbac.yaml
2. Update deploy-api with registry, keyvault, Environment and
   instrumentation key
3. Update registry in deploy-portal and deploy-admin
4. Update values in identity-binding.yaml (ClientId is also from the
   managed identity above)
5. kubectl create namespace XX
6. kubectl config set-context --current --namespace=XX
7. kubectl apply -k ./
8. Verify cert is available: kubectl describe certificate XX-tls-secret

Yes, it's really that hard. And no there isn't an easier way in k8s. Your
only other option is a VM with a public IP and use a RP infront of your
app. You can use an Linux VM and run docker on it, and install HAproxy and
your app in a docker container with a single docker-compose file pretty
easily.

Otherwise you're screwed until they start rolling out the kernel from
Windows 2004 (spring 2020) to Azure. (assuming it made it in there and
isn't delayed until November)

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-627302354,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABCSC7P74W4DK5RP2BKKI7LRRE365ANCNFSM4HDHMSDA
.

Websockets is probably a good fall back if you haven't committed to gRPC and are focused on Azure App Services.

Once you have k8s configured, Azure Devops is easy. You tell it to build the docker container and deploy to the azure repository with the build:id tag and then to release you run kubectl to tell it to update the deploy's container with the right tag for the build id and it will just transparently roll out the new version. Only thing we did is create a tool that does EF migrations before it does that so that you don't end up with multiple k8s replicas calling the migration script at the same time.

Magic mate thanks heaps, I am also really into Domain Driven Design so I
guess I can add AKS to my armory now but I want my clients to move to
serverless, I don't get why most people don't seem to want to move on from
containers?

On Tue, May 12, 2020 at 11:05 PM James Hancock notifications@github.com
wrote:

Websockets is probably a good fall back if you haven't committed to gRPC
and are focused on Azure App Services.

Once you have k8s configured, Azure Devops is easy. You tell it to build
the docker container and deploy to the azure repository with the build:id
tag and then to release you run kubectl to tell it to update the deploy's
container with the right tag for the build id and it will just
transparently roll out the new version. Only thing we did is create a tool
that does EF migrations before it does that so that you don't end up with
multiple k8s replicas calling the migration script at the same time.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-627329964,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABCSC7MW7NJUS475HICIJTTRRFCQBANCNFSM4HDHMSDA
.

@acrigney containers are pretty broadly considered a 'serverless' technology. It's definitely debatable, but there isnt a strict definition

@acrigney There are many reasons why serverless especailly Azure functions aren't desirable:

1. Azure Functions is a brittle steaming pile of crap that is always behind on security patches with .net core.
2. Azure functions is very much a black box and hard to debug in many cases.
3. Once you start utilizing it fully it's more expensive than other options when you have constant load.
4. There's nothing you can't do otherwise that you can do in Azure functions
5. K8s provides a generic known environment that functions the same on your local dev machine as it does in any cloud you want to create. When you create a resource it works. It doesn't matter if it's Azure or AWS backing it, it works the same and consistently unlike Azure Functions that we got different results in Azure than locally on a regular basis.
6. K8s, on a loaded system costs less than Azure Functions.
7. K8s does deployment better than functions.
8. Once you start working with VS code remoting into docker you'll not want to go back. Same environment same configuration as production for 100% consistency. (We use k8s inside docker to dev with WSL2 docker and spin k8s up in linux which works wonderfully with Windows 10 2004, but full dev in k8s is coming soon)
9. k8s gives you all of the autonomy of VMs without having to manage VMs, load balancing etc. It just works.
10. If you build your docker images properly using platform targeting and IL linking your micro services in k8s are just as small as the same in Azure functions so there's no scaling issues.

That's just a short list. Azure functions is great in theory, then you start beating your head against the wall with it and you discover that it isn't much worth it.

until they start rolling out the kernel from Windows 2004 (spring 2020) to Azure.

The necessary work for IIS is still in progress and is not available in the 2004 release.

@Tratcher Wow. Just ouch. So more than a year will have passed with .net core supporting gRPC and Azure not having a viable way for the vast majority of the world's developers to use it.

MS needs to create true docker based app services that use nginx or ha proxy and not IIS for RP. This is nuts.

Really mate, I think that is stretching it, sure AKS can scale but
especially with the coupling of messaging required to run multiple
containers for a large project I would hardly consider containers in
keeping with the ideals of serverless tech. I can easily plug and play any
backend tech microservices with app servers and functions but would I have
this agility with containers?

On Tue, May 12, 2020 at 11:31 PM onionhammer notifications@github.com
wrote:

@acrigney https://github.com/acrigney containers are pretty broadly
considered a 'serverless' technology

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-627347120,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABCSC7PPWZ7MPIETCXPEFYDRRFFUNANCNFSM4HDHMSDA
.

@acrigney Absolutely you would. And you wouldn't have dependency hell that is Azure Functions either. (and you can easily use Azure Function host in containers and even k8s if you want)

@acrigney Are you trying to expose gRPC to other microservices running in app service? What does your topology look like?

Thanks mate but I think you would not have any dependency hell or tight
coupling with functions. I make stateful microservices using DDD aplication
services with Azure app services and I make stateless microservices with
DDD aplication services in Azure functions. The DDD app services expose
DTOs and use the domain objects and the other app services can observe the
events fired by these domain objects. I just don't need containers and once
you build a container its going to have a lot of duplicated code that would
would be needed in other containers.

On Wed, May 13, 2020 at 12:09 AM James Hancock notifications@github.com
wrote:

@acrigney https://github.com/acrigney Absolutely you would. And you
wouldn't have dependency hell that is Azure Functions either. (and you can
easily use Azure Function host in containers and even k8s if you want)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-627369635,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABCSC7PQLO2K4RVWBQRGQS3RRFKCZANCNFSM4HDHMSDA
.

The it-does-not-run-on-IIS-warning should be placed on top of the page using a <marquee>-tag: https://docs.microsoft.com/en-us/aspnet/core/grpc/?view=aspnetcore-3.1

It's really inject profanity here if you have been prototyping, created proto files, configured your server, client, auth using JWT and have just pitched the whole idea to a client as this-is-the-best-next-thing-since-sliced-bread to find out we can't use it in production because we are running on IIS. :(

until they start rolling out the kernel from Windows 2004 (spring 2020) to Azure.

The necessary work for IIS is still in progress and is not available in the 2004 release.

Is there an eta / roadmap?

The it-does-not-run-on-IIS-warning should be placed on top of the page using a <marquee>-tag: https://docs.microsoft.com/en-us/aspnet/core/grpc/?view=aspnetcore-3.1

You're right, I've filed https://github.com/dotnet/AspNetCore.Docs/issues/18336 to clarify.

Is there an eta / roadmap?

No, there are too many moving parts to give a reliable estimate.

Does anyone has some documentation in how to configure nginx with grpc and kestrel?

Hey all, can we redirect some of the requests for gRPC in AppService user voice https://feedback.azure.com/forums/169385-web-apps?

Quick question: Is support for IIS and Azure App Service coupled together or can/will they be delivered separately?

Thanks yall!

They are somewhat coupled - Azure App Service's ingress and windows hosting relies on IIS, so getting support into IIS is a pre-req.

Then App Service needs to deploy based on a build that has those fixes, so App Service will come after IIS support.

Quick question: I deployed gRPC server on IIS (10.0) and now getting error, "Status(StatusCode=Cancelled, Detail=\"No grpc-status found on response.\")". I have used WebApi project as gRPC client. Anyone can Help me?

Quick question: I deployed gRPC server on IIS (10.0) and now getting error, "Status(StatusCode=Cancelled, Detail="No grpc-status found on response.")". I have used WebApi project as gRPC client. Anyone can Help me?

Can't be done, gRCP is not supported by IIS.

@lumogox @Dhananjay48 Note: GRPC-web is supported by IIS and you lose only client streaming for the most part. So that is a work around, although not a great one.

Otherwise according to what I'm seeing we're waiting until at least December before this gets fixed in IIS so move off and use something else like nginx as a reverse proxy.

If you just want to deploy GRPC on Azure App Service, you can do it now with a Linux Container

@EdiWang This is currently not supported on App Service for Linux. We are currently working with App Service to enable this, but I don't have any ETA to share

Is this because there still is HTTP.sys in front of the webapp, even though it is a docker container running on Linux?

It's my understanding that all app services are reverse proxied by iis. Hence they won't work until this is fixed.

Only something with a public IP or rped by ha or nginx etc (Linux) will work. Kubernetes with nginx or ha work fine as an example but application gateway as ingress won't.

It's my understanding that all app services are reverse proxied by iis. Hence they won't work until this is fixed.

Only something with a public IP or rped by ha or nginx etc (Linux) will work. Kubernetes with nginx or ha work fine as an example but application gateway as ingress won't.

It is also my understanding. I actually ended up here because I reading up on if all app services is fronted by an IIS. Because in the docs here: https://docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?view=aspnetcore-3.1#when-to-use-kestrel-with-a-reverse-proxy - it advices us to install a reversed proxy in front of kestrel if you are going to expose kestrel to the internet :) I know there is an IIS when running on windows, but I cant find any to validate that HTTP.sys or IIS is also fronting when running docker in an app service. This thread is the closest I have ever come. Funny thing is, that i am subscribing to this thread because i am also pretty much interesting in gPRC :)

I can confirm that iis also fronts container based app services including Linux ones.

Your only options are VMS where you've done the rp yourself or aks.

＠davidfowl AppService User Voice has not received much attention.

https://feedback.azure.com/forums/169385-web-apps/suggestions/40585333-grpc-support-in-azure-app-service
Could this be the reason for the slow implementation? As you see this Issue, I think gRPC support is important.

Yes especially as I could not get websockets to work either and I am
worried about the cost of containers as I would have to run a lot.

On Fri, Jun 12, 2020 at 9:58 PM Takekazu Omi notifications@github.com
wrote:

＠davidfowl AppService User Voice has not received much attention.

https://feedback.azure.com/forums/169385-web-apps/suggestions/40585333-grpc-support-in-azure-app-service
Could this be the reason for the slow implementation? As you see this
Issue, I think gRPC support is important.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-643232429,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABCSC7L4452ZISXIPNAXWYLRWIKADANCNFSM4HDHMSDA
.

Adding the request there is still very important.

@davidfowl That's much easier said than done. Try logging in to the site with your microsoft account with new edge. Pops up a new window and does nothing. Try and login with my email, well I forgot the password, password email goes to junk mail for an @outlook.com email address. Change it, login, and no password manager prompts to store the password etc.

Just WOW bad. I'd guess that the Azure team isn't getting good feedback as a result. Hope you can forward this to the right people to fix that mess.

Maybe it will help to someone to host grpc to iis.
Here is example of working grpcweb Blazor WebAssembly with gRPC-Web code-first approach which hosts to iis via via remote publish like a charm. I assume it could work other ways too. I havent done any performance testing, so i couldnt comment on that, but i think at least it would work good on anything up to middle size solutions.
Here is link to github
It also uses protobuf-net.Grpc.AspNetCore which is no boring protobuff declaration. It is so good when you could go directly to implementation or add extra methods to request/response.

Hi all, I need to define a string array type dataType in Grpc message. not sure how to do. right now i am doing it as a
repeated string Name = 1,
here i need name field as string array Type. But it is showing error that it is, field is readonly type when bind data in it.

@Dhananjay48 This is not StackOverflow. Please ask your question there.
Let's keep this issue for stuff related to gRPC in App Service.

It's my understanding that all app services are reverse proxied by iis. Hence they won't work until this is fixed.

Only something with a public IP or rped by ha or nginx etc (Linux) will work. Kubernetes with nginx or ha work fine as an example but application gateway as ingress won't.

Could 'Kestrel used in a reverse proxy configuration' with nginx, be a solution? https://docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?view=aspnetcore-3.1#when-to-use-kestrel-with-a-reverse-proxy'

I put the suggestion to @JamesNK in the docs, to include an example hosting solution:
https://github.com/dotnet/AspNetCore.Docs/issues/18953

https://devblogs.microsoft.com/aspnet/grpc-web-for-net-now-available/?utm_source=vs_developer_news&utm_medium=referral
Was announced recently and can be deployed to Azure.

On Thu, Jun 25, 2020 at 1:48 PM OzBob notifications@github.com wrote:

It's my understanding that all app services are reverse proxied by iis.
Hence they won't work until this is fixed.

Only something with a public IP or rped by ha or nginx etc (Linux) will
work. Kubernetes with nginx or ha work fine as an example but application
gateway as ingress won't.

Could 'Kestrel used in a reverse proxy configuration' with nginx, be a
solution?
https://docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?view=aspnetcore-3.1#when-to-use-kestrel-with-a-reverse-proxy
'

I put the suggestion to @JamesNK https://github.com/JamesNK in the
docs, to include an example hosting solution:
dotnet/AspNetCore.Docs#18953
https://github.com/dotnet/AspNetCore.Docs/issues/18953

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-649198280,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABCSC7KBUALMCXDGUS2NV7LRYLCKNANCNFSM4HDHMSDA
.

@acrigney and mentioned here on Ch9 too: https://youtu.be/T4RD3W2MgHQ?list=TLPQMjUwNjIwMjB6we-UTBA_VA&t=288 by @shirhatti (https://twitter.com/sshirhatti)

I just wanted to call out that we've been working with the Windows team to start enabling these scenarios. Here's a blog post from the Windows team about it, and https://github.com/dotnet/aspnetcore/pull/24120 has some of the follow-up work to expose things in ASP.NET Core.

It'll still be a while before all of this lands, but it's nice to be able to report that we're making progress at least.

Thanks for the follow up, very helpful and appreciated!!

On Wed, Jul 22, 2020 at 11:17 AM Kevin Pilch notifications@github.com
wrote:

I just wanted to call out that we've been working with the Windows team to
start enabling these scenarios. Here's a blog post
https://aka.ms/grpcblogpost from the Windows team about it, and #24120
https://github.com/dotnet/aspnetcore/pull/24120 has some of the
follow-up work to expose things in ASP.NET Core.

It'll still be a while before all of this lands, but it's nice to be able
to report that we're making progress at least.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/aspnetcore/issues/9020#issuecomment-662547810,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAUKMASPCV3UE47OJZ6TIMDR44GKTANCNFSM4HDHMSDA
.

I just wanted to call out that we've been working with the Windows team to start enabling these scenarios. Here's a blog post from the Windows team about it, and #24120 has some of the follow-up work to expose things in ASP.NET Core.

It'll still be a while before all of this lands, but it's nice to be able to report that we're making progress at least.

Note this has already been integrated into AspNetCore's HttpSys server in the 5.0 previews. Please give it a try. If we can identify any issues at this layer now then we should have less trouble when we add the IIS layer on top of this.

Does this mean I can do full gRPC on IIS if I use ASP.NET Core targetting .NET 5 preview?

Not yet. There are a bunch of different parts here:

1. Http.sys module in Windows
2. ASP.NET Core support for this in HttpSysServer
3. IIS support for this in Windows
4. ASP.NET Core support for this on IIS
5. Support for this in the reverse proxy that Azure App Service uses
6. Azure App Service deploying a build of Windows with 1 and 3.
7. Azure App Service deploying a build of the reverse proxy from 5
8. Azure App Service deploying a build of ASP.NET Core with 2 and 4.

What @Tratcher was saying is that 1 and 2 are available in previews of .NET 5. We're working on 3 and 4 right now, but trying 1 and 2 will help give us feedback on whether that will work, since the Http.sys support is an underpinning of the IIS support.

Should have said, 1 is available in previews of Windows, and 2 is available in Previews of .NET 5.

Windows Insider preview is available with updated http.sys
https://techcommunity.microsoft.com/t5/networking-blog/windows-server-insiders-getting-grpc-support-in-http-sys/ba-p/1534273

Any ideas if this will be available as a Windows update to Windows Server 2016/2019?

And the IIS support is now in the latest Windows Insider builds announced here.

We're investigating whether it will be possible to backport these changes to servicing build, but that is still up in the air. As of now, the only plan of record is that they will be in future releases.