| The Hello World tutorials show just how easy it is to develop managed code that runs on standard supported devices, such as the Pocket PC. The .NET Compact Framework can also run on a wide variety of hardware that runs Windows CE. Table 1.2 shows what processors are compatible with the .NET Compact Framework and what operating systems are supported for specific processors. The .NET Compact Framework binaries are stored as a CAB file on your desktop computer. There is a unique CAB file for each operating system and processor type that the .NET Compact Framework supports. Smart Device Extensions pushes the correct CAB file to your device when it detects that your device does not have the Compact Framework installed. In this section we discuss in detail how this process works and how to deploy the CAB files by hand if you are unable to get deployment to work automatically. .NET COMPACT FRAMEWORK IS IN ROM FOR POCKET PC 2003 All Pocket PC devices running Pocket PC version 2003 or later have the .NET Compact Framework in ROM. If you are unable to deploy or debug your application on these devices, this section teaches how Smart Device Extensions communicates with devices for debugging and deployment and discusses work-arounds to a variety of problems. |
Table 1.2. Processors and Operating Systems Supported by the .NET Compact Framework | CPU NAME | SUPPORTED OS VERSIONS | | Intel ARM 4 | Pocket PC 2000, 2002, 2003, and WinCE 4.1 or greater | | Intel ARM 4i | Pocket PC 2000, 2002, 2003, and WinCE 4.1 or greater | | Hitachi SH3 | Pocket PC 2000, 2002, 2003, and WinCE 4.1 or greater | | Hitachi SH4 | Pocket PC 2003 and WinCE 4.1 or greater | | Intel 80x86 | Pocket PC 2000, 2002, 2003, and WinCE 4.1 or greater | | MIPS 16 | Pocket PC 2000, 2002, 2003, and WinCE 4.1 or greater | | MIPS II | Pocket PC 2000, 2002, 2003, and WinCE 4.1 or greater | | MIPS IV | Pocket PC 2000, 2002, 2003, and WinCE 4.1 or greater | Table 1.2 demonstrates that the .NET Compact Framework runs on a wide variety of hardware. The trick is getting the IDE to allow you to deploy and debug to that hardware. There are three levels of support for nonstandard devices: Full deploy and debug support This level of support means that the IDE can deploy binaries to the device and debug code running on the device. Deploy-only support This means that the IDE can deploy only binaries to the device but cannot debug code running on the device. Nonstandard devices will rarely support ConmanClient enough to allow deployment without being able to run the debug host. Target-only support This level of support means that you can develop your application in Visual Studio, but you must install the Compact Framework onto the device manually and also copy your device binaries manually. It is the "last resort" for developing applications to a nonstandard device. The overall strategy for targeting a nonstandard device is to attempt to achieve full deploy and debug support, then fall back to deploy only, and settle for target only as a last resort. To achieve the first two levels, we need to examine carefully how Visual Studio gets binaries to a device and communicates with the device-side debugger host. To work with Target Only support, see the section entitled "Installing the .NET Compact Framework Manually." How Visual Studio Communicates with Devices If you have a device that you believe fulfills the requirements for running the .NET Compact Framework, but you are unable to use the Smart Device Extensions to debug or deploy to the device, there are a variety of tricks for getting successful debug and deployment sections. In order to fully understand how to use these tricks, we need a strong understanding of how Smart Device Extensions communicates with the device. Conman Conman is the connectivity technology for Smart Device Extensions. It is through Conman that connections are made between the desktop and the device for deploying files and communicating debugging messages. The role of Conman is to abstract the physical connection between a desktop running Smart Device Extensions and the Windows CE device with which it is communicating. For example, the communication might occur through a TCP/IP connection, an ActiveSync connection, or when the remote device is an emulator, through Direct Memory Access. Regardless of the underlying connection, the deployment and debugger code in Smart Device Extensions knows only that it is communicating with a Conman connection. The specific underlying connections are called transports. The code for each transport is held in a separate DLL. Two examples of transports are the TCP transports and the Direct Memory Access transports. Table 1.3 shows the name of all of the transport DLLs available on the desktop and the device. Table 1.3. Conman Transport DLLs | TRANSPORT DLL NAMES | PLATFORM | DESCRIPTION | | cmtnpt_TCPConnect.dll TCPTransportConnect.dll | Desktop | Used to connect to a device with a and network card or ActiveSync connection | | cmtnpt_TCPAccept.dll | Device; binaries for each CPU and OS build type are in the Target directory | Accepts incoming TCP or ActiveSync connections from the desktop | | cmtnpt_Emulator.dll | Desktop | Connects to an emulator | | cmtnpt_Emulator.dll | Device; binaries for each CPU and OS build type are in the Target directory | Allows ConmanClient.exe running on emulator to accept desktop connection | | IRDATransportAccept.dll | Desktop | Used to connect to device via infrared; works for deployment but not debugging | | Cptnpt_IRDAConnect.dll | Device; binaries for each CPU and OS build type are in the Target directory | Used to connect to device via infrared; works for deployment but not debugging | The desktop side gains access to the Conman transports when the Visual Studio executable, devenv.exe , loads and initializes the transports because the user tried to debug or deploy to the device. On the device an executable called ConmanClient.exe runs. When it is first launched, ConmanClient.exe loads a transport and listens until a desktop transport connects to it. At that time internal protocols determine whether the connection is for deploying files, launching an executable, or passing debugging information, and the transport connection is handed off to the correct party. WHEN COMMUNICATION WITH CONMAN FAILS Communication occurs through Conman transports anytime a project is deployed or debugged . Deployment uses a single instance of a Conman transport. Debugging opens two additional transports used for communicating debug information between the device and the desktop. Whenever either of these two features is not working correctly, a likely cause of the problem is that Conman is not being initialized on the device correctly. If you cannot find these DLLs on your desktop computer, then your Visual Studio installation is damaged, and deployment and debugging will fail. Missing DLLs can indicate that you did not select to install Smart Device Extensions as shown in Figure 1.1. |
Initializing Conman on the Device One of the major problem areas with nonstandard devices is getting ConmanClient.exe launched on them. If it is not successfully launched, then no connection will ever succeed for deployment or debugging. When the Smart Device Extensions tries to deploy or debug to the device, it uses the transport that is specified in the Device Tools folder in the Visual Studio options dialog. If you are having trouble connecting to a device, you can specify a specific transport that might work for you. To set the transport used to connect with the device, follow these steps: -
Select Tools, Options from within Visual Studio. -
Double-click the Device Tools folder and select the Devices subcategory . Figure 1.13 shows the resulting Options dialog. Figure 1.13. Use the Device connection Options dialog to choose what kind of device to connect to.  -
Choose either Pocket PC or Windows CE as the platform, depending on whether you are trying to connect to a Pocket PC device. -
Choose what kind of device you are deploying to. In Figure 1.13 the choices are Emulator or Pocket PC Device. Note that for the emulator there is only one Transport choice available. -
Select the transport to use. For the Pocket PC device, there are two choices: TCP Connect or IRDA. The TCP Connect Transport means that the desktop device will connect to ConmanClient.exe on the device by making a TCP connection to the device. The IRDA Tranport uses the device's IRDA transport to communicate. This is especially useful if your computer is a laptop with an IRDA port. -
If you choose the TCP Connect Transport, then you can alter the behavior of that transport by clicking the Configure... button shown in Figure 1.13. Clicking Configure... yields the dialog box seen in Figure 1.14. Figure 1.14. The TCP Connect Transport lets you choose settings related to connecting to your device via TCP.  -
The new dialog lets you choose the IP address of your device, if you know it. If your device is connected by ActiveSync, then Visual Studio can discover the address automatically. You can also choose to use a specific port number other than the default value of 5656. To use the non-default port number, you must configure ConmanClient.exe by hand on the device. This procedure is specified later in this chapter. When the user tries to deploy or debug on a device, Smart Device Extensions attempts to connect to the device, assuming that ConmanClient.exe is running on the device and following the parameters specified in the configuration dialog from Figure 1.14. If there is no response, then Smart Device Extensions installs a new copy of ConmanClient.exe and the associated DLLs by using ActiveSync. There is a prebuilt binary of ConmanClient.exe for devices running Pocket PC and devices running Windows CE version 4.1 or greater. Also, there are binaries for each of the possible processor types: SH3, ARM, MIPS, and X86. Smart Device Extensions determines which specific build of ConmanClient to send to the device by querying ActiveSync about the operating system and processor type of the target device. There is a version of ConmanClient.exe and the transport libraries for every processor and operating system version that the .NET Compact Framework supports. BE CAREFUL WHEN DEFINING PARAMETERS FOR CONMANCLIENT.EXE PITFALL These configurations give users a lot of freedom in specifying how the desktop connects to the device. If you are trying to connect to a Windows CE device (not a Pocket PC), specifying the details of how the desktop connects to ConmanClient.exe on the device is often helpful. However, be careful to match your choices with the choices you make for ConmanClient.exe . |
IF YOU ARE USING A DEVICE WITH WINDOWS CE 4.1 OR HIGHER There is a bug in ActiveSync that causes it to return improper processor-type information on nonPocket PC devices running Windows CE 4.1 or greater. This creates a problem for users working with such devices. Because of the inaccurate information from ActiveSync, Smart Device Extensions sends the wrong build of ConmanClient.exe to the device, and it does not launch successfully. Thus, deploy and debug always fails. There is a utility pack available on the Microsoft Smart Devices developer Community Web site at: http://smartdevices.microsoftdev.com/Downloads/default.aspx called Windows CE Utilities for Visual Studio .NET 2003 Add-on Pack. The Add-on Pack includes the CPU Picker, which is useful for working around the ActiveSync bug. CPU Picker is discussed in great detail later in this chapter. |
If Visual Studio is installed in the default location of C:\Program Files , then the Conman binaries are located in the directory ConnectionManager\Target\wce300 for Pocket PC 2000 and 2002 devices, and in ConnectionManager\Target\wce400 for Windows CE 4.1 or greater and Pocket PC 2003 devices. Each of these directories holds subdirectories for each supported CPU. At the same time that Smart Device Extensions sends ConmanClient.exe to a device, it creates a security relationship with the device by exchanging a shared key. This is called prepping the device. It ensures that no desktop can connect to a device that has not been prepped by that desktop. Since the device must be physically connected to the device with ActiveSync to be prepped, an implicit trust relationship exists between a desktop and a device it has prepped. This process prevents rogue hackers from connecting to your device from the Internet, and it also prevents hackers from creating devices that can accept connections from your desktop. After prepping, Smart Device Extensions uses ActiveSync to launch the ConmanClient.exe program and attempts to connect to it again using the transport specified in the transport preferences. If the connection fails again, then Smart Device Extensions gives up and returns an error message to the user. THE REMOTE PROCESS VIEWER Many developers interested in deploying to nonstandard devices also use Microsoft Embedded Visual Tools version 3.0 or 4.0. These products include the Remote Process Viewer, which shows which executables are running on the device. If ConManClient.exe is running on your device, you will see an entry for it by using the Remote Process Viewer, as shown in Figure 1.15. Figure 1.15. The Remote Process Viewer can show when ConmanClient.exe is running on a device.  |
Launching ConmanClient.exe Manually If you have a Windows CE device without ActiveSync, you must launch ConmanClient.exe yourself. There are two ways to do it. The most convenient and most strongly recommended way is to use the Smart Device Authentication Utility, because it preps the device and launches ConmanClient in one easy step. IF YOU RESET YOUR DEVICE If you reset your device, ConmanClient.exe is stopped . You must connect to your desktop computer through ActiveSync the next time you try to deploy or debug to your device. If your proprietary device does not have an ActiveSync connection, see the "Devices without ActiveSync" section. |
However, when the Smart Device Authentication Utility launches ConmanClient.exe , it sets ConmanClient.exe to listen to the default TCP port, 5656, for the TCP transport. If you are running software that conflicts with this port, then you can launch ConmanClient.exe manually and specify the port by following these steps: -
Connectivity will fail if the device is not prepped. Use the Smart Device Authentication Utility, which copies ConmanClient.exe and the transport libraries to the device, preps the device, and launches ConmanClient.exe configured to use the TCP Accept transport on port 5656. -
Warm-reboot the device. This stops ConmanClient.exe but retains the prep information. -
Launch ConmanClient on the device. The easist way to do this is to use the Windows CE File Explorer or the Windows CE command prompt. ConmanClient.exe is located in \Windows . Figure 1.16 shows the File Explorer displaying the ConmanClient.exe binary. Figure 1.16. You can use the Windows CE File Explorer to launch with ConmanClient.exe .  -
When ConmanClient is launched by hand, it displays the interface shown in Figure 1.17. Figure 1.17. ConmanClient.exe has a user interface with which you can alter connection settings.  -
In the top menu, pull down the selection TCP_ACCEPT__. Although it is technically possible to choose TCP_CONNECT__, this choice is worthless because after the Beta 1 release of Visual Studio .NET 2003, the desktop has no way to accept a connection. -
Choose the port on which the device should listen and click the Connect button. ConmanClient.exe is now listening with the TCP Accept transport on the specified port, and the device is prepped because of the Smart Device Authentication Utility. NonPocket PC Devices Running Windows CE 4.1 and Greater Users who try to deploy and debug to devices running Windows CE 4.1 and greater and who also have an ActiveSync connection to their devices often run into problems due to a bug in ActiveSync. ActiveSync reports improper CPU information for the device, causing Smart Device Extensions to attempt to launch a version of ConmanClient.exe that will not run on the device. To solve this problem, Microsoft has provided a utility called CPU Picker. Using CPU Picker, you can determine exactly what kind of CPU your device has and specifically start the correct version of ConmanClient.exe . Devices using Windows CE 4.0 sometimes work with the .NET Compact Framework, but it is not an officially supported platform. When to Use CPU Picker CPU Picker might help when the following are true: -
You have a device using Windows CE 4.1 or greater, and it is connected to your desktop computer through ActiveSync. -
The device exhibits one of the following behaviors: Attempts to deploy to the device fail after the initial connection is established. The CAB file that Smart Device Extensions pushes to the device are copied to the device, but they do not explode successfully. CAB files are dropped onto the root directory of the device and deleted after they are successfully exploded. If you see one of the CAB files shown in Table 1.4 on your device and it is the wrong CAB file for your device CPU, then Smart Device Extensions is unable to tell which CPU your device uses. This is a condition that CPU Picker can remedy. The .NET Compact Framework CAB Files The .NET Compact Framework is delivered to your device through CAB files. Smart Device Extensions uses ActiveSync to determine what kind of CPU your device has and copies the needed CAB files to the device for you. Because there are so many supported-device CPU types, there is a wide variety of CAB files. However, there are only six basic types of CAB files, and their names adhere to the following conventions: netcf. core .ppc3.{CPU} This kind of cab file holds the central .NET Compact Framework binaries compiled specifically for the Pocket PC 2000 and 2002 operating systems. The " {CPU} " is a placeholder for the extension indicating what kind of CPU the CAB works with. For example, netcf.core.ppc3.arm is for the ARM processor. netcf.all.wce4.{CPU} Like netcf.core.ppc3.{CPU}, except for Windows CE version 4.1 or higher. sqlce.ppc.{CPU} This kind of cab file holds the SQL CE engine. It is deployed to your device if your project requires the SQL CE engine. The " {CPU} " is a placeholder for the extension indicating what kind of CPU the CAB works with. For example, sqlce.ppc3.arm is for the ARM processor. sqlce.wce4.{CPU} Like sqlce.ppc.{CPU} , except for Windows CE version 4.1 or higher. sql.ppc.{CPU} This kind of cab file holds the code that supports the SQLClient namespace, which is used for desktop SQL Server connectivity. It is deployed to your device if your project requires it. The " {CPU} " is a placeholder for the extension indicating what kind of CPU the CAB works with. For example, sql.ppc3.arm is for the ARM processor. sql.wce4.{CPU} Like sql.ppc.{CPU} , except for Windows CE version 4.1 or higher. The CAB files come in sets of three: one for the .NET Compact Framework binaries, one for the SQL CE engine, and one for desktop SQL connectivity. Each set of three CAB files corresponds to a specific CPU and operating system. Furthermore, each set of three is held in its own special directory. Table 1.4 shows which directories hold sets of CAB files for specific operating systems and CPU types. Table 1.4. CAB Files for Various CPUs | CAB PATH AND NAME | CPU | OS | | wce300\arm\ | ARM | Pocket PC 2000 Pocket PC 2002 | | wce300\armv4\ | ARMv4 | Pocket PC 2003 Win CE 4.1 or higher | | wce300\mips\ | MIPS | Pocket PC 2000 Pocket PC 2002 | | wce300\sh3\ | SH3 | Pocket PC 2000 Pocket PC 2002 | | wce300\wce420x86\ | 80x86 | Pocket PC 2000 Pocket PC 2002 | | wce300\x86\ | 80x86 | Pocket PC 2000 Pocket PC 2002 | | wce400\armv4\ | ARMv4 | Pocket PC 2003 Win CE 4.1 or higher | | wce400\armv4t\ | ARMv4t | Pocket PC 2003 Win CE 4.1 or higher | | wce400\mips16\ | MIPS16 | Pocket PC 2003 Win CE 4.1 or higher | | wce400\mips16\ | MIPS16 | Pocket PC 2003 Win CE 4.1 or higher | | wce400\mipsii\ | MIPS II | Pocket PC 2003 Win CE 4.1 or higher | | wce400\mipsii_fp\ | MIPS II FP | Pocket PC 2003 Win CE 4.1 or higher | | wce400\mipsiv\ | MIPS IV | Pocket PC 2003 Win CE 4.1 or higher | | wce400\mipsiv_fp\ | MIPS IV FP | Pocket PC 2003 Win CE 4.1 or higher | | wce400\sh3\ | SH3 | Pocket PC 2003 Win CE 4.1 or higher | | wce400\sh4\ | SH4 | Pocket PC 2003 Win CE 4.1 or higher | | wce400\x86\ | 80x86 | Pocket PC 2003 Win CE 4.1 or higher | | Note: These directories are relative to the Visual Studio subdirectory \CompactFrameworkSDK\ v1.0.5000\WINDOWS CE\. | Installing CPU Picker CPU picker is available as an MSI file on the GOTDOTNET Web site at www.gotdotnet.com. As of this writing, Visual Studiorelated utilities were located by following these links: .NET Downloads, Visual Studio .NET, Tools and Utilities. Before installing CPU Picker, exit all instances of Visual Studio .NET and click the MSI file to start installation. After installing the CPU Picker, start Visual Studio. During startup, Visual Studio brings up the CPU Picker interface, as shown in Figure 1.18. Select one of the CPU architecture types shown in the list to match your device hardware and click OK. Figure 1.18. You can manually select the device CPU type with the CPU Picker.  IF YOU CHOOSE THE WRONG CPU WITH CPU PICKER If you make a bad CPU selection, you can change it at any time by quitting Visual Studio and restarting it from the command line by typing devenv.exe/ setup . Typically, Visual Studio is installed into the C:\Program Files folder, and devenv is in the folder \Program Files\Microsoft Visual Studio .NET 2003\Common7\IDE\devenv.exe . If you installed Visual Studio in a custom location, simply look in the Common7\IDE subdirectory wherever you installed Visual Studio. |
After you click OK, Visual Studio asks you to confirm your choice. After Visual Studio confirms your CPU selection, restart Visual Studio to make the changes take effect. The next time you deploy or debug against the device, Visual Studio will use your CPU choice instead of trying to detect the CPU type using ActiveSync. Devices without ActiveSync The primary target audience for the first release of the .NET Compact Framework is the Pocket PC and the SmartPhone, two classes of devices that support ActiveSync connections. The previous discussions show that Smart Device Extensions rely on ActiveSync to copy ConmanClient.exe to a device and to prep the device. This means developers who want to target Windows CE devices without ActiveSync connections will not have any way to deploy or debug against their devices. In recognition of this problem, Microsoft created the Smart Device Authentication Utility. Smart Device Authentication Utility The Smart Device Authentication Utility allows users to prep their devices and launch ConmanClient.exe by using a TCP connection instead of a ActiveSync connection. This is the utility that lets developers target devices without ActiveSync. It is available at the Microsoft Smart Devices Developer Community Web site at http://smartdevices.microsoftdev.com/Downloads/default.aspx. As of this writing, the Smart Device Authentication Utility is part of the Windows CE Utilities for Visual Studio .NET 2003 Add-on Pack. There is a link on the Web page to download this product. The Smart Device Authentication Utility comes in two parts the desktop- and device-side executables. The desktop side is composed of the SDAuthUtil.exe executable. The device side is a single client executable called SDAClient.exe . To use the Smart Device Authentication Utility, follow these steps: -
Make sure your desktop has Visual Studio 2003 installed and launch the SDAuthUtil.exe program. Note that SDAuthUtil.exe requires version 1.1 of the .NET Framework. This version of the Framework is automatically installed when Visual Studio .NET 2003 is installed. When SDAuthUtil.exe is launched, it shows a simple user interface, as shown in Figure 1.19. Figure 1.19. Users interact with the Smart Device Authentication Utility mainly through the Desktop Client user interface.  -
Copy the correct version of SDClient.exe to the device and launch it. You can use any convenient means to get the executable to the device, such as emailing it to yourself and checking your email with the device. Some devices support FTP from the Windows CE command line. If you are a developer using a nonstandard device, we assume that you know enough about your device to get the SDClient.exe program to your device. There are separate builds of SDClient.exe available, each for a different operating system version and processor. Each version of SDClient.exe is in a separate directory, as shown in Table 1.5. Use the table to determine which directory holds the version of SDClient.exe that will run on your device. Table 1.5. SDClient Device Builds | DIRECTORY NAME | CPU | OS VERSION | | wince3\arm | ARM | Pocket PC 2002, Pocket PC 2003 | | wince3\mips\ | MIPS | Pocket PC 2002, Pocket PC 2003 | | wince3\sh3\ | SH3 | Pocket PC 2002, Pocket PC 2003 | | wince3\x86 | 80x86 | Pocket PC 2002, Pocket PC 2003 | | wince4\armv4\ | ARMv4 | Win CE 4.1 or greater | | wince4\armv4t\ | ARM v4t | Win CE 4.1 or greater | | wince4\mips16 | MIPS 16 | Win CE 4.1 or greater | | wce400\mipsii\ | MIPS II | Win CE 4.1 or greater | | wince4\mipsii_fp | MIPS II FP | Win CE 4.1 or greater | | wince4\mipsiv\ | MIPS IV | Win CE 4.1 or greater | | wince4\mipsiv_fp\ | MIPS IV FP | Win CE 4.1 or greater | | wince4\sh3\ | SH3 | Win CE 4.1 or greater | | wince4\sh4\ | SH4 | Win CE 4.1 or greater | | wince4\x86 | 80x86 | Win CE 4.1 or greater | -
When SDClient.exe launches on the device, a simple user interface shows up. Note that SDClient.exe displays all of the IP addresses for the device. If SDClient.exe does not launch, it is possible that you chose the wrong build of SDClient.exe . It is especially easy to make this mistake because of all of the different versions of the ARM processor and MIPS processor. Look at Table 1.5 and try another build that looks like it might run on your hardware. For example, if MIPS II did not work, MIPS IV may. You might have to try several different builds before you find one that runs on your device. -
Enter the device IP address that you discovered in step 3 into SDAuthUtil.exe on the desktop, as shown in Figure 1.19. In this example we set up the desktop to try connecting to a device whose IP Address is 172.26.121.33 . -
Click the Connect button on SDAuthUtil.exe (on the device). -
Click the Launch Conman on Device button on the desktop. The Smart Device Authentication Utility determines what version of ConmanClient.exe to install based on what build of SDClient.exe is running on the device. It installs ConmanClient, preps the device, and displays a message of success. If there are more than one IP address for the device, you may have to try more than one before you get a successful connection. -
After you have successfully prepped your device and launched Conman, you can quit by clicking the Close button. This causes both the desktop- and device-side programs to quit. After a successful interaction with the Smart Device Authentication Utility, your device is running the correct version of ConmanClient.exe , and it has been prepped with the desktop. -
Attempt to deploy and/or debug against the device. Do not reboot the device, or you will have to run the Smart Device Authentication Utility all over again. Installing the .NET Compact Framework Manually If nothing seems to get debugging and deployment to work, some devices can still run the .NET Compact Framework if it is installed onto the device manually. Once the .NET Compact Framework is successfully installed to a device, managed applications can be copied over to the device and launched by hand. While this is not an ideal scenario, it helps make some nonstandard devices viable for use with managed code. If you are forced into this situation, you can still debug your code using the Pocket PC or Windows CE emulator and deploy your application and the .NET Compact Framework manually. RISKS ASSOCIATED WITH SMART DEVICE AUTHENTICATION UTILITY Using the Smart Device Authentication Utility carries a small risk because it uses a TCP/IP connection to transmit the shared key that is created when prepping the device. When the shared key is transmitted from the desktop to the device, it is encrypted using the device's exchange key. This means that even if a hacker accessed the shared key as it traveled between the desktop and the device, it would be useless to him. Thus, using the utility is still a reasonably safe thing to do, but nothing beats the security of using an ActiveSync connection with a USB cable, since the data transmitted on the USB cable cannot go out to the internet. |
The .NET Compact Framework is stored in CAB files on your desktop computer. There are three CAB files that must be copied to the device. One holds the .NET Compact Framework runtime and class libraries. Another holds the SQL CE database engine, and the third holds the .DLLs that implement the SQLClient namespace that is needed to connect to a desktop SQL Server (see Chapter 7, "Programming with Microsoft SQL Server CE"). These CAB files are built for Pocket PC operating systems and Windows CE 4.1 or greater. There is one set of CAB files for each combination of operating system version and processor type. Table 1.4 shows the names of the CAB files and their contents according to the processor and operating system in the device. The CAB files are all in the Visual Studio .NET subdirectory \CompactFrameworkSDK\v1.0.5000\WINDOWSCE\ . You can use the Windows Explorer Search function to search for the CAB files directory. .NET COMPACT FRAMEWORK APPLICATIONS ARE PORTABLE Although you must choose the correct build of the .NET Compact Framework to install manually on your nonstandard device, you do not have to make a special build of your application for a specific device. This is because your application's executable is managed code that is JITed specifically for the processor that is running the application. Chapter 2, "Introducing the .NET Compact Framework," discusses the JIT engine in greater detail. |
To manually install your application and the .NET Compact Framework to your device, follow these steps: -
Locate the directory holding the CAB files appropriate for your device. -
Copy the two CAB files to the root directory of your device by using ActiveSync or any other convenient means. -
Click the .NET Compact Framework CAB file to explode it first, and then click the SQL CE CAB file to explode it second. -
Copy all of the files associated with your application to your device in any directory you wish. You can tell if the CAB files exploded successfully by looking in the device's Windows directory. The files listed in Table 1.6 are dropped there if the .NET Compact Framework installed successfully. Table 1.6. Files in the \Windows Directory for the .NET Compact Framework | GAC_Microsoft.VisualBasic_v7_0_5000_0_cneutral_1.dll | | GAC_Microsoft.WindowsCE.Forms_v7_0_5000_0_cneutral_1.dll | | GAC_Mscorlib_v7_0_5000_0_cneutral_1.dll | | GAC_System.Data_v7_0_5000_0_cneutral_1.dll | | GAC_System.Drawing_v7_0_5000_0_cneutral_1.dll | | GAC_System.Net.IrDA_v7_0_5000_0_cneutral_1.dll | | GAC_System.SR_v7_0_5000_0_cneutral_1.dll | | GAC_System.Web.Services_v7_0_5000_0_cneutral_1.dll | | GAC_System.Windows.DataGrid_v7_0_5000_0_cneutral_1.dll | | GAC_System.Windows_Forms_v7_0_5000_0_cneutral_1.dll | | GAC_System.XML_v7_0_5000_0_cneutral_1.dll | | GAC_System_v7_0_5000_0_cneutral_1.dll | | Note: The filenames may differ slightly if you installed a non-English localized version of the .NET Compact Framework. | Devices with Unusual Memory Maps Some proprietary devices have memory maps that mix flash memory with standard static memory. The result is that some entries that are written to the file system remain even after the device is cold-rebooted. The only way to reset the file system to a "pristine" state is to re-flash the device, which means downloading the original operating system image by using a special tool that overwrites the flash memory. This scenario can become a field support nightmare because unsuspecting users can alter the root filesystem in such a way as to disable the device completely, unless a tech support specialist comes to re-flash the device. This alteration is especially problematic if the memory map is set up so that the device registry is stored on flash memory. Users can do things to damage the registry that causes the device to malfunction, and there is nothing that can be done without re-flashing the device. Holding the system registry in writable flash memory causes a very specific problem when working with Smart Device Extensions. Recall that the process of prepping a device means that a private key is exchanged between the desktop and the device. To ensure safety, the private key is encrypted using the device's key exchange key before it is transmitted between the desktop and the device. The key exchange key is created when it is needed the first time, and then it is stored in the device registry. If the device is cold-rebooted but the registry is not cleared, then the old key exchange key remains. However, the old key exchange key is incompatible with the newly cold-rebooted device, and so the device now has no way to exchange private keys with other parties. Thus, prepping will fail, and trying to deploy or debug to the device will never work again until the device is re-flashed. If you have a device with which you could deploy and debug until it was cold-rebooted, and even the Smart Device Authentication Utility does not seem to help after a cold reboot, it is possible that the registry is surviving cold reboots. To check for this condition, follow these steps: -
Look for the default key exchange key in the device registry. The easiest way to do this is to use the device registry editor that is included with embedded Visual C++ version 3.0 or 4.0. The default exchange key is stored under the key HKEY_CURRENT_USER\ Comm\Security\Crypto\UserKeys\*Default* . Figure 1.20 shows the device registry editor as it examines the default key exchange key. Figure 1.20. You can use the Device registry editor, shipped with Embedded Visual Tools 3.0 and 4.0, to display the Default exchange key.  -
Write down the value for the key exchange key and cold-reboot the device. -
The default key exchange key entry should be gone. If it is not, then the registry is surviving cold reboots and will cause the problems just described. -
To make deployment possible again after a cold reboot, delete the default key exchange key after a cold reboot by using the device registry editor. DEVICES WITH REGISTRY INFORMATION IN FLASH A device with a memory map in this state is likely to exhibit problems other than those related to the .NET Compact Framework. It is not a good design. However, this discussion is included to give readers every chance of getting deployment and debugging to work on their nonstandard devices. |
Connectivity Summary and Troubleshooter Table 1.7 lists the most common problems users experience when connecting to their devices and possible solutions. The table is most effective when the reader has read the previous sections of this chapter and has an understanding of how device connectivity works. Table 1.7. Common Connectivity Problems and Solutions | PROBLEM | SOLUTION | | Cannot deploy or debug against CE device running ActiveSync and Windows CE 4.1 or greater. | -
Use the CPU Picker utility. -
Use the Smart Device Authentication Utility to prep the device and launch the correct version of ConmanClient.exe. -
Install the .NET Compact Framework onto the device manually. | | Device has TCP/IP connectivity but not ActiveSync. | -
Use the Smart Device Authentication Utility. -
Install the .NET Compact Framework onto the device manually. | | Deployment and debugging to a nonstandard device without ActiveSync worked until device was rebooted. | ConmanClient.exe is stopped. Relaunch it using the Smart Device Authenticaiton Utility. | | Nonstandard device was set up successfully by using the Smart Device Authentication Utility until device was cold-rebooted; subsequent attempts to use the Smart Device Authentication Utility fail and deployment and debugging fail. | Device has a nonstandard memory map. See discussion on such devices in previous section. | | Deployment and debugging to a Pocket PC device work until Pocket PC device is rebooted. | Device must be connected through ActiveSync so that Smart Device Extensions can restart ConmanClient.exe. |  |
