ASP.Net on Windows CE

Summary: I've been asked this a number of times in the last few weeks, so I'll say for the record Windows CE does not currently have ASP.Net support nor is it on our plan of record.  We have a very good subset of ISAPI extensions, ISAPI Filters, and ASP Pages but we don't have a managed web server story.

Want to do it yourself?

Suppose you want to write your own ASP.Net for CE?  There's nothing stopping you though it would be tricky.  Some German college students asked me how to do this a few weeks ago, for the very curious here's my slightly polished response. 

The hardest part here is that you can't call managed code from within any native process.  So you can't write an ISAPI extension that just calls C# objects, since the ISAPI & Web Server are both running from within services.exe.

This means your options are:
1) Write a web server from scratch using C# that is ASP.Net smart.  I don't really recommend this unless you happen to have a C# web server to start out with.  The CE Web Server does bunches of stuff for you like HTTP parsing, user validation, SSL, etc etc etc which even if you started with C# would be a fair amount of work to re-invent.

2) Write an ISAPI extension that proxies HTTP requests on to another process written in C#.  The C# will then look at the HTTP headers, POST data, etc... and be the ASP.Net implementor and will return whatever data it wants to back to the ISAPI extension which in turn returns it to the client. 

You don't have to proxy the request in raw form exactly as it was received on the wire.  You can put it in some easy to use data structure that has the key fields already parsed out and then ship that across process.  If I were to implement this, I would go with this option. 

I was able to get the key portions of standard ASP in about 5000 lines of code (without going into the details ASP on the desktop is a bit bigger than this :), though in fairness it does a lot more too).  So if you carefully subsetted out the ASP.Net required for the scenario you could probably get a pretty good bang for the buck once you got the interprocess communication stuff down.

[Author: John Spaith]


Comments (6)

  1. Nino.Mobile says:

    Software / Hardware SOTI Pocket Controller Professional v5.07 is out Pocket PC Thoughts is reporting

  2. Andreas Schloffer says:

    I accept, that there is no managed web server for Win CE 5 around today – but I don´t understand why MS doesn´t see no story/plan… There is a big need on ASP.NET on Win CE devices: We currently develop a headless Win CE (PXA270) industrial controller integrated into a 10/100 MBit LAN. People simply want to control, manage, program and use all the features of the device via Web-Interfaces. Every "cool" device (VoIP-phone, Set-Top-Box, LAN-Harddisks, …) are set up using web-interfaces. This could be done much faster with ASP.NET and we could reuse a whole lot of our existing ASP.NET code there. Now we are forced to re-implement ASP.NET-stuff (done for XPembedded) for (the old/deprecated?) ASP technology. Personally I always feel pushed back to the old stuff every time I get in contact with CE… On the other hand we have no mobile, no low-power issues, no off-line issues – maybe we simply chose an inadequate plattform/OS? I’m too happy with (other) MS products to really want this to think.

  3. cenet says:

    Andreas – having done some work myself for a night school class, i appreciate how nice it is to program in.  As far as us not having it on WinCE, it really gets down to basically number of customers asking for it versus number of people asking for other stuff (like for instance removing the 32MB VM limitation per process, which was a huge work item for the networking team). is on our radar, but as I said we’re not doing any work on it presently.  I’m sorry we don’t have anything better to help out in the time being.


  4. Nik says:

    I wonder if you could just elaborate a little on the second option. Considering following scenario: Using the server SSL and authentications capabilities and redirect the http request data in the ISAPI extension to the managed process or server that response back to the ISAPI extension that returns the SSL data to the client.  I have developed a crazy construct for IPC within the ISAPI extension that works well but I was wondering whether there is a better option to do this. My solution is to cash the request data within the ISAPI extension then notify the managed application by sending custom WM_BROADCAST window message. The managed application intercepts the message and updates the chased ISAPI data via http request on the local host to the same ISAPI extension that then send back the response from the managed application to the client. Since the ISAPI extensions are cashed for 30 min on the server it works fine but I am sure there is better solution for this scenario. The question is can I use Point to Point Message Queues or raw TCP client sockets for IPC within the ISAPI extension or what will be the best choice of inter-process communication between the unmanaged ISAPI extension and managed application for this scenario? How to write an ISAPI extension that proxies HTTP requests on to another process written in C# and how to get the data back to the ISAPI extension? The idea is to keep all SSL HTTPD server functionality but to redirect the response from a managed application.

  5. cenet says:

    First, you could check out — it’s commercial though.

    If you want to go with your own —

    I write in general about IPC on CE at

    Unfortunately I don’t know managed as well, you may try a managed group.  For this particular scenario, you may actually try writing a service that runs in services.exe.  Then your C# application will call CreateFile("") on your service and can do a DeviceIoControl (I think you’ll have to P/Invoke into that).  Your DeviceIoControl() will pass your service an empty buffer for it to write whatever data it wants back into it.

    When an HTTP request comes in, then your ISAPI extension notifies your service to wakeup a listening DeviceIoControl caller, which isn’t hard since they’re in the same process.  Your ISAPI & service can be the same DLL in fact to make things even easier.  When your C# has a response to send, it calls DeviceIoControl() with a different IOCTL code that indicates it wants the ISAPI extension to send a response – the ISPAI was blocked waiting for the C# app to respond in interim.

    This mechanism of service w/ISAPI extension is effectively how UPnP works, it has same issue where we want stuff in a diferent process playing well with it.

    I have a white paper on services.exe for CE4-5 (mostly true for CE6 too, but some specifics have changed) at that walks through writing a service that handles DeviceIoControl’s.


Skip to main content