I'm looking at using the line number option in VB.NET so as to better
determine the source of errors. Since I want to use structured error
handling I'd need to use the StackTrace property like this:

        Catch ex As Exception

            MsgBox(ex.StackTrace)

        End Try

to find out exactly what procedure and line # caused the problem.
Since production builds do not offer lines #s, I'd need to compile as
a debug version in order to have this feature and ship the PDB file
along with the app. My question is: Has anyone every tried this
successfully? What kind of performance issues are there? Are these any
other issues with this approach or alternatives that I could use
(other than unstructured error handling)?

Thanks

Carl

Hi Carl,

Enabling debug tracking (by producing a PDB file) lowers performance a
little (I've never been able to see the difference), while disabling code
optimization can lower performance quite a lot. However, I've also seen
examples where code optimization has *decreased* performance.

You can change the release configuration (rather than use the debug
configuration) to produce a PDB file while still keeping the setting that
says optimize the code. Then the released program will produce line numbers,
although optimization can occasionally play some funny games with the line
numbers. I've used this, and never found any problems with it.

Here's a cool trick. Create a file in your application folder called
MyApp.ini (where MyApp is your app name). This ini file can tell the JIT
compiler how to do its JIT compilation, regardless of how the language
compilation was performed. The settings look like this, where 1=true and
0=false:

[.NET Framework Debugging Control]
GenerateTrackingInfo=1
AllowOptimize=0

As long as you ship a matching PDB file, this allows you to decide on your
app's optimization and debug tracking at run-time rather than compile-time.

<plug>
This all comes from part of my upcoming book "Comprehensive VB .NET
Debugging".
</plug>

Regards,

Mark

I'm looking at using the line number option in VB.NET so as to better
determine the source of errors. Since I want to use structured error
handling I'd need to use the StackTrace property like this:

        Catch ex As Exception

            MsgBox(ex.StackTrace)

        End Try

to find out exactly what procedure and line # caused the problem.
Since production builds do not offer lines #s, I'd need to compile as
a debug version in order to have this feature and ship the PDB file
along with the app. My question is: Has anyone every tried this
successfully? What kind of performance issues are there? Are these any
other issues with this approach or alternatives that I could use
(other than unstructured error handling)?

Thanks

Carl