Jeder, der schon das ein oder andere Programm in C# geschrieben hat, wird das Problem vermutlich kennen. Man bindet die ein und die andere Library ein. Teilweise auch Librarys, die ähnliche Zwecke erfüllen. Das kann gut gehen, muss es aber nicht.
Schnell bekommt man eine Fehlermeldung nach dem Schema: “XYZ ist ein mehrdeutiger Verweis und kann von LibraryA.XYZ oder LibraryB.XYZ sein.”
Doch was nun? Am Beispiel der AForge Library möchte ich das Problem einmal exemplarisch lösen. Als Beispiel nehmen wir an, wir hätten bisher folgende beide Referenzen gesetzt und die using-Direktiven geschrieben.
using System.Drawing; using AForge.Imaging;
Verwenden wir nun die Klasse “Image” in unserem Programm, so erhalten wir folgende Fehlermeldung, die daraus resultiert, dass es sowohl im Namespace System.Drawing als auch in AForge.Drawing eine Klasse namens “Image” gibt.
Nun könnte man abwägen, auf die Elemente wessen Namespace wir öfter zugreifen und dann die using-Direktive des seltener verwendeten Namespace entfernen. Schließlich könnte man ja auch unter Angabe des Namespaces direkt auf dessen Elemente zugreifen.
Image img = AForge.Imaging.Image.FromFile(imagePath);
Das ist jedoch je nach Anzahl der Aufrufe als auch nach der Länge/Verschachtelung des Namespaces mehr als umständlich. Viel einfacher und in meinen Augen auch eleganter ist es, einen Alias für einen Namespace zu vergeben. Das Setzen eines Alias lässt sich direkt in der using-Direktive erledigen. Anhand unseres Beispiels könnten wir die AForge using-Direktive wie folgt umschreiben.
using System.Drawing; using AF = AForge.Imaging;
Nun können wir nachfolgend in unserem Programm anstelle von “AForge.Imaging” einfach immer “AF” einschreiben. Das löst zum einen das Problem der mehrdeutigen Verweise und zum anderen hilft es auch, schnell und einfach zwischen den Referenzen zu unterscheiden.
Image img = AF.Image.FromFile(imagePath);
Maybe in the future it’ll do even better in those areas, but for now it’s a fantastic way to organize and listen to your music and videos, and is without peer in that regard. The iPod’s strengths are its web browsing and apps.
Danke für den Tipp!
Habe schon lange nichts mehr in C# programmiert, vielleicht sollte ich das doch mal wieder tun :)