| Author |
 Topic  |
|
|
Uniwares
Tomato Guru
Portugal
2322 Posts |
 Posted - Jul 29 2022 : 07:06:58 AM
|
A bit of a complex situation but here it goes:
C#, VS2017
I have a solution with one project that has about 20 web references (REST) of which half implement a class called "Document" in their respective namespace (all in Reference.cs in their own folder as created when adding a webreference).
In another project those web services are consumed. When I reference a certain webservice by "using" its namespace, obviously the Document class in this given namespace is available.
Now, when I use the Document class somewhere and put the caret on it, in the definition bar always appears the Document class in the alphabetically first namespace and not the one referenced in the current file.
When I fully specify the document class with its namespace all it good.
This of course also affects the Goto feature (Ctrl+Click by default), which goes to the wrong definition.
Let me try to visualize this:
Project 1:
WebService1
Reference.cs
public class Document
WebService2
Reference.cs
public class Document
WebService3
Reference.cs
public class Document
WebService4
Reference.cs
public class Document
Project 2:
SomeFile.cs
using WebService3;
var x = new Document(); // this should resolve to WebService3.Document
|
|
|
feline
Whole Tomato Software
United Kingdom
19020 Posts |
Posted - Jul 29 2022 : 10:54:13 AM
|
We should handle this correctly, but I am not really surprised at this bug, given the problems I have seen with duplicate names over the years.
Is the "Document" class name a function of it being a web reference / REST project, or just a logical name? I am setting up a test now, but if web reference projects are going to encourage this problem to happen that's worth knowing. |
zen is the art of being at one with the two'ness |
 |
|
|
Uniwares
Tomato Guru
Portugal
2322 Posts |
Posted - Jul 29 2022 : 10:58:50 AM
|
| Just a class name, no methods of the same name in this case. I think it might happen with other classes structured the same way but not sure. Didnt have time to test. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19020 Posts |
Posted - Jul 29 2022 : 11:54:08 AM
|
I have set up a very simple test case, perhaps far to simple, but so far no sign of the problem. I have emailed you my simple test case, so you can see what I have tried:
case=148403 |
zen is the art of being at one with the two'ness |
|
|
|
Uniwares
Tomato Guru
Portugal
2322 Posts |
Posted - Jul 29 2022 : 12:13:11 PM
|
| Yeah, there seems to be more to it than is happening in this sample project. Cant repro it neither with it. Next week I am on vacation, will try to make a full test project. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19020 Posts |
Posted - Aug 01 2022 : 04:38:22 AM
|
| Obviously if you have something you are able to share, purely for testing purposes, I am happy to try and find the trigger. Sometimes the trigger for odd bugs can be quite unexpected, as I am sure you know. |
zen is the art of being at one with the two'ness |
|
|
|
Uniwares
Tomato Guru
Portugal
2322 Posts |
Posted - Aug 16 2022 : 08:42:41 AM
|
Well, vacations didnt work out as expected, didnt have time (read mood) to make a test project, but...
... along the lines of confusing classes in the very same project, this one goes a bit too far for my taste. Especially since there are no duplicate names involved (except for the fact that seemingly somewhere exists a System.ApplicationId class)
Funny thing is that going to definition, by whatever means, really takes me to the correct definition and not what is shown in the VA bar.
The tooltip though shows the correct type.
But then again, "Goto Related" shows me:
Which is also definitely not correct.
And on to "Goto Member", where it gets weirder:
Where does it take that from??? And, none of the items actually can be opened/jumped to. Just doesnt do anything at all.
PS: sidenote: when clicking into the list of the "Members" listbox in the "goto member" dialog, typing anything always jumps to the first item and not to the corresponding item in the list. But this again might be resolved by simply setting the focus back to the input field when typing.
|
Edited by - Uniwares on Aug 16 2022 08:56:09 AM |
|
|
|
feline
Whole Tomato Software
United Kingdom
19020 Posts |
Posted - Aug 16 2022 : 11:28:22 AM
|
I just hope you managed to have a relaxing and enjoyable vacation! That is more important after all 
If I add the line:
ApplicationId =
to a .cs file in my main test solution, I get the same Goto Related information for this. But this is an undeclared symbol, and won't compile. I assume this compiles correctly in your solution?
For focus, I am seeing the same thing, and the same behaviour happens in both Find Symbol and Open File dialogs as well. Focus goes back to the filter field on Tab. I am tempted to say this is working normally, since the mouse click is placing focus into the list. |
zen is the art of being at one with the two'ness |
|
|
|
Uniwares
Tomato Guru
Portugal
2322 Posts |
Posted - Aug 16 2022 : 12:07:13 PM
|
Yes, compiles normally here. In this case, ApplicationId is a propery name in the class PublicCommunicationsMetadata of type System.Guid which VA should easily be able to determine from the simple context.
Wish I could send you the project but not possible. But its definitely related to the structure where we have RPC services, referenced by webservices, referenced by applications. seems to create kinda circular references in VA and symbols start to mess up.
As for the Member Dialog (and open file, find symbol), I would just expect that typing actually jumps to the first item matching the letter typed, or puts the focus on the input field. Minor UX issue. |
|
|
| |
Topic |
|
VA 2451: definition resolves to wrong class
