views:

34

answers:

3

When I inspect an object in the debugger, I see a lot more properties in the debugger than what is available in Intellisense or code.

For example, the Page object in ASP.NET in the debugger shows a property RelativeFilePath which has a value. But when I try to use it in code, it doesn't exist. Why is that?

I looked up the property RelativeFilePath in MSDN, it exists for mobile controls. Not sure why it shows up then in the debugger for a regular asp.net control.

A: 

There are several attributes that can be attached to a type for better debugging support. Perhaps one of these is what you're seeing?

http://msdn.microsoft.com/en-us/library/ms228992.aspx

Scott Bilas
A: 

I'm guessing it's because it's a protected or private property tht you don't have access to. You can't use it in code for that reason, but you can see it in the debugger.

AHungerArtist
+2  A: 

The debugger and intellisense have very different goals in terms of what they want to display.

Intellisense is trying to provide the set of members which can be validly invoked on the object. Essentially accessible members and extension methods. The goal here is to help guide the user to writing valid code.

The debugger is trying to provide inspection on the runtime state of an object. It cares little about accessibility and instead puts all relative information up for display. It even allows for customization of the display by user extensions. This means you will often see members which simply don't exist on the object or are inaccessible from user code.

The latter comes into play for your scenario. The Page type does indeed have a RelativeFilePath property. But it is internal which is inaccessible to your code and hence Intellisense doesn't display it. The debugger does not consider accessibility for member display and hence provides the value.

JaredPar