8

Possible Duplicate:
Generating .NET crash dumps automatically
include line numbers in stack trace without pdb?

Currently I have a .NET Windows application and I don't deploy the pdb files with it. If a client gets an exception I display it in nice window with the stack trace so they can email it to me. I am considering deploying the pdb files also so I get line numbers in the stack trace.

Now I am wondering if there is a better way. The pdb files will roughly double the size of my install, which I don't like. Is there a way to catch an exception and maybe create some kind of dump file that the user could sent to me and then I could debug that information and retrieve the line number?

If there's no common easy way to do this then I'll just deploy the pdb files and be done with it.

Community
  • 1
  • 1
Jeff Stock
  • 3,796
  • 12
  • 46
  • 61
  • 1
    If you need the line numbers and not just stack traces, your methods don't follow good software design. :) – bzlm Nov 01 '11 at 16:27
  • I haven't used it personally as it seemed to be more geared for client deployments, but there is a commercial product available that might be suitable: http://exceptioneer.com/Public/WhatIsExceptioneer.aspx whether this offers more than emailing a stack trace I am not sure. – Chris Marisic Nov 01 '11 at 16:29
  • 3
    I agree with @bzlm, but I think deploying the PDB files is a simple interim solution. – neontapir Nov 01 '11 at 16:30
  • 1
    The line numbers you'll get are not reliable, the jitter optimizer will be enabled and it moves code around. Assuming you are unaware of this, you are probably better off without them, given that they'll have a knack for steering you in the wrong direction. – Hans Passant Nov 01 '11 at 16:40
  • 5
    @blzm - Good software design doesn't have anything to do with knowing the line number of an exception. The exception happens in a method that has 20 lines (good software practice) without the line number I have a lot more work to do to figure out what went wrong. The more info you have to diagnose a problem the better. – Scott Wylie Nov 01 '11 at 16:48
  • 1
    @HansPassant - Can you explain why they are not reliable? I have been deploying pdb's for a WinForms app for 2 years (big internal app) and almost never have been steered wrong by the line numbers in the stack trace. When I have it is due to the user having an older version of the main line code base than I but I have info in TFS history. – Scott Wylie Nov 01 '11 at 16:50
  • @Scott - I'll defer to your experience with it. You are not shipping the Debug build are you? – Hans Passant Nov 01 '11 at 17:01
  • @HansPassant - Since it is entirely internal, it was deemed ok to deploy the pdb's and it has help countless times. I would agree if it were external or a commercial type application you should really carefully consider deploying them. – Scott Wylie Nov 01 '11 at 17:12
  • @ScottWylie, spell my name right next time. Let the auto-completion work for you. :) – bzlm Nov 01 '11 at 17:18
  • Having the stack trace is great and a good way to debug an exception. If I deploy the pdb files with my executables it gives me the line numbers in the stack trace. Having this feature is far better than not having it, so I think I'm going to deploy the PDB files. Having the line numbers has saved me on a few occasions. I don't understand why people think this is bad software design. – Jeff Stock Nov 01 '11 at 17:35
  • Please check the accepted answer to [this question][1]. [1]: http://stackoverflow.com/questions/1328836/include-line-numbers-in-stack-trace-without-pdb – HTTP 410 Nov 01 '11 at 18:39

0 Answers0