I've made some Visual Studio debugger visualizers for classes not related to NHibernate, and initially hoped I could create some for our entity classes. Unfortunately, the whole Visual Studio debugger visualizer model appears to be at odds with lazy loading.

Has anyone else even attempted to create debugger visualizers for their entity classes (or other classes acting as entity containers)? If so, what were your successes and failures?

For those not familiar with debugger visualizers, starting with VS 2005 you can create your own visualizers for classes. When an obect assignable to the class type appears in any of the debugger display windows (Autos, Locals, Watch), a magnifying glass dropdown icon appears in the object's Value grid column, and clicking it will open your custom UI to view the object's state in a convenient way. Unfortunately, for "security reasons" they are forced to run in a separate AppDomain, and the object being displayed in the visualizer (or some proxy for it that you provide) is serialized/deserialized across AppDomain boundaries. This means that either properties that need lazy loading will throw exceptions, or all of the entity's properties accessed by the visualizer must be recursively initialized before passing it for serialization. Neither approach appears to be of much value to us. To be useful, we want the ability to visually mark properties needing lazy-loading in some way in the visualizer, and allow the user to click something near where the value normally displays to force the lazy-load to occur if they need to see the value.

BTW, in Visual Studio's standard display of object values (in the Autos, Locals or Watch windows), sometimes I see values greyed out with a refresh icon whose tooltip says something like "this property causes side effects and will not be displayed." If you click the refresh icon, it forces it to evaluate. However, I can't figure out how it decides that side effects will occur. It would be great if properties could be marked with some custom attribute to indicate that its getter can cause side effects, but I can't find any such attribute.

Even if that were possible, though, the best option would be if a boolean method/field/property name could be specified with such a custom attribute that could be used indicates if side effects will occur on the property's next access. Then the debugger could check that value and if false, just go ahead and display it.