2016-02-16 6 views
28

Derzeit versuche ich etwas über den .NET Plattform Standard zu lernen. Ich bin ziemlich verwirrt über die Idee von "verschiedenen Plattformen".Was sind die Plattformen im .NET Platform Standard?

Ich werde versuchen, meinen Standpunkt klar zu machen. Was ich derzeit über das .NET Framework verstehe, ist, dass .NET grob gesagt aus der CLR, der BCL und unterstützender Software besteht, um die CLR zu booten und die Schnittstelle zwischen der virtuellen Maschine und dem zugrunde liegenden Betriebssystem bereitzustellen.

Also, wenn wir mit dem .NET Framework programmieren, zielen wir tatsächlich auf einige Versionen des Frameworks ab, weil die Typen, die wir vom BCL verwenden, mit dem Framework geliefert werden und daher von der spezifischen Version abhängen.

Nun, .NET Core ist ganz anders als ich verstanden habe. Es ist nicht alles so zusammen gepackt. Wir haben die CoreCLR, die eine leichte VM ist, um die IL zu betreiben, die CoreFX, die Bibliotheken, die ordnungsgemäß als NuGet Pakete organisiert sind, und wir hatten bis jetzt die DNX/DNVM/DNU, die die unterstützenden Sachen wie das Booten der CoreCLR und die Anbindung an die OS.

Trotzdem, wenn wir das Framework auf Windows 7, Windows 8 oder Windows 10 installieren, codieren wir gegen das Framework.

nun auf dem .NET-Plattform Standard-spec sehen wir die folgende Definition:

Platform - z.B. .NET Framework 4.5, .NET Framework 4.6, Windows Phone 8.1, Monotouch, UWP usw.

Auch sehen wir, dass nach einer Liste von Plattformen, die

  • .NET Framework 2.0 enthält - 4.6
  • Windows 8
  • Windows Phone 8,1
  • 4 Silverlight 5
  • DNX auf .NET Framework 4.5.1 - 4.6
  • DNX auf .NET Core 5.0

Jetzt verwirrt mich das vollständig. Ich denke immer: Wir codieren gegen das .NET Framework und das Framework ist das Framework egal was.

Aber hier haben wir diese Plattformen, die das .NET-Framework als nur eine der vielen Plattformen enthält. Wir haben zum Beispiel Windows 8, aber warte mal, das Ausführen von .NET unter Windows 8 ist nicht das Gleiche wie das Ausführen von .NET unter anderen Betriebssystemen? Warum ist es von der .NET Framework 2.0 - 4.6-Plattform getrennt?

Wir haben auch DNX als eine spezifische Plattform. Das wundert mich: Die Plattform ist die "Unterstützung" beim Starten der virtuellen Maschine und beim Bereitstellen der Schnittstelle mit dem Betriebssystem? Oder die Plattform enthält die virtuelle Maschine?

Wie auch immer, wie ich sehen kann, bin ich ziemlich verwirrt. Was sind diese Plattformen tatsächlich und wie verhält es sich mit meinem aktuellen Verständnis von .NET Framework? Warum wird .NET Framework 2.0 - 4.6 auch separat beschrieben? Ist nicht alles beschrieben hier einige Version von .NET Framework, außer .NET Core?

+0

Es gibt keine * "virtuelle Maschine" * in .NET. – IInspectable

+3

@IInspectable http://blogs.msdn.com/b/brada/archive/2005/01/12/351958.aspx "Die Quintessenz ist, dass die CLR und JVM in der gleichen Klasse sind, ob Sie diese Klasse von aufrufen Software "virtuelle Maschinen" "Execution Engines" hängt von Ihrer Perspektive ab. " – Rob

+2

Ich dachte immer über die CLR als eine Art von virtuellen Maschine. Eine Software, die als Sandbox fungiert, auf der die Anwendung ausgeführt wird. Wir geben dieser VM den IL-Bytecode und der enthaltene JIT-Compiler erstellt den nativen Code und führt ihn in dieser speziellen Sandbox aus. Obwohl ich die CLR nie im Detail studiert habe, beschreiben die Dokumente auf GitHub es als "eine vollständige, hochgradige virtuelle Maschine, die entworfen wurde, um eine große Vielfalt von Programmiersprachen und Interoperabilität zwischen ihnen zu unterstützen". Das ließ mich glauben, dass mein grobes Verständnis vernünftig war. – user1620696

Antwort

5

Es gibt viele Frameworks (.NET Framework, WinRT, UWP, Silverlight,.NET Core, Windows Phone, Mono, Micro Framework und das alte Compact Framework) nicht nur das .NET Framework.

