An Metro Style application needs to be packaged, signed, and deployed before it can be launched from the the Windows desktop, as I discussed in my post on Creating an Appx Package. This means an IDE needs to go through a lot more work in order to launch an application for debugging than just calling CreateProcess with the DEBUG_PROCESS flag set.
Creating a package
For now, I'm just using createappx and the PowerShell cmdlets Add-AppxPackage and Remove-AppxPackage to manage my packages from batch scripts. IDE integration should use the App Packaging and Deployment APIs to achieve these steps.
Windows Runtime internals: understanding "Hello World" is a talk I've mentioned before as a must watch talk. A large part of what he does is debugging low level stuff with the provided command line debugger, cdb. I found this indispensable for getting started. In this talk he uses a tool that enables debugging on a package using IPackageDebugSettings. He shared this tool unofficially on codeplex, and then Microsoft packaged an official sample on their own site. Another package Matt suggested you get is the Windows Developer Preview Symbols (for x86 and x64), which are available for download through MSDN. These symbols are useful for debugging the internals of the Windows libraries from cdb, windbg, or Visual Studio. It's handy being able to put breakpoints in things like, RoGetActivationFactory to see a little bit of what's going on behind the scenes in WinRT.
Something that is not obvious to me about the IPackageDebugSettings.EnableDebugging API, I'm not sure if you can specify the parameters. When I specify a debugger, it seems to add the parameters "-p (PID) -t (TID)", and I'd like to know if I can tell it to provide those in a different way. With RAD Studio, the command line argument to attach to a debugger is "bds.exe -attach:(PID);(TID)" and in order to parse the "-p (PID) -t (TID)" I need a helper script/program.
By the way, the Windows 8 Developer Preview with developer tools English, 64-bit (x64) provides x86 and x64 debuggers, somewhat unsurprisingly at the path "C:\Program Files (x86)\Windows Kits\8.0\Debuggers".
Automating the startup
I'm still missing a part of automating my application startup for debugging, and that's actually launching the application. I found an article by Raffaele Rialdi on contracts and activation where he describes how Explorer launches a process:
"Explorer uses the RPCSS (RPC system service) to activate the application. As RPCSS is exposed to the network and has a large attack surface, RPCSS runs with low privileges (network_service) and with a integrity level system that prevents other processes with a lower integrity level can affect RPCSS in reading or writing.
As we have been told during the build conference, RPCSS maintains the list of activated objects, and can create a pool of objects (anyone remember COM+?) via IObjectControl.
To start the process (real or surrogate), RPCSS service uses "DCOM Launcher" that has higher privileges (localsystem). The "DCOM Launcher" service reads from the registry the informations related to the class and the host process and finally create the application process."
This all seems like relevant and useful information, I'm just unsure how to do that from my own application. Or possibly there's some way I can tell Explorer to do all that?
Before I mentioned attaching my application to RAD Studio for debugging, which is unfortunately something I've hit a bit of a road block with. I actually have the same problem if I debug with the x86 version of cdb.exe or windbg.exe. The debugger will attach fine, but when I attempt to run, I occasionally see an Access Violation that the application can't recover from. The Access violation happens in the loader before my exe has even been loaded, so I suspect this has something to do with new linker features for Win8 in cl.exe and csc.exe; there's probably some information I'm supposed to add to my exe file that the Delphi compier can't do yet.
Oddly enough, if I attach with the x64 version of cdb.exe (or windbg.exe), I still hit the access violation, but the debugger more gracefully handles it and the application continues to load and run. I can even detach from that debugger, re-attach with RAD Studio, and debug my code in a more familiar environment.
Unfortunately, for some reason the loader loads the executable image with the name "image(RANDOMBASEADDRESS)" and it doesn't actually load symbols. I can force RAD Studio to load the symbols by opening the Modules tab (ctrl+alt+m), right clicking my module selecting "Reload Symbol Table..." and selecting my the executable or its TDS file on disk. It's very clumsy, but for now, it works.