How to debug Visual Studio 2012 instance design-time
Asked Answered
B

3

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)
Bacitracin answered 11/10, 2012 at 10:48 Comment(0)
B
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.

Bacitracin answered 27/2, 2015 at 9:50 Comment(3)
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.Sickroom
because one visual studio instance can't debug itself. (XDesProc is thight coupled with the visual studio process)Bacitracin
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?Martita
P
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.

Predisposition answered 11/10, 2012 at 15:37 Comment(4)
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.Bacitracin
Please elaborate what "fiddling with that process" means.Tesstessa
@Bacitracin I would recommend to publish your comment as an answer.Ginger
see this articles of mine... codeproject.com/Tips/1040701/…Plasterwork
B
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.

Bacitracin answered 27/2, 2015 at 9:50 Comment(3)
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.Sickroom
because one visual studio instance can't debug itself. (XDesProc is thight coupled with the visual studio process)Bacitracin
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?Martita
V
4

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.

Vescuso answered 22/6, 2016 at 20:22 Comment(1)
This also works in VS 2022, if the designer does no longer correctly show complex components from your solution.Belmonte

© 2022 - 2024 — McMap. All rights reserved.