How should I build a c# app that's based on amqp instead of rest. A .NET Core webapi expects requests via standard Http and not messages from amqp servers like rabbitmq. I'm trying to develop a microservice using c# but the way the rabbitmq client works does not seem to fit inside of a .NET Core rest api, so is there a package that can make this happen or is there a .NET project template specific for this use case.
Use .NET Generic Host in ASP.NET Core - see here for setup etc.
You can then use messaging frameworks like NServiceBus, MassTransit or EasyNetQ to interact with the broker (RabbitMQ in your scenario). I've used MassTransit quite a bit and highly recommend - really makes interacting with the broker a lot easier. I've also heard good things about NServiceBus, but haven't used it personally.
You can use Worker services I have used it for other message queue technologies. Here is a link to the Microsoft documentation.
Here are some articles I found, in particular to RabbitMQ
https://www.programmingwithwolfgang.com/rabbitmq-in-an-asp-net-core-3-1-microservice/
https://codeburst.io/get-started-with-rabbitmq-2-consume-messages-using-hosted-service-e7e6a20b15a6
Related
In .net framework they introduced ASP.NET Webhooks to make implementing Webhooks nice and simple. For the life of me, I can't find this in the .NET 6 documentation.
Is this library deliberately absent and is the new best practice to build this from scratch for your own app and perhaps tie it into Azure Service Bus or a similar queuing system?
I have a dated game server with typical TCP packet protocol (length / type / data[length]), and my task is to find modern frameworks to rewrite it in.
Having written a (small) RESTish API in ASP.NET Core 2.1, I know that it provides DI / logging / configuration features which could perfectly replace similar functionality in the old server. I thought I could use ASP.NET Core, making it handle said TCP packets instead of HTTP requests.
Now I'm a bit stuck in where to start and if / how it would fit into ASP.NET Core.
So far I've RTFM'ed about inner ASP.NET Core workings and found some things that confused me:
Official docs state Kestrel only supports HTTP based scenarios (don't wanna use IIS). So does the tag here on SO.
Then I found a project claiming to add TCP support to Kestrel, yet I don't fully understand how it's done. It seems to be done by implementing a ConnectionHandler, but I can't see, for example, where it starts a TcpListener to accept new continuous connections with clients.
With Kestrel seemingly out of the question, I thought about writing an IHostedService or BackgroundService to do all TCP communication in.
Then I didn't know if I could use Middleware to pipe my TCP packets through (thought of an authorization and game logic middleware). Official docs quickly talk about HTTP or "web" requests, so I thought a typical middleware pipeline is out of the question too.
To sum it up, my research resulted in the following two questions:
Can I actually use Kestrel for continuous TCP connections with binary communication?
What is the relation between the middleware pipeline and HTTP functionality / Kestrel? Can I use a middleware pipeline in custom services for TCP communication?
After getting back to this, I realized that Project Bedrock is aiming to further generalize Kestrel to support completely custom protocols, not even limited to raw TCP. An overview / description can be found here.
The link above shows the current public state of the project on the GitHub repository with great practical examples. It seems to be planned to be integrated with whatever follows the ASP.NET Core roadmap for .NET 6, but a prerelease version compatible with .NET Core 3.1 is available and works great in my experiments.
I am interested in deploying a server to GoDaddy as a C# web application, then have desktop clients developed in C# and Java be able to subscribe/publish to the server using WebSockets (RFC 6455).
WebSocket supported libraries I am looking at are XSockets.Net and SignalR.
I am not able to find anything on using XSockets.Net (not to be confused with XSocket.org) in Java. I understand that XSockets targets MS .Net framework and Mono environments. However, looking at SignalR, there is also SignalA which is a Java based SignalR client for Android.
Thinking-out-loud... I understand there are many WebSocket libraries for Java, which suggests the idea that if I am able to publish a message (using WebSocket) from a Java application to a server, then I should be able to read it and processes it in C#, since WebSocket protocol is a standard.
Thus far, I believe a SignalR solution will satisfy my requirement to allow C# & Java applications to talk on the Web, but due to transport requirments of SignalR, my communication will not utilize WebSockets. Reading through SignalR requirements, to get WebSockets transport activated I must use Windows8+ with .Net Framework for 4.5+. GoDaddy does not use Windows8 for windows hosting, and even if it did, then all my clients must also use Windows8, which is not a guarentee.
So the question is: How can I get C# & Java desktop clients to talk on the web via WebSockets, othan than using SignalR and XSockets.Net?
Any help is very much appreciated!
EDIT: I will now look into deploying a C# XSockets.NET Server and have a C# XSockets.NET client and a Java JWebSocket client since both JWebSockets and XSockets support the WebSocket RFC6455 protocol. I will post my findings here and close this question if that was a successful effort.
You can implement a RFC6455 client in any language and use XSockets. However do note that XSockets uses a publish/subscribe pattern that you will have to implement as well to take benefit of the platform.
The upside is that you actually wont have to implement RFC6455 since you can implement a custom (non websocket protocol) and use that when communicating from desktop (or anything else). Since everything in XSockets is a plugin you can add custom protocols and still communicate with client talking RFC6455 since XSockets will offer cross-protocol communication.
So the thing you have to implement is actually only the publish/subscribe functionality in the java client.
There are probably not any Java clients out there that implements the IXSocketClient interface today, and we focused on Mono instead of Java when covering multi-platform support.
We will help you out in any way we can if you decide to write your own java implementation.
Note: as of the next version (not far away) it will be very easy to implement your custom protocol and connect from any device talking TCP/IP
In my humble opinion, you have misunderstood some things.
XSockets and SignalR are libraries which are totally oriented to a specific platform, .NET. They both wrap the functionality of WebSockets, a platform independent standard, to ease its use. This does not by anyway mean that you could use XSocket, or SignalR libraries in all platforms.
I suppose that creating a java client for XSockets or SignalR would be an overkill and would lead you to heavily depend on a 3rd party library. In your situation, I would go on with using WebSockets directly on my server side. Then I would use a library handling the WebSockets standard for each client, which could be different for each client development platform. Therefore, you would depend on one universal standard and you would minimize dependencies on 3rd party libraries.
Hope I helped!
I want to implement a simple cardgame in silverlight that can be played together via a server.
My question is, what concept for communication between client and server I should use.
Is it possible to use WCF to
implement the server ? I guess no because its more like a dataprovider right ?
or do I need to use .NET Remoting ? Haven't read much about it yet, but
I'm not quite sure if it is maybe out
of date ?
Maybe there are newer approaches that I don't know yet ?
Maybe someone has a good tutorial link for the beginning that is not a bad coded sample from year 2002
WCF and .NET Remoting define communication protocols, that is, they define the plumbing between client and server.
When writing a client/server application, you should use WCF as .NET Remoting is deprecated.
See this code project article and code for a simple client/server implementation using WCF. The code is for uni-directional communication, where the server responds to the client.
Here is another article, with a more complicated sample (chat client), using bi-directional communications between client(s) and server. It also uses WPF as the UI layer, so you may need to read around that if using winforms.
WCF (Windows Communication Foundation) is the .NET technology for communication. It includes simple client / server scenarios, as well as publish / subscribe and peer to peer.
Ignore .NET Remoting. It has been replaced by WCF.
I have no idea why you thought that WCF was a data provider, but you're mistaken. See the WCF Developers Center for more on WCF.
I created a service that is hosted on a server that has .Net 3.5 installed and I need to call this service from a client that only has .Net 2.0 installed.
Is there a way I can do this?
If your WCF service exposes an endpoint using basicHttpBinding, then it should be possible for the .NET 2.0 client to consume it. As Marc said, "no problem".
Yes you can do it. There are some caveats, however:
You have to use protocols that match. The standard .NET 2.0 libraries don't support many secure web service features; in fact, you're pretty much stuck with using only basicHttpBinding on the WCF service if you want to be consumed by a default install of .NET 2.0. That is a severe limitation in many enterprise scenarios. However, it may be all you need.
If you need more security but are still using .NET 2.0, there are alternatives. Again, your WCF service must accommodate your .NET 2.0 client, but your .NET 2.0 client will also need to take advantage of an external library. Specifically, you'll need the Web Service Enhancements put out by Microsoft. Keep in mind, however, that these libraries implement a beta version of some SOAP protocols, while WCF (the successor to WSE in many ways) implements the standards by default. Since there were some breaking changes in the protocols (particularly WS-Addressing), you'll have to offer a customBinding endpoint on your WCF service to accommodate.
Unfortunately, I can't tell you which you'll use, as it'll depend on which protocol you want to accommodate on the service, but most of your problems will be solved by changing the messageVersion of the textMessageEncoding for the custom binding. This is not the best scenario, but it could buy you something if you're trying to integrate a client.
Bottom line, there's a lot of work to get a .NET 2.0 client to talk to a WCF service for anything other than basicHttpBinding. In many cases, basicHttpBinding may be enough. For many enterprise scenarios, it will not. I can't speak as to which will help you or not, but it is possible to get it to work -- I've done it successfully.
But it's a big pain. Look for an alternative if you can.
Yes of course - the service being hosted on .NET 3.5 doesn't require the same version of the .NET framework on the client. Heck - you can even call such a service from Java or PHP! That's the whole POINT of Service Oriented Architecture! :-)
You need to define your service contract (what's the service called; what methods are available to be called on it) and you need to decide how to host it, e.g. at what address can you call this service, and what parameters are required (e.g. HTTP vs. TCP, secured or not secured etc.) - that's a lot of work, even in WCF.
Here are three introductory articles for WCF - check them out!
MSDN
CodeProject
Dennis van der Stelt's Blog
But calling that service from a .NET 2.0 client is ABSOLUTELY no problem!
Marc