Silverlight Anwendungen migrieren

Silverlight Anwendungen migrieren

In diesem Blog beleuchten wir die verschiedenen Lösungsansätze zur Migration von Silverlight Anwendungen.

Silverlight History
Bei den meisten Plattform-Verantwortlichen und Entwicklern, die bereits 2009 mit Softwareprojekten zu tun hatten, löst das Wort „Silverlight“ keine positiven Gefühle aus. 2009 pushte Microsoft die neue UI-Technologie so sehr, dass viele auf dieses Technologie-Framework setzten. Faktoren wie „zukunftsträchtig“, „plattformunabhängig“ und „Investitionsschutz“ wurden dabei häufig in den Entscheiden genannt. Wie wir heute wissen, kam alles anders. Apple unterstützte mit dem Safari Browser Silverlight nicht und die Plattformunabhängigkeit war nicht mehr gegeben. Silverlight wurde auch technologisch überholt mit moderneren Ansätzen. Microsoft stoppte die Weiterentwicklung schliesslich komplett. Viele Projekte wurden mit Silverlight zu Ende geführt und sind heute noch im Einsatz. Spätestens im Oktober dieses Jahrs sollten diese Projekte abgelöst werden, denn dann endet der offizielle Support. Schon jetzt wird Silverlight nur noch vom Internet Explorer unterstützt. Für den IE ist mit Sicherheitslücken zu rechnen, da der Browser von Microsoft ebenfalls (bereits seit August 2021) nicht mehr supportet wird.
Migrationspfade

Doch welche Migrationspfade gibt es? Lässt sich bestehender Code wiederverwenden? Lassen sich die Benutzeroberflächen mit XAML wiederverwenden? Gibt es Migrationstools?

Die kurze Antwort auf die letzte Frage ist: Nein. Zumindest keine, die den Code mit ein paar Klicks einfach und schnell in eine neue Anwendung mit moderner Technologie überführen. Die wenigen Migrationstools, die es auf dem Markt gibt, haben nur den Anspruch, eine bessere Entscheidung für die Migration treffen zu können, indem sie den Quellcode analysieren und meist in Verbindung mit Consulting-Dienstleistungen verkauft werden.

Wiederverwendung von XAML
Da die User Interfaces von Silverlight mit der Beschreibungssprache XAML definiert werden, könnte man auf die Idee kommen, eine Silverlight-Anwendung einfach nach WPF zu konvertieren. Dies gestaltet sich in der Praxis jedoch nicht so einfach. Die XAML-Definitionen von Silverlight und WPF unterscheiden sich in einigen Details. Silverlight verwendet andere .NET Klassen und Basisklassen, die zwar ähnlich aber nicht exakt kompatibel sind, so dass unabhängig von XAML der Quellcode im Code-Behind angepasst werden muss. Und schliesslich muss eine WPF-Anwendung normalerweise auf den Client-PCs verteilt werden, während eine Silverlight-Anwendung eine Web-Anwendung ist.
WCF RIA Services
Eine weitere Schwierigkeit ist, dass in Silverlight-Business-Anwendungen meistens die WCF RIA Services zum Einsatz kamen. Die WCF RIA Services wurden damals von Microsoft als State-of-the-Art-Architektur, unabhängig von Silverlight, beworben. Diese Architektur hat sich nie wirklich durchgesetzt und existiert heute nur noch als relativ bedeutungsloses Open-Source-Projekt. WFC RIA Services sorgen u.a. durch Code-Generierung auf dem Client für eine sehr enge Kopplung zwischen der Server- und der Client-Logik. In heutigen Micro-Service-Zeitalter will man jedoch flexibler sein. Wir empfehlen, eine auf WCF RIA Service basierte Architektur durch REST-Services oder Graph-QL zu ersetzen. Häufig können dabei auch Teile des Quellcodes wiederverwendet werden.
Ist Blazor das neue Silverlight?

