Skip to main content
Email Password   helpLost your password?
Sample image

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 code developed to aid rapid development for a recent Vista project that 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, 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, in the past I've personally 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 that unmanaged applications use for exactly 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 (Visual Studio Tools), you can monitor all of the messages that a window receives in real-time.

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 best their applications can communicate with each other and 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 serves 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 two 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 that we want to transfer to another application. This is referenced by the members lpData and dwData. lpData is a pointer to the string data that is stored in memory. 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 that we've wrapped our message up as a COPYDATASTRUCT object, we're ready to send this to another Window using the SendMessage API. However, 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. It looks for a flag (property name) on the window that represents the channel name. If found, the Windows WM_COPYDATA message is sent to that window. Once there, it will be caught and processed by the XDListener instance that 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 propagate 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 that 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 enumerating the desktop Windows.

// Delegate 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);

Further Reading

History

You must Sign In to use this message board.
 
 
Per page   
 FirstPrevNext
GeneralReally Interesting article Pin
bilo81		8:05 16 Nov '09  
GeneralMessaging from IIS? Pin
Senor Plankton		1:09 3 Jun '09  
GeneralWnd proc Pin
kurtsune		23:58 7 Apr '09  
GeneralBroken link Pin
Member 6038196		23:19 18 Mar '09  
GeneralRe: Broken link Pin
TheCodeKing		4:43 20 Mar '09  
GeneralAlternative to Cross AppDomain Communication Pin
cwfong		4:54 27 Dec '08  
GeneralExecution stuck at SendMessage method call Pin
Suneel_Sarode		23:25 2 Jun '08  
GeneralRe: Execution stuck at SendMessage method call [modified] Pin
TheCodeKing		10:32 3 Jun '08  
GeneralScalability question Pin
Member 3861085		5:38 29 Apr '08  
AnswerRe: Scalability question Pin
TheCodeKing		11:50 30 Apr '08  
GeneralRe: Scalability question Pin
Member 3861085		22:03 30 Apr '08  
GeneralA great concept but .. [modified] Pin
Wytek Szymanski		19:17 15 Jun '07  
GeneralRe: A great concept but .. Pin
RenniePet		13:13 8 Dec '07  
GeneralExcellent Pin
merlin981		4:19 30 May '07  
Questionreading deallocated memory? Pin
rhguera		0:56 30 May '07  
AnswerRe: reading deallocated memory? [modified] Pin
beelineuk		1:02 30 May '07  
GeneralRe: reading deallocated memory? Pin
rhguera		1:15 30 May '07  
GeneralExcellent!...But does not work for IPC (inter-process communication) Pin
Homey11		3:53 12 Apr '07  
GeneralRe: Excellent!...But does not work for IPC (inter-process communication) Pin
TheCodeKing		4:22 12 Apr '07  
GeneralRe: Excellent!...But does not work for IPC (inter-process communication) Pin
Homey11		6:40 12 Apr '07  
GeneralRe: Excellent!...But does not work for IPC (inter-process communication) Pin
TheCodeKing		7:03 12 Apr '07  
GeneralRe: Excellent!...But does not work for IPC (inter-process communication) Pin
Homey11		7:35 12 Apr '07  
GeneralRe: Excellent!...But does not work for IPC (inter-process communication) Pin
TheCodeKing		9:24 12 Apr '07  
GeneralRe: Excellent!...But does not work for IPC (inter-process communication) Pin
Homey11		11:23 12 Apr '07  
GeneralRe: Excellent!...But does not work for IPC (inter-process communication) Pin
mav.northwind		19:51 29 May '07  
Last Visit: 23:56 20 Nov '09     Last Update: 23:56 20 Nov '09 12 Next »


Last Updated 4 Jun 2008 | Advertise | Privacy | Terms of Use | Copyright © CodeProject, 1999-2009