Communicating between a console app and a hosted service?
Is there any decent way of communicating between a console application and a hosted service? For instance if I want to update some in-memory data from outside the service (eg. via a console command). Ex.
myhostedservice add
would in this case access the currently running hosted service and add some new data to it or whatever.34 Replies
IPC maybe?
or RPC
okay seem pretty complicated this isn't a good idea
Actually do you happen to have any resources on using RPC? I read a bit about it and it seems like it's mostly a C/++ thing?
rpc is just remotely calling a function from another process and/or device
possibly across a network
Isn't gRPC quite simple with a library and code gen?
Any tutorials/articles about RPC/gRPC in C#?
dont know any sorry
I found this but it seems to be specifically about ASP.NET Core
https://learn.microsoft.com/en-us/aspnet/core/grpc/?view=aspnetcore-6.0
Overview for gRPC on .NET
Learn about gRPC services with Kestrel server and the ASP.NET Core stack.
Here are some docks on what seems to be plain gRPC client/server: https://grpc.io/docs/languages/csharp/quickstart/
Looks like this one is more focused on using in just plain C# apps: https://learn.microsoft.com/en-us/aspnet/core/grpc/basics?view=aspnetcore-6.0
gRPC services with C#
Learn the basic concepts when writing gRPC services with C#.
yeah looks good
Now I'm all of a sudden very interested in gRPC and want to build a client/server or peer-to-peer app. I'll probably neglect my security and devops training
I'm not too concerned about security really, this is just a dumb idea
I've got some very interesting security training lined up and our org deals with billions (literally) of legal documents and personal information so security is paramount
you have the options of REST and gRPC which depends on what you're trying to do. if you're using small amounts of data infrequently, then REST will work and is definitely the easiest to set up on your client + API. If you plan on more frequent comms, gRPC is the route
How about WCF? There is a new implementation called WCF Core. It could be complicated if you have never worked with WCF before, but it will allow you to communicate between processes without network
I've done a lot of IPC, but you wouldn't like the way i handle it lol
I use it to communicate between a process and a NativeAOT library that i injected into another process
isnt wcf ancient
I use a combination of Mutexes and MemoryMappedFiles
CoreWCF is under active development. https://github.com/CoreWCF/CoreWCF
Still, I wouldn't recommend using it if you're new to WCF. But it has it's own benefits, like the inter-process communication, which can be very handy if you don't want to expose communication over the network.
you could use named pipes which are simpler
Do you think so?
Can you write entire structs into a pipe?
With MemoryMappedFiles you can do
mmva.Write<MyBlittableStruct>(theInstance);
And read that back just the same
mmva being a MemoryMappedViewAccessorYou can just serialize it however you want
Don't you need to pass strings between pipes though
They're binary, they don't care. As long as you control both ends it doesn't matter too much
I would say maybe pipes feel a little dated, but they still might be fine. Could also consider a simple HTTP endpoint
I use Mutexes mainly to simply "wait for the next command"
For a pipe, you'd often continually read the pipe over and over and over until it receives relevant data
With a Mutex, i just
.WaitOne()
Oooh right, so I could like hypothetically host both a local API alongside the hosted service, then make calls to the API from another app?
Would that work though? Hosting a Windows background service alongside a web API in the same project running at the same time?
Well, it would be a web api project with a IHostedService for your background stuff, but yea that should work fine
That's cool
Gonna have to investigate that
And if you want to give pipes a try, check out https://learn.microsoft.com/en-us/dotnet/standard/io/how-to-use-named-pipes-for-network-interprocess-communication
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
I think I'm gonna try the API + hosted service approach, although SignalR would probably also work.
SignalR would be a slightly weird pick for IPC between a console app and a long running service
I'm thinking your messages will most often be a single request and a single response pair for each "conversation", right?
ie, I start the console app, it sends a request to the service adn the service responds, and thats it
yes
Don't need any long-running connection
definately a normal web api or a named pipe then, imho