Best way to let multiple .NET apps communicate with each other - c#

So, first of all sorry for my bad english.
Back to the questio, i have a main app, with a tab control, each tab contain another .NET exe. These need to send infos to the main app. Example:
Each exe in a tab have a random generated guid every second and the main app need to catch this and show in a listview or something as long the exe is "alive".
Currently i'm using SQLite, and everytime a new exe is started this one write in a table. Before closing it this exe remove the recod from the table.
In the mainwhile, the main app retrieve this update table and show the "alive" exe and the random generated guid (every second). All works fine, the problem is that i need to abandon this method and remove the two dll of SQLite.
What i tried is:
UDP socket between the N clients and the main app, but is not so stable. And sometime some exe got freezed. (using TCP will be so "heavy" for the only purpose to send a short string. Right?)
Changing the window text of the other exe and retrive it via processinfo, but is not updating it, i get it just the first time string.
So, there is a way for that? In local. Like, i don't know.. user32 sendmessage maybe? Or this method is too invasive for just a short string?
Considering that the N sub exe are process "inside" the main one, there is not a way to obtain infos from child process?
Thanks for your help!

UDP does not guarantee delivery of the packet by-desing. Unless you implement your own confirmation protocol above it. But implementation itself should be stable.
Using TCP will provide similar results. You'll just have to deal with reconnect stuff.
SendMessage/PostMessage is the easiest and straight forward method. But it will not allow you to pass string directly. Take a look at RegisterWindowMessage to register your own message and SendMessage with HWND_BROADCAST handle. And you'll have to send pointer to your string. Since SendMessage is synchronous you should be teoreticaly fine with disposing of that message, but I haven't tried that. Another option would be storing string somewhere-else (registry, file) and sending just update notification using SendMessage. And the main app will read and delete that registry/file record.
Self hosted WCF with netNamedPipeBinding should work as well. But that would be propably too robust solution.

Related

How do I let multiple consoles share input between one another?

What I'm Trying to Achieve
I'm attempting to build a console game that has multiple console windows that would be displaying inventory, status effects, current map, and health. Another console would be the main one that gathers input to effect the other consoles. The reason I want to do it this way is so that the other consoles can be updating their "graphics" (or text) without disturbing the input flow.
What I've Tried So Far
So far, I've attempted to use System.IO's File, FileStream, StreamWriter, and StreamReader to communicate between the consoles via text files. The problem I've ran into is that, when the main console (the input console) is attempting to write inputs to a file--which is communicating with another console (the "graphics" console)--it throws an error because the "graphical" console is trying to read the input of the file (or vice versa).
I figured that making the FileStream's FileAccess be Readable would do the trick, but I ran into the same issue.
I think I could get this to work if I could communicate between the consoles to tell each other that one is done writing to or reading the file... kind of like a back and forth... "I'm writing to the file... okay, I'm done" "I'm reading the file... okay, I'm done" and the cycle continues...
So, in summary, I suppose, my question is how can I communicate between two consoles using files?
Possible Solutions I could try learning SQL, but I don't know if I'd end up running into the same issue... so, if I must learn SQL for this project, I suppose, that'd be my last option.
Thank you!
IPC (inter process communication) is the keyword you're looking for.
There are multiple ways to do IPC, e.g. shared memory, named pipes or similar. .NET has an IpcChannel which uses TCP or a named pipe if the destination is on the local PC.

Forcing action right before application termination

I have 2 libraries.
The first one downloads some web pages and stores them in more "parsable" way to some files on disc.
The other relies on the files and therefore it needs some sort of verification that all the files were downloaded and processed correctly.
I couldn't figure out any other solution than the first library creating something like setup.txt where it would append messages such as $"Exception {e.GetType()} - {pathToDirectoryWithCorruptedFiles}" or $"Success - {pathToDirectoryWithCorrectFiles}".
I don't think this is the correct way, because after exceptions like StackOverFlowException or OutOfMemoryException and after termination with Ctrl + C the program is terminated and so there is no time to do something.
Is there any way of writing something or storing some information after these exceptions of after Ctrl + C ? Thank you for your answers.
If I understand correctly - one application downloads the file, and the second processes it. You need to notify the second application that the file download was completed successfully. Correct me if I'm wrong. I think it is better to use a message broker to send a message from the first application to the secondю This message will notify the second one that the work is completed without error and the second application can start working. Rabbitmq or Kafka should do the trick.
Or if there are exactly libraries - you can use events to notify the second library that file was downloaded successfully.

