Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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.
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.
FWIW, I think the compiler won't allow it either...
Correct, shouldn't be resolveable there - I think mono 2.11 is the first mcs not allowing this.
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:
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.
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.
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.
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.
That's how resolve errors are displayed.
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.
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 ?
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.
2) Unreferenced type resolve result doesn't contain the info that the type exists in an unreferenced assembly.
Well, sure, but that info is *somewhere*, it just needs to be propagated around during the resolve, right?
No that info is nowhere. It needs to be resolved separately.
Should've been fixed