Source code in the runtime error page

[Pavils Jurjans]

Hello,

I have to debug an ASP.NET project which is hosted on the remote server, and
it is not possible to achieve the same environment on localhost. So, I need
to debug on the remote site. Problem with the remote is, that when runtime
error occours, I nicely get the error description, stack trace, but under
the "source error" subheading, instead of the source code with line numbers
and code fragment, I see text "An unhandled exception was generated during
the execution of the current web request. Information regarding the origin
and location of the exception can be identified using the exception stack
trace below."
Is there any way to get the source code fragment on the remote location? I
have put in the "<customErrors mode="Off"/>" section in my web.config file,
perhaps there is some other setting to enable the code fragment? I have
copied both the "pdb" and "cs" files of the codebehind library, where the
error occours. My wild guess is that maybe the ASP.NET process does not have
rights to read the CS file? Though it's kind of unlikely, because it has to
fetch the dlls from there anyway...

Thank you for any clues,

Pavils

 

[Kevin Spencer]

Is the remote application compiled with debug symbols?

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.

 

[Pavils Jurjans]

Is the remote application compiled with debug symbols?

As I said, the pdb file for the buggy library is there. Exactly the same
file set, stored locally, gives me the feature I need - shows the code. When
copiend on the remote, there is no code fragmen in the error information.

Pavils

 

[Kevin Spencer]

I didn't ask if a pdb file was present. I asked if the esxecutable DLL was
compiled with debug symbols. There is a difference. Simply putting a pdb
file into the same directory as an executable DLL doesn't mean that you will
get any debugging information from the app. The DLL must be compiled with
debug symbols, and it must match the pdb.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.

 

[Pavils Jurjans]

I didn't ask if a pdb file was present. I asked if the esxecutable DLL was

compiled with debug symbols. There is a difference. Simply putting a pdb
file into the same directory as an executable DLL doesn't mean that you
will get any debugging information from the app. The DLL must be compiled
with debug symbols, and it must match the pdb.

The DLL what is compiled on my local machine, is compiled with /debug
switch. The same DLL was copied to the remote machine, together with the PDB
file what was created in the compilation.

-- Pavils

 

[Pavils Jurjans]

Ok, I've detected the problem.

The PDB file contains *full path* to the source CS file, so when the error
is intercepted, ASP.NET looks for the source file in that location, and
since the paths on my local machine and remote server differ, then the
application on the remote site fails to find the source file and thus is
unable to show the code fragment with line numbers.

I mirrored the folder structure and matched the drive letter on my local
machine, compiled the lib with the debug symbols, and when I copied the
built PDB file, the remote site was able to retrieve the source code and
show it.

Of course, it's sort of hassle to maintain the project path just like it is
on the remote server. Is there some way to tell the compiler to use some
alternate source code reference path, when building the PDB file?

Pavils