I’m absolutely stunned by the fact that MS just couldn’t get it right to navigate to the definition of a method, when you’re combining C# and VB projects in one solution. If you’re trying to navigate from VB to C#, it brings up the ‘Object Explorer’, and if from C# to VB, it generates a metadata file.
Honestly, what is so complicated about jumping between different languages, especially if they’re supposedly using the same CLR?
Does anyone know why this is, or if there’s any workaround? Did they get it right in VS 2008?
@Keith, I am afraid you may be right about your answer. I am truly stunned that Microsoft screwed this up so badly. Does anyone have any ideas for a workaround?
@Mladen Mihajlovic – that’s exactly the situation I’m describing. Try it out yourself; project references don’t make a shred of difference.
This is general to both languages.
This is a deliberate mechanism to try and match expected behaviour for upgrading users. The C# way gives you the right information, but the VB way is what users of VBA or VB6 will expect.
The behaviour is the same in VS2008.
These are the rules for external projects, both should take you to the code if it is in the same solution.
You’re quite right – VB projects treat C# projects as external and vice versa – you can’t navigate from code in one to the other. I’ve tested this in the latest VS2008 and it’s still an issue.
It also fails to get complete meta-data. Add a method to your C# code and it won’t appear in VB’s intellisense until you compile the C# assembly.
This is similar to how components appear in the toolstrip, so I figure the normal navigate to code functionality is a feature of code with a common compilers, and everything else uses some kind of reflection.
As long as you’re still building a PDB it should be able to find the files, I guess it doesn’t because they need it to support release builds too. It couldn’t find the line of code without the PDB lookups.