Created gRPC service with code-first approach.
Published my gRPC code to IIS and while consuming in Blazor client am getting "Exception was thrown by handler"
Same code working fine with localhost
Thanks in advance
According to this github issue that IIS cannot current host a gRPC service because http.sys doesn't support trailing headers.
gRPC relies on trailing headers to communicate vital information, like call status.
This issue has mentioned that IIS is supported with .NET 5 and an insiders build of Windows.
Related
I have a .Net Nuget Package that works on a .NET Core Web API Service when it is proxied by my API Management Server. I would like to setup some automated testing of this service to be run when I run my builds.
Normally, when I want to run a service to be seen from other computers, I host it in IIS. But I would rather not have to have IIS up and running on my build servers.
I am wondering, is there a simple way to host a .Net Core Web API Service that can just run in-memory? (Similar to the way NodeJs can be run) I understand that Kestrel is used under the hood for ASP.NET Core. Maybe it be setup to do that?
NOTE: Because this will be proxied by my API Management Server, it need to be accessible by other servers on my network. (Not just localhost.)
Kestrel is the simplest way you can use to achieve, you can config kestrel to enable it listening to remote request, see this document
I have followed the instructions here and here to setup SignalR in a ASP.NET Core web app. Then replicated the same code in a Service Fabric ASP.NET Core service only to find that the 100% working code when hosted outside of service fabric did not work when hosted on Service Fabric. When I open the html client included in both of these samples and turn on developer tools in the browser I see what appears to be the WebSocket handshake failing with HTTP 410 GONE errors.
In the Service Fabric documentation for ASP.NET CORE I found that the ServiceFabric Middleware can return HTTP 410 GONE if the identifier that validates each request does not match. But I guess I don't understand the inner workings of SignalR to know how to properly configure Service Fabric to unblock this.
I am running on a local single node cluster so I figured that I wouldn't have any issues until I needed to do multi-node cluster deployment, at which point I would need to figure out the SignalR backplane I'm going to use.
Any idea what would cause this to be?
I needed to disable Service Fabric Integration in the WebHost Builder. Simply replacing this:
.UseServiceFabricIntegration(listener, ServiceFabricIntegrationOptions.UseUniqueServiceUrl)
with this:
.UseServiceFabricIntegration(listener, ServiceFabricIntegrationOptions.None)
allowed it to start working.
I've been looking into the possibility of using ASP.NET Web API and SignalR in a self-hosted application, and I noticed that the ASP.NET Web API self-hosted implementation uses WCF, and the SignalR self-hosted implementation uses System.Net.HttpListener. This makes it a little harder to come up with a combined self-hosting solution, but it does get me wondering why the different project teams would use different approaches.
What are the advantages and disadvantages of each approach? Is there any particular reason why SignalR could not use WCF self-hosting, or Web API could not use HttpListener?
EDIT: I understand that Web API self-hosting provides a more complete stack than SignalR, my question is more about why you would choose a WCF implementation over System.Net.HttpListener when implementing your own self-hosting solution.
Web API self host provides entire HTTP stack so it's much much richer than System.Net.HttpListener.
SignalR uses that to purely open a communication window for its own purposes.
So yeah for now, you need to run them in parallel on different ports.
In the future, with OWIN, you will have everything under one roof.
EDIT: there was actually an issue similar to yours raised on SignalR github, and the answer was pretty much what I just said - https://github.com/SignalR/SignalR/issues/277
Just so we are on the same page, The WCF Self-host that Web API Self host uses, does use HttpListener under the covers. However, I think I may have found a major downside to the WCF Self-host.
I have not confirmed this yet, but it seems that when you use Web API Self Host, the base address you provide is not translated directly into a HttpListener prefix. It seems like WCF translates the base address and wildcards the host.
This means that the WCF self-host will respond to any host on the specified port. This means that you cannot run a Web API Self hosted service side by side with IIS on the same port using a different host name.
This might be the reason that SignalR decided to scrap the WCF Self-Host and use HTTPListener directly.
While you can use the WCF stack to host the services yourself, you may want to consider the "IIS 7.0 Hostable Web Core". It has the benefit of running IIS in your user process. Using this approach, you can have several applications running on the same port, irrespective of the technologies.
If you are interested, you can look at:
Host your own Web Server in your application using IIS 7.0 Hostable Web Core
Creating Hosted Web Core Applications
This all assumes you are running Vista or later...
I have an asp.net 4 application that hosts a WCF REST service via WebServiceHost...
WebServiceHostFactory factory = new WebServiceHostFactory();
routes.Add(new ServiceRoute("mss", factory, typeof(ModuleStorage)));
My application has a custom authentication module and requires IIS Anonymous access. I also have Windows Integrated so that I can debug my application.
The issue I am having is the WebHttpBinding created by the WebServiceHost does not support having two authentication methods enabled in IIS. I can turn off Win. Auth. and it works but I can not debug.
So my question is... Can I enable WebHttpBinding to support both or can I somehow enable debugging without Win. Auth.
This service must be hosted as part of the application and I need a way to debug it.
Try debugging WCF REST Service using Fiddler, see the following links for more informations :
http://www.codeproject.com/Tips/213007/Debug-WCF-REST-Service
Depends what you are trying to debug. You could always trace the WCF service using SvcTraceViewer. Here is the config you can use on the server.
I ended up using ASP.NET Web API. I have to say so far I am a big fan!
http://www.asp.net/web-api
One of our C# ASP.Net projects has some dependencies on the Microsoft WSE 3.0 library, in order to consume a WSE3.0 web service. However, we're migrating the project to Windows Server 2008, which does not support WSE3.0.
So I need to refactor the code to remove the dependency to WSE 3.0 but still maintain its functionality. The code is simply adding a username security token to the SOAP context and then invoking the web service. I'm not sure where to start though. I suspect I switch to WCF, and if so, is there any tutorial available online to help?
I'd start by creating a simple application, maybe a Console application, to be a test consumer of the existing web service. Create client proxy classes for this application by using "Add Service Reference", and pointing it to the existing WSE service. That should take care of most of the problems.
Once the simple console application works, you can do the same for your ASP.NET project.
Needless to say, it's way past time to update that WSE service to WCF, which is supported, and which will continue to be supported for a long time to come.
This article is a pretty good rundown of the differences between WSE 3.0 & WCF and migration recommendations. I'd start by getting the migrated service to run under the basicHttpBinding configuration (without user name/password authentication).
Once the service is running as expected and look at this article to see how to get the migrated service configured for user name/password authentication. The article is written for Silverlight use but there should be enough in it to get you going.