StackTrace Line Numbers

[Vlad]

Please consider this code

public class MyClass{
public bool MyMethod1(){
return false;
}
public bool MyMethod2(){
int x=0,y=1/x;
return false;
}
}
If an exception occurs within MyMethod2 the stack trace is going to contain
the line numbers relative to the beginning of the file (in our case line 6).
Is there anyway to change that behavior and show the line numbers relative
to the method declaration (line 1)?
We use CodeDOM to generate the code on a fly and if any exception occurs
within each method it would be much more relevant to get the line numbers
relative to each method.
Thanks!

[Jon Skeet [C# MVP]]

Vlad <RE***************@comcast.net> wrote:

Please consider this code

public class MyClass{
public bool MyMethod1(){
return false;
}
public bool MyMethod2(){
int x=0,y=1/x;
return false;
}
}
If an exception occurs within MyMethod2 the stack trace is going to contain
the line numbers relative to the beginning of the file (in our case line 6).
Is there anyway to change that behavior and show the line numbers relative
to the method declaration (line 1)?
We use CodeDOM to generate the code on a fly and if any exception occurs
within each method it would be much more relevant to get the line numbers
relative to each method.

Yes - you can use the #line directive, eg

#line 1

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jeffrey Tan[MSFT]]

Hi Vlad,

Thank you for posting in the community! My name is Jeffrey, and I will be
assisting you on this issue.

============================================
Yes, just as Jon said, you can use Line directives to specify any line
number for your source code.

For more information about Line directives, please refer to:
http://msdn.microsoft.com/library/de...us/csref/html/
vclrfLine.asp

Hope it helps,

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

[Vlad]

Thanks a lot!
That's exactly what I needed
Vlad
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Vlad <RE***************@comcast.net> wrote:

Please consider this code

public class MyClass{
public bool MyMethod1(){
return false;
}
public bool MyMethod2(){
int x=0,y=1/x;
return false;
}
}
If an exception occurs within MyMethod2 the stack trace is going to contain the line numbers relative to the beginning of the file (in our case line 6). Is there anyway to change that behavior and show the line numbers relative to the method declaration (line 1)?
We use CodeDOM to generate the code on a fly and if any exception occurs
within each method it would be much more relevant to get the line numbers relative to each method.

Yes - you can use the #line directive, eg

#line 1

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jeffrey Tan[MSFT]]

Hi Vlad,

I am glad you got what you want, if you have further concern, please feel
free to tell me, I will work with you.
Thanks

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

[Vlad]

Now sometimes I am getting the following compiler error:
System.ApplicationException: System.ApplicationException: 1 Compile Error:
Line: 43 - Filename specified for #line is too long
Just to show how long the file name is here is the exact line from the code
being compiled:
#line 1 "0w5gekg_.cs:RuleId 5"

