| T O P I C R E V I E W |
| tomerico |
Posted - Feb 28 2006 : 10:27:40 AM
Hi,
I'm an old time user of Visual Assist, and a big fan.
However, I have a very frustrating problem, the Go button doesn't work when I want to go to source of files outside of my project.
I import a lot of dlls from different solutions, and when I debug, stepping into the outer code works perfectly. However, visual assist for some reason doesn't manage to find the source files.
So when I click on it, it does nothing.
I use Visual studio 2003, with c#.
Thanks,
Tomer |
| 11 L A T E S T R E P L I E S (Newest First) |
| tomerico |
Posted - Mar 08 2006 : 02:09:43 AM
Thanks, I think it's an obvious feature visual assist should support, as VA's role is to improve the IDE and not to provide the same functionality.
|
| support |
Posted - Mar 07 2006 : 1:56:07 PM
For C# users, both the IDE and VA X get 3rd-party definitions from imported DLLs. The debugger, on the other hand, also gets the locations of 3rd-party implementations from pdb files. (VA X doesn't parse pdb files.) Hence, the request here is that VA X parse and use info available in pdb files so Goto works during edit.
case=1021 |
| tomerico |
Posted - Mar 07 2006 : 02:02:32 AM
Thanks. keep me updated. |
| feline |
Posted - Mar 06 2006 : 4:47:12 PM
to be honest i am out of my depth here.
it strikes me as odd that the IDE can step into the library code when debugging, but not when editing. i have this feeling that asking VA to find and read pdb files could be asking for trouble.
i will ask support and see what they make of this. |
| tomerico |
Posted - Mar 05 2006 : 02:16:24 AM
When I use Go to Definition, it send me to the Object Browser. The object browser is a place where you can see all the class definitions that you use. It takes that information from the dll.
I can tell you, that if there is no pdb file, I can't step into source. I don't know if the compiler knows where the source lies.
Tomer |
| feline |
Posted - Mar 04 2006 : 12:33:40 PM
it occurred to me that i may be going about this the wrong way. in C# VA gets the intellisense information from the IDE its self, so the rules for parsing code are probably different.
given a piece of code you want to use alt-g on, and it fails, what happens if you use right click menu -> go to definition?
this is the IDE's goto command. if this works while editing code then this suggests that the IDE its self knows about the library code. also do you get intellisense on the classes from these library dll's?
i am speculating that when you first import a new dll there may be no pdb file, but that one will be created when you compile the code and the library. if this theory is correct then the question becomes, does "go to definition" work before a pdb file is created? if so, how does the IDE know where to find this code?
do you follow my logical chain here? at some level something must be telling the IDE about the library code, so it is a case of finding this thing, and then workout out why VA is not reading the same information, and getting it to do so. |
| tomerico |
Posted - Mar 02 2006 : 02:11:33 AM
Feline,
Thanks for replying.
When you compile a c# project, you get a [project name].pdb file in your debug directory. This file contains all the debug information, and the location of the source files.
So when I add referance to a dll, the compiler automatically look for a .pdb file. (If no such file exist, I can't step into the code.
I'd assume visual assist should be able to do the same thing...
If there is any other solution besides adding all the projects I'm referancing to, I'd be glad to hear. (I have about 30).
Tomer |
| feline |
Posted - Mar 01 2006 : 7:18:51 PM
tomerico without a bit more information all i can do is offer vague suggestions.
how are you telling the IDE about these libraries and more importantly their code? i see what jpizzi is saying, and follow his logic. drawing on my C++ background if i simply tell the linker to pick up a dll file this will not tell the debugger where to find the associated source code, and in fact i may not even have the associated source code.
one "simple" solution would be to create a second project for the library source code, add this to your solution, but exclude it from the build and make sure it is not a dependency. VA will then be told about the code, and will know where to find it.
if this was C++ i would point you towards the IDE tools menu -> options -> projects -> VC++ directories
however the situation is obviously different for C# |
| tomerico |
Posted - Mar 01 2006 : 04:17:36 AM
Hi,
What I need, is a way to specify to visual assist to parse all the other source files, so the it will know where to send the Go cocmmand to.
It's very common to use other sources, we have more than a million lines of code, it can't be all in the same project.
If there is a workaround, I'd really happy to hear about it.
Regards,
Tomer |
| jpizzi |
Posted - Feb 28 2006 : 8:48:25 PM
Remember that when you are debugging, the source code (symbols, etc.) are right there with the executable code. The debugger doesn't have to look anywhere (and probably has specific information about where the source is, anyway). Expecting the editor to be able to do that is asking too much.
I have seen this type of behavior in another editor/compiler pair. The debugger has absolute information about the source code (if the code was compiled with debugging information).
I think your expectation of VA being able to find source files outside your project is expecting too much. This is opinion, however. I am not affiliated with WT. |
| feline |
Posted - Feb 28 2006 : 4:11:06 PM
i don't know how this works in the C# world, but in C++ there are two seperate halves to this.
the compiling half is setting the dll as a dependency for the linker
the code half is done by telling the IDE or VA about the headers for the dll - this seems to be what is missing here.
obviously the debugger is picking something up. do you have the actual cs files for these dll's, assuming they are even written in C#. is it possible / likely the IDE is using something like reflection on the dll's when you debug and step into them? |
|
|
