Debugger (visualizer) not working properly for entire Orchard project

Topics: Troubleshooting
Apr 8, 2011 at 3:04 PM

This bites me every time I want to look inside lists or dictionaries while debugging. For every other project (including other MVC projects) I instantly can see the values and to bottom most contextmenu entry is "Raw view" (which isn't very helpful) -- now with Orchard I always have the raw view, which requires me to expand 3-4 levels of context menus to see a list at all -- and never shows me the contents of a dictionary (endless loop: You can fill your entire desktop with useless context menus).

I searched the web and found some hints that say: Known bug with web projects, fixed in VS2010Sp1.

But now I am on VS2010Sp1 (and others tell it works: ) but I don't see this using Orchard.


  1. Do the others here around have the same problem or is it a local problem with my system?
  2. Has anyone an idea how to find out why it doesn't work?
Apr 8, 2011 at 3:12 PM

I think it's a general problem with certain IDictionary<TKey,TValue> implementations. I see this problem all the time. It's really bad with a lot of built-in .NET dictionaries like RouteValueCollection as well. I'm on VWD 2010 SP1 and still seeing it.

Apr 8, 2011 at 3:53 PM

But it even fails on List<string> -- that's not really a "certain implementation". Something has a smell here, I just don't know where to search. Maybe a bad guid inside the web project .csproj file or something in web.config which only affects the debugger but not the runtime.

Apr 8, 2011 at 4:03 PM

Oh... my List<String>s are fine. Can you give a specific example of where this is happening, with source code of how you are generating the list / where it's coming from?

Apr 8, 2011 at 4:31 PM

By the way ... do you see the icon at the bottom left of the debugger popup ... it looks like a Refresh button i.e. two arrows in a circle. Sometimes you have to click that to enumerate the list, you can then expand the node and see the contents. This usually happens with IEnumerable<T> lists.

Apr 8, 2011 at 5:15 PM

The IEnumerable invoke button does exist and works (for example on Shape.Items) -- but not for lists (like Shape.Metadata.Alternates) 

Apr 8, 2011 at 5:30 PM

Ah, when you're casting lists out of dynamic / ClaySharp objects like Shape, there are all kinds of strange things going on. I've seen this as well. It's not actually a List<String> you're looking at but a proxy type that behaves like one.

I think there are other threads / workitems relating to the ability to debug dynamic. The best thing you can do right now is to use Shape Tracing to peek into the model but maybe there are other methods I don't know about.

Apr 11, 2011 at 11:48 AM
Edited Apr 11, 2011 at 11:49 AM

This is definitely not related to ClaySharp/AutoFac or dynamics. I can just insert the following line anywhere

var test = new List<string> { "eins", "two", "trois" };

and the debugger does not show the contents on first level as it does on any other non-Orchard project. I have to expand "Non-Public members" and then "_items".

Apr 11, 2011 at 12:41 PM

This is plain strange in that case. I just did a quick test and I can't reproduce this at all (in VWD of course).

Can you give a bit more detail; where exactly are you running the above code? Is it in a Razor view?

There shouldn't really be any way that Orchard could mess the debugger up like this.

Some things you could try:

- Attempt the same debug in an empty MVC 3 application (if you haven't already)

- Install VWD 2010 and see if you get the same problem

- Update to latest Orchard 1.1 (if you haven't already) and see if it's still happening

- Set up a new "clean" Orchard 1.1 instance from default branch, with no additional modules at all, and see if it still happens

- Reformat and reinstall your computer. I know this is an extreme step but failing everything else, there is clearly something corrupted or screwy going on, and without knowing where it is it's hard to say whether just reinstalling VS or clearing all its settings and related registry entries would fix the problem. But reformatting will ensure that you are working on a "blank slate" and it's just a good thing to do now and then; I usually notice a big speed boost whenever I do so in any case. Obviously I won't recommend you do this until you've exhausted all other possibilities, but sometimes it's actually the simplest thing - especially if your installation is a few years old.

Apr 11, 2011 at 1:19 PM

- Where the code is running doesn't change anything: Views, handlers, filters, drivers, services -- everywhere the same.

- Any other existing or new MVC3 application works fine.

- I'm using VS2010Sp1-Professional where VWD (if it means visual web developer) is part of.

- it happens with every Orchard version 1.0, 1.1, anything in between. On clean pulls and on different machines.

Apr 11, 2011 at 2:03 PM

Ok ... I ran the code in the first place I could find that I knew would get executed, in this case the GetNavigation method of an AdminMenu.cs (an INavigationProvider for admin menu). So can I just get you to try it there - although I'm assuming the result will be the same.

When I said VWD, I meant VWD Express, which yes is a subset of full VS2010 features but still a different application. It could be that some advanced feature of VS2010 is conflicting with the debugger and an Orchard component. It's the only real difference between my setup and yours.

Something else on this; I am working in a different solution file than Orchard.sln. I created a new solution because VWD express mangles the VS solution file so the ClickToBuild.cmd doesn't work, and also it pops up a load of messages about "solution folders" not being supported every time I open it.

So can you try creating a new empty solution and then adding the core Orchard projects as well as your own to it. Then debug from there. This tells us if it's somehow something in the main solution file.

BTW; I assume you have checked you are running in Debug build configuration, rather than Release or any other? (This isn't the same as the Web.config debug setting...)

Jun 3, 2011 at 1:56 PM

As today it started to work for the very first time (I'm synchronizing to 1.1 branch every some days) I looked through the changesets and finally found a line which has been commented:

<!--<trust level="Medium" originUrl="" />-->


It was on in the past, and enabling it again just suddenly disables all DebuggerVisualizers.

Jun 3, 2011 at 3:37 PM

Yes, I can confirm debugger visualizers don't run in medium trust. This was documented somewhere in the msnd documentation. As per another thread about debugging performance, we removed medium trust from web.config in the 1.x branch. Note that this doesn't mean we don't support medium trust, it just means it's not "on" by default in environments where it's not required.