Häufig wird „Blazor“ als Nachfolgetechnologie für Silverlight ins Spiel gebracht. Dabei hat Blazor mit Silverlight nur die Idee gemeinsam, dass in C# geschriebener Code direkt im Browser ausgeführt wird. Als Beschreibungssprache für das User-Interface verwendet Blazor das sogenannte „Razor“-Format, das im Grunde ein HTML-Code ist, in den C#-Code eingebettet werden kann. XAML-Code kann in Blazor nicht wiederverwendet werden.

Im Wesentlichen unterscheidet sich Blazor kaum von den Konzepten populärer Javascript-Frameworks, wie Angular oder Vue.js, nur dass nicht Javascript oder Typescript, sondern C# als Entwicklungssprache eingesetzt wird. Die Trennung von Design und Code erfolgt in ähnlicher Weise.

Die Frage, ob sich Razor langfristig durchsetzen kann, ist offen. Alle grossen Toolhersteller, wie z.B. Telerik, Infragistics, oder Devextreme haben zwar umfangreiche Bibliotheken für Blazor mit an Bord. Allerdings bleibt die negative Erfahrung mit Silverlight im Hinterkopf, die durchaus auf Blazor abfärben könnte. Man möchte einfach keine Experimente mehr machen und nur noch die Technologien einsetzen, die wirklich zukunftssicher sind, weil sie von den meisten Entwicklern eingesetzt werden und keine weiteren Anforderungen an den Browser stellen als HTML, CSS und Javascript.

Auf welches Pferd setzen?

Diese Frage haben sich in den letzten Jahren viele Entwickler und Plattform-Verantwortliche gestellt. Etliche Frameworks haben leider nur noch eine Halbwertszeit von wenigen Jahren. Kaum hat man sich für ein Framework entschieden und sich eingelernt, gibt es schon das nächste, das noch besser und populärer ist.

Um einen besseren Eindruck zu bekommen, hilft ein Blick zu den Trends von Stack Overflow. Die Plattform führt eine Statistik zu Anfragen, die Entwickler bei ihrer Arbeit haben. Daraus lässt sich eine Tendenz ableiten, wie häufig ein Framework oder eine Technologie in Projekten weltweit eingesetzt wird.

Hier ist klar erkennbar, dass es für Silverlight bereits 2011 bergab ging und das Framework ab 2014 nahezu bedeutungslos war. Auch für WPF geht es seit 2009 kontinuierlich bergab, allerdings liegt WPF auch heute noch in der Statistik vor Blazor. Das liegt aber auch daran, dass Blazor eine noch neue Technologie ist, die es erst seit 2019 gibt. Interessant ist, dass auch Angular seit 2018 an Popularität eingebüsst hat, während react seit 2015 einen nahezu ungebremsten Aufwärtstrend erlebt. Auch vue.js wurde seit 2016 sehr beliebt und ist es auch heute noch. Natürlich muss man auch berücksichtigen, dass die Fragen der Entwickler mit der Zeit abnehmen, wenn ein Framework schon länger am Markt ist. Auch kann es sein, dass eine Technologie sehr einfach und schnell erlernbar ist und deshalb für weniger Fragen bei Stackoverflow sorgt. Die Statistik stellt dennoch eine gute Entscheidungshilfe dar.
Fazit
  • Um eine Silverlight Anwendung abzulösen, gibt es kein Patentrezept.
  • Zuerst sollte eine Analyse der Anwendung vorgenommen werden.
  • Aufgrund der Analyse und des Business-Cases wird die Zielarchitektur definiert.
  • Werden modernen Entwicklungs-Frameworks genutzt, sind diese zu berücksichtigten.
  • Sind noch keine Frameworks im Einsatz, kann die Verbreitung von modernen Ansätzen eine Entscheidungshilfe darstellen.
Unser Angebot

Stehen Sie vor einer Silverlight-Migration? Gerne unterstützen wir Sie mit einer Analyse und der Empfehlung für die neue Zielarchitektur.
Oder suchen Sie nach einem Umsetzungspartner zur Applikations-Ablösung? Unser erfahrenes Entwicklungs-Team freut sich auf eine Herausforderung.