Der neue Weg besteht darin, gegen einen Plattformstandard zu programmieren, der eines oder mehrere dieser Frameworks unterstützt. Der Plattformstandard definiert eine API, die einem oder mehreren Frameworks entspricht. Das bedeutet, wenn Ihre Anwendung den Plattformstandard 1.1 unterstützt, werden Sie wahrscheinlich fast alle Frameworks unterstützen. Platform Standard 1.4 wird .NET Framework 4.6.x und .NET-Core-Unterstützung nur

einen Blick auf dieses Dokument haben: https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md

6

wir Code gegen den Rahmen.

Nun, sicher bist du. Wenn Sie Zeichenfolgen in Ihrem Code bearbeiten, verwenden Sie immer System.String. Und es verhält sich (fast) immer genau so mit genau den gleichen Methoden und Eigenschaften.

Aber Anzeigen der String Implementierungsdetails hat, dass man nicht wirklich ignorieren können:

  • Wenn Sie es in einem Unix-Terminal auf Linux oder OSX zeigen wollen, dann müssen Sie Mono oder CoreCLR zum Ziel, die Framework-Implementierungen, die auf solchen Betriebssystemen ausgeführt werden können.
  • Wenn Sie es in einer Windows Store App anzeigen möchten (aka WinRT, auch bekannt als Windows 8, aka UWP), dann ist es eigentlich ein HSTRING unter der Haube, ein sehr gut verstecktes Detail, um das Sie sich keine Sorgen machen müssen. Aber erfordert ein UI-Gadget, wie Windows.UI.Xaml.Controls.TextBlock, eine Klasse, die sehr spezifisch für WinRT ist
  • Wenn Sie es in einem Browser anzeigen möchten, dann müssen Sie ASP.NET oder Silverlight, Framework Hosts, die für die Ausführung auf einem Webserver oder als Add-In für einen Browser optimiert wurden.
  • Wenn Sie es auf einem Gerät zeigen möchten, das mit einem kleinen Lithium-Ionen-Akku wie einem Telefon betrieben wird, müssen Sie sich zwangsläufig mit einer Framework-Version befassen, die so optimiert wurde, dass sie möglichst wenig Strom verbraucht. Das tut beeinflussen den Code, den Sie schreiben müssen, gibt es einen großen Unterschied zwischen Code, der 100 Watt brennt und Code, der eine kleine Batterie für 8 Stunden am Leben hält. Nichts, was Sie direkt sehen können, abgesehen von der Notwendigkeit, async zu verwenden/erwarten eine Menge, aber sicherlich etwas, das die Laufzeit sehr stark beeinflusst. Targeting Xamarin oder WinRT ist erforderlich.
  • Wenn Sie es auf Betriebssystem zeigen möchten, dann müssen Sie eine Framework-Version, die nicht die Art von Tricks, die .NET unter Windows verwendet, um eine EXE starten die CLR virtuelle Maschine. Das erfordert dnx.exe, genau wie Sie java.exe oder python.exe für Programme verwenden würden, die in Java oder Python geschrieben sind.

Es wäre schön, wenn diese Implementierungsdetails nicht wichtig wären. Aber nicht so, wie es in der Praxis funktioniert, denn .NET wächst und wird auf immer mehr Geräten und Betriebssystemen verfügbar, es wird zwangsläufig auch komplizierter. Wählen Sie Ihre geplanten Ziele früh, es ist wichtig.

+0

Danke für die Antwort @HansPassant. Also sind diese Plattformen die Vertikalen, die auf Dokumenten erschienen, die .NET Core vorstellen? Und jede Plattform besteht aus einer Laufzeitumgebung (CLR, Mono, CoreCLR) zusammen mit einem Basissatz von Bibliotheken (wie dem BCL) und mit unterstützender Software zum Booten der Laufzeitumgebung und zur Anbindung an das Betriebssystem? In diesem Fall, da .NET Framework 2.0 - 4.6 alle diese Funktionen hatte, handelt es sich um eine spezifische Plattform. Aber um zum Beispiel Store-Apps zu entwickeln, wurde eine neue Runtime mit einem neuen Basissatz von Bibliotheken und neuen Support-Sachen gebaut, und das gleiche gilt für all diese Branchen. – user1620696

+0

Ich habe es absichtlich vermieden, dieses Diagramm zu posten, es hilft nicht wirklich imo. Die unterste Schicht ist am wichtigsten, .NET muss darüber laufen und das beeinflusst, wie es aussieht und was es kann. Die Änderungen in der CLR zur Unterstützung von Store-Apps (WinRT) sind eigentlich ziemlich bescheiden. Was sich wirklich geändert hat, ist die OS-Oberfläche, sie ist so unterschiedlich wie, sagen wir, OSX unterscheidet sich von iOS. Microsoft Marketing-Strategien sind im Weg, wenn Sie das sehen, wenn Sie die Plattform nicht gut genug kennen. –

