Windows CE Base Team Blog

Comment from Dave Edson.

I would like to explain a bit the different components of RTFx.

Desktop Side
-----------------
* RemoteToolServer.dll - a Native COM component that talks to CoreCon. CoreCon is the transport layer that ships with VS2005. RemoteToolServer.dll brings up the "Select Device" dialog, and opens a communication channel that's accessed by the "Command Transport" object in the .NET code.
* Microsoft.RemoteToolSdk.dll - A .NET Library that talks to RemoteToolServer.dll. This library contains the code to provide a managed communication channel (the CommandTransport), and also the shell view that the plugins use. The entire plug-in architecture, .cetool file format decoding, and doc/view stuff is contained in this .DLL
* RemoteToolsShell.exe - .NET application that creates a top-level form window, and then gets the "guts" from the Microsoft.RemoteToolSdk.dll to display the shell.

Device Side
--------------
* RTFHLP10.DLL  - A native DLL that talks to the device-side of CoreCon. A communication channel is established with this DLL, and the "CCommandTransport" is available as an object for native device-side apps to use.
* Microsoft.RemoteToolSdk.DeviceComonponents.dll - A .NETCF 1.0 library that wraps RTFHLP10.DLL with a CommandTransport object that has the same interface as the desktop side. Managed device-side applications consume this library.

So, if you write a plugin that's all managed (such as SimplePluginManaged from the samples), your project output generates two binaries that are packed into the .cetool file. The desktopside binary is a .NET class library that is consumed by the Microsoft.RemoteToolSdk.dll library via a LoadAssembly call.  The desktopside binary uses all sorts of objects from the .NET class libary, and the plugin gets all the connectvity for free. The device side binary consumes the Microsoft.RemoteToolSdk.DeviceComponents.Dll library, which then p/invokes the RTFHLP10.DLL.

If you write the desktop side in managed code, the above paragraph is for you. If you want to write your desktop code in native, then you have to do a whole lot more work. Since the plugin's desktop code uses the Microsoft.RemoteToolsSdk namespace, there are lots and lots of dependancies between your desktop code and the library. If you go native, you lose all that. Which means that a native desktop application would need to talk directly to the RemoteToolServer COM object. You still get a command transport-like object, with command packet-like things, and you still get an easy way to bring up the "Select Device" dialog box and make the connection. You still get to easily deploy your bits down to the device, start that app and establish the CoreCon connection. What you DON'T get is a shell to present the information, docs objects, view objects or any data traffic rules. And, you will be writing COM code (fun fun fun). Also, RTFx's native library generates a critical data file automatically for CoreCon that instructs CoreCon how to deploy and execute the device-side binaries. If you write your desktop app in native, you will need to write your own UI, own main window, and you will need to generate your own CoreCon data file. You will need to "install" your binaries for each platform before you can run your desktop app. RTFx's native code does all this for you.

We are working on making a native sample program that will show how this is all done. Keep in mind that there are lots of ways to shoot yourself in the foot. The managed part of the framework takes care of a lot of micro-details that keeps CoreCon stable. It is easy to confuse CoreCon and make for some very pizza-laden long evenings scratching your head.

Hopefully this makes some sense. Go ahead and ask away if you have more questions.

Dave Edson
RTFx Wrangler