Although Data Driven Adapters (DDAs) are mainly designed for Automation Adapters in HAT, we can make use of them from legacy adapters, too. Here's an example of an external VB application, which is configured to use a legacy application adapter and a WinDataDrivenAdapter with the corresponding bindings:
<?xml version="1.0" encoding="utf-16"?>
<UseTopLevelWindow class="ThunderRT6Form" />
<optimumSize x="800" y="600" />
<minimumSize x="640" y="480" />
One thing to take into account is that, if the application uses an alternative top level window, the DDA must be instantiated with that top level window instead of the process MainWindowHandle. The picture shows how the alternate top level window configuration is seen in the Admin Console:
And here is the code of the legacy adapter making use of the data driven adapter to automate the hosted application's UI:
public class MyExtVBAppAdapter : ApplicationAdapter
protected DataDrivenAdapterBase _dda;
public override bool Initialize()
//IntPtr topLevelWnd = Process.MainWindowHandle;//this won't work for a VB app
IntPtr topLevelWnd = GetTopLevelWndHandle();
//Initialize Data Driven Adapter with proper top level window handle
_dda = DataDrivenAdapterBase.CreateInstance(ApplicationInitString, topLevelWnd);
return _dda != null;
public override bool DoAction(Action action, RequestActionEventArgs args)
return base.DoAction(action, args);
private void PressButton()
//Find the top level window of the VB application (for example of class "ThunderRT6Form")
private IntPtr GetTopLevelWndHandle()
IntPtr agentDesktopPtr = Win32API.FindWindow(null, "Agent Desktio");
if (agentDesktopPtr != IntPtr.Zero)
IntPtr tabWindowHandle = Win32API.FindWindowByText(agentDesktopPtr, "MyApp");
if (tabWindowHandle != IntPtr.Zero)
return Win32API.FindWindowByText(tabWindowHandle, "MyAppTopLevelWndCaption");
The Hosted Application Toolkit (HAT) is a new component of CCF 2.6 (2008) that facilitates the task of automating the UI of the hosted applications. It consists of two main parts: the Data Driven Adapters (DDA) and the Automations (WF workflows) that automates the hosted application using the DDAs.
My colleagues Ariel Neisen, Federico García, Rodolfo Finochietti and I wrote the cover article of the #42 edition of the .Code Magazine (in Spanish) about Silverlight. The article talks about this new technology's fundamentals, architecture, programming tools, advanced features, code samples and a lot more.
A WCF binding is the endpoint component that defines how the client needs to communicate with the service. It groups settings such as underlying transport protocol, security requirements, and message encoding.
WCF provides nine built-in bindings:
- BasicHttpBinding: Basic web service communication. Exposes WCF services as legacy ASMX web services. Used for interoperability. No security by default.
- WSHttpBinding: Web services with WS-* support. Supports transactions and reliable messaging.
- WSDualHttpBinding: Web services with duplex contract and transaction support.
- WSFederationHttpBinding: Web services with federated security. Supports transactions.
- MsmqIntegrationBinding: Communication directly with MSMQ applications. Supports transactions.
- NetMsmqBinding: Communication between WCF applications by using queuing. Supports transactions.
- NetNamedPipeBinding: Communication between WCF applications on same computer. Supports duplex contracts and transactions.
- NetPeerTcpBinding: Communication between computers across peer-to-peer services. Supports duplex contracts.
- NetTcpBinding: Communication between WCF applications across computers. Supports duplex contracts and transactions.
Although most bindings will work on scenarios they are not designed for, it's a good practice to choose the right binding for a given endpoint. In chapter one of the "Programming WCF Services" book, Juval Lowy provides a very useful decision-activity diagram for choosing the right binding:
"The first question you should ask yourself is whether your service needs to interact with non-WCF clients. If the answer is yes, and if the client is a legacy MSMQ client, choose the MsmqIntegrationBinding that enables your service to interoperate over MSMQ with such a client. If you need to interoperate with a non-WCF client and that client expects basic web service protocol (ASMX web services), choose the BasicHttpBinding, which exposes your WCF service to the outside world as if it were an ASMX web service (that is, a WSI-basic profile). The downside is that you cannot take advantage of most of the modern WS-* protocols. However, if the non-WCF client can understand these standards, choose one of the WS bindings, such as WSHttpBinding, WSFederationHttpBinding, or WSDualHttpBinding. If you can assume that the client is a WCF client, yet it requires offline or disconnected interaction, choose the NetMsmqBinding that uses MSMQ for transporting the messages. If the client requires connected communication, but could be calling across machine boundaries, choose the NetTcpBinding that communicates over TCP. If the client is on the same machine as the service, choose the NetNamedPipeBinding that uses named pipes to maximize performance. You may fine-tune binding selections based on additional criteria such as the need for callbacks (WSDualHttpBinding) or federated security (WSFederationHttpBinding)."