I was helping one of the developers on our team with an interesting little debugging issue in Visual Studio .NET today. I thought I share it with my readers (all 3 of you).
One of our developers came up to me today and said he was having an issue with a breakpoint not hitting. This particular situation involved a main web project alongside a class library project under one solution. He was setting a breakpoint in the class project and sure enough it wasn’t firing. These are always fun ones to figure out, so I go through my standard questions for debugging web applications:
1.) Are you compiling in Debug or Release mode?
2.) Does the web config have the debug attribute set to true in the configuration setting under ?
3.) Do you have the appropriate permissions? Are you an Administrator? If not, are you a member of the VS Developers and Debugger Users groups?
In this particular case, he answered Yes to all 3.
Our standard team project setup includes source control integration (in this case Visual SourceSafe) and a team build server. The build server serves up all of the latest and greatest library DLLs to be shared among the development team. The Reference Path setting in the project properties is set so that the referenced DLLs (by file, not project) are retrieved from the build server when a doing a local build. I thought that he might be pointing to the Release directory on the build server which would mean that the .PDB file for the library in which he was trying to debug wouldn’t have been found. Nope. He’s pointing to the right directory.
So I did a little more digging… I try to compile the main web project just to see if everything looks in order. For whatever reason, the developer’s environment doesn’t have the Build output window opened. Upon opening the Build output window I noticed that the build process was having an issue with copying some of the libraries and their respective .PDB files to the main projects /bin directory. Strange I thought. So I did what any self respecting developer would’ve done…shut down the IDE, reopened and tried again. No go. Same problem.
While I was pondering what my next steps were I noticed something that was a little odd. “Why is the \bin folder of the main web project not grayed out?” Seeing as how our project is bound to VSS, any folders included in the project are added to source control… meaning the \bin folder was under source control… meaning the \bin folder contents were write protected! D’oh!
We removed the \bin folder from the project and removed the read-only attribute setting for its contents and everything was good again. We were back to debugging harmony. Tack one up to user error here.
So for those of you out there, please don’t select “Include in Project” for you \bin directory while under source control integration in Visual Studio .NET. Your project outputs are not meant to be checked into source safe (at least that’s my opinion), your source code is. Which the appropriate build process, you should be able to pull source files out an any particular time and re-compile your outputs. If you’re interested on some insight into our process check out How do you handle your build/promotion process? post.