Die.NET Geschichte
Wie und wann alles begann Nachfolgeversion von COM+ (Component Object Models) Next Generation Windows Services (NGWS) Umbenennung in.net (Jahre 2000) Version 1.0 Januar 2002
Motivation Einheitliche Laufzeitumgebung (CLR) VB, C++ C#, andere.net Sprachen Garbage-Collector statt Reference-Counting Runtime Hosts Windows (Shell) IE (Geplant für DHTML-Anwendungen) IIS (ASP.NET) Einheitliche Klassenbibliothek Format(1.234, "#.#") vs. sprintf(str, "%3.1f", 1.234) MSIL und Just-in-Time-Compiler Optimale Ausnutzung der vorhandenen CPU
Neue Technologien CPUs mit unterschiedlichen Befehlssätzen AMD 3DNow! Multimedia-Befehlssatzerweiterung 1998 : AMD K6-2 Intel Streaming SIMD Extensions (SSE) 1999 : Pentium-III-(Katmai) Windows NT 4 (1996-2000) X86, MIPS, später auch PowerPC und Alpha Multicore (2006) AMD Athlon 64 FX, Intel Core Duo Hyper-Threading
Übersetzung in Maschienencode
Neue Anwendungsgebiete 2003 SPOT (Smart Personal Object Technology)
Timeline 2002 03 04 05 06 07 08 09 10 11 12 13 14 15.NET Framework 1.0 1.1 2.0 3.0 3.5 3.5.1.NET Compact Framework (NETCF) 4.0 4.5 4.5.1 4.5.2 4.6 1.0 2.0 3.5 3.9.NET Micro Framework (NETMF) Open Source 1.0 2.0 2.5 3.0 4.0 4.1 4.2 4.3 Mono Xamarin 0.9 1.0 2.0 2.10 3.0 3.12
.NET Core Hintergrund Info s Quelle:.NET Framework Blog http://blogs.msdn.com/b/dotnet/ archive/2014/12/04/introducingnet-core.aspx
Ein Rückblick Motivation für.net Core.NET Ein Satz von Verticals Quelle: http://blogs.msdn.com/b/dotnet/archive/2014/12/04/introducing-net-core.aspx
Die Geburt der PCL (Portable Class Libraries) Es gab bis dato kein Konzept, um übergreifend Libraries auszutauschen. Code Sharing mittels Linked Files Partial Classes #if def Abgeleitete Klassen
PCL Vor Windows 8 Seit Windows 8
PCL Contract Assembly Windows Desktop Windows Phone ASP.NET 5 App Model App Model App Model Platform spezifische Assembly PCL Contract Assembly Platform spezifische Assembly Platform spezifische Assembly
PCL- Contract Assembly
API Vereinheitlichung anstatt Code Vereinheitlichung Die verfügbare Funktionialität beeinflusst das API-Design. z.b. ACL ist nicht auf allen Platformen verfügbar Ergo wandert diese Funktionalität in ein eigenes API/Assembly, damit dieses weggelassen werden kann, wenn es nicht benötigt wird.
Maschinen weites Framwork vs. Application Lokales Framework Maschinenweit Einige Vorteile Zertralisierte Aktualisierung Disk Space Reduzierung
Maschinen weites Framwork vs. Application Lokales Framework Maschinenweit Einige Nachteile Man benötigt als Entwickler auf der Zielumgebung ein installiertes.net Framework oder man bringt die Installation mit. Man muss sich mit dem begnügen was man auf der Zielumgebung findet. Eine Aktualisierung durch meine Application kann andere Applikationen beinträchtigen.
Maschinen weites Framwork vs. Application Lokales Framework Kompatible Änderungen Selbst kompatible Anpassungen können bestehende Applicationen beeinflussen. Ein Interface hinzufügen => Die Serialisierung kann sich verändern Ein Overload hinzufügen => Die Anzahl der Methoden ändert sich Einen internen Type umbenennen => To String verändert sich 99,9% Kompatibilität bei 1.8 Millarden Maschinen => 1.8 Millionen nicht klappt
Maschinen weites Framwork vs. Application Lokales Framework Applikationslokal Einige Vorteile Man hat alles unter Kontrolle als Entwickler. Man braucht nur noch seine Applikation installieren.
Maschinen weites Framwork vs. Application Lokales Framework Applikationslokal Einige Nachteile Der Disk Space, den man für seine Applikation hat wird mehr. Teilung von Assemblies wird eine wenig komplizierter. Man muss sich eventuell selber um die Aktualisierung der Microsoft Assemblies kümmern. Wie läuft das mit dem Update? So wie es aktuell auch für NuGet Packages laufen würde, die in der Applikation verbaut sind. Die Hersteller der Applikation ist dafür verantwortlich.
- Ein Neuanfang. Quelle: http://blogs.msdn.com/b/dotnet/archive/2014/12/04/introducing-net-core.aspx
.NET Core.NET Core ist eine modulare Implementation, welche in vielen Verticals benutzt werden kann..net Core ist im Grunde ein Fork des.net Frameworks, dessem Implementierung auf das Decomposition/Factoring Gesichtspunkte optimiert ist.
.NET Core Es skaliert vom Data Center zum Touch Based Device. Es wird von Microsoft für Windows, Linux und Max OSX supported.
Vereinheitlichung von.net Native und ASP.NET Quelle: http://blogs.msdn.com/b/dotnet/archive/2014/12/04/introducing-net-core.aspx
Verteilung über NuGet Quelle: http://blogs.msdn.com/b/dotnet/archive/2014/12/04/introducing-net-core.aspx
Nuget -.NET Core Pakete Für den BCL-Layer werden die NuGet Pakete so heißen wie die Komponten. z.b. wird das Paket Microsoft.Bcl.Immutable zu System.Collections.Immutable Die Assembly Nummern entsprechenden den Nummer des NuGet Paketes (Semantic Versioning). Vorteil: Man sieht gleich schon am NuGet Paket was drin ist und in welcher Version. Der Upgrade der.net Core Komponenten ist so einfach wie der Upgrade jeder anderen Komponente, die über NuGet verteilt wird...
NuGet Verteilung => Application Lokales Framework Man braucht nur das nehmen, was man für seine Applikation braucht. Smart Sharing Verschiedene Applikationen verwenden das selbe Framework (Sie arbeiten daran Stand Nov 2014) Ziel war es, dass ein Upgrade eines lokalen Frameworks keine Auswirkungen auf andere Applikationen hat. (Sieht gut aus ;o)
Ist das Enterprise Ready? Es wird einen Snapshot aller zusammenarbeitenden NuGet Packages geben, die wie heute als.net Framework in einer bestimmten Version angesehen werden können. Das Testen übernimmt Microsoft. Es wird darüber nachgedacht 4 mal im Jahr solch einen Snapshot anzubieten.
Security vs. NuGet Packages Kein Problem, Microsoft wird Security Fixes bereitstellen, ob dass dann über Windows Update läuft. Schauen wir mal.
.NET Foundation.NET Core ist Open Source. Eine Chance für.net noch schneller zu wachsen auf allen Platformen. Quelle: http://blogs.msdn.com/b/dotnet/archive/2014/12/04/introducing-net-core.aspx
Wie steht.net Core zu den existierenden Platformen? 8? Irre. Wir müssen einen universellen Stack umsetzen das jeden SITUATION: Use Case abdeckt There a 8 competing stacks Yes! Bald SITUATION: There a 9 competing stacks
.NET Framework 4.6 Zuerst ist wohl das Ziel mit Visual Studio 2015, dass.net Core ein Subset des neuen.net Frameworks 4.6 ist. Wenn.NET Core released ist, wird es sich aber wahrscheinlich schneller entwickeln als das.net Framework und einige Features werden dann wahrscheinlich auch nur dort enthalten sein. :o(
.NET Framework 4.6 Es wird weiterhin Updates für das.net Framework geben. Geplant ist ca. einmal im Jahr. Innovationstransfer.NET Core =>.NET Framework. Es wird aber auch Bestandteile geben, die es nur im.net Framework geben wird z.b. WPF. -??? - Wie kriege ich das jetzt übereinander?
Mono vs..net Core Mono ist wie das.net Framework mit all seinen Problemen und einer gewissen Komplexität. Die Komplexität ist auch das Problem, warum das.net Framework nicht Open Source wird
Mono vs..net Core Statement: Another way to look at it: The.NET Framework has essentially two forks. One fork is provided by Microsoft and is Windows only. The other fork is Mono which you can use on Linux and Mac..
Mono vs..net Core Wenn man das so betrachtet, dann wird Mono das selbe Schicksal erleiden wie das.net Framework und.net Core wird beide in Zukunft ablösen.. (So meine Einschätzung) Mal wieder ein harter Schritt den was empfehle ich meinem Kunden. Wie spielt das Ganze mit WPF zusammen
Windows Store & Windows Phone.NET Core wird dort Einzug halten. und man ist nicht mehr so abhängig von Framework Releases, was auch die Innovationsgeschwindigkeit erhöhen soll..
Code Sharing -.NET Core /.NET Framework in der eigenen Applikation Portable Class Libraries (Sharing Binaries) Das wird bestimmt spannend, wenn man im.net Framework.NET Core Sachen benutzen möchte. Shared project (Shared Code on Steroids) Das #if def wird es noch eine Weile geben.. Wird benutzt in Universal Apps.
Summary.NET Core ist ein neuer Stack, der auf die Open Source Entwicklung optimiert ist. Es wird mit der Mono Community zusammengearbeitet, um eine gute Platform für Windows, Mac und Unix bereit zu stellen. Das Enterprise wurde nicht vergessen. Die Sicherheit wird nicht leiden.
Links Der Blog Eintrag, auf den diese Folien basieren ist zu finden unter http://blogs.msdn.com/b/dotnet/archive/2014/1 2/04/introducing-net-core.aspx Ein paar Intformationen zu Shared Projects und Protable Class Libraries http://blogs.msdn.com/b/dotnet/archive/2014/0 4/21/sharing-code-across-platforms.aspx
.NET Foundation http://www.dotnetfoundation.org/
.NET wird OpenSource
.NET Core 5.NET Core 5 Framework => corefx.net Core 5 Common Language Runtime => coreclr
.NET Compiler Platform ( Roslyn ) Irgendwas muss man ja haben, um.net auf den Platformen kompilieren zu können
Summary Der Schritt war nur logisch, um.net auf allen Platformen bereitstellen zu können.. Take.NET to the next Level Scott Gu (Build 2014)
Links.NET Foundation
Getting Started
Was braucht man Zeit Rechner/VM Geduld Rudimentäre GIT Kenntnisse Ausdauer
Betriebssystem Windows 8.1!!! PowerShell VisualStudio 2013 Community Edition DIA SDK (Debug Interface Access SDK) VisualStudio 2015 CTP 5 Compiler und Templates GIT Sourcecodeverwaltung CMake Build-Tool
Quellen https://github.com/dotnet coreclr.net Core runtime corefx foundational libraries roslyn The.NET Compiler Platform buildtools Build tools that are necessary for building projects corefxlab Demos
Build C:\git\coreclr>build clean Commencing CoreCLR Repo build Doing a clean build Checking pre-requisites...
10 Minuten später
Was hat man davon?
und
und
Windows 7 -
Debugging
Getting Started unter Linux
Was baucht man? Zeit Rechner/VM Rudimentäre GIT Kenntnisse Rudimentäre Linux Shell Kenntnisse (Rudimentäre Docker Kenntnisse) Ausdauer und Nerven
Betriebssystem ubuntu 14.04 LTS (eventuell Windows 8) GIT Sourcecodeverwaltung CMake (Version >= 2.8.12.2) Build-Tool LLVM (Version 3.5) Compiler-Unterbau-Architektur CLang (Version 3.5) Compiler Frontend LLDB (Version 3.5) Debugger Mono für Ubuntu.NET für Linux/Max/Windows. (Docker für Ubuntu) Container für die Softwareverteilung
Quellen https://github.com/dotnet coreclr.net Core runtime Dort die Anleitung, wie man das unter Ubuntu baut
Build /git/coreclr$./build.sh Commencing CoreCLR Repo build Doing a clean build Checking pre-requisites...
1 Minute später Failed to build coreclr
Build as Superuser /git/coreclr$ sudo./build.sh Commencing CoreCLR Repo build Doing a clean build Checking pre-requisites...
1 Minute später /git/coreclr/binaries/product/amd64/debug Corerun libcoreclr.so libmscordaccore.so libmscoredbi.so
mscorlib.dll Da noch kein bauen auf Linux aktuell unterstützt wird braucht man doch noch ein Windows 8 oder Docker (Dazu aber später mehr) D:\git\coreclr> build.cmd unixmscorlib => mscorlib.dll => What? D:\git\corefx> build.cmd /p:os=unix /p=skiptests
corefx Selber bauen (unter Windows) NuGet (https://www.myget.org/f/dotnet-corefx/) Docker (Aber dazu später mehr)
Selber bauen Sieht zuerst einmal gut aus, aber leider fehlt die System.Runtime.dll
NuGet benutzen Erst einmal Mono Installieren. Erst einmal curl installieren. Dann NuGet mittels curl holen. Dann die dll s aus aspnetcore50 ins runtime Verzeichnis kopieren (System.Runtime.dll is auch da - komisch) Dann noch ein HelloWorld.cs aus corefxlab holen. Mit mcs kompilieren => HelloWorld.exe Starten mit./corerun HelloWorld.exe und
BOOM (agrgrgghahrhghgh)
ok, was tun? In dem HowTo zu dem Ganzen wird ein Docker Container erwähnt, den man benutzen kann um das Ganze mal ohne Windows auszuprobieren. Dort habe ich mir nach und nach die dll s geholt und.
Was war der Unterschied bei System.Console.dll?
Was war der Unterschied bei System.Console.dll?
Wie entwickle ich jetzt unter Linux? Command Line mcs /nostdlib /noconfig r:/../packages. HelloWorld.cs Mono Develop
Mono Develop
Mono Develop - BOOM /nostdlib wurde beim Compilieren nicht gesetzt. Also doch wieder Command Line
Mono Develop
Wie mancht das aber ASP.NET vnext unter Linux? Die benutzen aktuell wohl Mono als Runtime solange bis die coreclr und die entsprechenden Hosts zur Verfügung stehen. 2015 wird spannend.
Summary Es funktioniert noch nicht richtig. Für ASP.NET vnext wird aktuell noch mono als runtime benutzt unter Linux und Mac. Ich bin gespannt, wann das Ganze unter Linux, Mac und richtig läuft. Aber es ist ein Anfang und ja, es wird unser Leben als.net Entwickler ändern
Links CoreCLR Developer Guide für Linux CoreFX Developer Guide Ubuntu Desktop Mono on Ubuntu Visual Studio 2013 Comminity Edition
CoreCLR auf RasPi
Voraussetzungen GIT (schon vorinstalliert) CMake 3.2 (mindestens 2.8.12) llvm-3.5 clang-3.5 lldb-3.5 GCC 4.7 (nicht über apt-get install nachinstallierbar) Paketquellen auf jessie (beta) umstellen und dann Update durchführen
Los Stop Schade Nach all den Mühen kommt man zu folgenden Zeilen # TODO: Support this message(fatal_error Not implemented! )
Mono
Integration in VisualStudio Mono installieren (3.12.0) http://www.mono-project.com/download/#download-win Bibliotheken kopieren C:\Program Files (x86)\mono\lib\mono\4.0 => C:\Program Files (x86)\reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\Profile\Mono Datei anlegen ~\Profile\Mono\RedistList\FrameworkList.xml <?xml version="1.0" encoding="utf-8" standalone="yes"?> <FileList ToolsVersion="4.0" RuntimeVersion="4.0" Name="Mono 3.12.0" Redist="Mono_3.12.0"> </FileList> Registry Eintrag HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\SKUs\.NETFramework,Version=v4.0,Profile=Mono
Als Target Framework verfügbar
Debugging Windows local VisualStudio TargetFrameworkVersion und TargetFrameworkProfile in csproj eintragen <PropertyGroup> <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration> <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform> <TargetFrameworkVersion>v4.0</TargetFrameworkVersion> <TargetFrameworkProfile>Mono</TargetFrameworkProfile> </PropertyGroup>
Debugging Windows remote VisualStudio mit MonoDebugger von Christian Giesswein MonoDebugger.MonoServer.exe auf dem Zielsystem starten Build --> Start Mono-Debugging (remote)
Debugging Windows local Xamarin Studio F5
Debugging Windows remote Xamarin Studio Umgebungsvariable setzen MONODEVELOP_SDB_TEST=1 Neuer Menüeintrag Custom Command Mono Soft Debugger
Fazit Verwendbar Mehrere Möglichkeiten Einschränkungen des Frameworks Win32 Spezifika Mono Migration Analyzer (MoMA)