__LINE__
-
In C++ we have a macro __LINE__ that can be used to report what line of source code we are on. Is there a way to do this in C#?
-
In C++ we have a macro __LINE__ that can be used to report what line of source code we are on. Is there a way to do this in C#?
I found this: CodeLinePragma clp = new CodeLinePragma("Service1.cp",188); but it doesn't seem to keep up with the line number... it just reports back whatever I initialize it with.
-
I found this: CodeLinePragma clp = new CodeLinePragma("Service1.cp",188); but it doesn't seem to keep up with the line number... it just reports back whatever I initialize it with.
That's just the CodeDom class that represents the
#linepreproc instruction, mostly used in debugging and error/warning reporting during compilation, if one was to strip the lines for some stupid reason. What do you need something like this for? If it's for debugging purposes, exceptions will already contain line numbers for assemblies compiled with debugging information. When doing release builds (i.e., DEBUG is not defined), this information is stripped. If you're doing it for some kind of logging, I don't know what to tell you. csc.exe doesn't doing anything like that based on the documentation. If using VS.NET 2003, you could have a pre-build step that runs a macro to replace some line with the line number (I would think that would be available through the scripting object model in VS.NET).-----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++ -----END GEEK CODE BLOCK-----
-
That's just the CodeDom class that represents the
#linepreproc instruction, mostly used in debugging and error/warning reporting during compilation, if one was to strip the lines for some stupid reason. What do you need something like this for? If it's for debugging purposes, exceptions will already contain line numbers for assemblies compiled with debugging information. When doing release builds (i.e., DEBUG is not defined), this information is stripped. If you're doing it for some kind of logging, I don't know what to tell you. csc.exe doesn't doing anything like that based on the documentation. If using VS.NET 2003, you could have a pre-build step that runs a macro to replace some line with the line number (I would think that would be available through the scripting object model in VS.NET).-----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++ -----END GEEK CODE BLOCK-----
Thank you for your reply! I'm currently working on some services and I'm not seeing the line number when I catch an exception. Maybe it's because I handled the exception - by exiting my service but this is an example of what my exception reports: System.Data.SqlClient.SqlException: SHUTDOWN is in progress. Log off. at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream) at System.Data.SqlClient.SqlCommand.System.Data.IDbCommand.ExecuteReader(CommandBehavior behavior) at System.Data.Common.DbDataAdapter.Fill(Object data, Int32 startRecord, Int32 maxRecords, String srcTable, IDbCommand command, CommandBehavior behavior) at System.Data.Common.DbDataAdapter.Fill(DataSet dataSet, Int32 startRecord, Int32 maxRecords, String srcTable, IDbCommand command, CommandBehavior behavior) at System.Data.Common.DbDataAdapter.Fill(DataSet dataSet, String srcTable) at GetAcc.GetAcc.timer1_Elapsed(Object sender, ElapsedEventArgs e) I want the line number so I know where (which exception trap) trapped the error. In a case like the example above (depending on what step I'm in in my process) I may be able to keep my service alive until the SQL server is available again. I have found that I can use Environment.StackTrace which gives more info... but does include the line number. So I'm adding that to my message that I log to a file.
-
Thank you for your reply! I'm currently working on some services and I'm not seeing the line number when I catch an exception. Maybe it's because I handled the exception - by exiting my service but this is an example of what my exception reports: System.Data.SqlClient.SqlException: SHUTDOWN is in progress. Log off. at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream) at System.Data.SqlClient.SqlCommand.System.Data.IDbCommand.ExecuteReader(CommandBehavior behavior) at System.Data.Common.DbDataAdapter.Fill(Object data, Int32 startRecord, Int32 maxRecords, String srcTable, IDbCommand command, CommandBehavior behavior) at System.Data.Common.DbDataAdapter.Fill(DataSet dataSet, Int32 startRecord, Int32 maxRecords, String srcTable, IDbCommand command, CommandBehavior behavior) at System.Data.Common.DbDataAdapter.Fill(DataSet dataSet, String srcTable) at GetAcc.GetAcc.timer1_Elapsed(Object sender, ElapsedEventArgs e) I want the line number so I know where (which exception trap) trapped the error. In a case like the example above (depending on what step I'm in in my process) I may be able to keep my service alive until the SQL server is available again. I have found that I can use Environment.StackTrace which gives more info... but does include the line number. So I'm adding that to my message that I log to a file.
If you do a debug build, you should get line numbers for your assemblies (.NET BCL assemblies obviously aren't debug assemblies). I take it you're testing this with a release build? You also have to use the same path for the PDB files (debug files) that were created when you compiled. That contains the information. If you switch to a different machine (unless you keep the path to the copied PDB files the same), you don't see this. Does that ring a bell at all?
-----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++ -----END GEEK CODE BLOCK-----
-
That's just the CodeDom class that represents the
#linepreproc instruction, mostly used in debugging and error/warning reporting during compilation, if one was to strip the lines for some stupid reason. What do you need something like this for? If it's for debugging purposes, exceptions will already contain line numbers for assemblies compiled with debugging information. When doing release builds (i.e., DEBUG is not defined), this information is stripped. If you're doing it for some kind of logging, I don't know what to tell you. csc.exe doesn't doing anything like that based on the documentation. If using VS.NET 2003, you could have a pre-build step that runs a macro to replace some line with the line number (I would think that would be available through the scripting object model in VS.NET).-----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++ -----END GEEK CODE BLOCK-----
Heath Stewart wrote: What do you need something like this for? If it's for debugging purposes, exceptions will already contain line numbers for assemblies compiled with debugging information. When doing release builds (i.e., DEBUG is not defined), this information is stripped. If one generated some code from some other source, its allways helpful to make #line references. Think lex & yacc for example :) leppie::AllocCPArticle("Zee blog");
Seen on my Campus BBS: Linux is free...coz no-one wants to pay for it. -
That's just the CodeDom class that represents the
#linepreproc instruction, mostly used in debugging and error/warning reporting during compilation, if one was to strip the lines for some stupid reason. What do you need something like this for? If it's for debugging purposes, exceptions will already contain line numbers for assemblies compiled with debugging information. When doing release builds (i.e., DEBUG is not defined), this information is stripped. If you're doing it for some kind of logging, I don't know what to tell you. csc.exe doesn't doing anything like that based on the documentation. If using VS.NET 2003, you could have a pre-build step that runs a macro to replace some line with the line number (I would think that would be available through the scripting object model in VS.NET).-----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++ -----END GEEK CODE BLOCK-----
Heath Stewart wrote: if one was to strip the lines for some stupid reason. One place this is done is in ASP.NET code that's embedded in the page. ;)
**"Love does not delight in evil but rejoices with the truth." -- 1 Corinthians 13:6
-
If you do a debug build, you should get line numbers for your assemblies (.NET BCL assemblies obviously aren't debug assemblies). I take it you're testing this with a release build? You also have to use the same path for the PDB files (debug files) that were created when you compiled. That contains the information. If you switch to a different machine (unless you keep the path to the copied PDB files the same), you don't see this. Does that ring a bell at all?
-----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++ -----END GEEK CODE BLOCK-----
Oh... ok I am using debug builds... but I have not copied PDB file to the production machine. When I tested Environment.StackTrace I was on my development machine. I bet I won't get line numbers from that either on the production machine. Thanks again!