Develop Reference

Listen to system reboot/shutdown event with C# - cross platform

If we're just talking about Windows, I can use the Microsoft.Win32.SystemEvents.SessionEnding
Is there something cross-platform that I can use? I want something that works with Windows and Linux. I shall be using .NET 6.0

To my knowledge, there is no straightforward and reliable way to determine this in a Linux environment, let alone a cross-platform solution. You will need to implement a linux-specific way to detect this.
As #fredrik mentioned in the comments, using PosixSignal would let you know that your application is being asked to terminate, but not why. You can nevertheless examine the situation upon receiving a SIGTERM to determine if the system is indeed shutting down. For example, running systemctl is-system-running would return "stopping" if that is the case.
If we assume a modern Linux desktop environment, a more robust alternative could be to subscribe to the D-bus signal PrepareForShutdown. From the systemd documentation:
The PrepareForShutdown() and PrepareForSleep() signals are emitted when a system suspend or shutdown has been requested and is about to be executed, as well as after the the suspend/shutdown was completed (or failed)...
The library Tmds.Dbus provides an async API to listen to that signal in your .net app. You will still need to deal with the fact that you'll receive this AND the SIGTERM in sequence.

Changing a game server platform

I'm developing a small multiplayer game, and currently the game server runs in a c# console application.
This limits me because:
the server gets stuck whenever I even start a text select in the console. If I even accidentally touch the console, the server gets stuck and I'm left shocked that the client is stuck somewhy, whereas it gets timed-out as soon as I right click the console and the select is canceled
I'm limited with supplying user input to the server. Say, I want to implement server commands, I have a great system I've written that handles pub-sub messages that I can use, and I just don't have any way to easily send those messages, since the server is console based and I can't rely on console input, when there's a lot of output to the console, and the client (which can publish those messages as well) is XNA base, and there's no easy way to implement a console on the client side (which would be an awesome thing to do, and would somehow solve some of my problems if I found a good library for XNA consoles).
I have several options to choose from -
WPF - I can write the server in WPF instead of a ConsoleApplication. This would give me somehow nice GUI, and it would be relatively easy to integrate since the majority of the code is a library and I wouldn't even need to export events, since I would be able to use my pub-sub system for the events.
Web - I have this picture in my mind - I run an executable which starts a local server, and it would just run in the background, people would be able to connect regularly, but I would be able to access a web page, and control the server through it. It would of course be a different port than the game server itself (I assume), and I would be able to control the server (send commands, kick players, restart rounds, and so on) through it.
What I'm here for, is for your suggestions, first of all. What do you find more suitable, pros and cons.
And if we're talking about a web-based server, what's the most standard way of doing that? I mean... mostly for raising a server, and how the website would communicate with it.
Thanks for reading, and thanks in advance for the advises!

Easiest would probably be to use something like Nancy (which is super simple to use) to process REST commands. You can add a Nancy webhost project to your solution and run it alongside your server, reusing your pub/sub architecture. Bonus, you can then use Nancy for certain client services that may not work as well on the server.
This is in fact similar to what we're doing with out XNA game, except Nancy also talks directly to clients, alongside the server, to serve up certain cpu or database bound data that isn't performance critical. We use redis to handle the pub/sub communication between the Nancy hosts and server instances.

2 Console applications running in different threads

How would I make it so that I have one main program with a background process that "listens" for catches (via a function like sendDebugInfo(Exception e) for example) and then unhide the second console and display the message but if the user closes the debug window it doesn't exit the program.
If the above isn't clear enough here is a simple version:
Console application 1 function helloWord() is used
Console application 1 function helloWorld() sends a String to a second console window (but within the same project)
The second console displays "hello world".

You are really asking about inter-process communication (IPC).
There are many ways to achieve IPC. I suggest you have a look at Named Pipes. They are easy to use and quite reliable.
http://msdn.microsoft.com/en-us/library/system.io.pipes.aspx
The basic idea behind Named Pipes is that you have a named resource that you can write messages to in one process and read messages from in the other process. The message can be anything you want. The processes connect to the pipe simply by using the pre-agreed name for it.

Just for clarification, saying that you want two console applications running in different threads is somewhat misleading. Console applications typically run on different processes entirely and since threads are not shared between processes two console applications running in different threads is the norm. However when you say this explicitly it sounds like you're trying to run them on the same process but different threads which I'm not even sure is possible.
That said, Eric J. is right you really seem to be asking about IPC which can be performed in a number of ways. Named pipes is one way and TCP loopback is another. If you want these applications to run on separate machines at some point you're going to want to use TCP. Otherwise named pipes are a lot easier to deal with.
I'd suggest reading up on IPC, figuring out which method suits your needs and try to make it work. When you run into a specific issue like "my messages aren't getting through" or something then you should come back and search for a similar question or create a new question.

C# communication between processes

I'm working with an application, and I am able to make C# scripts to run in this environment. I can import DLLs of any kind into this environment. My problem is that I'd like to enable communication between these scripts. As the environment is controlled and I have no access to the source code of the application, I'm at a loss as to how to do this.
Things I've tried:
File I/O: Just writing the messages that I would like each to read in .txt files and having the other read it. Problem is that I need this scripts to run quite quickly and that took up too much time.
nServiceBus: I tried this, but I just couldn't get it to work in the environment that I'm dealing with. I'm not saying it can't be done, just that I can't get it done.
Does anyone know of a simple way to do this, that is also pretty fast?

