MAUI • Xamarin • Innovation • .NET

Soweit der kurze Exkurs – jetzt wird es konkret:

Microsoft bietet mit dem .NET-Upgrade-Assistenten ein Kommandozeilentool an, das beim Upgrade von Xamarin-Projekten auf .NET MAUI hilft, indem es allgemeine Anpassungen in den Projektdateien und im Code automatisiert vornimmt.

Unsere Erfahrungen mit dem Tool zeigen, dass es bei kleinen und einfachen Xamarin-Projekten zwar etwas Arbeit abnehmen kann, aber spätestens bei komplexen Enterprise-Apps sehr schnell an seine Grenzen stößt und am Ende des Tages der Entwickler in jeder einzelnen Projektdatei selbst Hand anlegen muss.

Wir empfehlen daher, dieses Tool nicht zu verwenden, sondern die wenigen Schritte (Projektdateien anpassen, Namespaces anpassen, NuGet-Packages aktualisieren, etc.) selbst auszuführen. Dies erfordert zwar etwas Fleißarbeit, ist aber nicht kompliziert und je nach Größe der Projektmappe relativ schnell erledigt. Wenn man bedenkt, dass nach dem Einsetzen des .NET-Upgrade-Assistenten jede Änderung überprüft und ggf. angepasst oder erweitert werden muss, ist die Zeitersparnis durch den Einsatz dieses Tools nicht wirklich gegeben.

Microsoft hat auch eine neue Visual Studio Extension für Windows angekündigt, um den .NET-Upgrade-Assistenten direkt in Visual Studio nutzen zu können. Die Unterstützung für die Migration von Xamarin zu .NET MAUI steht ebenfalls auf der Roadmap.

Nachdem die allgemeinen Anpassungen durchgeführt wurden – entweder mit dem .NET-Upgrade-Assistenten oder manuell – steht die erste größere Aufgabe an: Die im Projekt verwendeten NuGet-Pakete müssen – sofern es angepasste Versionen für .NET 6 (oder höher) oder MAUI gibt – aktualisiert oder durch Alternativen ersetzt werden.

Hier hängt der Aufwand davon ab, auf wie viele externe Bibliotheken das Xamarin-Projekt aufbaut. Wenn viele Funktionalitäten nicht selbst programmiert, sondern “von außen zugekauft” wurden (OpenSource oder von anderen Anbietern), kann sich hier unter Umständen der größte Aufwand verbergen. Im schlimmsten Fall stehen keine angepassten Versionen mehr zur Verfügung und die Bibliotheken müssen aufwändig ersetzt werden.

Klassisches Beispiel ist die Verwendung von Dependency Injection Containern wie Unity: Diesen gibt es unter .NET 6 nicht mehr, was aber auch nicht schlimm ist, da Microsoft über die Microsoft Extensions einen eigenen DI-Container zur Verfügung stellt und trotzdem sehr flexibel für andere DI-Container bleibt. Ich gehe hier nicht weiter ins Detail, da mein Kollege Alexander Jung sehr gute Artikel zu den Microsoft Extensions und speziell zu Dependency Injection mit den Microsoft Extensions geschrieben hat.

Wenn es von NuGet-Paketen keine angepasste MAUI-Version geben wird, es aber noch native Versionen für iOS und Android gibt, können diese auch selbst über die MAUI Binding Library angebunden werden. Diese Binding-Projekte sind leider noch nicht sehr gut dokumentiert und einige Fehlermeldungen sind irreführend, z.B.:

Diese Fehlermeldung könnte bedeuten, dass keine Verbindung zu einem Mac besteht oder dass die Typen in der Library nicht mit den Typen in der Referenz übereinstimmen und es gibt noch viele andere mögliche Erklärungen für diese Fehlermeldungen.

Wenn man aber auch bei solchen Fehlermeldungen durchhält und dranbleibt, können gute Ergebnisse erzielt werden und der Aufwand bleibt auch hier überschaubar (natürlich abhängig von der Größe der einzubindenden Bibliothek).

Wir haben in den letzten Jahren viele Xamarin-Projekte selbst entwickelt und auch viele andere Xamarin-Projekte gesehen und eines haben alle gemeinsam: Es gibt keine Xamarin.Forms App ohne Custom Renderer. Die Frage ist eher, wie viele Custom Renderer in einer App verwendet werden und diese Zahl kann sehr schnell sehr groß werden.

Daher unsere Empfehlung: Alle Custom Renderer direkt zu Beginn auskommentieren und am Ende folgendes prüfen:

• Gibt es die Funktionalität inzwischen direkt in MAUI? (Hier hat sich einiges getan!)
• Kann der Custom Renderer durch einen neuen MAUI Handler ersetzt werden?
• Soll der alte Custom Renderer im Kompatibilitätsmodus weiter verwendet werden?

Da die MAUI-App nach den grundlegenden Anpassungen zunächst auch ohne Custom Renderer rudimentär funktionieren sollte, kann man diese Entscheidung ganz am Ende treffen und sich dafür Zeit nehmen, wenn man View für View durch die App geht.

Es kann durchaus möglich sein, dass neue Handler oder auch Workarounds für eigene Custom Controls benötigt werden. Es gibt Fälle, in denen Event Handlers in Custom Controls nicht mehr aufgerufen werden (GitHub issue).

Unter Xamarin mussten die verwendeten Bilder für jede Plattform separat gespeichert und in unterschiedlichen Auflösungen bereitgestellt werden. Dies hat sich in MAUI geändert: Es genügt, eine einzige SVG-Datei hochzuladen und in der Projektdatei für das Bild die “BaseSize” anzugeben. Damit erzeugt MAUI automatisch die benötigten Auflösungen und die Größe der Bilder passt zum vorhandenen Layout, so wie es unter Xamarin der Fall war.
Erfahrene Xamarin Entwickler kennen die Build Action “BundleResource” für iOS für Bilder – diese wurde aus der Visual Studio UI entfernt, kann aber weiterhin manuell in der Projektdatei angelegt werden. Dies kann hilfreich sein, wenn z.B. Bundle Resources für den SplashScreen benötigt werden.

Ansonsten können weiterhin alle Plattform Features der Betriebssysteme über .NET MAUI angesprochen werden. Seien es iOS Extensions für Call Directory, Background Jobs oder andere Funktionen – diese können (nach Anpassung der grundlegenden Aspekte wie Namespaces etc.) wie gewohnt weiter verwendet werden.