I am trying to create webhook receiver using .Net 5.
But the Nuget Package Microsoft.AspNetCore.Webhooks.Receivers.Custom appears to be depreciated.
Is there any alternative Nuget package which works on .Net 5/.Net 6?
Which template is better for webhook receiver implementation (like MVC,Web API,Console etc)?
Any supporting links for implementation of webhook receiver using .Net 5/.Net 6 will be a great help.
I also didn't find the webhook support in ASP.net core 5/6. I came up with another option as ASP.NET Core SignalR
https://learn.microsoft.com/en-us/aspnet/core/signalr/introduction?view=aspnetcore-6.0
Check if this helps you.
Webhook receiver is just a post endpoint, so something like this should do it. Or you can find some useful extension here https://github.com/aspnet/AspLabs/tree/main/src/WebHooks
[HttpPost]
public async Task MyWebHookEndpoint()
{
using (StreamReader reader = new StreamReader(HttpContext.Request.Body, Encoding.UTF8))
{
var body = await reader.ReadToEndAsync();
}
}
Related
It appears that this can be achieved by setting up a callback function to the ServicePoint.
The solution (although the goal is different, the same technique can be used) is discussed in this question Specify the local endpoint for HTTP request.
Following it, I tried
var servicePoint = ServicePointManager.FindServicePoint(new Uri(uri));
servicePoint.BindIPEndPointDelegate = (servicePoint, remoteEndPoint, retryCount) =>
{
if (remoteEndPoint.AddressFamily == System.Net.Sockets.AddressFamily.InterNetwork)
{
return new IPEndPoint(IPAddress.Any, 0);
}
throw new InvalidOperationException("no IPv4 address");
};
var _client = new HttpClient();
HttpResponseMessage response = await _client.GetAsync(uri);
expecting that the callback is called at the GetAsync() but it is not.
It would be much appreciated if someone tells me what I am missing.
Or, a completely different approach to achieve my goal, to force IPv4 at connections that HttpClient makes, would also be very much welcome.
Thanks in advance for your help.
Update
In the question How to use HttpClient to send a Request from a specific IP address? C#, someone says "... the .net core team have implemented the HttpClientHandler etc without bothering to put anything related to service points in there ..."
To confirm, I build the above code both with Framework4.7 and Core3.1 to find out that indeed, when built with Core, the callback is NOT called.
A Xamarin project targets .Net standard, which is a Core if I am not mistaken. I guess I need to forget this ServicePoint stuff and look for other solutions...
Again, your insight will be very much appreciated!
This article shows a well-known problem with HttpClient that can lead to socket exhaustion.
I have an ASP.NET Core 3.1 web application. In a .NET Standard 2.0 class library I've added a WCF web service reference in Visual Studio 2019 following this instructions.
In a service I'm using the WCF client the way it's described in the documentation. Creating an instance of the WCF client and then closing the client for every request.
public class TestService
{
public async Task<int> Add(int a, int b)
{
CalculatorSoapClient client = new CalculatorSoapClient();
var resultat = await client.AddAsync(a, b);
//this is a bad way to close the client I should also check
//if I need to call Abort()
await client.CloseAsync();
return resultat;
}
}
I know it's bad practice to close the client without any checks but for the purpose of this example it does not matter.
When I start the application and make five requests to an action method that uses the WCF client and then take a look at the result from netstat I discover open connections with status TIME_WAIT, much like the problems in the article above about HttpClient.
It looks to me like using the WCF client out-of-the-box like this can lead to socket exhaustion or am I missing something?
The WCF client inherits from ClientBase<TChannel>. Reading this article it looks to me like the WCF client uses HttpClient. If that is the case then I probably shouldn't create a new client for every request, right?
I've found several articles (this and this) talking about using a singleton or reusing the WCF client in some way. Is this the way to go?
###UPDATE
Debugging the appropriate parts of the WCF source code I discovered that a new HttpClient and HttpClientHandler were created each time I created a new WCF client which I do for every request.
You can inspect the code here
internal virtual HttpClientHandler GetHttpClientHandler(EndpointAddress to, SecurityTokenContainer clientCertificateToken)
{
return new HttpClientHandler();
}
This handler is used in to create a new HttpClient in the GetHttpClientAsync method:
httpClient = new HttpClient(handler);
This explains why the WCF client in my case behaves just like a HttpClient that is created and disposed for every request.
Matt Connew writes in an issue in the WCF repo that he has made it possible to inject your own HttpMessage factory into the WCF client.
He writes:
I implemented the ability to provide a Func<HttpClientHandler,
HttpMessageHandler> to enable modifying or replacing the
HttpMessageHandler. You provide a method which takes an
HttpClientHandler and returns an HttpMessageHandler.
Using this information I injected my own factory to be able to control the generation of HttpClientHandlers in HttpClient.
I created my own implementation of IEndpointBehavior that injects IHttpMessageHandlerFactory to get a pooled HttpMessageHandler.
public class MyEndpoint : IEndpointBehavior
{
private readonly IHttpMessageHandlerFactory messageHandlerFactory;
public MyEndpoint(IHttpMessageHandlerFactory messageHandlerFactory)
{
this.messageHandlerFactory = messageHandlerFactory;
}
public void AddBindingParameters(ServiceEndpoint endpoint, BindingParameterCollection bindingParameters)
{
Func<HttpClientHandler, HttpMessageHandler> myHandlerFactory = (HttpClientHandler clientHandler) =>
{
return messageHandlerFactory.CreateHandler();
};
bindingParameters.Add(myHandlerFactory);
}
<other empty methods needed for implementation of IEndpointBehavior>
}
As you can see in AddBindingParameters I add a very simple factory that returns a pooled HttpMessageHandler.
I add this behavior to my WCF client like this.
public class TestService
{
private readonly MyEndpoint endpoint;
public TestService(MyEndpoint endpoint)
{
this.endpoint = endpoint;
}
public async Task<int> Add(int a, int b)
{
CalculatorSoapClient client = new CalculatorSoapClient();
client.Endpoint.EndpointBehaviors.Add(endpoint);
var resultat = await client.AddAsync(a, b);
//this is a bad way to close the client I should also check
//if I need to call Abort()
await client.CloseAsync();
return resultat;
}
}
Be sure to update any package references to System.ServiceModel.* to at least version 4.5.0 for this to work. If you're using Visual Studio's 'Add service reference' feature, VS will pull in the 4.4.4 versions of these packages (tested with Visual Studio 16.8.4).
When I run the applications with these changes I no longer have an open connection for every request I make.
You should consider disposing your CalculatorSoapClient. Be aware that a simple Dispose() is usually not enough, becaue of the implementation of the ClientBase.
Have a look at https://learn.microsoft.com/en-us/dotnet/framework/wcf/samples/use-close-abort-release-wcf-client-resources?redirectedfrom=MSDN, there the problem is explained.
Also consider that the underlying code is managing your connections, sometimes it will keep them alive for later use. Try calling the server a lot of times to see, if there is a new connection for each call, or if the connections are being reused.
The meaning TIME_WAIT is also discussed here:
https://superuser.com/questions/173535/what-are-close-wait-and-time-wait-states
https://serverfault.com/questions/450055/lot-of-fin-wait2-close-wait-last-ack-and-time-wait-in-haproxy
It looks like your client has done everything required to close the connection and is just waiting for the confirmation of the server.
You should not have to use a singleton since the framework is (usually) taking good care of the connections.
I created an issue in the WCF repository in Github and got some great answers.
According to Matt Connew and Stephen Bonikowsky who are authorities in this area the best solution is to reuse the client or the ChannelFactory.
Bonikowsky writes:
Create a single client and re-use it.
var client = new ImportSoapClient();
And Connew adds:
Another possibility is you could create a channel proxy instance from
the underlying channelfactory. You would do this with code similar to
this:
public void Init()
{
_client?.Close();
_factory?.Close();
_client = new ImportSoapClient();
_factory = client.ChannelFactory;
}
public void DoWork()
{
var proxy = _factory.CreateChannel();
proxy.MyOperation();
((IClientChannel)proxy).Close();
}
According to Connew there is no problem reusing the client in my ASP.NET Core web application with potentially concurrent requests.
Concurrent requests all using the same client is not a problem as long
as you explicitly open the channel before any requests are made. If
using a channel created from the channel factory, you can do this with
((IClientChannel)proxy).Open();. I believe the generated client also
adds an OpenAsync method that you can use.
UPDATE
Since reusing the WCF Client also means reusing the HttpClient instance and that could lead to the known DNS problem I decided to go with my original solution using my own implementation of IEndpointBehavior as described in the question.
I am working on the .NET framework 4.6.1. I want to stream data from the typescript client to my service. I have taken code from here.
This is the service side code :
public async Task UploadStream(ChannelReader<byte[]> stream)
{
while (await stream.WaitToReadAsync())
{
while (stream.TryRead(out var item))
{
// do something with the stream item
Console.WriteLine(item);
}
}
}
Client side:
const subject = new signalR.Subject();
await connection.send("UploadStream", subject);
// getting the byte data and calling next in a loop.
subject.next(data);
I am using ASP .NET core signalR library. These are the packages installed at the server side: Microsoft.AspNetCore 1.1.0 , Microsoft.AspNetCore.SignalR.Common 1.1.0,Microsoft.AspNetCore.SignalR.Core 1.1.0, Microsoft.AspNetCore.SignalR.PRotocols.MessagePack 1.1.0
At the client side, I have the latest preview release.
"#aspnet/signalr": "3.0.0-preview6.19307.2",
"#aspnet/signalr-protocol-msgpack": "3.0.0-preview6.19307.2",
I tried searching for the right package to install for ASP .NET framework but didn't find anything. Is this functionality available for .NET framework 4.6.1.
When I am calling the UploadaStream function from the client side. I have received an error specifying that unable to invoke the "UploadStream" function.
Please tell me the right set of the package to install.
I have some data in my app's backend that I need to post from my application to another application.
I was thinking about creating form, filling it with the data and auto-posting with javascript within onLoad. But this seems somehow outdated practice for me. What would be the correct way to post from backend to some other application's url using ASP.NET 5 & MVC6 features?
Note: preferably, it should be JSON & RESTful design (controller will be accepting the data on another end), though I don't think this should change anything.
You should be able to use e.g. ordinary HttpClient. This is an example from the MS blog.
using System.Net.Http;
using (var client = new HttpClient())
{
var baseUri = "http://playapi.azurewebsites.net/api/products";
client.BaseAddress = new Uri(baseUri);
client.DefaultRequestHeaders.Accept.Clear();
var response = await client.GetAsync(baseUri);
if (response.IsSuccessStatusCode)
{
var responseJson = await response.Content.ReadAsStringAsync();
//do something with the response here. Typically use JSON.net to deserialise it and work with it
}
}
This is a GET example, but POST should be pretty similar. If you control both servers, then you can use a fancy thing called Swagger (and Swashbuckle nuget package for .NET). It is kind of WSDL for the REST API, it can generate full proxy to access your API, similar to what WCF does + a nice page with documentation and testing forms.
P.S. Not sure of the state of Swashbuckle for ASP.NET Core, but the pre-release version is available on Nuget as well.
if I send a request, and I expect the response to come trough SignalR, is it possible to test this using a LoadTest or PerformanceTest in Visual Studio?
Short answer: Yes
I've done this several times in CodedWebTests but it would also be possible to do in a declarative WebTest. You can use a custom PreWebTest Event Handler to create your signalR client and connect to your SignalR hub. What you choose to do with the signalR notification is up to you but I like to save it to the WebTestContext as well as display it on the test results screen using the AddCommentToResult method.
The method below creates a hubConnection invokes the "addToGroup" function on the hub and then tells the client what to do when it receives a message.
using Microsoft.AspNet.SignalR.Client;
public class SignalRPlugin : WebtTestPlugin
{
public override void PreWebTest(object sender, PreWebTestEventArgs e)
{
var hubConnection = new HubConnection("yourSignalRUrl");
var hubProxy = hubConnection.CreateHubProxy("notifications");
hubConnection.Start().Wait();
hubProxy.Invoke("addToGroup", "me");
hubProxy.On<string>("message", s =>
{
e.Webtest.AddCommentToResult(s);
e.Webtest.Context.Add("signalRMessages", s);
});
}
}
Use it by attaching the event handler in your test constructor.
public MyWebTest()
{
PreWebTest += new SignalRPlugin().PreWebTest;
}
Then once you have the signalR messages you can use a custom validation rule to validate that the response was received. Just have a while loop checking the WebTestContext for the "signalRMessages" key. I strongly suggest making sure you add a timeout feature so you are not waiting forever if the messages never come in.
The other option if you are writing CodedWebTests is to create a WaitForNotifications method that basically does the same thing as the validation rule. The advantage with this is that you can use an extraction rule to get data out of the last response and then use that data in validating your signalR messages. If you still need to fail a test in your WaitForNotification method use WebTest.InternalSetOutcome(Outcome.Fail);
The best way to load test a SignalR application is by building on the crank project included in the source.
This is a simple ramp up solution built with the .Net client but it is relatively easy to modify to call whatever hub methods you require and to analyse the responses.
You can always attach the Visual Studio profiler to your iis express instance to get detailed profiling data if required.