You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I made the changes to appsettings.Development.json as that's the file that's being processed when debugging from VS. right? simple setup:
{
"Kestrel": {
"Endpoints": {
"HttpsInlineCertFile": {
"Url": "https://localhost:6585",
"Protocols": "Http2"
}
}
}
}
Now couple of things:
I noriced that the kestrel port defined in this json has NO effect.. when I tried to use it in a console client app, it gave the error "no connection could be made because the target machine actively refused it". why does it have no effect? I previously used worker service to host a grpc server, specifying similar settings and it was able to work..
Now, using the port specified in the popped up browser window, the https port is some funny number (i can't even find out where I can set this number, not in project properties, nowhere), I tried using the client to connect. Now I get this error: "System.InvalidOperationException: Trailers are not supported for this response. Server may not support grpc". does it mean IIS Express in VS2019 can't support grpc server being hosted in asp.net core web app? And since the microsoft doc site mentioned above said IIS also don't support grpc, does it then mean that grpc server and asp.net core web apps can't co-exist? or I have to use some other web server (Apache/Nginix) to do it?
is it possible to host an asp.net core web api app in a worker process together with grpc server? I found the swagger UI provided by swashbuckle a very convenient way to observe runtime status of the app, and would like to explore if worker service can be used to host a web API app, with swagger, while also hosting grpc server. That would be another way of doing what I'm trying to do above actually.. instead of web API+grpc, this is grpc service+web api. can it be done?
The text was updated successfully, but these errors were encountered:
What is specified in your appsettings.json file is overriden by launchSettings.json (it is under properties).
gRPC in ASP.NET Core currently doesn't support HttpSys/IIS/IIS Express. That is why you get that error message. Yes you can run gRPC inside an ASP.NET Core web app, just not on IIS. Right now only Kestrel is supported.
basically, the only diff is the Certificate section commented away in the appsettings.json, which makes them the same. The funny thing is this, when I debug from within VS2019, with this content, it will use appsettgs.Development.json. I verified this by setting a differnt ports for http/https from the appsettings.jspn, and based on the console output, I can see that indeed it's listening on what I set for the development json. BUT, when I uncommented the Certificate section in appsettings.json, trying to debug from VS will show System.IO error, can't find file specified. this is strange, because I thought in debug mode it should load appsettings.Development.jspn which does not specify the cert file? why is it loading the production json?
Basically what I hope to achieve is to have one setting each for http and https, with https having the ability to specify the cert file and support for http 1.1 amd http2. is this the right way to do it?
This might be a known issue. if so, please advice me again..
I used VS2019 to create a new ASP.NET WEB API project. I added in my own controller, and with swashbuckle 5.0.0 rc4, was able to verify that it's working. I proceeded to add grpc server inside. according to what's described here: https://docs.microsoft.com/en-us/aspnet/core/grpc/aspnetcore?view=aspnetcore-3.0&tabs=visual-studio
I made the changes to appsettings.Development.json as that's the file that's being processed when debugging from VS. right? simple setup:
{
"Kestrel": {
"Endpoints": {
"HttpsInlineCertFile": {
"Url": "https://localhost:6585",
"Protocols": "Http2"
}
}
}
}
Now couple of things:
The text was updated successfully, but these errors were encountered: