次の方法で共有

CE 6.0: Don't add Platform Manager to your OSDesign

  • [アーティクル]

Adding the Platform Manager component to a CE 6.0 operating system design will generate build errors for a platform - the error will read something like:

Error: Could not find file 'C:\WINCE600\OSDesigns\<Release Dir Path>\cemgrc.exe' on disk

The image below shows the Platform Manager component in the CE 6.0 catalog (more information on Platform Manager can be found in this MSDN Article) 

Take a look at the contents of C:\WINCE600\PUBLIC\COMMON\CESYSGEN\makefile - line 1187, "Platman Stuff" - this tries to copy files from $(OTHERS_ROOT)\platman\target\$(_TGTCPU)\ - this resolves (for a default install) to C:\WINCE600\OTHERS\platman\ (etc...) - the Platman folder doesn't exist in the CE 6.0 install, so the files cannot be copied and therefore the build fails. For the RTM build Platform Manager should have been removed from the catalog, the underlying files were removed from the \WINCE600 folder structure but the catalog item was somehow overlooked.

With the introduction of CE 6.0 the underlying connection betweeen Visual Studio 2005 and your embedded target is CoreCon, to deploy and debug an application you need to start two processes on your target device, these are known as ConManClient2.exe and CmAccept.exe - these can be found in the following folder on your desktop development machine C:\Program Files\Common Files\Microsoft Shared\CoreCon\1.0\Target\wce400\<Processor_Type> - with previous releases of CE you would use Visual Studio 2003 or eMbedded Visual C++ 4.0 SP4 to write applications, Visual Studio would require you to run a desktop application (the Smart Device Authentication Utilitiy) which would run two applications on your target device (ConmanClient.exe and SDAuthUtilDevice.exe) - note that Visual Studio doesn't need Platform Builder attached to the target to run this application - for eMbedded Visual C++ you have two options to deploy an application, the first is to "piggy back" on the existing Platform Builder connection to the device (using CESH/KITL as the connection from eMbedded Visual C++), the second option is to deploy the appliation using TCP/IP and running applications directly on the target like CEMGRC which uses an interesting command line!

With the release of CE 6.0 native and managed application development is merged into one tool, Visual Studio 2005 - now you just need to run the ConManClient2 and CmAccept utilities on the device (how you get them there is another story) and then you can write, deploy, and debug your managed or native applications - which means that Platform Manager isn't needed any more and therefore shouldn't be added to your platform (note that ActiveSync doesn't need Platform Manager to work).

- Mike

Comments

  • Anonymous
    November 27, 2006
    The comment has been removed

  • Anonymous
    November 27, 2006
    The comment has been removed

  • Anonymous
    December 07, 2006
    Mike, Do you have any suggestions on how best to get CoreCon loaded on a headless device.  Using HKLMInit for loading at startup is problematic, since an IP address must be allocated from the DHCP server before ConmanClient2.exe can be executed.  Is there a dependnn hex value associated with the IP stack? Jim Y. Wilson

  • Anonymous
    December 07, 2006
    I'm not aware of a dependency on the IP stack from the HKLMinit launch keys. If you are building a headless device and want to launch ConManClient2 and CmAccept these have a three minute timeout for you to connect from VS 2005, plus VS 2005 needs to know the IP address of the device you are connecting to. If you are booting a headless device from Platform Builder you can of course use the Target Control Window (ALT+1) to issue a "s ipconfig /d" command once the image has booted to then get the IP address of the target device, feed this into VS 2005 for application development and then launch conmanclient2 and cmaccept on the target (again using the Target Control Window). Do you have the option of using a fixed IP address or do you need DHCP ? - if you need DHCP then perhaps the following might be possible... have a launch application that periodically monitors the IP address of the device - if the IP address is valid then the device could send a UDP broadcast with the IP address of the device (and perhaps device name from the registry) and spwan ConManClient2 and Cmaccept - a listner application running on the desktop would then have three minutes to plug the IP address into Tools|Options and deploy an application to the device. Sound like a plan ? - the alternative is to run a remote display application on the device (again when the device has a valid IP address) - of course the device will still need to broadcast the IP address of the device to a listening application on the desktop - the desktop side could then display the 'virtual desktop' from the headless device, you could then control the device from the desktop. So many possibilities !

  • Mike

  • Anonymous
    December 12, 2006
    We are also trying to implement application debugging on a headless device (x86). Our problem is the SDK which does not contain e.g. OLE32.DLL. Is there any method in the properties for a smart device project where I can disable the default OLE32 library?

  • Anonymous
    December 17, 2006
    Hi Mike, how can I use the remote tools without the platform manager in a release kernel and not connected to the platform builder? Mike Engel