(a) Unlike OS subprojects you can’t:
(b) Whilst you can launch such apps directly from the IDE using CoreCon, debugging isn’t supported.
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
FOOTNOTE:
With Compact 2013 it was possible to directly merge a manage code project in the OS project solution, directly into the OS project and have it built with the OS as a subproject. This was because of the unified build system. The build engine for the OS was the same as that used for the subprojects (build.exe). This was the case with previous versions of Windows CE. You could "Add Existing Subproject" to the OS subproject and choose the managed code project file (.csproj, .vbproj). When the managed code project is selected, the following dialog appears:
By accepting, Platform Builder then generates a sources project for it, including parameter files.
Unfortunately this technique doesn't work with managed code projects with Compact 2013.
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:
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.
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
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:
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 up the application directly from its default build Output Directory.
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: 17.11 Managed Code Summary
Click here to provide feedback and input