 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / New Users / July 2007private fields of component show up in debugger
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. 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. > 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 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? > 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 > Members marked "internal" are visible to any code within the same > assembly. I don't know what you mean by "container", but the debugger [quoted text clipped - 4 lines] > 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. > [...] > 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 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. 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. > Hi Hairlip, > [quoted text clipped - 31 lines] > > This posting is provided "AS IS" with no warranties, and confers no rights. > 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 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.
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.