When I created a template (posts here and here) that speeds up development of Silverlight Sidebar gadgets, I wanted to offer the smoothest development experience possible. Ironically, that in itself has been a very bumpy ride. The last hurdle I had to cross was to provide the familiar debug experience (F5).
My first attempt at this was just to set appropriate start options for the Web project that is in the template:
- Post build event that installs the gadget (runs a generated .gadget file)
- %ProgramFiles(x86)%\Windows Sidebar\sidebar.exe as the start program
This attempt failed with a very suggestive error:
I ran into this error every time the debugger was attached by the start options (F5, not using the Attach to Process command) and a Silverlight gadget was running in the Sidebar. I even tried to start debugging the sidebar when no Silverlight gadget ran, then added the Silverlight gadget to the Sidebar, but it was no use: same result.
I tried to get help with this error, but I could not find anything on it. The issue also seems like a very isolated corner case that does not affect too many people, so it would be tough to get any help.
While trying to find a workaround for F5 debugging, I wondered if I could run a custom app that manipulates the right Visual Studio instance to run the Attach to Process command and attach to sidebar.exe. Luckily, I was in Michael Leonard’s office at the time, because I got a quick answer: he had done similar things in the past. Half an hour later I had a code snippet about getting the Visual Studio automation object corresponding to a specific VS instance. Many thanks to Michael Leonard and Adam Nathan for getting the wheels turning on this.
The other parts of the solution flowed naturally:
- You can attach to the Visual Studio instance that has a specific solution open (info here).
- You can start the sidebar if it’s not already running (System.Diagnostics.Process.Start)
- You can launch the “Attach to Process” command using the DTE objects (info here).
- You can pass the full solution path as a command line parameter from the Visual Studio project Debug options (though not for all projects; for web projects it won’t work because macros are not supported).
- You can provide a transparent retry logic for COM calls that fail due to the destination being busy (info here; note the part about the single-thread apartment requirement).