The MSDN specifies that this exception could occur of the file name is
longer then 256 characters or the total line length is over 2000 characters
(http://msdn.microsoft.com/library/de...-us/cscomp/htm
l/vcerrCompilerErrorSC1560.asp)
we are using the filename parameter of #line directive to pass extra
information to the compiler.
If I substitute the "_" characters with any other character it seem to work
(i.e. #line 1 "0w5gekgX.cs:RuleId 5". Or if I substitute the ":" characters
with any other character it also seem to work. (#line 1 "0w5gekg_.cs_RuleId
5")
"Vlad" <RE***************@comcast.net> wrote in message
news:OA*************@TK2MSFTNGP12.phx.gbl...

Thanks a lot!
That's exactly what I needed
Vlad
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Vlad <RE***************@comcast.net> wrote:

Please consider this code

public class MyClass{
public bool MyMethod1(){
return false;
}
public bool MyMethod2(){
int x=0,y=1/x;
return false;
}
}
If an exception occurs within MyMethod2 the stack trace is going to contain the line numbers relative to the beginning of the file (in our case line

6).

Is there anyway to change that behavior and show the line numbers relative to the method declaration (line 1)?
We use CodeDOM to generate the code on a fly and if any exception

occurs within each method it would be much more relevant to get the line

numbers relative to each method.

Yes - you can use the #line directive, eg

#line 1

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Vlad <RE***************@comcast.net> wrote:

Now sometimes I am getting the following compiler error:
System.ApplicationException: System.ApplicationException: 1 Compile Error:
Line: 43 - Filename specified for #line is too long
Just to show how long the file name is here is the exact line from the code
being compiled:
#line 1 "0w5gekg_.cs:RuleId 5"

The MSDN specifies that this exception could occur of the file name is
longer then 256 characters or the total line length is over 2000 characters
(http://msdn.microsoft.com/library/de...-us/cscomp/htm
l/vcerrCompilerErrorSC1560.asp)
we are using the filename parameter of #line directive to pass extra
information to the compiler.
If I substitute the "_" characters with any other character it seem to work
(i.e. #line 1 "0w5gekgX.cs:RuleId 5". Or if I substitute the ":" characters
with any other character it also seem to work. (#line 1 "0w5gekg_.cs_RuleId
5")

I'm afraid I don't know much about that - I haven't had to use #line
myself, and I suspect most other people haven't, so I wouldn't be
surprised if there were a few bugs in the compiler in this area.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jeffrey Tan[MSFT]]

Hi Vlad,

Thanks for your furhter feedback! My name is Jeffrey, and I will be
assisting you on this issue.

Based on my understanding, when you use #line with a file name, a "Filename
specified for #line is too long" compile-time error generates.
================================================== ========
I think the error generated because the file name you specified in that
line is invalid.

While there is a known issue that C# compiler will generate misleading
error message text "Filename specified for #line is too long" when the file
name/path is bad.

So I think you should use the valid file name in your code.

================================================== ========
Thank you for your patience and cooperation. If you have any questions or
concerns, please feel free to post it in the group. I am standing by to be
of assistance.

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

[Jeffrey Tan[MSFT]]

Hi Vlad,

Does my reply make sense to you?

If you still have anything unclear, please feel free to tell me.

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

[Vlad]

Hi Jeffrey,

While it "could" make sense, I do not see any mentioning of it in
documentation. All it says is that the file name can be specified as a
parameter to #line directive.

Besides, how can "0w5gekg_.cs:RuleId 5" file name be invalid while
"0w5gekg.cs:RuleId 5" or "0w5gekg_.cs_RuleId 5" are still valid?

The last two both use "_" and ":" character. So if your assumption that it
just finds that the file name is invalid, the "0w5gekg.cs:RuleId 5" would
still produce compile error, but it does not.

It does not matter to me that much so I just generate a different file name
without the ":" in it, but I think it should be addressed by MSFT by either
acknowledging that it is a bug or modifying documentation to reflect that
behaviour.
Thanks,
Vlad
""Jeffrey Tan[MSFT]"" <v-*****@online.microsoft.com> wrote in message
news:Wh*************@cpmsftngxa07.phx.gbl...

Hi Vlad,

Does my reply make sense to you?

If you still have anything unclear, please feel free to tell me.

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

[Jeffrey Tan[MSFT]]

Hi Vlad,

Thanks for your feedback.
I have seen your concern. I will contact the product group for this issue.
I will reply to you ASAP.

Thanks for your understanding.

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

[Jeffrey Tan[MSFT]]

Hi Vlad,

I still did not get useful feedback from product group, please wait for a
little more time.

Thanks for your understanding.

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

[Jeffrey Tan[MSFT]]

Hi Vlad

Sorry for letting you wait for so long time.

I have got the feedback from product group. Actually, this behavior is by
the design of C# compiler.

The C# compiler must sanitize the filename (according to the spec) to
change it from a relative filename to a fully-qualified file+path.
However, it also supports URIs. So first it checks to see if the filename
is a URI using the OS provided API PathIsURL. In the given example the
second filename is a valid URL according to this API. Because it is a URL,
the compiler makes no attempt to sanitize it. That's why the second
filename is OK. The third filename is simply a valid filename with a
really wierd extension that included a space. The first filename is not a
valid URL, and it is not a valid filename (we don't support NTFS stream)
becuase of the ":".

I hope this makes sense to you. If you still have concern, please feel free
to tell me, I will help you.

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

[Vlad]

Thanks a lot for all your help. That's exactly the kind of information I
was looking for. It explains it all and is very valuable information to
have.
Vlad

""Jeffrey Tan[MSFT]"" <v-*****@online.microsoft.com> wrote in message
news:MW**************@cpmsftngxa07.phx.gbl...

Hi Vlad

Sorry for letting you wait for so long time.

I have got the feedback from product group. Actually, this behavior is by
the design of C# compiler.

The C# compiler must sanitize the filename (according to the spec) to
change it from a relative filename to a fully-qualified file+path.
However, it also supports URIs. So first it checks to see if the filename
is a URI using the OS provided API PathIsURL. In the given example the
second filename is a valid URL according to this API. Because it is a URL, the compiler makes no attempt to sanitize it. That's why the second
filename is OK. The third filename is simply a valid filename with a
really wierd extension that included a space. The first filename is not a
valid URL, and it is not a valid filename (we don't support NTFS stream)
becuase of the ":".

I hope this makes sense to you. If you still have concern, please feel free to tell me, I will help you.

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

[Jeffrey Tan[MSFT]]

Hi Vlad,

Thanks for your feedback.

I am glad the information I found makes sense to you. If you have any
further concern, please feel free to post in this group.
I will work with you.

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.