Visual Studio 2005 – Do we need a Windows CE SDK ?

So, I've been thinking... To write managed or native code applications for Windows CE 5.0 you need to generate a custom SDK (Software Development Kit) from Platform Builder - Why do I need to do this?

Generating an SDK takes time, and is a multi step process, first I need to configure the SDK, then (optionally) modify the SDK settings, then build and install the SDK - I can understand that eMbedded Visual C++ would need an SDK to know about the native APIs exposed from my platform (since every platform is going to be different) - but what about managed application development ? - surely the .NET Compact Framework 2.0 is an abstraction layer, meaning that applications written to run on the Compact Framework don't (for the most part) need to know about the underlying operating system, the applications are calling the framework APIs, not the underlying O/S bits directly (although they could - but even still, this is a runtime function call to a native o/s feature, not a build time feature).

I'm wondering (and this will take some investigation) whether it would be possible to build a Skunk tool that 'fools' Visual Studio 2005 into thinking that an SDK has been installed by creating the appropriate files or updating the registry or whatever, the tool could prompt for a platform name (perhaps the PBXML file), the processor type, and then build the appropriate bits. Actually, take this one step further... for native development, the headers/libs must already be there since your platform has already been generated, so I'm wondering whether it would be possible to generate the appropriate SDK files/registry bits by simply pointing VS 2005 at the appropriate folders for an existing workspace...

So, this is going to take some investigation, the tool makes total sense to me, and could be a useful time saver for managed/native development against a Windows CE 5.0 based device.

Thoughts/comments ?

- Mike

