MAUI • Xamarin • Innovation • .NET

MAUI Migration von Xamarin Apps

30. März 2023

Die Migration komplexer Enterprise-Apps von Xamarin auf MAUI ist anspruchsvoll, Neuentwicklungen mit MAUI sind dagegen kein Problem. So lautet unser Fazit nach über einem Jahr Erfahrung mit der innovativen Technologie MAUI.

Kurz vorweg: MAUI steht für “Multi-Platform App UI” und ist die Portierung der Xamarin-Technologie auf die erste gemeinsame .NET Plattform “One.NET”. Seit der offiziellen Verfügbarkeit von MAUI am 23.05.22 haben wir Verbindlichkeit für unsere MAUI-Kundenprojekte und konnten mit neuen Projekten, aber vor allem auch mit bestehenden Enterprise-Projekten durchstarten.

Frontend-Strategie

Wir haben bereits vor zwei Jahren begonnen, mit den MAUI-Previews eine Strategie zur Frontend-Modernisierung zu entwickeln, wahlweise auch in Kombination mit Blazor, der schon etwas länger verfügbaren Technologie zur Entwicklung von Single Page Applications mit .NET/C#. Diese Strategie hat sich in den letzten Monaten bestätigt, so dass wir weiterhin auf dem richtigen Weg sind.

autor Daniel Thomas

Daniel Thomas

Head of Sales Daniel.Thomas@sdx-ag.de

Soweit der kurze Exkurs – jetzt wird es konkret:

Laut der offiziellen Xamarin Support Policy endet der Support für Xamarin zwar erst am 01.05.24. Allerdings werden die im Herbst 2023 erscheinenden OS-Versionen Android 14 und iOS 17 bereits nicht mehr unterstützt und zwingen noch in diesem Jahr zum Handeln.

.NET-Upgrade-Assistent

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.

Dependency Injection und NuGet Packages

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.:

Irreführende Fehlermeldungen in MAUI

Tipp: iOS Binding-Projekte direkt unter Visual Studio for Mac bauen und die DLL dann wieder in Visual Studio for Windows verwenden. Das Tooling und der Build laufen unter Mac deutlich stabiler.

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).

Custom Renderer und MAUI Handler

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).

Fazit: MAUI Migration von Xamarin Apps

Mit der richtigen Herangehensweise und, je nach Komplexität der bestehenden Xamarin-App, dem Know-how über Binding Libraries und nativem Code können die größten Stolpersteine bei der Migration aus dem Weg geräumt werden. Vor allem, wenn die verwendeten SDKs und Packages von den Anbietern nicht mehr für MAUI angepasst werden und man daher im Zweifelsfall auf die nativen Varianten umsteigen muss.

Das Tooling hakt noch etwas und die Konzepte haben sich etwas geändert, aber insgesamt können mit .NET MAUI nicht nur neue Projekte aufgesetzt, sondern auch bestehende und durchaus komplexe Enterprise-Apps migriert werden.

Plattform Features

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.

One.NET – Enterprise Ready!

Nach über zwei Jahren Erfahrung mit MAUI: Eine coole, tragfähige Technologie für moderne Frontends, die mit einer Codebasis auf allen Plattformen lauffähig sind. Damit ist One.NET am Frontend endlich Realität geworden.

imageimage

Technologiepartner für Multi-Plattform gesucht?

E-Mail