Introduction
This article demonstrates a quick and easy-to-use implementation for cross AppDomain communication in .NET by leveraging Windows native messaging.
The XDMessaging library is based on some code developed to aid rapid development for a recent Vista project which required a lot of cross AppDomain communication in a locked-down environment. It proved to be extremely useful in a number of scenarios where .NET Remoting would have been impractical (if not impossible), and actually solved more problems than I could have imagined due to its simplicity.
The library is intended to send messages between multiple applications in a same-box scenario. For example where a task-tray application might want to communicate with (or monitor) a separate desktop application. The library does not implement cross-domain communication across a network, for which case .NET Remoting is sufficient.
Background
So why not use .NET Remoting? Well personally in the past I’ve found this extremely tedious to set-up and configure. The other issue is the lack of helpful error reporting when things go wrong, invariably with permissions.
Don’t get me wrong, I’m not opposed to .NET Remoting, it has a lot more functionality than my own implementation and of course is not limited to communication on a single box. However for same-box communications it doesn’t need to be that complex. So why not leverage Windows Messaging? After all this is the mechanism unmanaged applications use exactly for this purpose. Well now there’s an idea…
If you've never heard of them, Windows messages are low-level communications used by the Windows operating system to broadcast information regarding user-input, system changes, and other events that applications running on the system can react to. For instance application repaints are triggered by the WM_PAINT message.
As well as system messages, unmanaged applications may also define custom Windows messages and use them to communicate with other windows. These usually take the form of WM_USER messages. If you have Spy++ installed (VS Tools), you can monitor in real-time all the messages that a window receives.
The XDMessaging Library
The XDMessaging library provides an easy-to-use, zero configuration solution to same-box cross AppDomain communications. It provides a simple API for sending and receiving targeted string messages across application boundaries.
The library allows the use of user-defined pseudo 'channels' through which messages may be sent and received. Any application can send a message to any channel, but it must register as a listener with the channel in order to receive. In this way developers can quickly and programmatically devise how their applications will communicate with each other best to work in harmony.
Example: Sending a message.
// Send shutdown message a channel named commands
XDBroadcast.SendToChannel("commands", "shutdown");Example: Listening on a channel.
// Create our listener instance
XDListener listener = new XDListener();
// Register channels to listen on
listener.RegisterChannel("events");
listener.RegisterChannel("status");
listener.RegisterChannel("commands");
// Stop listening on a specific channel
listener.UnRegisterChannel("status");Example: Handling the messages.
// Attach an event handler to our instance
listener.MessageReceived+=XDMessageHandler(this.listener_MessageReceived);
// process the message
private void listener_MessageReceived(object sender, XDMessageEventArgs e)
{
// e.DataGram.Message is the message
// e.DataGram.Channel is the channel name
switch(e.DataGram.Message)
{
case "shutdown":
this.Close();
break;
}
}The Messenger demo
To see the demo you will need to launch multiple instances of the Messenger.exe application. The demo application severs no practical purpose other than to demonstrate the use of the XDMessaging library. It shows how messages may be passed to multiple instances of a desktop application across application boundaries.
The application uses 2 arbitrary channels named Status and UserMessage. Window events such as onClosing and onLoad are broadcast as messages on the Status channel (displayed in green), and user messages are broadcast on the UserMessage channel (displayed in blue). By checking or unchecking the options you may toggle which channel messages the window will listen for.
How it works
The library makes use of a Windows system message of the type WM_COPYDATA. This system message allows data to be passed between multiple applications by carrying a pointer to the data we wish to copy, in this case a string. This is sent to other windows using the SendMessage Win32 API with PInvoke.
StructLayout(LayoutKind.Sequential)]
public struct COPYDATASTRUCT
{
public IntPtr dwData;
public int cbData;
public IntPtr lpData;
}
[DllImport("user32", CharSet = CharSet.Auto)]
public extern static int SendMessage(IntPtr hwnd, int wMsg, int wParam, ref COPYDATASTRUCT lParam);The COPYDATASTRUCT struct contains information regarding the message data we want to transfer to another application. This is referenced by the members lpData and dwData. lpData is a pointer to the string data which is stored in memory, and dwData is the size of the transfer data. The cdData member is not used in our case.
In order to pass the data we must first allocate the message string to an address in memory, and get a pointer to this data. To do this we use the Marshal API as follows.
// Serialize our raw string data into a binary stream
BinaryFormatter b = new BinaryFormatter();
MemoryStream stream = new MemoryStream();
b.Serialize(stream, raw);
stream.Flush();
int dataSize = (int)stream.Length;
// Create byte array and transfer the stream data
byte[] bytes = new byte[dataSize];
stream.Seek(0, SeekOrigin.Begin);
stream.Read(bytes, 0, dataSize);
stream.Close();
// Allocate a memory address for our byte array
IntPtr ptrData = Marshal.AllocCoTaskMem(dataSize);
// Copy the byte data into this memory address
Marshal.Copy(bytes, 0, ptrData, dataSize);With the string data now in memory, referenced by our ptrData pointer in the above code, we can create our COPYDATASTRUCT instance and populate the lpData and dwData members accordingly.
So now we've wrapped our message up as a COPYDATASTRUCT object, we're ready to send this to another Window using the SendMessage API. But to do this we first need to know which applications should receive the data, i.e. which are listening and on the correct channel. Also what if the application doesn't have a Window handle to send our message to?
To overcome this we use some native Window properties and our XDListener class. When an instance of the class is invoked it creates a hidden window on the desktop which acts as listener for all Windows messages. This is done by extending the NativeWindow class of System.Windows.Forms. By overriding the WndProc method, this allows us to filter Windows messages and look for our WM_COPYDATA message containing the message data.
The XDListener class also makes use of Window properties to create property flags indicating which channels the instance is listening on, and therefore which messages it should receive. When a message is broadcast it enumerates all of the desktop Windows using the EnumChildWindows Win32 API, and looks for a flag (property name) on the window which represents the channel name. If found, the Windows WM_COPYDATA message is sent to that window where it will be caught and processed by the XDListener instance which owns the hidden window.
To read the message data we use the lParam of the native Windows message in order to expand the COPYDATASTRUCT instance. From this we can locate and restore the original string message which was stored in memory earlier.
// NativeWindow override to filter our WM_COPYDATA packet
protected override void WndProc(ref Message msg)
{
// We must process all the system messages and propogate them
base.WndProc(ref msg);
// If our message
if (msg.Msg == Win32.WM_COPYDATA)
{
// msg.LParam contains a pointer to the COPYDATASTRUCT struct
Win32.COPYDATASTRUCT dataStruct = (Win32.COPYDATASTRUCT)Marshal.PtrToStructure(msg.LParam , typeof(Win32.COPYDATASTRUCT));
// Create a byte array to hold the data
byte[] bytes = new byte[this.dataStruct.cbData];
// Make a copy of the original data referenced by the COPYDATASTRUCT struct
Marshal.Copy(this.dataStruct.lpData, bytes, 0, this.dataStruct.cbData);
// Deserialize the data back into a string
MemoryStream stream = new MemoryStream(bytes);
BinaryFormatter b = new BinaryFormatter();
// This is the message sent from the other application
string rawmessage = (string)b.Deserialize(stream);
// do something with our message
}
}Note because the message is stored in memory whilst it's broadcast to other applications, we must remember to free that memory after the message has been sent. Each Window receiving the data will make its own copy, so the original data can be destroyed safely as soon as the messages have been sent. This is necessary because the data is stored in unmanaged memory, and would otherwise result in a memory leak.
// Free the memory referenced by the given pointer
Marshal.FreeCoTaskMem(lpData); Below are the other PInvoke methods used for setting and removing Window properties, as well as to enumerate the desktop Windows.
// Delgate used during window enumeration
public delegate int EnumWindowsProc(IntPtr hwnd, int lParam);
// The Win32 API used to enumerate children of the desktop window
[DllImport("user32.dll")]
[return: MarshalAs(UnmanagedType.Bool)]
public static extern bool EnumChildWindows(IntPtr hwndParent, EnumWindowsProc lpEnumFunc, IntPtr lParam);
// The API used to look for a named property on a window
[DllImport("user32", CharSet = CharSet.Auto)]
public extern static int GetProp(IntPtr hwnd, string lpString);
// The API used to set a named property on a window, and hence register a messaging channel
[DllImport("user32", CharSet = CharSet.Auto)]
public extern static int SetProp(IntPtr hwnd, string lpString, int hData);
// The API used to remove a property from a window, and hence unregister a messaging channel
[DllImport("user32", CharSet = CharSet.Auto)]
public extern static int RemoveProp(IntPtr hwnd, string lpString);