5

I've created a DLL with a Class Library Project with some classes. While adding this DLL as a reference in another projects and debugging, when going step by step or when the class returns an Exception the code from the class is shown.

How can I hide this? I want the exception to be shown on the class instruction, not inside and allowing to see al the code. And when debugging by steps, I want to do the methods without steping inside the code of the method.

Just like if you step through str.Split(), for example. You don't see the code and all the steps. You just see the error on that line or jumps to the next one.

For example:

Dim myObj As New myClass.SomeObj()

myObj.MyMethod()

I do not want the code inside MyMethod to be shown.

SysDragon
  • 9,692
  • 15
  • 60
  • 89

2 Answers2

4

Add on the specified method a DebuggerStepThrough attribute to prevent step into. If an exception occures, the debugger breaks at the method call, not inside the method. See MSDN

CodeTherapist
  • 2,776
  • 14
  • 24
  • There are a lot of classes with a lot of methods. Should I add this to each one? One by one? Maybe there is a more general option? – SysDragon Jul 05 '13 at 08:19
  • Yes. You can set the attribute on your class directly. – CodeTherapist Jul 05 '13 at 08:20
  • Tested it. Works perfect, even with the entire class, thank you. I will keep in mind this possibility althought I prefer in this case the Code Gray solution. +1 – SysDragon Jul 05 '13 at 08:41
  • I actually prefer this solution and wish something similar was available for the native C++ debugger... :-) But confusingly, you've mentioned the `DebuggerStepThrough` attribute and linked to the docs for the `DebuggerNonUserCode` attribute. – Cody Gray - on strike Jul 05 '13 at 08:43
  • Why do you think is better to add this on every class instead of disabling the debug symbols? – SysDragon Jul 05 '13 at 08:52
  • 1
    Link is now correct thanks, sorry. The `DebuggerNonUserCode` is more restrictive. The debug symbols can give you more inforamtion when an exception is thrown. So, if you disabling it, you get less details. – CodeTherapist Jul 05 '13 at 08:56
  • So I'm going to use this solution instead and, @CodyGray, if you don't mind, I'm going to mark this answer as correct. – SysDragon Jul 05 '13 at 09:20
2

The behavior you describe is a convenience. It allows the caller to see exactly what is going wrong by looking at the details of the code he's trying to consume. Microsoft even supports this for the .NET Framework source, and it's rather useful in my opinion. I'm not really sure why you'd want to disable it. You can always just use F10 (Step Over) instead of F11 (Step Into) when debugging so that the DLL's code remains available in case you ever need it.

But if you are sure that you don't want to be able to step into any code from the DLL, you need to make sure that the debug symbols are not available to the client application. Visual Studio generates these symbols in the form of a PDB file, which contains the location of the source files and mappings between the generated code and the source lines.

Contrary to some of the other answers, the generation of debug symbols is unrelated to whether the code is optimized (e.g., a "Release" build). I've written about this before in the context of why you might want symbols for an optimized build, but the point is that these are two orthogonal settings. You can turn on optimization and turn off symbol generation, and vice versa. Suffice it to say that I strongly recommend generating debug symbols for all builds.

You can disable the generation of debug symbols in the project's properties (it's hidden under the "Advanced..." button), or you can just move the PDB files to ensure that the client application cannot locate them when debugging. By default, a build places them into the same directory as the binary output, so that when you add a reference to the DLL, Visual Studio finds them easily. If you move either the symbols or the binaries, it won't be able to find them. (The debugger also searches the symbol path, but your symbols probably won't end up there.)

Community
  • 1
  • 1
Cody Gray - on strike
  • 239,200
  • 50
  • 490
  • 574
  • The dll file I was using was without the .pbd files, copying the dll alone to the new project folder. It seems that it looks somewhat for the .pdb files of the original Library Project or something. Anyway, setting the Library Project to not generaing the debug symbols worked just as I wanted. Thank you very much and thank you for your suggestions. – SysDragon Jul 05 '13 at 08:31
  • 1
    @SysDragon Hmm yeah, come to think of it, I think that when a build is set to generate symbols, it actually writes the path to the symbol path into the binary output. Trivial to break this relationship, of course, if you still want symbols to be available. – Cody Gray - on strike Jul 05 '13 at 08:33