"Verborgene" Erweiterungsmethode finden

Hallo zusammen,

in einer kleinen Sammlung habe ich unter anderem eine im System-Linq-Namespace definierte Erweiterungsmethode

public static IEnumerable<T> TakeLast<T>(this IEnumerable<T> source, int count)

die ich bisher in meinen WPF-Projekten verwendet habe.

Heute habe ich diese auch in einem Xamarin.Forms-Projekt verwendet, woraufhin mir der Compiler ausgab, dass es eine solche Erweiterungsmethode schon gäbe und nicht entschieden werden könne, welche der beiden nun verwendet werden soll.
Deshalb habe ich die Erweiterungsmethode von der allgemeinen in die WPF-Sammlung verschoben und schon ging's. Jetzt meckert allerdings VisualStudio immer, dass es die Methode nicht finden kann.

Gibt es eine Möglichkeit, wie ich VisualStudio trotzdem sagen kann, wo es diese findet, sodass mir nicht permanent ein Fehler angezeigt wird, der überhaupt nicht da ist?

Gruß

Micha

Kannst Du bitte die originale Fehlermeldung(en) posten?

Klar!

Fehlermeldung:
error CS0121: The call is ambiguous between the following methods or properties: 'System.Linq.IEnumerableTExtensions.TakeLast<T>(System.Collections.Generic.IEnumerable<T>, int)' and 'System.Linq.Enumerable.TakeLast<TSource>(System.Collections.Generic.IEnumerable<TSource>, int)'

Die erste Variante wird meine Erweiterungsmethode sein.

Du benennst deine Namespaces wirklich System..., wie im Framework? Sollte man nicht machen, das führt zu Konflikten.

Ich denke mal ein Alias beim Using kann dir dar weiterhelfen.

Bei solchen Erweiterungsmethoden mache ich das, damit ich nicht extra zusätzliche usings habe.
So kann ich z.B. in diesem Fall meine Methoden direkt mitnutzen, wenn ich Linq einbinde.

In der Regel funktioniert das auch, nur bei dieser Methode in Verbindung mit Xamarin.Forms nicht.
Deshalb hatte ich die Erweiterungsmethode aus der allgemeinen Bibliothek in die für WPF verschoben, damit sich das mit Xamarin nicht beißt.
Leider sagt mir VS nun, dass es die Methode vom Xamarin (oder Mono?) nicht findet - der Compiler hingegen ist glücklich.

Also ich kann das so nicht nachvollziehen, denn diese Erweiterungsmethode System.Linq.Enumerable.TakeLast kann ich leider nicht finden

GitHub: mono/System.Linq.Enumerable

Stellt sich also die Frage, was und woher du dir diese Erweiterungsmethode eingefangen hast. Offiziell sieht das irgendwie nicht aus.

Hmmm...
Wenn ich im Object Browser nach TakeLast suche, dann finde ich da auch nur meine Methode - egal, ob ich in "My Solution" oder "All Components" suche.

Wenn ich direkt im Android-Projekt - und nicht im Shared-Projekt - die Methode verwende, dann findet VS doch was (siehe Screenshot).
Offenbar ist die Methode nur im UWP-Teil nicht auffindbar - und der ist aus irgendeinem Grund oben im Fenster eingestellt gewesen, obwohl das Android-Projekt als Startprojekt ausgewählt ist.

Dann muss ich meine Methode wohl mal mit einem #if ausstatten...

Mich würde aber irgendwie trotzdem interessieren, weshalb die TakeLast-Methode nicht im Object Browser auftaucht und wo sie im Source versteckt ist.

Danke für eure Hilfe!

Das ist eben die Krux mit Mono (und Xamarin).
Du siehst ja auch, dass Du hier mit Mono arbeitest - und da gibt es durchaus interne Methoden, die dann diesen Fehler auslösen.

Im .NET Framework gibt es diese Methode definitiv nicht.

Dass man solche Methoden im IntelliSense versteckt: absolut normal.
Ist sehr wahrscheinlich das Browsable-Attribut und hier auch korrekt im Einsatz.
Im Quellcode ist sie nicht versteckt.

Warum sie das hier spezifisch gemacht haben: frage bitte die Mono Entwickler dazu.

Bei solchen Erweiterungsmethoden mache ich das, damit ich nicht extra zusätzliche usings habe.
So kann ich z.B. in diesem Fall meine Methoden direkt mitnutzen, wenn ich Linq einbinde.

Ich persönlich Bevorzuge ja lieber zusätzliche Usings als zusätzliche Fehlerquelle. 😉

Schau mal hier Use system namespaces for class libraries: good or bad

Es ist absolut ein Bad ein System. Namespace zu nutzen, wenn die entsprechende Bibliothek nicht dafür ausgelegt ist.
NuGet hat mittlerweile auch eine Protection, sodass gewisse Namensräume von Paketen nicht genutzt werden können (zB. Microsoft.XYZ) bzw. nur dessen Besitzer.