.NET 5 klopft nicht mehr nur leicht an die Tür, es trommelt vielmehr in ohrenbetäubender Lautstärke. Seit Microsoft angekündigt hat, dass das klassische .NET zukünftig nicht mehr unterstützt wird, stellt sich kaum noch die Frage ob, sondern nur noch wann, eine Migration notwendig wird.
In dieser Dev Session betrachten wir deshalb zunächst was es mit den verschiedenen .NET Versionen auf sich hat und wie sich diese über die Jahre entwickelt haben. Anschließend migrieren wir eine WPF Anwendung und betrachten hierbei das Vorgehen, sowie die damit verbundenen Herausforderungen. Dabei gehen wir auch auf die Zukunft von so wichtigen Bestandteilen wie Entity Framework und Windows Communication Foundation ein. Abschließend behandeln wir Migrationsszenarien bei denen nicht die gesamte, sondern nur Teile von Anwendungen migriert werden und erläutern die damit verbundenen Migrationsstrategien beispielhaft.
4. 2012
Version 4.5
Task-Based
Async Model,
.NET APIs for
Store/UWP
Apps
2010
Version 4.0
CLR 4.0,
Parallel LINQ,
Task Parallel
Library
2007
Version 3.5
LINQ, Entity
Framework,
REST, AJAX
2003
Version 1.1
ASP.NET
Mobile
Controls,
Event und
Delegate2002
Version 1.0
ASP.NET,
ADO.NET,
WinForms,
Framework
Class Library,
CLR 1.0,
Web Services
2006
Version 3.0
WPF, WCF,
WF,
Card Space,
Lambda-
Expression
2005
Version 2.0
CLR 2.0,
Generics,
Anonyme
Function
5. STAND 2019
.NET STANDARD
Allgemeine Infrastruktur
Laufzeitkomponenten Compiler Sprachen
.NET FRAMEWORK
WPF
ASP.NET
WinForms
.NET CORE
UWP
ASP.NET Core
XAMARIN
iOS
OS X
Android
Quelle: https://devblogs.microsoft.com/dotnet/introducing-net-standard
6. .NET STANDARD
Wie .NET Standard funktioniert
DataInput.Models
class Project:
System.Object
System.Runtime.dll
System.Object
netstandard.dll
MainWindow.xaml
dll Referenz
.NET Core
Type Forwarding
Quelle: https://devblogs.microsoft.com/dotnet/introducing-net-standard
9. Juli 2019
.NET Core 3.0
RC
Sep 2019
.NET Core 3.0
GA
Nov 2019
.NET Core 3.1
LTS
Nov 2020
.NET 5.0
GA
Nov 2021
.NET 6.0
LTS
Nov 2022
.NET 7.0
GA
Nov 2023
.NET 8.0
LTS
VON .NET CLASSIC ZU .NET 5 UND FOLGEND
Quelle: https://devblogs.microsoft.com/dotnet/introducing-net-standard
11. Blazor Server
• Alle Interaktionen
werden auf dem Server
behandelt
Blazor WebAssembly
• Web App die
clientseitig ausgeführt
wird
• Kann offline arbeiten
Blazor PWA
• Erscheint als native
Anwendung (Windows)
• Kann offline oder
online benutzen
Blazor Hybrid
• Native .NET rendert zu
Electron / WebView
• Erscheint als native
Anwendung (Windows)
• Kann offline oder
online benutzen
Blazer Native
• Gleiches
Programmiermodel,
aber in non-HTML UI
rendern
Blazor!
WAS KOMMT DANACH?
Web
Desktop
+ Mobile
Icon made by Eucalyp, Freepik from www.flaticon.comThe Future of Blazor on the clientQuelle:
13. › Refactoring
› Kleinteilige Anpassung der Struktur ohne Verhaltensänderung
› Restrukturierung
› Großflächige Anpassung der Struktur ohne Verhaltensänderung
› Migration / Portierung
› Übertragung vorhandener Funktionalität oder Daten auf neue technische Basis
› Sanierung
› Versetzen des Systems in seinen ursprünglich geplanten bzw. einen verbesserten Zustand
DEFINITIONEN
22. PRÜFEN & AKTUALISIEREN EXTERNER ABHÄNGIGKEITEN
Reicht nicht
Perfekt
Man muss nicht zwangsläufig die neuste Version nehmen!!!
http://fuget.org
23. Selbst schreiben
PRÜFEN & AKTUALISIEREN EXTERNER ABHÄNGIGKEITEN
Riskant wenn es keine Unterstützung für .NET
Core gibt.Aktuelle Version
Neuere Version
Separates Paket
Alternative
Möglicherweise gibt es Änderungen an der API
oder dem Verhalten.
Aufwändige Konfiguration.
Möglicherweise breaking Changes.
Breaking Changes sind gewiss.
Aufwändige Anpassungen notwendig.
Ungeplante Umsetzungsaufwände.
Bei kleineren Werkzeugen aber durchaus eine Lösung.
30. Bestandteil Erscheinung
seit .NET Framework
Version
in .NET Core 3.0
verfügbar
Name in .NET
Core
Migration
möglich
Alternative
ASP.NET 2002 1.0 Ja ASP.NET Core normal
ASP.NET Web Froms 2002 1.0 Nein unmöglich Blazor
ADO.NET 2002 1.0 Ja** SqlClient normal
Windows Forms (WinForms) 2002 1.0 Ja* normal
Common Language Runtime
(CLR)
2002 1.0 Ja CoreCLR leicht
.NET Remoting 2002 1.0 Nein unmöglich
Event und Delegate 2003 1.1 Ja leicht
Generics 2005 2.0 Ja leicht
Anonyme Funktion 2005 2.0 Ja leicht
Windows Presentation
Foundation (WPF)
2006 3.0 Ja* normal
Windows Communication
Foundation (WCF)
2006 3.0 Ja** CoreWCF schwer Siehe nächste Foile
Windows Workflow
Foundation (WF)
2006 3.0 Ja** CoreWF schwer
Windows CardSpace 2006 3.0 Nein unmöglich
Lambda-Ausdruck 2006 3.0 Ja leicht
Language Integrated Query
(LINQ)
2007 3.5 Ja leicht
Microsoft Silverlight 2007 3.5 Nein unmöglich Blazor, Angular, VueJS
Entity Framework (EF) 2007 3.5 Ja EF Core schwer
Parallel LINQ (PLINQ) 2010 4.0 Ja leicht
Task Parallel Library (TPL) 2010 4.0 Ja leicht
Task-based Async Pattern
(TAP)
2012 4.5 Ja leicht
.NET APIs for Store/UWP Apps 2012 4.5 Ja leicht
*: nur auf Windows verwendbar
**: nicht vollständig kompatibel
32. Kriterium gRPC
Web API mit ASP.NET
Core
SignalR CoreWCF IPC Service Framework
Unterstützung für
komplexe
Anwendungen
einige WCF-Features
verfügbar
Sehr gut
einige WCF-
Features
realisierbar
wie WCF
Funktionsumfang
könnte zu gering sein
Performance sehr gut Sehr gut gut
(voraussichtlich) wie
WCF
k.a.
Migrationsaufwand
ähnliches Konzept wie
WCF, Funktionalität kann
weiter verwendet werden
Rewrite der
Vermittlungsschicht
Wrapper vorhanden,
allerdings anderes
Konzept
(voraussichtlich)
keiner oder minimal
Je nach Szenario gering
bis sehr hoch.
Kompatibilität eigenes NuGet-Paket
Komplett anderes
Vorgehen
ASP.NET-Core-
Feature
noch nicht für
Produktiveinsatz
geeignet
Ähnliches Vorgehen
anderer Ansatz
Sicherheit SSL/TLS SSL/TLS SSL/TLS (vermutlich) wie WCF SSL/TLS
Besonderheit Empfehlung von Microsoft
Clients und Server sind
unabhängig
Bidirektionale
Kommunikation
Ist möglicherweise am
nahest an WCF
Leichtgewichtig, gut für
kleinere Projekte
WCF - ALTERNATIVEN
Ab Januar 2020: https://github.com/saxsys/Vergleich-WCF-Alternativen
34. Neue Solution / neues Projekt anlegen und alle Quellen kopieren
• Bei kleinen Projekten die einfachste Lösung
• Bei großen Projekten fehleranfällig
Projektdateien ersetzen
• Harte Migration
• Kein XAML Designer
Projekt mit Multitarget
• Aktuell sehr fehleranfällig
Eigene Solution die die Quellen einbindet
• Beide Lösungen können auseinander laufen
• Aufwändiger Build
Mehrere Projektdateien mit eigenem Buildtarget in einer Solution
• Aufwändig zu warten
• Kann verwirrend sein
MIGRATION DER PROJEKTDATEIEN
Wahl der Qual
54. EF VS. EF CORE
Quelle: https://docs.microsoft.com/de-de/ef/efcore-and-ef6/porting/
Quelle: https://docs.microsoft.com/de-de/ef/efcore-and-ef6/index
55. public class DataContext : DbContext
{
public DbSet<Publication> Publications { get; set; }
public DbSet<Medium> Media { get; set; }
public DbSet<Project> Projects { get; set; }
public DbSet<Publisher> Publishers { get; set; }
public DataContext()
{
}
protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
if (!optionsBuilder.IsConfigured)
{
var connection = new SqliteConnection("DataSource=:memory:");
connection.Open();
optionsBuilder.UseSqlite(connection);
}
}
}
LOGISCHE FEHLER LÖSEN
56. ANPASSBARKEIT VS. BUSSINESS VALUE
Innere Qualität /
Anpassbarkeit
Business Value
Start der
Entwicklung
Featureentwicklung mit
geringem Qualitätsanspruch
Featureentwicklung
unter hohem Zeitdruck
Entfernen fehlerhafter
Bestandteile
Umfassende
Restrukturierung inkl.
neuer Features
Einsatz der
Pfadfinderregel
81. Analyse des
Bestandssystems
Zerlegung der
Systemstruktur
Design der
Zielschnittstellen
Design des
Zielsystems
Design der
Zieldatenbank
Aufbau
notwendiger
Gateways
Migration der
Legacy
Datenbanken
Migration der
Legacy
Applikationen
Migration der
Legacy
Schnittstellen
Abschalten des
Altsystems
CHICKEN LITTLE
Quelle: Brodie, M. L., & Stonebraker, M. (1995). Migrating Legacy Systems: Gateways, Interfaces & the Incremental Approach. San Francisco:
Morgan Kaufmann Publishers.
86. Migration des Legacy Systems
CHICKEN LITTLE
MainWindow
XAML
Logik
PublicationRepository
IPublicationRepository
„Gateway“
Entity Framework
EF Code
Schrittweise Übertragung
89. Vorteile
› Verringerung des gleichzeitigen Aufwandes durch
Schrittweises vorgehen
› Weniger Planung & Absprache notwendig als bei Alternative.
Nachteile
› Man migriert was da ist, nicht was sinnvoll ist.
› Änderungen an einer Schicht können sich auf das
Gesamtsystem auswirken.
› Fehler sind schwer einzugrenzen.
MIGRATION VON TECHNISCHEN SCHICHTEN
113. Vorteile
› Man migriert was gebraucht wird.
› Änderungen lassen sich besser planen und kommunizieren.
› Änderungen lassen sich anhand von Features organisieren.
› Verringerung des gleichzeitigen Aufwandes durch schrittweises Vorgehen.
Nachteile
› Hoher Planungs- und Kommunikationsaufwand.
› Es wird sehr viel mehr Zeit gebraucht.
MIGRATION VON FACHLICHEN KONTEXTEN
118. Hendrik Lösch
Senior Consultant & Coach
Hendrik.Loesch@saxsys.de
@HerrLoesch
Hendrik-Loesch.de
Frank Kubis
Consultant
Frank.Kubis@saxsys.de
@FrankKubis
Hinweis der Redaktion
.NET Standard ist wie ein Interface, dass dann von den Platformabhängigen Implementierungen realisiert wird.
.NET Core 3.0 wurde in September veröffentlicht
.NET Core 3.1 = Langzeitunterstütrung (LTS)
.NET 5.0 wird in November 2020 veröffentlicht
Hauptversion wird jedes Jahr veröffentlicht, LTS alle zwei Jahre
Planbar Schedule, Minor-Version wird im Bedarfsfall veröffentlicht
Eigentlich spricht man bei der Übertragung von Daten eher von Migration und bei der Übertragung von Funktionalität von Portierung. Beide Begriffe werden aber gern synonym verwendet.
Das hilft dabei, sich bei der Umstellung auf das wichtige zu konzentrieren.
Mit FuGet kann man prüfen wie sich die API der externen Abhängigkeiten geändert hat. Man kann aber auch im NuGet Explorer nachsehen.
Einige Pakete, welche .NET Framework unterstützen, funktionieren auch unter .NET Core. Diese Pakete weiter zu verwenden ist jedoch riskant, da es passieren kann, dass das Paket versucht eine .NET-API aufzurufen, welche unter .NET Core nicht verfügbar ist, was wiederum eine RuntimeException zur Folge hätte.
Manchmal unterstützen neuere Versionen als die derzeit verwendete .NET Core. Es kann jedoch sein, dass die neuere Version Veränderungen enthält, welche anderweitige Probleme mit sich führen können. Informationen zum Aktualisieren des Pakets finden sich im nächsten Abschnitt.
Manchmal gibt es von einem Paket separate .Core- bzw .NetCore-Pakete, welche stattdessen verwendet werden können.
Sind alle Alternativen erschöpft, muss nach einem alternativen Paket gesucht werden, welches das aktuelle ersetzen kann. Dies ist jedoch mit deutlichem Mehraufwand verbunden.
Man könnte den Stand auch schon ausrollen und ein paar Wochen in Produktion laufen lassen!
.NET Core ist Plattformunabhängig. Wollen wir also auch WPF zum Laufen bekommen brauchen wir die Plattform Extensions für Windows!
.NET Core ist Plattformunabhängig. Wollen wir also auch WPF zum Laufen bekommen brauchen wir die Plattform Extensions für Windows!
Die Prozentangaben sagen nicht aus, dass die API sind die wir nutzen, sondern die angeboten werden!
gRPC
gRPC wurde ursprünglich von Google entwickelt und besitzt ein ähnliches Konzept wie WCF. Es werden Contracts definiert, aus welchen anschließend das Codegerüst für Client und Server generiert werden kann. Hierzu wird eine eigene Sprache, die Interface Definition Language (IDL), verwendet. Der generierte Code beinhaltet bereits alles, was zum Ausführen des Services benötigt wird, sodass sich der Entwickler auf die Implementierung der Funktionalität konzentrieren kann. gRPC nutzt eine HTTP-Verbindung.
gRCP unterstützt weiterhin einige komplexere Fähigkeiten von WCF, wie Full-Duplex Messaging over TCP. Der generierte Code arbeitet sehr effizient und kümmert sich um die (De-)Serialisierung der Daten und Requests/Reponses. Für die Serialisierung wird Protobuf verwendet, welches Traffic-arm und speichereffizient arbeitet. Dadurch lassen sich gRCP-Projekte sehr gut skalieren. gRCP-Projekte lassen sich direkt aus Visual Studio heraus erstellen.
CoreWCF
Bei CoreWCF handelt es sich um eine quelloffene Portierung von WCF zu .NET Core, welche von der .NET Foundation unterstützt wird. Die Portierung ist grundsätzlich lauffähig, allerdings noch nicht für produktive Umgebunden geeignet.
ASP.NET
Quelle: https://dotnet.microsoft.com/apps/aspnet (abgerufen am 14.11.2019, 17:45 Uhr)
ASP.NET ergänzt .NET um Tools und Bibliotheken zur Entwicklung von Web Apps. Microsoft teilt die Features von ASP.NET dabei in vier Bereiche auf:
Web Apps
ASP.NET bietet die Möglichkeit, Web Apps mit HTML5, CSS, JavaScript und C# zu bauen. Mittels Entity Framework lässt sich einfach auf bestehende Daten aus den meisten beliebten Datenbanksystemen zugreifen. Außerdem ist eine Nutzerdatenbank mit Unterstützung für Muti-Factor-Authentication und Authentifizierung über Drittservices integriert. Dynamische Inhalte lassen sich mittels der Markup-Sprache Razor einfach erstellen. ASP.NET Web Apps sind nach dem Model-View-Controller-Prinzip aufgebaut.
APIs
Mit ASP.NET lassen sich einfach REST APIs erstellen, welche ein einfaches Request-Response-Verfahren zur Abfrage von Daten von einem Server bereitstellen. ASP.NET setzt standardmäßig auf HTTPS und bietet mehrere Möglichkeiten der Authentifizierung/Autorisierung, wie JSON Web Tokens und Policies. Daten werden automatisch zu JSON serialisiert. […]
Real-time (WebSockets/SignalR)
WebSockets stellen eine einfache Möglichkeit dar, eine Client-Server-Verbindung herzustellen und über diese Daten auszutauschen. WebSockets sind message-agnostic, die zu sendenden Nachrichten können also in jedem beliebigen Format vorliegen, solange der Empfänger mit diesem umgehen kann.
SignalR ist ein ASP.NET-Core-Feature, welches einen einfachen Wrapper für WebSockets bereitstellt. Es bietet Unterstützung für JSON- und MessagePack-Serialisierung und besitzt einen geringen Netzwerk-Overhead.
Alte und neue Projektdatei im Vergleich
.NET Core 3.0 verwendet ein neues Format für die Projektdatei.
Im <Project>-Element wird das vom Projekt verwendete SDK angegeben.
Die größte Änderung ist, dass sämtliche Quelldateien (C#, resx, XAML) in Zukunft nicht mehr explizit in der Projektdatei angegeben werden. Stattdessen werden diese in Visual Studio automatisch dem Projekt hinzugefügt. Dadurch wird die Projektdatei deutlich übersichtlicher.
In .NET Core werden NuGet-Pakete global statt pro Projekt installiert und die pro Projekt genutzten Pakete einfach in der Projektdatei mittels <PackageReference> referenziert.
Weiterhin generiert eine .NET Core 3.0 App automatisch Assembly-Attribute (z.B. Titel, Autor, Version der App). Damit diese selbst angegeben werden können, muss <GenerateAssemblyInfo>false</GenerateAssemblyInfo> hinzugefügt werden.
Falls noch nicht passiert, jetzt muss man es auf jeden Fall tun.
Der Halen bei „Vorabversion einbeziehen“ muss gesetzt sein.
Nicht nur das sich die Frameworks anders verhalten. Man stolpert auch über Fehler die ohnehin schon in der Software stecken ohne, dass man es bisher gemerkt hat.
Man beachte auch, dass die Pfeile immer kürzer werden.
Verringerung des Ressourcenbedarfs.
Optimierung des Quellcodes durch vereinheitlichte Konzepte.
Ablösen alter Frameworks durch neue.
Das Softwaresystem war ein Monolith. Wir haben Teile des Monolithen verändert. Damit wurden unsere Änderungen Teil des Monoliths und wir übernahmen die Verantwortung für alle Fehler die darin enthalten sind.
Das Softwaresystem war ein Monolith. Wir haben Teile des Monolithen verändert. Damit wurden unsere Änderungen Teil des Monoliths und wir übernahmen die Verantwortung für alle Fehler die darin enthalten sind.
Es wird an anderen Features, nicht aber an der Migration gearbeitet. Dadurch bekommen die Stakeholder ihre Wertsteigerung, es wird erst einmal nach Fehlern bei der Migration gesucht und die Migration blockiert nicht die gesamte Entwicklung.
Es wird an anderen Features, nicht aber an der Migration gearbeitet. Dadurch bekommen die Stakeholder ihre Wertsteigerung, es wird erst einmal nach Fehlern bei der Migration gesucht und die Migration blockiert nicht die gesamte Entwicklung.
Es wird an anderen Features, nicht aber an der Migration gearbeitet. Dadurch bekommen die Stakeholder ihre Wertsteigerung, es wird erst einmal nach Fehlern bei der Migration gesucht und die Migration blockiert nicht die gesamte Entwicklung.
Farben – Fachlichkeit
Vierecke – Teams
Schwarze Pfeile – Upstream Beziehung
Rote Pfeile – Schlecht gewählte Upstream Beziehungen
Orangene Pfeile – Partnerschaftliche Beziehungen
Legt man die Verantwortlichkeiten der Teams darüber, merkt man, wo Abhängigkeiten zwischen den Teams bestehen. Hier ist es insbesondere schwierig, weil Partnerschaftliche Beziehungen zwischen Modulen bestehen die bei unterschiedlichen Teams liegen. Außerdem liegen Module der gleichen Fachlichkeit bei unterschiedlichen Teams.
Grüne Pfeile -> bewusste Abhängigkeitsumkehr.
Die Quellcodemenge die zu betreuen ist, ist fast noch die gleiche. Team 1 hat etwas mehr zu tun.
Farben – Fachlichkeit
Vierecke – Teams
Schwarze Pfeile – Upstream Beziehung
Rote Pfeile – Schlecht gewählte Upstream Beziehungen
Orangene Pfeile – Partnerschaftliche Beziehungen
Legt man die Verantwortlichkeiten der Teams darüber, merkt man, wo Abhängigkeiten zwischen den Teams bestehen. Hier ist es insbesondere schwierig, weil Partnerschaftliche Beziehungen zwischen Modulen bestehen die bei unterschiedlichen Teams liegen. Außerdem liegen Module der gleichen Fachlichkeit bei unterschiedlichen Teams.
Grüne Pfeile -> bewusste Abhängigkeitsumkehr.
Die Quellcodemenge die zu betreuen ist, ist fast noch die gleiche. Team 1 hat etwas mehr zu tun.
Klare fachliche Trennung einzelner Module.
Fachliche wie technische Bestandteile können leicht ausgetauscht oder verändert werden.
Gerichtete und damit nachvollziehbare Abhängigkeiten.
Änderungen wirken sich nur auf einen definierten Teilbereich aus und sind frei von Nebeneffekten.
Kommunikation nur über abstrakte Schnittstellen.
Es ist leicht automatisierte Tests zu verfassen und Bestandteile unabhängig voneinander zu betrachten.
Zusammensetzung der Anwendung durch entsprechende Modulaggregatoren und eine Rahmenapplikation.
Definierte Schlüsselpunkte weisen hohe Komplexität auf, alle anderen eher geringe.
Einheitliches Vorgehen bei der Umsetzung neuer Funktionalität.
Geringer Einarbeitungsaufwand.
Anwendung wird geklont. Ab der Stelle wo sie geklont wurde, laufen sie bewusst auseinander und kümmern sich nicht mehr umeinander.
Der Code wird aufgespalten Man entfernt die anderen Bestandteile komplett.
Es wird nur das entfernt was definitiv nicht gebraucht wird. Alles andere bleibt drin, selbst wenn es ggf. nicht benötigt wird.
Die gemeinsamen Bestandteile werden wieder zusammen geführt und den anderen Teilen zur Verfügung gestellt.
Die gemeinsamen Bestandteile werden wieder zusammen geführt und den anderen Teilen zur Verfügung gestellt.
Die gemeinsamen Bestandteile werden wieder zusammen geführt und den anderen Teilen zur Verfügung gestellt.
Das System wird in viele, völlig eigenständige Systeme (Self-Contained Services zerlegt).