Comments (13)

  1. Mike,

    Dealing with this in a 2540N class this past week, it seemed that PB 5.0 doesn’t let you actually create an SDK for CF 2.0; in fact, if you leave off the CF 1.0 from the Workspace, and just include 2.0, the SDK Wizard greys out the CF choices, leaving only the eVC++ choices.

    In the lab environment at least, things worked fine without the CF support in the SDK. I didn’t try without an SDK installed yet (they install the SDK in the lab, even though it only has eVC++ support), but at least on our development boards (BSQUARE DevkitIDP), with ActiveSync 4.0 and VS 2005 (RTM), things worked when selecting "Windows CE Device" for deployment.

  2. As a follow-up to the previous comment, I should point out that in the lab we do both CF and native development. Don’t touch eVC++ at all. The curious part is about native development, as you suggested, because CF I agree doesn’t need to worry.

  3. Oskar Berreteaga says:

    I’d say that for managed development you should be fine without an SDK. I mean it should be possible to develop managed apps using VS 2005 for a device that supports CF with no SDK, as long as CF isn’t componentized (would it be a good idea? For headless devices, yes. But that’s another story).

    On the other hand, if you’re doing native development, I think you definitely need an SDK cause it may happen that you don’t have Platform Builder with you so your platform headers/libs must come from somewhere.

  4. Valter Minute (valter.minute_AT_gmail_DOT_com) says:

    I think that the SDK is more useful for native development than for managed applications but, in some cases, it could be useful to allow OEMs to redistribute information and native components to managed developers who need, for example, to interact with the hardware using DLLs that "wrap" the driver functions or to use high performance C/C++ libraries for example to encode/decode audio and video data.

    I know that you don’t need an SDK to do that, but being able to simply install an .msi that creates the right build environment is nice.

    I would like to see some componentization support for the CF. For example being able to remove database, winforms or XML support if your application doesn’t need them will allow you to remove also some components from the image, reducing its footprint (and maybe spreading the usage of the CF that is still considered a memory hungry monster by many device developers).

    Another thing that could be very useful is a custom emulator image.

    I’m working on a device that should work using a TV as it’s screen,

    I had to customize the UI in a heavvy way. Having an emulator image including my modification allows the UI (managed) developers to check the appearance of their applications. Doing that on a standard emulator would be much more difficult.

    I hope to see a QFE that includes the BSP for the new ARM-based emulator, since using the old x86 based one to debug managed application is a bit clumsy (and the new one seems also to be faster and more reliable).

  5. mikehall says:

    I’m not suggesting that we do away with SDK’s, you will certainly need an SDK if you want to code against a device and don’t have the original platform image. I’m suggesting that on the development PC you shouldn’t need to build an SDK since all the files are already in place, wouldn’t it be useful to "build" an SDK that actually only puts the right registry information in place to allow VS 2005 (or eVC) to connect to your board ?

    – Mike

  6. Oskar Berreteaga says:

    Yep, it would be fine if SDK building & installing process were easier. That’s specially helpful when your OS isn’t fully stable and you’re adding or removing components. Having to build and install an SDK for each OS config is a bit tiring.

  7. Valter Minute (valter.minute_AT_gmail_DOT_com) says:

    I thought that you were also suggesting to avoid the usage of an SDK for managed development. I’m sorry for the misunderstanding but, as you can read, English in not my mother tongue 🙂

    The idea of having a "virtual" SDK on the development PC is interesting.

    The only drawback I can see is that you should be careful if you use the same PC also to build evc++ or applications that should be used on a "stable" release of your platform while you’re working on a new release.

    If you change a structure, for example, you may risk to rebuild an application that uses the new structure and run it on the old version (on the device) where the "old" structure is expected.

    You could avoid this kind of problems by installing the "stable" SDK (that you’ll build once when a new release of the platform is shipped to customers) and using the "virtual" SDK to build applications for the release you’re working on, but I think that this issue should be pointed out for people that will use your tool.

    P.S. may I hope to see the ARM-emulator BSP included in a QFE or we’ll have to wait for the next major upgrade of the OS to be able to use the VS2005 emulator?

    A tutorial about how to use the old emulator with VS2005 could be useful for many developers, I think.

  8. Mattn says:

    Our BSP development guys are dragging the chain, and our hardware is months over due. Some of out code is native, most managed, however, we cannot easily test the interfaces until we have emulators. I don’t have and don’t want to bother with platform builder.

    An SDK would make life much easier.

  9. David Jones says:

    I have tried many times to create and run a CF application from VS.NET 2003 in debug mode on a CE system running in debug mode from platform builder. I run into timestamp problems amongst other things, errors trapped by PB.

    One useful conduit I have often thought about, and used in a peacemeal manner is via the FlatRelease directory. ie When running a CE image from PB in debug mode, files placed in the FR directory can be used as if in the platform’s windows dir.

    So what if VS.NET used the FR directory to pass files and control to the CE platform


  10. Wesley Snell says:

    Personally I believe that we need to enhance VS 2005 such that you can add a custom SDK (just like you can in eVC) so that you have only the single development environment. I believe that is the current intent but with the RTM version I see no way to associate a plotform SDK for the native module I want to create. As such I am still stuck with eVC. This needs to be a single environment for all development. Especially since it contains greatly improved IDE functionality a new debugger and emulators (although we might need to wait for the new ARM emulator). So anything to bring SDKs into the environment is a worthy task. Especially since a custom build environment will likly not have a clearly define set of components (when created with CE 5.0 and Platform Builder), v.s Pocket PC or SmartPhone where the SDKs are preinstalled and the interfaces and components fully defined and consistent.

    Should there be any other way to associate a SDK for native code development in VS2005 for CE 5.0 projects lets get that process better documented and realize this is still a very useful requirement.

  11. Matt Foster says:


    I like your comment about a ‘Virtual’ SDK that only points eVC (or VS2005) to the correct platform headers and libs.

    I’ve just started looking into how to setup an efficient development environment for about 20 soon-to-be Windows CE developers. In our current dev environment (using VxWorks) we’re able to work multiple issues at the same time, possibly against slightly different platform code bases. It seems to me that the requirement to install an SDK in order to do some application development against a platform is a serious limitation: Each developer would need to uninstall an SDK and install a different SDK depending on their current ‘view’ of the platform. This seems like an artificial limitation, since each developer likely has access to the entire code base for the platform that we’ve created.

    Is my view of the Platform SDK flawed, or is it expected that developers will need to uninstall/reinstall every time the OS (or drivers within the OS) change?

    I agree that an SDK is required in certain cirumstances (eg for an application only developer), but I think that should be the choice of the developer and not required by the tools.


Skip to main content