Line numbers missing from error list - Visual Studio 2005

The line number information is based on the configuration for the project (Debug/Release), and whether the .pdb file exists for the project.

Bob

Bob,

I am aware of the project configuration and pdb aspects of the debugger.  Here is a more complete description of my issue. (this is what I posted to an MSDN forum and am still waiting for input on):
======================
I've recently run into a problem with the debugger and have spent several hours trying to understand & resolve the problem, with no luck.  The setup:

Visual Studio 2005 SP1
Windows XP SP2
.NET 2.0
ASP.NET application
Configuration in DEBUG mode
I've been working on this project for several months, but this problem started in the last couple of days.  When I have an unsuccessful build / build errors, the error list no longer displays information in the file, line, column and project columns.  I cannot jump to the location to fix the problem by double-clicking the line in the error list.  This is driving me crazy.

I tried deleting the ASP.NET temp sub-folder related to this project, but that didn't fix the problem.  I also tried creating a new solution with my web application and related assemblies, but that didn't help either.  The detailed build output does not list any errors related to symbols [pdb].
===================
So, in a nutshell:
- This is a web application in debug mode
- Debugging works correctly in other applications (both web apps and DLL projects)
- Debugging used to work correctly in this application

What specific, concrete steps can I take to fix this problem?

Thanks,

Mike
 

I have other web projects which are not affected by this problem, so I don't think it's a problem with the VS installation.

And, can I assume that you still have this line in the web.config file?

    <compilation debug="true">

Bob

Your assumption is correct.

Mike

Actually, with the web site model, the PDB file is only generated for the precompiled option.  I am wondering if it gets created in the temporary ASP.NET folder when you compile the web site?

Bob

Bob,

I tried deleting the temporary ASP.NET folder before rebuilding, but that did not solve the problem.  I'm not sure how Visual Studio handles symbol files with web applications.

Mike

I didn't mean delete it, I meant to look into the folder and see if a .pdb file exists.

Example:
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\linx.businessobjects.operation.testweb\9ea4e21e\54cb5f78\app_web_nwgmqeoq.pdb

Bob

I did a compile this morning.  Two .pdb files were created in the temp folder; one for app_code and one for global.asax.  There were no files beginning with "app_web".

Mike

In that folder, is there a file that has the .cmdline extension?

Example:
   My file = fq_ge0mq.cmdline has this entry:
         /D:DEBUG /debug+

I know that you said that it was in Debug configuration, but is that really how the web site is compiled?

Bob

There are 29 files with a .cmdline extension.  The first one that I opened had the debug entry (and syntax) you mentioned.

Also, it seems my last comment about no app_web files was not quite accurate.  I was doing a release build this morning, and at that time there were no app_web files in the folder.  But in response to your last post I did a debug build, and in fact a slew of app_web_xxx.dll and .pdb files were created.

And thanks for your ongoing interest in helping me to solve this problem.  :)

Mike

Bob,

It might have been unclear from my last comment... I am seeing app_web DLLs and PDBs, but my problem still exists.

Thanks,

Mike

I've finally found the problem and the solution, with the help of the development team at Microsoft.

My web application had open and close parens in the path; this is what was fouling things up.  It's a known bug (also, the pound symbol - "#").  Once I renamed my web directory without these characters, I was able to build as expected.

Thanks,

Mike

Awesome, good to know.  I will probably forget about it in the future, but even if I don't it is still good knowledge.

Bob