Components of a Plug-in (Windows Embedded CE 6.0)

1/6/2010

Plug-ins based on the Microsoft Remote Tools Framework have specific characteristics in common. After you use the Remote Tools Framework to develop the plug-in, the result is a remote tool plug-in .cetool file that contains all the components necessary for the plug-in.

Components of a .cetool File

The following table lists the main components of a Remote Tools Framework plug-in.

Component	Description
Desktop-side component	A .NET class library that you write. The code in this component is responsible for defining the plug-in using the Remote Tools Framework, storing data received from the device, and rendering the data.
Device-side component	A native application written in C++, or a managed application written in .NET Compact Framework 1.0 or later. The device component gathers data from the target device and then returns it to the desktop component using objects in the libraries. For native device components, a dynamic-link library (DLL) links with the application to expose the Remote Tools Framework functionality. For managed device components, there are two DLLs: The same DLL as a native device component; and a managed class library DLL that the managed component uses. In addition, for native components, there is a separate device component application for each processor type. Meanwhile, managed components use the same device component application. The Remote Tools Framework also automatically deploys DLLs associated with the device components to the target device.
Metadata	A bundler input file that contains metadata associated with the plug-in. This metadata can include information about the components and identification information that both the Remote Tools Framework and Core Connectivity require. Core Connectivity is the transport mechanism that the Remote Tools Framework abstracts. For more information, see Bundle Input Editor.
Optional files	Other files needed to complete support for the plug-in, such as data files.

Desktop-side Component

The desktop-side component, written using managed code, calls the PluginComponent class in the Remote Tools Framework. This class performs the following tasks:

• Defines the plug-in
• Stores data received from the device-side component
• Displays the data in the Remote Tools Shell

While the PluginComponent class accomplishes the task of defining the plug-in, it calls two additional classes to perform the other two tasks of storing and displaying the data received from the device-side component in the Remote Tools Shell. These are the PluginDataView and PluginData classes.

The latter class, PluginData, is the class that performs the actual duties of managing communication between the desktop-side and device-side components. This class calls the CommandTransport class, setting up an agnostic connection between the desktop-side and device-side components. This connection is a command transport and is an essential portion of a plug-in. The command transport exposes APIs to allow for simple file and directory management between the desktop and the device.

Communication is sent in the form of command packets over the command transport between the desktop and the device components. A command packet is an object that contains an integer ID, and a variable list of parameters. The parameter types can be a WORD, a DWORD, a string, or an array of bytes. For more information, see Remote Tools Framework Native API.

The CommandPacket class packages data into command packets, and then transports them over the command transport.

After the command packets arrive on the device side of the command transport, they pass to a different set of classes, depending on whether the device-side component uses native code or managed code.

When the device-side component returns command packets to the desktop-side component, the PluginData class accepts these command packets and renders their contents for display in the Remote Tools Shell.

However, if the plug-in uses asynchronous mode, the class that accepts these command packets containing asynchronous data from the device-side component is PluginComponent, not PluginData. In this case, the PluginComponent class passes the command packet to the PluginData and PluginDataView classes for data storage and rendering as needed.

For more information about the Remote Tools Shell, see Remote Tools Shell.

While the PluginData class renders the data for display, the actual work associated with displaying a given node in the shell uses the PluginDataView class. In other words, each node that you see in the Remote Tools Shell is created using a pair made up of one view implementation and one data implementation.

This means that in hierarchical mode, there are two possible outcomes for displaying a node in the Remote Tools Shell. If the pair contains both a PluginDataView and a PluginData implementation, the resulting node in the Remote Tools Shell contains data to display, and is known as a data node. Otherwise, if there is a PluginDataView implementation, and no PluginData implementation, the resulting node is a hierarchical label that contains no data and acts as a container for other nodes.

For more information about plug-in design requirements, see General Plug-in Design Requirements.

Device-side Component (Native)

If your device-side component is an application written using native code, it depends on two device-side classes to perform tasks and communicate with the desktop-side component, as shown in the following list.

• CDeviceRemoteTool
• CCommandPacket

The CDeviceRemoteTool class runs any device-side tasks that the application code contains, and closes the application when the tasks have completed. It also includes methods that you use to call the CCommandPacket class to create a new command packet, and then pushes the command packet to the desktop.

The CCommandPacket class is the device-side class that you use to create a command packet on the device. The packet contains data gathered from running the application on the device, or data that passes to the device from the desktop-side component.

For more information about design requirements for device-side components, see Requirements for Device-Side Components.

For more information about these classes, see Remote Tools Framework Reference.

Device-side Component (Managed)

If your device-side component is an application written using managed code, it depends on two device-side classes to perform tasks, and communicate with the desktop-side component, as shown in the following list.

• DeviceCommandTransport
• CommandPacket

The DeviceCommandTransport class runs any device-side tasks that the application code contains and closes the application when the tasks have completed. It also includes methods that you use to call the CommandPacket class to create a new command packet, and then pushes the command packet to the desktop.

The CommandPacket class is the device-side class that you use to create a command packet on the device containing any data gathered from running the application on the device.

For more information about design requirements for device-side components, see Requirements for Device-Side Components.

For more information about these classes, see N:Microsoft.RemoteToolSdk.DeviceComponents.

See Also

Other Resources

Remote Tools Framework Plug-in Development
Remote Tools Framework
Remote Tools Framework Native API