Once upon a time I was a Visual Studio 6.0 developer, and thankfully it was a long time ago. Before last week I thought most of my day to day toolset experience from that era was left in the past where it belonged. Nonetheless I found myself adding DDE inter-process communication support to an ActiveX control written in .NET and C# last week. This means marrying Windows 3.11 era functionality with Windows 7 platforms. I doubt most developers will ever need to climb this mountain and I would not be surprised to find out I was the last man on earth. Just in case DDE lives on until the next decade though, I present you this chronicling of our experience.
In order to make a web based component talk to a locally installed DDE server we had to build a signed user control in Visual Studio.NET 2008 that could speak DDE. If it is not signed it is a real PITA to even get the control to instantiate. Save yourself some time and sign the control. It is really easy to automate it in VS.NET 2008 too. Once the control is instantiated in the browser it needs to make some DDE calls. This means “unmanaged code”, since DDE only exists strictly for backwards compatibility as a set of Win32 API library calls. Remember this since we will need to take special steps to allow for this later.
First you are going to want to read this conversation between a hapless code-monkey, who in 2007 had the stones to call DDE a “dead technology”. HA!
You will see a few experts contributing, one of which is Brian Gideon who is very helpful on the topic of .NET and DDE.
Now if you are lucky enough to get your .NET code to make some DDEConnect calls but you can’t tell if your code is working, you are going to want a tool called DDESpy. The trouble with this tool is finding it. It is so old that you will have trouble even finding a safe website to download it from.
Eventually, if you are a google master such as I, you will find where to download the whole 131Mb Visual Studio 6.0 samples download, and within that you will pray that you find DDESpy. If you are very persistent you will indeed find it buried within, however it is only the uncompiled C Source code!
So I hope that this link to the compiled version we created saves you a great deal of time and trouble and also I hope that whoever you are, you are the last developer on earth who must climb “mount DDE over .NET”.
Finally, to close out my ever so obscure topic blog post, I present you with a few steps that are required for any browser instantiated control to make unmanaged Win32 Calls. A few security changes are going to be required to allow this to happen. We would never have figured this out if it weren’t for glorious DDESpy which by the way is in fact is a wonderfully detailed tracing tool.
Steps to Allow signed controls access to unmanaged win32 calls.
Our application uses DDE messages to send call requests to Telecor Connect, a local DDE Server TSR. For these messages to send correctly, a few security measures should be in place.
First, open Internet Explorer and click Tools then Internet Options.
Go to the Security tab and click Trusted Sites. 
Click the Sites button.
Now enter the URL http://www.yourwebsite.com into the text box and uncheck require server verification (https:) for all sites in this zone. Click Add.
The URL should now be listed in the Websites: box on the bottom.
To ensure the correct URL has been added, open your application with Internet Explorer. The browser should indicate that the website is in Trusted Sites at the bottom.
2) The .NET Framework Configuration needs to allow calls to unmanaged code for DDE messages to be sent.
To change .NET Configuration settings, you must be logged in as a Local Administrator or equivalent.
The .NET Configuration Utility can be found at Start>All Programs>Administrative Tools>Microsoft .NET Framework 2.0 Configuration.
Finally, create or edit a permission set to allow calls to unmanaged code. Then, assign this permission set to the Trusted Zone.
Permission Sets can be found at:
Console Root>.NET Framework 2.0 Configuration>My Computer>Runtime Security Policy>Machine>Code Groups>Permission Sets.
Disclaimer:
It is not recommended by anyone that you allow calls to unmanaged code for any zones other than trusted zones.