Programatically Get Error Line numbers for debug.

  • Thread starter Thread starter Ravi, Dallas, Texas
  • Start date Start date
R

Ravi, Dallas, Texas

http://www.netnewsgroups.net/group/microsoft.public.dotnet.framework.aspnet/topic22503.aspx
shows ways to get errors in a server context.

i am trying to find ways to trap the line number where the code is
failing in try catch set up. if i hard code the line number by
looking at the IDE's editor, it will be soon out of date when i start
modifying the code as needed.

i want to let the users know on which line the application failed. if
it some form of a function, then i will greatly benefit from it.

thanks and regards
Ravi.
 
http://www.netnewsgroups.net/group/microsoft.public.dotnet.framework....
shows ways to get errors in a server context.

i am trying to find ways to trap the line number where the code is
failing in try catch set up. if i hard code the line number by
looking at the IDE's editor, it will be soon out of date when i start
modifying the code as needed.

i want to let the users know on which line the application failed. if
it some form of a function, then i will greatly benefit from it.

thanks and regards
Ravi.
Click to expand...

This may not be pretty but one way to do it is to ship pdb files with
your app. They're generated by default in debug mode but can be
generated for release mode as well (project properties - build -
generate debugging information).

The stack trace will have line numbers if the pdb files in colocated
with the app.
 
Not sure I understand what you mean by "it will soon be out of date when I
start modifying the code...". If you modify the code, you need to recompile
your assembliies, and so the .pdb file associated with each will be
automatically updated.

Make sure your release build configuration generates .pdb files, and deploy
those with the asembly. When an exception is caught, the StackTrace property
will give you an accurate listing of the exact line numbers, method names and
so on. You can present this information to the user, or you can log it to a
database so it can be looked up.
-- Peter
Recursion: see Recursion
site: http://www.eggheadcafe.com
unBlog: http://petesbloggerama.blogspot.com
BlogMetaFinder: http://www.blogmetafinder.com
 
Arnshea and Peter,

thanks for the clarification. I understand that .pdb files need to be
packaged with the executables at the time of deployment. i work in
always 'full' updates environment - so i can silently package my .pdb
files in .msi packages without raising too many eyebrows by the
deployment team.

i will figure it out. i might be doing it right now - but i need to
confirm and test to be sure that i am packaging those files.

thanks for your time,

regards
Ravi,
 
Arnshea and Peter,

thanks for the clarification. I understand that .pdb files need to be
packaged with the executables at the time of deployment. i work in
always 'full' updates environment - so i can silently package my .pdb
files in .msi packages without raising too many eyebrows by the
deployment team.

i will figure it out. i might be doing it right now - but i need to
confirm and test to be sure that i am packaging those files.

thanks for your time,

regards
Ravi,
Click to expand...

One other thing - if you ship it with PDB files it will also print out
the path of the source file (e.g. C:\MySource\MyClass.cs) alongside the
line number. A lot of people think this looks a little crude.

The only way I ever found to remove these paths was to parse through the
Exception.ToString() method and remove anything that looked a bit like a
path before I outputted the error - not ideal, but it worked.

If anyone knows any other ways - please let me know!! I spent hours
looking into this, but could never find anything.

Cheers,

RB.
 
Back
Top