private fields of component show up in debugger

[Guest]

Should private fields of a .NET component show up when debugging the
container application?

Example, I have a field defined as

[NonSerialized]
private bool disposed = false;

When I set a breakpoint in my container app and look at the component's
props/fields list in the debugger, the field 'disposed' is listed.

If I change it to private, it does not show up. Obviously a simple change,
but I'm not clear on the rules.

 

[Guest]

Whoops sorry, disregard the last sentence of my previous post.

If I change it from private to internal, it still shows up in the debugger.

Also forgot to mention, the component is built in VS2003, so the
DebuggerBrowsableAttribute added in .NET FW 2.0 cannot be used.

 

[Peter Duniho]

Should private fields of a .NET component show up when debugging the
container application?

< [...]

The debugger has complete access to your data. The access modifiers apply
to compiled code, not the debugger, and what you're seeing is perfectly
normal.

Pete

 

[Guest]

Pete, thanks for the quick reply.

Two things:

1. I want to confirm that this is true for private and internal fields. It
seems like internal fields of a component should not be visible to the
container.

2. What do you suggest if I have some data that I do not want displayed in
the debugger?

 

[Peter Duniho]

1. I want to confirm that this is true for private and internal fields.
It
seems like internal fields of a component should not be visible to the
container.

Members marked "internal" are visible to any code within the same
assembly. I don't know what you mean by "container", but the debugger
isn't a "container", nor does the "internal" modifier relate to
"containers". If you have code in the same assembly that you still don't
to have access to the field, it has to be marked "private" or
"protected". And of course, "protected" will only work for code that is
not in a class derived from the class trying to hide the field (I assume
that's the case here, but you never know).

2. What do you suggest if I have some data that I do not want displayed
in
the debugger?

I haven't used it myself, but have you looked at the "Debugger..."
attributes? I think DebuggerBrowsableAttribute may do what you want. If
not, you may also have to apply DebuggerDisplayAttribute and/or
DebuggerHiddenAttribute.

Keep in mind that, AFAIK, these attributes are simply for the debugger's
reference. They will work in Visual Studio, but there's probably no
requirement that a debugger observe the attribute and comply with it. If
you are literally trying to prevent all access via a debugger to your
class data, you'll have to have a different mechanism (for example, not
providing the .pdb file to people looking at your code ).

Pete

 

[Guest]

Members marked "internal" are visible to any code within the same

assembly. I don't know what you mean by "container", but the debugger
isn't a "container", nor does the "internal" modifier relate to
"containers". If you have code in the same assembly that you still don't
to have access to the field, it has to be marked "private" or
"protected". And of course, "protected" will only work for code that is
not in a class derived from the class trying to hide the field (I assume
that's the case here, but you never know).

I'm authoring a component based on system.componentmodel and I'm testing the
component in a console application. The component is in a seperate assembly
than the console app. When I referred to container, I was talking about the
console app.

When I place a breakpoint in my console app and examine the contents of my
component I see fields that are declared as private and internal in the
component.

I haven't used it myself, but have you looked at the "Debugger..."
attributes? I think DebuggerBrowsableAttribute may do what you want. If
not, you may also have to apply DebuggerDisplayAttribute and/or
DebuggerHiddenAttribute.

DebuggerBrowsableAttribute is only available to .NET FW 2.0. My component
requires .NET FW 1.1.

 

[Peter Duniho]

[...]
When I place a breakpoint in my console app and examine the contents of
my
component I see fields that are declared as private and internal in the
component.

As I said, the debugger is not affected by the access modifiers. Fields
marked "private", "protected", and "internal" should not be visible to the
code in the console application (based on your statement that it's a
different assembly, and the implication that it's not derived from your
class), but that doesn't mean you won't see them in the debugger, assuming
you have symbols loaded for the component.

DebuggerBrowsableAttribute is only available to .NET FW 2.0. My component
requires .NET FW 1.1.

Then your only option is to not load the symbols for your assembly, if you
don't want the fields visible in the debugger (and by "visible" I mean
using the source-level tools...the debugger will _always_ be able to show
the data at some level).

Pete

 

