| T O P I C R E V I E W |
| franji1 |
Posted - Dec 02 2014 : 2:03:12 PM
In my native VS2008 C++ app, we have 40+ EXE/DLLs. I have one solution called Build.sln. However, when I debug, the .EXE/.DLL files must be copied into their "distributed" folders, hence the need for a separate .SLN for the .EXE.
Hence, when I am debugging/looking at code during my debugging session of the .EXE solution, I don't have any symbols (except for the immediate ones in the immediate file).
Is there a work-around for this. |
| 6 L A T E S T R E P L I E S (Newest First) |
| feline |
Posted - Dec 03 2014 : 5:17:56 PM
Personally I would be tempted to have the build solution do the copies as post build commands, but I don't know the details of your situation.
If you want VA to have up to date knowledge of changing source code then you really need to put this code into a solution, and have VA open this solution, it will then know which files to scan, and can check for changed files, to make sure it is up to date. So adding the existing projects to the EXE solution sounds like a simple and effective fix here, hopefully it works well for you. |
| franji1 |
Posted - Dec 03 2014 : 3:01:28 PM
quote:
Is there some reason why you are debugging with a solution like this? Why not debug from the main solution, where you are compiling your code? Am I missing something obvious here?
The "build" solution just generates the deliverables, but does NOT place the deliverables in their proper/final location.
We developers have a batch file that copies the 40+ raw deliverables from their corresponding 40+ "<project>\\Debug" xor "<project>\\Release" folders, and inserts them into a sub-directory structure that the "install" eventually would put them in (these folder structures are completely different and not organized in any similar way).
I have found out, like you said, that trying to use the C/C++ Directories lists doesn't quite do what I want it to do.
I think I may do something similar to what your script does with my .exe - only project, and just have THAT solution include all the ones from the Build solution (I don't want to tweak the Build solution since it is exclusively for building, not for debugging).
|
| feline |
Posted - Dec 03 2014 : 2:48:35 PM
The C/C++ directories settings are for STABLE code files, normally system and 3rd party libraries, we don't expect these code files to always be changing, so this is not the ideal approach.
Is there some reason why you are debugging with a solution like this? Why not debug from the main solution, where you are compiling your code? Am I missing something obvious here?
If you are prepared to point your debugging solution at your code base, is making a "dummy" project that contains all of your code files, and adding this project to your debugging solution an option? This will let VA find all of the code files, so it will understand the symbols, but it won't actually be the live, compiling projects that you are avoiding.
If this might help, then you might find this script file helpful. It is a vbscript file I wrote to generate a dummy solution from all of the code files in a directory tree. The project and solution it generates are not designed to compile, but it will let VA find all of the files. The usage details are at the top of the script file:
http://forums.wholetomato.com/colin/forumimages/make_solution_from_files_2_0_1.zip |
| franji1 |
Posted - Dec 03 2014 : 09:03:50 AM
One work-around. What if I just tweaked my C/C++ Directories "Source Files" list to include ALL of my 40+ projects' folders???
What are the drawbacks if I do that? There are over 1300 .CPP files and 1500 .h files. I have a multi-threaded quad core machine with 16GB, so I think I have adequate horsepower.
I am constantly making changes to source and header files across a handful of the 40+ projects.
I'll try it and see how well it works. If I do this, what is important is, that as I make changes to my source files, I want VA to recognize them "immediately" (yes, that's relative - I can wait a few seconds in my microwave world  ). |
| franji1 |
Posted - Dec 03 2014 : 07:30:32 AM
The Debugging solution contains one project/file, the .exe itself (see the screen shot below).
I USED to generate a .BSC file with ALL of the solutions' .SBR files, then open that .BSC file into my debugging solution. I don't want to do that anymore. I like Visual Assist .
|
| feline |
Posted - Dec 02 2014 : 11:49:15 PM
Does the separate SLN file contain an entire project, or just a couple of code files? You comment about the immediate file makes it sound like hardly any symbols at all are known.
All of the symbols from all of the files in the currently opened SLN should be known.
Are you able to add the extra projects, with the symbols you want to reference while debugging to this separate SLN file, but simply mark them as excluded from the compile, via the IDE Build menu -> Configuration Manager... |
|
|
