Bug 5141 - References of references are not handled well
Summary: References of references are not handled well
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: C# Binding ()
Version: Trunk
Hardware: PC Mac OS
: Low enhancement
Target Milestone: ---
Assignee: Mike Krüger
Depends on:
Reported: 2012-05-17 10:19 UTC by Alan McGovern
Modified: 2013-09-16 05:30 UTC (History)
1 user (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Alan McGovern 2012-05-17 10:19:01 UTC
1) Create LibraryA
2) Create LibraryB
3) Make LibraryA reference LibraryB
4) Make LibraryB referenece System.Xml.Linq
5) Create a method in LibraryB which exposes the "XElement" type from System.Xml.Linq
6) Try to call that method from LibraryA

MonoDevelop does not recognise XElement as a valid type and in the method parameter tooltip displays them as question marks.
Comment 1 Mikayla Hutchinson [MSFT] 2012-05-17 12:19:58 UTC
FWIW, I think the compiler won't allow it either...
Comment 2 Mike Krüger 2012-05-17 12:44:14 UTC
Correct, shouldn't be resolveable there - I think mono 2.11 is the first mcs not allowing this.
Comment 3 Alan McGovern 2012-05-17 13:46:32 UTC
Is there a better way to handle this? I've been seeing this 'problem' for ages and only figured out today that I needed to add a reference to another assembly to fix it. For example, suppose the method were:

class Foo
    void Bar (Baz b);

If Baz is in LibraryB then if i try to invoke Foo.Bar from LibraryA, could MonoDevelop highlight 'Bar' in red and when I right click it would then offer to automatically add a reference to System.Xml.Linq as it can deduce that that is the assembly I need.
Comment 4 Alan McGovern 2012-05-17 13:46:58 UTC
Comment 5 Mikayla Hutchinson [MSFT] 2012-05-17 15:19:51 UTC
The resolver could certainly handle this better - any tooltip mentioning such types could include a message about the type not being accessible as its assembly is not referenced. And as you say, if the type and its members are actually used, then the semantic highlighting should show them as unresolved.

Having a quick fix command to add references for unresolved types is tougher, I would suggest you file that as a separate enhancement request.
Comment 6 Mike Krüger 2012-05-17 15:22:19 UTC
The resolver can't handle that, because it's not in the lookup algorithms from MS. The compiler shouldn't compile it - it's a bug in the compiler - that's soon get fixed.

And transitive types are shown as unresolved btw.
Comment 7 Mikayla Hutchinson [MSFT] 2012-05-17 15:40:49 UTC
The problem is that the code completion does not display any useful information about the problem at all:

Nowhere does it tell you the name of the type you need to reference, or why resolution failed.
Comment 8 Mike Krüger 2012-05-17 16:30:25 UTC
That's how resolve errors are displayed.
Comment 9 Mikayla Hutchinson [MSFT] 2012-05-17 16:44:26 UTC
Sure, but that doesn't mean it couldn't be improved :)

IMO there are 3 parts to this:
1) Display the type name instead of "?", and some error message about it being not referenced.
2) Improve resolve errors so they show why the resolution failed, if possible.
3) Add a quick fix for referencing the assembly.

#3 is a low priority enhancement, of course, but #1 and #2 are more important as they do affect the usability of code completion.
Comment 10 Mike Krüger 2012-05-18 02:11:50 UTC
1) I can show something different here.
2) In that case: unresolved. There is no way for the resolver to find that.
3) Quick fixes are evil - aren't they ?
Comment 11 Mikayla Hutchinson [MSFT] 2012-05-18 13:41:10 UTC
1) Good, that would help a lot :)
2) I don't understand the details, but why couldn't the var be inferred to be an UnreferencedTypeResolveResult or something like that?
3) I don't think anyone every said quick fixes were evil. This is analogous to the resolve command. Low priority, anyway.
Comment 12 Mike Krüger 2012-05-18 16:30:47 UTC
2) Unreferenced type resolve result doesn't contain the info that the type exists in an unreferenced assembly.
Comment 13 Mikayla Hutchinson [MSFT] 2012-05-18 16:58:07 UTC
Well, sure, but that info is *somewhere*, it just needs to be propagated around during the resolve, right?
Comment 14 Mike Krüger 2012-05-19 03:46:06 UTC
No that info is nowhere. It needs to be resolved separately.
Comment 15 Mike Krüger 2013-09-16 05:30:36 UTC
Should've been fixed