Your method of interprocess communication should depend on how important it is that each message get processed.
For instance, if process A tells process B to, say, send an email to your IT staff saying that a server is down, it's pretty important.
If however you're streaming audio, individual messages (packets) aren't critical to the performance of the app, and can be dropped.
If the former, you should consider using persistent storage such as a database to store messages, and let each process poll the database to retrieve its own messages. In this way, if a process is terminated or loses communication with the other processes temporarily, it will be able to retrieve whatever messages it has missed when it starts up again.

The answer is simple;
Since you can import any DLL into the script you may create a custom DLL that will implement communication between the processes in any way you desire: shared memory, named pipe, TCP/UDP.

You could use a form of Interprocess Communication, even within the same process. Treat your scripts as separate processes, and communicate that way.
Named pipes could be a good option in this situation. They are very fast, and fairly easy to use in .NET 3.5.
Alternatively, if the scripts are loaded into a single AppDomain, you could use a static class or singleton as a communication service. However, if the scripts get loaded in isolation, this may not be possible.

Well, not knowing the details of your environment, there is not much I can really offer. You are using the term "C# scripts"...I am not exactly sure what that means, as C# is generally a compiled language.
If you are using normal C#, have you looked into WCF with Named Pipes? If your assemblies are running on the same physical machine, you should be able to easily and quickly create some WCF services hosted with the Named Pipe binding. Named pipes provide a simple, efficient, and quick message transfer mechanism in a local context. WCF itself is pretty easy to use, and is a native component of the .NET framework.

Since you already have the File I/O in place you might get enough speed by placing it on a RAM disk. If you are polling for changes today a FileSystemWatcher could help to get your communication more responsive.

You can use PipeStream. Which are fast than disk IO as they are done using main memory.

XMPP/Jabber is another appraoch take a look at jabber.net.

Another easy way is to open a TCP Socket on a predefined Port, connect to it from the other process and communicate that way.

.NET IPC without having a service mediator

I have two unrelated processes that use .NET assemblies as plugins. However, either process can be started/stopped at any time. I can't rely on a particular process being the server. In fact, there may be multiple copies running of one of the processes, but only one of the other.
I initially implemented a solution based off of this article. However, this requires the one implementing the server to be running before the client.
Whats the best way to implement some kind of notification to the server when the client(s) were running first?

Using shared memory is tougher because you'll have to manage the size of the shared memory buffer (or just pre-allocate enough). You'll also have to manually manage the data structures that you put in there. Once you have it tested and working though, it will be easier to use and test because of its simplicity.
If you go the remoting route, you can use the IpcChannel instead of the TCP or HTTP channels for a single system communication using Named Pipes. http://msdn.microsoft.com/en-us/library/4b3scst2.aspx. The problem with this solution is that you'll need to come up with a registry type solution (either in shared memory or some other persistent store) that processes can register their endpoints with. That way, when you're looking for them, you can find a way to query for all the endpoints that are running on the system and you can find what you're looking for. The benefits of going with Remoting are that the serialization and method calling are all pretty straightforward. Also, if you decide to move to multiple machines on a network, you could just flip the switch to use the networking channels instead. The cons are that Remoting can get frustrating unless you clearly separate what are "Remote" calls from what are "Local" calls.
I don't know much about WCF, but that also might be worth looking into. Spider sense says that it probably has a more elegant solution to this problem... maybe.
Alternatively, you can create a "server" process that is separate from all the other processes and that gets launched (use a system Mutex to make sure more than one isn't launched) to act as a go-between and registration hub for all the other processes.
One more thing to look into the Publish-Subscribe model for events (Pub/Sub). This technique helps when you have a listener that is launched before the event source is available, but you don't want to wait to register for the event. The "server" process will handle the event registry to link up the publishers and subscribers.

Why not host the server and the client on both sides, and whoever comes up first gets to be the server? And if the server drops out, the client that is still active switches roles.

There are many ways to handle IPC (.net or not) and via a TCP/HTTP tunnel is one way...but can be a very bad choice (depending on circumstances and enviornment).
Shared memory and named pipes are two ways (and yes they can be done in .Net) that might be better solutions for you. There is also the IPC class in the .Net Framework...but I personally don't like them due to some AppDomain issues...

I agree with Garo.
Using a pub/sub service would be a great solution. This obviously means that this service would need to be up and running before either of the other two.
If you want to skip the pub/sub you can just implement the service in both applications with different end points. When either of the applications is launched it tries to access the other known object via the IPC proxy. If the proxy fails, the other object isn't up.
-Scott

I've spent 2 days meandering through all the options available for IPC while looking for a reliable, simple, and fast way to do full-duplex IPC. IPCLibrary, which I found on Codeplex.com, is so far working perfectly out of all the options that I tried. All with only 7 lines of code. :D If anyone stumbles across this trying to find a full-duplex IPC, save yourself a ton of time and give this library a try. Grab the source code, compile the data.dll and follow the examples given.
HTH,
Circ