Whats the equivalent of __LINE__ and __FILE__ in C#


  • Whats the equivalent of __LINE__ and __FILE__ in C#? I thought this hot-button issue would have been answered by now. But no one seems to have a good answer for this. I would love to see a solution which presents no runtime overhead. What about C# 3.0 does it address this issue?
    Friday, February 23, 2007 11:47 AM


All replies

  • If you want to use it for exception handling you can find the filename and line number in the the StackTrace property of the exception:


    Friday, February 23, 2007 2:14 PM
  • What did _LINE_ and _FILE_ do? are they from c++?
    Friday, February 23, 2007 5:22 PM
  • They are instructions to the compiler to replace these "constants" with de line number and filename at the place where the compiler finds these constants. Sort of a compiler directive. Usefull for debugging. Personaly I don't think they have much use in c#.
    Saturday, February 24, 2007 3:43 PM
  • Thanks for your response. When you say they are useful for debugging but don't have much use in C# do you mean ...

    1) C# doesn't need (much) debugging?
    2) There are alternatives to using __LINE__ and __FILE__. If yes then how do I generate logs from my C# code which provide source line no and source file information?

    PS: My initial conditions still stand - no runtime overhead please. For example please don't suggest stack walking (in any case the required info is available only in debug builds)
    Monday, February 26, 2007 6:48 AM
  • You can't do it. End of story, I'm afraid.

    Monday, February 26, 2007 10:44 AM
  • Of course C# needs debugging. But the tools the tools are good enough that you don't have to find the line number or file yourself. Why is the info that importend to you?
    Monday, February 26, 2007 10:57 AM
  • This is important to me because I am interested in logging the path of execution that my program takes. For example the entry and exit points of important functions, exception information etc should get logged to a file. Such information will prove invaluable while remotely troubleshooting problems. All I need to do is ask the user to return the collected log. Reading the logs should give me a good lead on the problem.

    Without the line numbers and the source file names I surely would have a hard time mapping the log records to the point of origin in the source code. Also the "mapping" cannot be automated.

    By the way - can you take minidumps of C# applications and then debug them using .Net Debuggers (say VS2005)?

    I would have raised this as a bug against C#!! But I think its up to the developers of C# to decide what goes and does not go into the language. If any body from the C# team is listening please consider this as a request. I think it wont cost you much to add this feature (in terms of runtime costs as well as implementation costs)
    Monday, February 26, 2007 11:33 AM
  • If you want to log exception information then the exception itself should give you enough inormation. I think that if you want to use fault logging then you'd best use the System.Diagnostics namespace. Don't worry about the overhead. It's not that much and if you'ld only use for fault logging it doesn't really matter that it takes a little bit more time. Because the clr is a virtual machine, there's enough information you can query when thinks go wrong. In that case querying the stack is not such a bad idea.
    Monday, February 26, 2007 3:13 PM

  • string currentFile=new System.Diagnostics.StackTrace(true).GetFrame(0).GetFileName(); 
    int currentLine = new System.Diagnostics.StackTrace(true).GetFrame(0).GetFileLineNumber();  
    • Proposed as answer by Igor Lankin Wednesday, July 02, 2008 11:15 AM
    • Edited by Igor Lankin Wednesday, July 02, 2008 11:20 AM Added code for getting the line number
    Wednesday, July 02, 2008 11:15 AM
  • Igor Lankin said:

    string currentFile=new System.Diagnostics.StackTrace(true).GetFrame(0).GetFileName(); 
    int currentLine = new System.Diagnostics.StackTrace(true).GetFrame(0).GetFileLineNumber();  

    We recently got burned by this, it will work wonderfully if you build in debug, but will throw an exception if you build "release". Avoid, or ensure that you always deploy debug or turn this off in release. It would be nice to be able to do this as a precompiler step (like __FILE__ and __LINE__ in cpp) but oh well.
    Tuesday, February 03, 2009 6:00 PM
  • Catch your exception (e below), and use the following:

    "Exception.. type:"


    + e.GetType().ToString()


    " message: " + e.Message + " trace: " + e.StackTrace

    I believe your stack trace will have what you seek, along with other goodies.

    Monday, March 22, 2010 1:33 PM
  • If there is no useful application for __line__, then perhaps you can provide an alternate strategy for me.

    I have a number of unit tests that each generate some output files. Instead of repeating the lines of code that check for file existence, I'd like to collect the FilesExist() code into a single routine that does the asserts. However, I've found that when one of the files fails to exist, I get a message indicating an assertion fail for the line of the shared code, it then takes a bit of to-and-fro to learn which Unit Test called FilesExist(). To get around this, I change my FilesExist() function to add a single id parameter that identifies where I invoked the shared code that made the assertion. I sure wish I could use __line__, but if you've got something equivalent/better, i'm all ears.

    Generally, when someone wants something odd, it's to do something illicit. But I don't think there's anything wrong with writing unit tests in such a way that they minimize code duplication. But when I do an assert, it's awfully nice to see exactly where the problem originated.

    Wednesday, June 02, 2010 3:53 AM
  • However, I've found that when one of the files fails to exist, I get a message indicating an assertion fail for the line of the shared code, it then takes a bit of to-and-fro to learn which Unit Test called FilesExist().

    Isn't the StackTrace sufficient?
    Wednesday, June 02, 2010 8:01 AM
  • The assertion fail throws an exception caught by NUnit. I don't see the stack trace. It's part of that to-and-fro I'm trying to skip. Where I'm looking is at the message that I've coded for the assertion. Though I'd prefer to see the __line__, i'd settle for the name of the calling routine. But I can imagine where Unit Test "X" has two places where it calls shared code, and I'd prefer __line__ for those times.

    Wednesday, June 02, 2010 2:39 PM