I'm running a .Net 4.5 WPF application in Visual Studio 2015 Update 1 in a Debug build configuration.
In Tools > Options > Debugging > General I have checked Enable UI Debugging Toos for XAML and Preview selected elements in Live Visual Tree.
However, when I run my application, both the Live Property Explorer and Live Visual Tree Windows display the following message.
UI Debugging is either disabled, not supported by the current application or the application execution is paused.
What am I missing?
I had the same issue and resolved it by also selecting the "Preview selected elements in Live Visual Tree" sub-option (i.e. under Tools > Options > Debugging > General > Enable UI Debugging Toos for XAML). Whenever I unchecked that option, the Live Property Explorer and Live Visual Tree windows would go back to showing the "UI Debugging is either disabled..." message again.
In Visual Studio go to Tools --> Options --> Debugging --> General and uncheck "Use Managed Compatibility Mode" and the Live Visual Tree should show up.
On my end, the issue was that the Target device under the project Properties\Debug\Start Options had somehow changed from "Local Machine" to "Simulator". Going back to "Local Machine" (without changing any of the other debug options mentioned in the other answers) brought back the live visual tree and the live property explorer.
Steps can be seen below, it works well for me.
Open VS, then type "Enable UI Debugging Tools for XAML" in the Quick Lanch box, enter to go to setting detail page (see screenshot below).
You can refer from Microsoft:
How to: Display WPF Trace Information - Visual Studio | Microsoft Docs
Another thing that can cause this to fail is security common in a corporate environment. If the other solutions do not work for you (and your code is not already there), try moving your code to a location under your Documents folder. There are sometimes exceptions to security constraints on your Documents folder, and those security constraints can keep this feature from working.
Nothing worked for me except for a reboot (log out/in probably would have sufficed). I'm guessing a supporting process got into a bad state and wasn't closing when Visual Studio did.