[Steven Cheng[MSFT]]

Hi Hairlip,

I think Pete's explanation is reasonable. For the accessor of class(such as
private, protected, public), they will restrict the accessibility of class
members in program(from other classes in same assembly or from other
assemblies). However, debugger is not restricted by these accessors. The
debugging tools will directly inspect the runtime program's memory to get
the execution data structure and contents of the application being debuged.
And as long as the program (being debuged) provide the necessary metadata
and symbols, the debugging tools can inspect into each data
member/variables in the program. Here when you debugging the console
application(and also the referenced class library assembly), the VS IDE can
get the symbols, so all the variables is available in debugger.

here are some information about symbols and debugging:

http://www.microsoft.com/whdc/devtools/debugging/debugstart.mspx

http://www.codeproject.com/useritems/symbols.asp

Anyway, if what you worry about is only the debugger, you can think it
completely different from the container application since whether container
application can see the referenced class library assembly's internal data
or not is determined at compile/build time(according to the member accessor
).

If you still have any question on this, please feel free to post here.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Guest]

Sorry, but its still not clear to me, so let me re-phrase.

How can I prevent the debugger from displaying private variables in my
component?

The scenario that I'm concerned about is when a customer references my
component from their console application and uses the debugger to debug their
console app. Private variables in my component might contain licensing info,
etc. and I do not want the customer to see it.

I do not ship any files that contain debug info on the target system, so I
don't believe that I'm explicitly supplying metadata and debug symbols.

The links that you included talk about adding debugging capability.

 

[Peter Duniho]

Sorry, but its still not clear to me, so let me re-phrase.

How can I prevent the debugger from displaying private variables in my
component?

The only way to do this is to not provide the symbol for the private
variable in the first place.

The scenario that I'm concerned about is when a customer references my
component from their console application and uses the debugger to debug
their
console app. Private variables in my component might contain licensing
info,
etc. and I do not want the customer to see it.

Then you must not include information in your component that would reveal
that information.

I do not ship any files that contain debug info on the target system, so
I
don't believe that I'm explicitly supplying metadata and debug symbols.

You may not explicitly be doing it, but obviously you are doing it somehow.

I admit, I'm not that familiar with the mechanisms that a .NET debugger
might use to get at this sort of thing. However, I do note that I think
things like reflection are available without symbols so while leaving out
symbol information may be sufficient to hide code and declarations, a
debugger may still be able to display data structures using only
reflection.

I have heard of, but not used, something called "obfuscation" in the
context of .NET. I gather it does what the word implies: obfuscate your
code. I have the impression it is as much about rearranging the code
itself to make it harder to reverse engineer, but perhaps it also
obfuscates the data structures as well. You might want to look into that.

Keep in mind that no matter what you do, at some level your data
structures will always be visible to a debugger. You can make it harder
for someone to inspect them, but there's no way to make it impossible.

Pete

 

[Steven Cheng[MSFT]]

Hi Hairlip,

Thanks for your reply.

I'm afraid there is no definite means to prevent debugger from getting the
private members of the classes in your assemblies(Even VS debugger can let
you configure this, other debuggers still can view it if they want).
Actually, you can use the reflector tools to open any .NET managed
assmblies and inspect the class members(public or private ), correct? This
has also indicated this. Actually, managed application's nature (has rich
metadata that describe the program and data's structure...) make debuger or
disassemble tools very easy to inspect the code. If you do want to hide
such info, what you need is some code protection/obfuscate tools as Pete
has suggested. Here are some web reference mentioned such tools

#How-To-Select an Obfuscation Tool for .NET
http://www.howtoselectguides.com/dotnet/obfuscators/

#Code protection - Obfuscation
http://sharptoolbox.com/categories/code-protectors-obfuscators

and VS 2005 Team suite has provided the Dotfuscator Community Edition:

#Dotfuscator Community Edition 3.0
http://msdn2.microsoft.com/en-us/library/ms227240(VS.80).aspx

Anyway, debugging tools will never take care of those "public" or "private"
accessors(only compiler will take care of them). As long as data are in
memory and hasn't been obfuscated, debugger can watch them out.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.