Wie kann eine einzelne .NET-Assembly, die gleichzeitig 2.0, 3.0, 3.5, 4.0 und 4.5 unterstützt, Erweiterungsmethoden für C # - und VB.NET-Konsumenten unterstützen?
Der Standardvorschlag ist, dies hinzuzufügen:
%Vor%Dies ist der Ansatz, den mehr als ein Microsoft-Mitarbeiter und wurde sogar in MSDN Magazin . Es ist weit gefeiert von viele Blogger haben" keine negativen Auswirkungen ".
Oh, außer dass es einen Compiler-Fehler von einem VB.NET-Projekt verursacht, das auf .NET 3.5 oder höher abzielt.
Die Autoren von Microsoft.Core.Scripting.dll haben es herausgefunden und änderte "öffentlich" in "intern".
%Vor%Was das VB Kompatibilitätsproblem zu lösen schien.
Also habe ich diesen Ansatz vertrauensvoll für die neueste Version (3.2.1) der weit verbreiteten ImageResizing.Net-Bibliothek verwendet.
Aber dann , fangen wir an, diesen Compiler-Fehler zu bekommen ( Originalbericht ) für bestimmte Benutzer, die auf .NET 3.5 + abzielen, mehr oder weniger zufällig.
%Vor%Da der MSBuild / VisualStudio-Compiler offensichtlich keine Scoping-Regeln beim Auflösen von Namenskonflikten in Betracht zieht und die Reihenfolge der Assembly-Referenzen eine nicht ganz dokumentierte Rolle spielt, verstehe ich nicht ganz, warum und wann dies geschieht .
Es gibt einige Hacky-Workarounds , wie zum Beispiel das Ändern des Assemblynamensbereichs, das Neuerstellen der Projektdatei, das Löschen / Lesen von System. Core und Fiedeln mit der Zielversion von .NET Framework. Leider ist keine dieser Problemumgehungen 100% (außer Aliasing, aber das ist ein inakzeptabler Schmerz).
Wie kann ich das während
beheben?Oder gibt es einen Hotfix, damit der Compiler Scoping-Regeln beachten kann?
Verwandte Fragen zu SO, die diese Frage nicht beantworten
Wir haben das gleiche Problem mit IronPython bekommen. Ссылка
Am Ende haben wir unsere benutzerdefinierte Version von ExtensionAttribute in eine eigene Assembly verschoben. Auf diese Weise können Kunden wählen, ob sie unsere benutzerdefinierte ExtensionAttribute-Assembly oder System.Core referenzieren möchten - aber niemals beides!
Die andere schwierige Sache ist, dass Sie die ExtensionAttribute-Assembly immer bereitstellen müssen - auch wenn Sie sie in Ihrem Projekt nicht referenzieren. Ihre Projektassemblys, die Erweiterungsmethoden verfügbar machen, verfügen über eine Assemblyref zu dieser benutzerdefinierten ExtensionAttribute-Assembly, sodass CLR verärgert wird, wenn sie nicht gefunden wird.
Angesichts der harten Anforderungen der .NET 2.0-Unterstützung würde ich meinen, dass es am besten wäre, Erweiterungs-Methoden überhaupt nicht zu verwenden. Ich bin mit dem ImageResizer-Projekt nicht vertraut, aber es scheint, dass dies eine kürzlich erfolgte Änderung von ImageResizer war. Wie durchführbar wäre es, die Erweiterungsmethoden auf traditionelle statische Methoden zu übertragen? Wir haben tatsächlich darüber nachgedacht für IronPython / DLR, aber es war nicht machbar (Wir waren zu diesem Zeitpunkt mit LINQ verschmolzen und LINQ hatte im Wesentlichen seine gesamte Existenz extensiv genutzt).
Tags und Links clr extension-methods csc vbc