“Das .NET Framework 4.5 geht uns nichts an – wir bauen gegen .NET 4.0!” werden Sie jetzt evtl. denken. Doch der Schein trügt. Sobald auf der Maschine auf der Ihre Applikation ausgeführt wird .NET 4.5 installiert ist, wird auch Ihre Applikation Assemblies aus dem neuen .NET Framework verwenden. Wir zeigen Ihnen worauf Sie achten sollten zur Entwicklungs-, Compile- und Laufzeit…
Über die Neuerungen von .NET 4.5 haben wir bereits in unserer Blogserie berichtet: Neu in .NET 4.5
Warum ist das für mich relevant?
Was vielen unserer Kunden entgangen ist, ist die Tatsache, dass auch Projekte von den Änderungen betroffen sind, die gar nicht gegen .NET 4.5, sondern gegen .NET 4.0 gebaut werden. Der Schein trügt: das .NET Framework 4.5 ist ein Inplace-Upgrade welches tw. Assemblies aus dem .NET Framework 4.0 austauscht!
Das hat tw. große Auswirkungen! Microsoft hat die Details zur Kompatibilität und den Änderungen hier zusammengefasst: Breaking Changes in .NET 4.5
Was bedeutet das zur Laufzeit?
Zunächst einmal zur Laufzeit: einmal gegen .NET 4.0 gebaut, kann Ihre Applikation auf dem Client der diese ausführt auf .NET 4.5 treffen. Damit werden auch von Ihrer Applikation die neuen Assemblies angezogen und verwendet. Dadurch können sich merkwürdige Effekte einstellen oder die Applikation gar nicht mehr funktionieren. Wir haben bereits Probleme im Namespace System.Reflection festgestellt, die eine Applikation völlig zum Erliegen gebracht haben.`
Das hat in Konsequenz zur Folge, dass Sie Ihre Applikation auf beiden Systemen (eines ohne und eines mit .NET 4.5) testen müssen. Theoretisch komplett… oder aber Sie bauen Ihre Applikation gleich gegen .NET 4.5 und unterstützen dann nur dieses Szenario. Was allerdings dem Support für Windows XP widerspricht. Oder wie es Microsoft ausdrückt:
Important: Note that the .NET Framework 4.5 is not supported on Windows XP.
Und das bringt uns zum Compile…
Was bedeutet das zur Compile- und Test-Zeit?
Für die Kompilierung bedeutet das, dass auf Build-Umgebungen mit .NET 4.5 auch gegen die ausgetauschten .NET 4.0 Assemblies gebaut wird – selbst wenn in den Visual Studio Projekteinstellungen 4.0 als Target Framework eingestellt ist. Hinzu kommt, dass bei der Verwendung von Team Foundation Server 2012 die Build-Umgebung immer auch .NET 4.5 gleich mitbringt, da der Team Foundation Build Service dieses implizit mitinstalliert. Soweit so gut, das mag ja noch verkraftbar sein – sollte in jedem Falle aber z.B. vor einem Upgrade von TFS 2010 geprüft werden.
Gravierender ist die Sache, wenn man im Build automatisierte Unit-Tests ausführt. Da diese Laufzeitaspekte prüfen, wird im Falle der Ausführung im TFS-Build-Prozess quasi gegen .NET 4.5 getestet. Und daran führt auf dem Build-Server kein Weg vorbei. Einziger Ausweg, um auch auf reinen .NET 4.0 Systemen zu testen, ist es einen Visual Studio 2010 Test Agent auf einer separaten Maschine ohne .NET 4.5 zu installieren und die Tests im Build-Prozess Remote auf dieser Maschine auszuführen. Der Test Agent 2010 ist kompatibel zum neuen TFS 2012, weshalb sich die Ergebnisse auch wieder in den TFS zurücksenden lassen. Wie dies genau konfiguriert werden muss, haben wir bereits in einem früheren Blogbeitrag für Sie zusammengestellt: CodedUI-Tests ohne Lab Management ausführen
Was bedeutet das zur Entwicklungszeit?
Für die Entwicklung hat das auch Auswirkungen. Bei der Installation von Visual Studio 2012 wird ebenfalls .NET 4.5 implizit installiert. Das hat zur Folge, dass evtl. Entwicklungs-Tools, die in Visual Studio 2010 bzw. mit .NET 4.0 laufen, nicht mehr funktionieren. Uns ist das mit Moles – dem bisherigen Mocking-Framework von Microsoft Research – aufgefallen. Dieses verweigerte seinen Dienst, nach der Installation von VS 2012 und ließ sich auch nach einer Deinstallation von VS 2012 im alten Visual Studio 2010 nicht mehr zum Laufen bringen.
Fazit
Die Entscheidung, ob man .NET 4.5 unterstützt oder nicht wird einem also durch das Inplace-Upgrade abgenommen. Man kommt nicht umhin Applikationen entsprechend zu testen bzw. den Komplettumstieg zu machen.
Bei Fragen können Sie sich gerne direkt an uns wenden: [email protected] Wir helfen Ihnen gern!