+0

In diesem Fall ist der Hauptunterschied zwischen den Plattformen die Bibliothek, die standardmäßig enthalten ist? Also, .NET Framework hat die Basisklassenbibliothek, während die Store-Apps standardmäßig einen weiteren Satz von Bibliotheken enthalten? Abgesehen davon gibt es auch Unterschiede bezüglich der CLR, glaube ich. Und die Idee ist, das Framework für die verschiedenen Umgebungen, in denen es ausgeführt wird, zu optimieren (z. B. einen Browser, ein Telefon oder einen vollständigen Desktop)? – user1620696

5

Jetzt verwirrt mich das vollständig. Ich denke immer: Wir codieren gegen das .NET Framework und das Framework ist das Framework egal was.

Nein, es gibt tatsächlich mehrere .NET-Frameworks oder -Plattformen, wie Sie sie nennen möchten. Vor .NET Standard hatten Sie sich an ein einzelnes Framework (möglicherweise das vollständige Framework, derzeit Version 4.6.3) gebunden, wenn Sie Webanwendungen oder Windows-Dienste entwickeln.DLLs, die auf ein Framework ausgerichtet sind, sind nicht mit einem anderen Framework kompatibel. I.E. Eine DLL, die für das vollständige .NET Framework entwickelt wurde, kann nicht auf Windows Phone 8.1 ausgeführt werden.

Diese Frameworks implementieren tatsächlich einen ziemlich kleinen gemeinsamen Satz von Libraries, aber auch spezifische Bibliotheken für den Umgang mit der Plattform, für die sie gedacht sind. I.E. Bibliotheken zum Verwalten eines auf IIS gehosteten Webservers im vollständigen .NET-Framework oder Funktionen für den Umgang mit einem Mobiltelefon im Windows Phone 8.1-Framework.

Bevor .NET-Standard wurde die PCL

Es gab zwar eine Abhilfe, die so genannte PCL, die für "Portable Klassenbibliotheken" steht. Wenn nur die kleine gemeinsame Teilmenge von Methoden/Assemblys in zwei oder mehr .NET-Frameworks verwendet wird, könnte man eine Bibliothek entwickeln, die in Projekte eingeschlossen werden kann, die auf verschiedene Frameworks abzielen. Zum Beispiel bedeutet PCL-Profil 37, dass Ihre Bibliothek in Projekten mit .NET Framework 4, Silverlight 5 und Windows 8 verwendet werden kann.

haben Sie einen Blick auf diese für eine Liste von PCL-Profile und deren Verträglichkeiten (ich weiß nicht, ob es vollständig ist): http://danrigby.com/2014/05/14/supported-pcl-profiles-xamarin-for-visual-studio-2/

Was ist nun mit .NET Standard?

Das Ziel mit .NET Standard ist es, dies zu vereinfachen und PCLs loszuwerden. Grob gesagt definiert .NET Standard einen Vertrag (eine Menge von Klassen und Methoden), der von allen .NET Frameworks implementiert wird. Wenn Sie eine Bibliothek entwickeln, die auf .NET Standard abzielt, können Sie sicher sein, dass sie auf allen .NET-Frameworks ausgeführt werden kann. Es ist die Grundidee/das Ziel dahinter (auch wenn es etwas subtiler ist).

Werfen Sie einen Blick auf diese für die genaue Kompatibilität: https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/#user-content-whats-new-in-net-standard-20

Wenn Sie auf der Kompatibilitätstabelle anschauen, werden Sie .NET Standard-sehen, dass eine Bibliothek Targeting 1.6 verwendbar ist, wie (keine Notwendigkeit, es neu zu kompilieren) in .NET Framework 4.6.3 und .NET Core 1.0-Anwendungen.

Mit anderen Worten können wir sagen, dass .NET Framework 4.6.3 und .NET Core 1.0 beide implementieren den .NET Standard 1.6 Vertrag: seine Klassen und Methoden.

Wenn Sie möchten, dass Ihre DLL auch in einem Windows Phone 8.1-Projekt verwendet werden kann, müssen Sie auf .NET Standard 1.2 abzielen, das weniger Funktionen als .NET Standard 1.6 bietet (z. B. keine System.Net.Sockets). .

Siehe hier für eine Liste der verfügbaren Namensräume in jeder Version von .NET Standard-https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md#user-content-list-of-net-corefx-apis-and-their-associated-net-platform-standard-version