Let's say that you have to write some server-side scripts that runs on the Web Server of your Windows CE device. You've read about the various server-side scripting technologies Microsoft supports here. You've come up with a design and you're about ready to start coding. I'll try to lay out how to make your life easier for the development stage below.
* If you're using ASP, turn on verbose error messages
For some of the Windows CE 4.x line, we turned off verbose ASP error messages by default. On any error you got something like "The ASP Page encountered a parse error". As you can imagine, this isn't very helpful if you're trying to debug an ASP page.
To workaround this, you can re-enable ASP verbose messages via the registry. Instructions are available here.
In WinCE 5.0 and beyond, we changed the default since people weren't finding out about the registry setting and were having a horrible time.
* If you modify an ISAPI extension DLL, you don't need to reboot the device
By default, the web server leaves ISAPI dlls in a DLL cache for 30 minutes after their last use. This makes them run more quickly, but is painful if you need to make a change to the DLL. I know a lot of people disconnect their debugger, recompile the DLL, and then reboot the device. That can be a very lengthy process.
It's much easier than that! Just run "services refresh HTP0:" from a command prompt on the CE device (or write an app to call CreateProcess to do it). This causes the Web Server to reread all its registry configuration settings and also to unload any ISAPI DLLs it has loaded. Note on Windows Mobile 5 you'll have to change the services.exe registry key to re-enable command line parsing, which it turned off by default. Note this will work on CE 4.0 and above only, not on CE 3.0.
* If you change an ASP DLL, you probably do need to reboot the device (if you're not clever)
Unfortunately running "services refresh HTP0:" will NOT unload COM DLLs that ASP loaded. The issue is that COM itself, and not services.exe, maintains this DLL cache. (This is tied to the infamous CoFreeUnusedLibraries.) You can try killing the services.exe process itself and restarting it. Sometimes it works, other-times it doesn't, and you'll hit some obnoxious but (in my experience at least) harmless ASSERTs killing services.exe.
A more clever way of going about this is to write a harness executable to call into your COM objects directly and test what you're interested in trying out, simulating as if it was called from ASP. Only after your COM DLL is reasonably stable should you do hard-core test from within an ASP page. Of course you want to do basic ASP tests at each stage of the development to make sure there won't be any nasty surprises about your COM object & ASP page interaction at the last moment.
* Consider developing on IIS, but be careful!
Microsoft does not ship any sort of Visual InterDev tool for the CE Web Server. It's not possible to step through ASP pages in a debugger on CE. However, if you have IIS you should be able to make your ISAPIs and/or ASP pages and COM objects compile and run there. On this platform you can use the better development environment and then port your work over to Windows CE.
Be very careful doing this! Make sure you don't accidentally use IIS only features and then when you port your work to WinCE discover they're not supported. Just like running the ASP COM object DLL in a test-only process, frequently test that your web pages work as you'd expect on WinCE throughout the development process.
* Setting break-points
If you want to set a break point and you're using Platform Builder, first break into the debugger and only then set or unset the break point. Just setting the breakpoint when the device is still running will not make the break point take effect until the next time you break into the debugger.
[Author: John Spaith]