(a) Unlike OS subprojects you can’t:

• Add a new project to the OS solution while the OS is running.
• Rebuild such projects while the OS is running.

(b) Whilst you can launch such apps directly from the IDE using CoreCon, debugging isn’t supported.

• F5 and the Debug—>Run, Step etc.. menu commands are not available for the application

Debugging is not available because when the OS is launched from Visual Studio it is being debugged, even if KITL etc. are disabled, and Visual Studio does not support multiple debuggers with Windows Embedded Compact.

Application deployment to the OS can be implemented in a variety of ways:

(i) Copy the files to the OS at runtime (e.g. with a memory stick).

(ii) If the OS is using KITL then you need only copy the files to the OS release directory and can then run it using target control.

(iii) Include its built files in the OS image

(iv) The Deploy and Debug—>Start New Instance Project context menu options in Project Explorer as used previously in this chapter.

Given that debugging is not possible in this configuration, when would you use this mode of application development? You could use it when the application to be added is quite simple such that debugging is not necessary. In that case you could use printf statements or MessageBox messages to debug any issues. You would most likely use it with an application that has been debugged and is ready to deploy. In this case you would set it to be built and included in the OS.

In what follows, these methods can be tested by recreating a native code application as previously covered in this chapter or by copying an existing project to the OS solution and adding it using:

Solution Context Menu (Right-Click in Solution Explorer)—>Add Existing Project

(i) Copy the application to the OS at runtime

To implement this, the target needs to have a USB option in its hardware, the OS would need the required API for the application plus the USB drivers required to support a USB memory device:

• USB Host Support/USB Host Controller (ECHI,OHCI,UHCI)
• USB (Host) Storage Class Driver
• File Allocation (FAT) File System (FAT, exFat and TFAT )
  (Automatically included with Storage Class Driver) as in Figure 16.2.

The application and its resources (images etc.) are then copied onto a memory stick with a suitable file system (FAT32 will work). The files are then copied from the memory device onto a suitable location on the device. \Windows will do. It can then be run from a command prompt on the device.

Alternatively the files could be copied to the device using FTP or OBEX if the requirements at both ends are enabled or by using Remote File Manager.

(ii) Set the application build output directory to the OS release directory

A simple way to implement that is to set the build output location to that directory. When copied, the application can be started via Target Control or from a Command window on the device.

1. From the OS Build—>Open the Release Directory In Build Window

2. Copy the path from the prompt:
Context menu (Right-click) in the window and select Mark.
Drag it over the prompt up to but not including the > and click the mouse or press [Enter]

3. Open the application’s property pages (Context Menu—>Properties) and select
Configuration Properties/General—>Output Directory

4. Paste in the release directory path.

5. Rebuild the application

6. Run the application using Target Control or TARGET—>Run Programs

(iii) Include the application in the OS image

With suitable project and solution configurations, building the application to the release directory and suitable BIB file entries, the application can be built with the OS and included in it:

1. Set the application’s build directory to the release directory as above,
so that when the OS is built it has access to the application’s built files.

2. Configure the Solution so that the OS is dependent upon on the application,
so the application is built before OS when the Solution is rebuilt.

3. Add suitable BIB file entries for the application in OSDesign.bib, including any resource files.

4. Rebuild the solution.
Alternatively if the OS is built:

• BUILD—>Copy Files to Release directory,
• Rebuild the application (..must be done AFTER Copy Files),
• BUILD—>Make Run-Time Image

5. Examine the image file and check for the application’s files:
Project—>Show BuiltImage Files

6. Run the OS and test that the application runs

Alternatively, chapter 25 discusses including content in the OS image. CEComponentWiz could be used to package the application up directly from its default build Output Directory.

Project Context Menu Options

The Deploy and Debug—>Start New Instance Project context menu options in Project Explorer as used previously in this chapter can be used to deploy and run the application as in Figure 16.2. The Step Into option doesn’t work as this involves debugging. Similarly, breakpoints are ignored. They require CoreCon to be started on the device. When deployed or run in this manner, the application is deployed to \Temp\ on the device and can be rerun on the device by navigating to this location

NEXT: 16.11 SDK Summary

Click here to provide feedback and input