14

I'm developing a WPF MarkupExtension and encountered errors during design time. With the previous version of Visual Studio 2010 it was possible to start a second instance of Visual Studio 2010 and attach to the process of the already-running instance, setting breakpoints and debugging the design time behavior.

In Visual Studio 2012 however I can attach to the process of another Visual Studio 2012 as well, but no symbols are loaded in the second instance and therefor I'm not able to debug the design time as with Visual Studio 2010.

How do I get this debugger running?

Things I've tried:

  • "devenv.exe /RootSuffix Exp" trick without success
  • Always execute as Administrator
  • Load all or default symbols
  • Debug with and without native code (attach process)
  • Debug with and without .NET 4 code (attach process)
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
SeriousM
  • 3,374
  • 28
  • 33

3 Answers3

14

In Visual Studio 2012, the WPF designer runs in a separate process. Try fiddling with that process. It should be easy to find out the process name.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
NileshChauhan
  • 5,469
  • 2
  • 29
  • 43
  • 13
    Thank you very much! The process is called XDesProc and it is created with each new Preview Window. Therefor: to debug a preview window open a second instance of vs2012 with the same solution, set your breakpoints and attach to XDesProc. Its recommended to have only one preview window open to attach to the right process. otherwise use the Process Explorer (sysinternals.com) to find the correct process. – SeriousM Oct 12 '12 at 09:57
  • 3
    Please elaborate what "fiddling with that process" means. – Mishax Nov 28 '14 at 09:21
  • 2
    @SeriousM I would recommend to publish your comment as an answer. – Mehrad Feb 26 '15 at 05:01
  • see this articles of mine... http://www.codeproject.com/Tips/1040701/How-to-Debug-the-Design-Time-Errors-in-WPF-XAML-Fi – Manish Dubey Oct 21 '15 at 03:44
8

The process is called XDesProc, and it is created with each new Preview Window. Therefor: to debug a preview window, open a second instance of Visual Studio 2012 with the same solution, set your breakpoints and attach to XDesProc. It's recommended to have only one preview window open to attach to the right process. Otherwise use Process Explorer to find the correct process.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
SeriousM
  • 3,374
  • 28
  • 33
  • Your tip helped me, thank you for that. But why do you suggest to open a second instance of Visual Studio? This seems to be optional. – Martin Oct 19 '15 at 13:12
  • because one visual studio instance can't debug itself. (XDesProc is thight coupled with the visual studio process) – SeriousM Oct 27 '15 at 15:01
  • I'm building a UWP, I was able to attach to the process, I'm getting the exception but the problem is I can't get to break at the breakpoint I set in my viewmode, and code behind constructors. Do I need to manually load a module to do that? – Lance Jun 10 '16 at 13:47
3

Make sure you have the "Enable/Disable Project Code" toggle set to "enabled"...in VS/Blend 2015 it's a small icon below the XAML editor as shown here.

If it's disabled, this could be the reason your design time instance doesn't seem to be working.

Further, if it's disabled and you attempt to debug using a second VS instance, then when you attach to the XDesProc any breakpoints you set in the code-behind will report that they "will not currently be hit. [because] No symbols have been loaded for this document". You might think that you need to somehow load the symbols, but if you open up the Modules window attempting to do so, you won't even see your module in the listing.

I lost a couple hours on this issue because of this setting being disabled. Hope this helps others not do the same. Because of that, I'll post this on a few of the related questions.

BTW, there's an excellent description of this debugging procedure by James McNellis on one of those related questions.

Community
  • 1
  • 1
Charlie Lotridge
  • 101
  • 1
  • 4