Using call back function between two project

I have a console application which continuously receives messages and saves those messages to a database. And I have another project which has a method that takes a message and checks if this message contains certain information. Now I want use a delegate to create a pointer for the check method and pass this pointer to the console application. Both projects are in the same solution. How can I do that?
You probably can't, because it sounds like from your description that the two programs are running in separate processes. Perhaps you could watch for new messages to your database, or set up a pipe between the two. In order to use a delegate your programs would need to be in the same process space.
If I have mis-read your post and one project is an exe and the other a dependent dll, then you can do what you are thinking. You can search for "C# event delegate examples". If you have a problem post some example code.

text exchange between two processes on a box using Memory Mapped File

Requirement is to be able to achieve 'chat' like communication between two console apps on the same windows box. I implemented this using named pipes, by implementing both a sender and receiver functionality in each app.
I want to try the same functionality but using Memory Mapped files (though I think it is not ideal for 'chat' type communication).
For simplicity sake, say chat messages are just strings of short length.
Here is what I have in mind:
One app will take care of creating a mutex and the memory mapped file.
Call it master.
In each app, we maintain two threads, one responsible for taking user
input and writing to the file, the other responsible for periodically
checking if it has something to read.
So four threads in all, each governed by a mutex for access to the
file.
Within the file, I think both should have their own 'section'. say
first half of the file size is for master app and the other half for
the second app.
So when user inputs a line of text in master app, the thread accesses
its half of the file and tries to append new text after the last new
line.
When app reads its section of the file for text, if there is any, app
reads it and blanks out its section.
Is this approach correct? Other approach would be to some how mark the message with the source id, so that the reader knows to ignore messages that are written by itself. But I feel that is unnecessary string parsing.
Also, other than each reader thread periodically trying to read their section of the file to see if there is new data, can you suggest any kind of notification mechanism? Sort of event handling? Reader thread will only go look for new messages if it gets some kind of event notification.
Any thoughts?
I agree with Hans for the most part, memory mapped files would not nessecarily be ideal here, if you go down this road though consider using a named event (see http://msdn.microsoft.com/en-us/library/windows/desktop/ms682396(v=vs.85).aspx) instead of polling.
You may need to p/invoke to get at this functionality from c#.
On the rest give each app its own region of the file, with a control section managed by the master to coordinate who gets what.

Run webpage C# function on visitors CPU?

What is a good way to run a time-consuming function from a C# webpage on the users CPU instead of running it on the web-server? Is it possible to get a C# function to run locally or do I have to write the function in JavaScript? The function itself is not secret in any way but I would prefer if the input and the output will be kept secret from the user. The solution should not require the user to download anything.
This functions uses data from the database + user input and when it's finished it writes the output to the database.
The functions best case is ~1s, average ~30s and worst ~10min (for every user) so it's not an option to run this function on the web-server.
You can get this to work, by either
coding the function in JavaScript
compiling the C# source to JavaScript (off the beaten track)
running the C# code in silverlight (done and done again, remember Java Applets? same science)
You won't really be able to keep the data totally secret, though.
Now, how to go about this... You will need a web service to provide the data to your silverlight component and another one to accept the computed results. You know, I don't really see why everyone else here thinks this is such a no-go...
As for data secrecy... The best you can do is obfuscate, though you should use a secure communication layer for aquiring the data and posting the results back, what ends up on the users computer will eventually be open for inspection by the user. If you use obfuscation techniques for your code, this will make reverse engineering an encryption/decryption scheme for the data payload harder, but you're playing essentially the same game as game devs / game crackers...
Personally, I would code the client side stuff in JavaScript. Chances are, what you want done is more of an algorithmic thing than a library thing, so porting to js should not be difficult to pull off.
You can't and shouldn't run arbitrary cs code on the user's computer. You also can't really run a long lived process in javascript on the client. User interaction with the page will be blocked and if they navigate to a different page it will stop.
What you should do is write a windows service to run these tasks in the background. Have a queue table where you save the input data from the web side, then have a service that polls the table for work and processes the input data.
You can't execute any C# code on the client computer when you they enter a webpage. You are correct in your assumption that you need to write it in javascript to execute it on the client.
This doesn't work. Web server does the processing. Unless you are doing distributed computing and stuff like that, it is not designed to work on a client. Client needs to download software to process stuff. Webpage is webpage. Text.
The only code you can run on the client is js.
That being said, you definitely don't want to run your function on the client if you have sensitive information involved.

Categories

Resources