Source code/projects get confused druing debugging

[jarvusluntatintel]

I am encountering a situation where Visual Studio gets my source code/projects confused during debugging. (And I realize this may be a VS bug not Intel.) This initially happened in 2008 and it suddenly started happening in 2010 (which I switched to a few weeks ago).

The simplest description of the problem is with two projects that share [almost] identical source code. There is the main project that is single precision. The source code is underneath this project: \\\\my projects\\\\projects single\\\\source code. Then there is the secondary project (that is a double precision version) that has its own directory and object files: \\\\my projects\\\\projects double\\\\debug. However, it directly uses the source code that is underneath the single directory: \\\\projects single\\\\source code.

When I am running the double project in debug mode and step into a new file (F11), the runtime behavior and the watch windows are correct. However, [sometimes] visual studio thinks that the file that I have stepped into/opened is the single project. If I make changes to this file, build it, and start debugging the current project, it launches the single precision version (which has its own command line that points to a different input file). This is really annoying and confusing.

VS only switches to the wrong project when the source code is not directly underneath the project directory. When I am debugging project single and step into a new file, it never thinks the file is part of double project.

The Visual Studio solution has a dozen or so projects and this behavior is always the same. Im not sure if it is relative path name problem, or the fact that I always created the main projects first. When I switched to VS 2010, I actually spent 20 hours or so recreating my solution/projects from scratch since I didnt want to import a corrupt file structure.

Anybody have any insight on whether there is any reason to think that putting the source in a different location would help? For instance:

\\\\my projects\\\\source code

\\\\my projects\\\\projects single\\\\debug

\\\\my projects\\\\projects double\\\\debug

Im reluctant to spend/waste time moving things around again. However, if I cant get anything else to work, Im going to make every project have its own dedicated solution. This is going to be a nuisance, especially since there are a number of libraries (that continually get modified and debugged into) and each solution will have to have all of the libraries. But this seems the lesser of two evils.

The attached file shows some screen shots of the behavior in progress.

[IanH]

Given the source files are almost the same - could you have two separate configurations instead of separate projects?

(The answer would be "No" if you needed both configurations active at the same because the project outputs were being combined in a third project or similar.)

[jarvusluntatintel]

I had not thought about multiple configurations. Some of my projects could probably be combined into multiple configurations, butthat won't work for all of them.

I have used multiple configurations in the past and found it a littleawkward, but perhaps I should revisit it. Thanks for the suggestion.

[jarvusluntatintel]

So to take care of the problems I have been having with this, I am planning on breaking up my current solution into ten or so different solutions. I'm debating on how I might organize this and I have some questions on the behavior of visual studio solutions and projects.

Say I have Solution_1.sln with project_1.vfproj and Solution_2.sln with project_2.vfproj and both of them use library.vfproj. One option would be to make a duplicate of the library, so that I had library1 (that had its own debug directory/obj files) and had library2 (that had its own debug directory/obj files). They would point to the same source code. So if I had either solution open and made changes to the source code, the changes would show up on the other solution/project. However, to update the library would mean that it would have to be compiled twice (or in my case, more like a dozen times--or really more like 30 times once I built both the debug and release versions). This is doable but a bit of a nuisance.

The other option is that the two different solutions both point to the same library project. If I have Solution_1 open, make a change to the library and recompile it, when I later open Solution_2, the library is good to go (this works, right?). But what happens if I have Solution_1 and Solution_2 open at the same time? Or more extreme yet, if both Solution_1 and Solution_2 try to debug down into the library at the same time (which means they are using the same *.obj files in the same debug directory)? Is trying this going to set myself up for problems again?

Or am I missing anything obvious? Is there some other approach I should consider?

Thanks for any suggestions.

[Steven_L_Intel1]

I would do this with a single solution and configurations. Are you changing the output or intermediate directory for the projects to some common location? Also, which specific compiler version are you using? In the early 12.0 versions, the PDB file was put in the wrong place and if you had multiple projects being built it could get confused. This was fixed in update 4, I think.

[jarvusluntatintel]

Steve,

The attached file on my original post has a screen shot of "help about". But the compiler is version 11 (I think).

No, I am not aware that I have changed an output or intermediate directory. The only thing that is confusing is the location of the source files.

As far as having a single solution for everything, I can no longer handle how it is switching projects on me. Again, the attachment on the first post shows the screwy behavior.

I have made one project into its own solution (the one that has recentlybeen most problematic)and so far I am rather liking it. For instance, my "batch build" window is not the nightmare that it used to be and doing a "find in files" for the entire solution is now a viable option (which it really wasn't before).

But so far I have held off on the others because I'm not sure what I want to do with the shared libraries.

But a confusion with the PDB file would certainly explain the sort of behavoir I am getting. If that is the case, is going to the verylatest Intel version likely to be a fix?

Thanks

[Steven_L_Intel1]

If you are using version 11, then the PDB file is not the issue.