Ich erinnere mich so lebhaft an Suns Slogan ... "Einmal schreiben, überall laufen" . Da Programme in Standard-Byte-Codes kompiliert werden, könnte jedes Gerät mit einer Java Virtual Machine das Programm ausführen. Im Laufe der Jahre scheint Java auf vielen Plattformen / Geräten angekommen zu sein.
Ist das die Absicht oder war es jemals die Absicht von .NET? Wenn ja, welche Anstrengungen werden unternommen, um dies zu verwirklichen?
Um einige Kommentare anderer hier zu korrigieren, war .Net IMMER dazu gedacht, Multi-Plattform zu sein. Aus diesem Grund hat Microsoft die Namespaces in "System. *" (Die plattformneutral waren) und "Microsoft. *" (Die Windows-spezifisch waren) getrennt.
Es gibt Mono , das unter Linux, Solaris und OS X läuft. In der Praxis ist .Net immer noch so ziemlich ein Windows - nur Plattform. Es liegt nicht wirklich im Interesse von Microsoft, es zu WORA zu machen, im Gegenteil. Es scheint aber plattformübergreifend zu sein. Viele Leute waren in Bezug auf Mono unter Linux wirklich paranoid. Die vermeintliche Strategie von MS besteht darin, es zunächst zu einem wichtigen Teil der Linux-Anwendungsplattform werden zu lassen und dann die Anwälte freizulassen. Ich würde meine Zukunft auf die Portabilität von .Net nicht wetten.
Die Antwort ist ein sehr wackeliges Ja. Sobald Sie eine externe Bibliothek hinzufügen, ändert sich die Antwort zu Nein.
Zum Beispiel hat Microsoft keinen 64-Bit-JET-Treiber. JET wird von .NET verwendet, um auf MS Access-Datenbanken zuzugreifen.
Alle Anwendungen, die für das Any-CPU-Ziel kompiliert wurden, das MS Access-Datenbanken verwendet, schlagen auf einer 64-Bit-Version von Windows fehl.
(Dies ignoriert, dass diese Anwendungen nicht zu Mono übertragbar sind.)
Microsoft hat diese Behauptungen nie gemacht, aber sie machen Schritte in der WORA-Arena. Silverlight 2.0 zum Beispiel wird eine Teilmenge des .NET-Frameworks verwenden und unter Windows, Linux (über das Moonlight-Projekt), MacOS, Windows Mobile und Nokia Handsets verfügbar sein.
Wie bereits erwähnt, hat das Mono-Projekt den Rahmen auch in mehrere Umgebungen gebracht.
Um dies in einen Zusammenhang zu stellen, hat Java in vieler Hinsicht niemals die "Write Once Run Anywhere" -Versprechung geliefert.
Im besten Fall hast du "Write Once Debug Everywhere" oder "Write Once sieht überall wie Mist aus"
Die erfolgreichen CLR-basierten Anwendungen wurden alle mit einem grafischen Framework geschrieben, das auf der Zielplattform nativ ist.
Zum Beispiel die folgenden sehr erfolgreichen Linux-Anwendungen, die mit c # -Bindungen zu GTK geschrieben wurden, nannten GTK # und verwendeten keine Winforms, wie Sie es erwarten würden:
Banshee - Musikspieler wie itunes
fspot - Foto-Manager
TomBoy - Notizen Programm
GnomeDo - Schnellstart und Dock
Ebenso erfolgreiche Windows .net-Anwendungen werden nicht mit GTK # geschrieben (obwohl es plattformübergreifend ist), sie werden mit Winforms oder WPF geschrieben.
Als Google zu Chrome kam, versuchten sie nicht, ein plattformübergreifendes GUI-Framework zu verwenden, stattdessen entschieden sie sich für native GUI-Frameworks auf jeder Plattform. Warum? weil auf diese Weise die Anwendung in die Umgebung passt, so wie sie aussieht, sich anfühlt und verhält, wie ihre native für das Betriebssystem es ist.
Wenn man einmal versucht hat, einmal irgendwo zu schreiben, muss man ernsthafte Kompromisse eingehen, und was man am Ende hat, ist etwas, das nicht wirklich überall funktioniert.
Die Industrie hat das hohe Ziel aufgegeben, einmal irgendwo zu laufen, als eine nette Idee, die in der Praxis nicht funktioniert hat.
Der beste Ansatz mit mono / .net ist die gemeinsame Nutzung der Binärdateien auf niedrigerer Ebene und die Verwendung eines nativen GUI-Frameworks auf jeder Zielplattform. GTK # unter Linux, Winforms oder WPF unter Windows, CocoaSharp unter Mac. Auf diese Weise wird Ihre Anwendung wie eine native App aussehen und sich auch so anfühlen.
Mit Mono kommen wir uns ziemlich nahe und mit SilverLight sind wir schon da.
Ich glaube nicht, dass die offizielle "Absicht" von .NET WORA war. Ich denke, dass Sie sicher sagen könnten, dass .NET so entworfen wurde, dass es immer auf zukünftigen MS-Betriebssystemen laufen würde. Aber es gibt nichts, was .NET davon abhält, auf anderen Plattformen zu laufen. Mono ist ein Beispiel für eine Implementierung der .NET-Laufzeitumgebung für ein anderes Betriebssystem als Windows.
Ja, das war ein Ziel von .NET, obwohl ich nicht glaube, dass es die gleiche Betonung hatte wie in Java. Momentan ist das einzige Effor, das ich kenne, das Mono-Projekt, das eine Version der CLI erstellt, die unter Linux läuft.
Interessanterweise verfügt Silverlight über eine abgespeckte Version der CLR, die sowohl unter Windows als auch unter Mac ausgeführt werden kann. Dadurch kann dieselbe Silverlight-App auf beiden Plattformen unverändert ausgeführt werden.
Dies ist theoretisch möglich, da die CLR (.Nets "virtuelle Maschine") einem offenen Standard (CLI) entspricht. Die Frage ist, welche anderen Implementierungen es von diesem Standard gibt. Mono ist eine weitere Arbeit in Arbeit, aber es ist die einzige andere, die ich kenne.
Ich denke, dass die Idee mit .NET ist, dass es ein "Einmal schreiben, Anywhere ausführen (das Microsoft wählt)" ist. Das Mono -Projekt ändert jedoch langsam die Situation.
Es wird niemals auf so vielen Plattformen wie Java unterstützt, IMHO.
Der einzige Aufwand ist Mono, nicht gesponsert von Microsoft.
Überprüfen Sie hier auf SO und auf offizielle Seite
In der Theorie ja. .Net-Assemblys sind Bytecodes, die beim Start mithilfe eines JIT-Compilers ("Just-in-Time") in nativen Code konvertiert werden.
In der Praxis gibt es außer Windows nicht viele Plattformen mit einem .NET JIT-Compiler. Für Linux gibt es einen namens MONO.
Weiß nicht über Mac, Sun usw. ...
Theoretisch ist die Sprache so entworfen, dass sie in Bytecode wie Java kompiliert wird, was von der Common Language Runtime interpretiert wird, einem Mechanismus, der auch mehrere Sprachen (nicht nur C #) erlaubt, zusammen zu arbeiten und auf dem .NET Framework zu laufen. p>
Microsoft hat jedoch nur die CLR für Windows entwickelt. Es gibt andere Nicht-MS-Alternativen, von denen die bekanntesten Mono , eine CLR-Implementierung oder einige davon sind Plattformen (siehe den Link).
Also in der Theorie ja, in der Praxis - wir werden sehen.
Ja und nein. Teile der .NET-Umgebung sind Standards und können offen übernommen werden.
Zum Beispiel hat die Laufzeit (CLR) eine portable Version namens Mono , die Multi-Plattform, offen ist Quelle und wird von (zum Beispiel) Second Life verwendet.
Es war ziemlich erfolgreich, aber es wird nicht offiziell unterstützt.
Wenn Sie daran denken, Ihren monolithischen Arbeitgeber von Acme dazu zu bringen, .Net und Linux zu übernehmen, vergessen Sie es. Realistisch, mit .NET, sind Sie auf Windows-Maschinen, Punkt.
Ja, .NET hat die Common Language Runtime (CLR), die das .NET-Äquivalent zur JVM ist. Microsoft unterstützt es nicht auf so vielen Plattformen wie Java, aber mit Hilfe des Mono-Projekts können plattformübergreifende Anwendungen realisiert werden mit den üblichen Vorbehalten.
Bedenken Sie, dass .NET mehr als nur die CLR ist. Es ist eine ganze Plattform.
Da .NET nur (offiziell) unter Windows verfügbar ist, dann ist es nicht möglich, es irgendwo zu schreiben. Aber das Mono-Team tut gut daran, .NET über Windows hinaus zu verbreiten, aber sie sind immer hinter den offiziellen Dingen zurück.
Ich glaube nicht, dass es der ursprüngliche Plan für Microsoft war, Laufzeiten für jede Plattform und jedes Gerät zu erstellen, aber sie ermutigten dies, indem sie eine dokumentierte (?) Zwischensprache verwendeten.
Kurze Antwort - Nein, Microsoft unterstützt nur MS-Betriebssysteme (einschließlich Windows Mobile) für .NET.
Lange Antwort - Es gibt öffentliche Open-Source-Projekte, um das .NET-Framework für Linux und andere Betriebssysteme zu replizieren, insbesondere Rotor und Mono . Sie unterstützen nicht alles, aber Sie können eine Menge .NET-Code bereitstellen, einschließlich silverlight.
Das hängt von Ihrer Definition von "Überall" ab. Es gibt verschiedene Varianten der Java Virtual Machine und des .Net-Frameworks. Und die meiste Zeit können Sie nicht einfach Code für ein Desktop-VM / Framework schreiben und erwarten, dass es auf einem Mobiltelefon läuft.
Also. In gewissem Sinne ist sogar Java nicht wirklich rein "Write Once, Run Anywhere".
Es ist jedoch richtig, dass Javas VM derzeit auf verschiedenen Betriebssystemen ausgeführt wird, während .NET Framework nur auf Windows-Geräten ausgeführt wird.
Es gibt eine interessante Initiative namens "Mono", die .NET-Unterstützung unter Linux, Solaris, Mac OS X, Windows und Unix bietet. Lesen Sie hier: Mono Site
dotNet kann wegen der CLR sein, die in der Funktion der JVM ähnlich ist. Aber ich glaube nicht, dass MS es beabsichtigt hatte. Ссылка könnte nützlich sein, aber es ist kein MS-Produkt. Übrigens, ähnlich wie das breite Spektrum von j2ee-Containern das WORA-Konzept für j2ee-Apps trübt, würden ASP.NET-Apps, die auf allem außer IIS laufen, auf verschiedenen Plattformen nicht wirklich funktionieren.
Ich glaube nicht, dass dies jemals ein Design-Ziel von .NET war - Microsoft hat kein besonderes Interesse an Leuten, die Software für Nicht-Windows-Plattformen schreiben ....
Allerdings gibt es das Mono-Projekt ( Ссылка ), bei dem es sich um eine "offene" Entwicklungsinitiative handelt, die von Novell gesponsert wird, um ein Open zu entwickeln Quelle, UNIX-Version der .NET-Entwicklungsplattform. "
Es war sicher gemeint, WORA zu sein. Es ist nur MS, dass Anywhere and Everywhere Windows wäre. Wer hätte gedacht, Linux und das MacOS wären noch da? Aber bei allen Macs der PDC zu urteilen, waren sie entweder halb richtig oder halb falsch!
Wenn WORA wirklich ein ursprüngliches Ziel wäre, dann würden wir auf allen großen Plattformen inzwischen .NET-Implementierungen sehen, die vollständig von Microsoft unterstützt werden. Ich glaube mich daran zu erinnern, dass zu der Zeit, als Sun WORA von den Dächern rief, Microsofts Riposte "Write Any (Sprache) Run on One (Plattform)" war (WARO :-). Wie jemand anderes erwähnt hat, denke ich, dass sie schon immer feste Unterstützer von WORASLAIW waren (Schreiben Sie einmal überall hin, solange es Windows ist)
Wie Sie darauf hinweisen, scheinen sie sich mit Silverlight ein wenig zu verändern, um zu versuchen, einen Teil der Flash / Flex-Aktion zu bekommen, nachdem sich das Schlachtfeld vom Desktop zum Browser verschoben hat.
Gegebene Antworten von anderen mir ist immer noch unklar, ob es eine tatsächliche Absicht von Microsoft war, .NET eine WORA-Initiative zu sein. Der einzige Weg, um wirklich zu wissen, ist, dass jemand aus dem Microsoft .NET Team in darüber klingelt.
Da wir die ursprünglichen WORA-Intentionen von .NET nicht definitiv kennen, können wir auf Bemühungen hinweisen, die versuchen, dies zu verwirklichen (wie frühere Antworten erwähnt haben).
Dieser Aufwand ist eine Initiative außerhalb von Microsoft.
Mono ist ein Projekt, das von Novell (früher von Ximian) geleitet wurde, um einen mit Ecma-Standard kompatiblen .NET-kompatiblen Satz von Tools zu erstellen, darunter unter anderem einen C # -Compiler und eine Common Language Runtime. Mono kann unter Linux, BSD, UNIX, Mac OS X, Solaris und Windows betrieben werden.
Diese Bemühungen werden von Microsoft stark vorangetrieben. Silverlight 2.0 implementiert eine Version des Frameworks, die mit .NET 3.0 identisch ist und scheint ein Versuch zu sein, das Framework erfolgreich über den Browser an mehrere Plattformen zu liefern.
Es ist mit mehreren Webbrowserprodukten kompatibel, die auf Microsoft Windows- und Mac OS X-Betriebssystemen verwendet werden. Mobile Geräte, beginnend mit Windows Mobile 6 und Symbian (Series 60) Telefonen, werden ebenfalls unterstützt.
Obwohl es sich nicht speziell um GNU / Linux-Funktionen handelt, gibt es anscheinend eine freie Software-Implementierung von Drittanbietern namens [Moonlight] ( Ссылка .
Dies scheint das zu sein, was wir derzeit wissen, aber wie bereits erwähnt, wäre es sehr hilfreich, wenn jemand aus dem .NET-Team hier reinkommen könnte, um klarzustellen, ob WORA tatsächlich eine originelle Initiative war.
Wenn Microsoft es mit Dotnet auf anderen Nicht-Windows-Plattformen ernst meinen würde, hätten sie die Klassenbibliotheken für die Wiederverwendung durch andere freigegeben, so dass die gleichen Bibliotheken wieder neu geschrieben werden müssten. Sun andererseits hat diese Bedeutung getan, es sind weniger Barrieren vorhanden, wenn man nicht auf eine andere Plattform portiert. Natürlich muss man mit java immer noch ein vm schreiben und die nativen Sachen machen, aber es hilft Kopfschmerzen zu vermeiden, die die gesamte Klassenbibliothek reimplementieren. Die Standardisierung der Sprache ist ein Marketing-Trick, um jon technische Leute zu ergreifen. Eine Sprache ohne Bibliotheken ist wertlos. Versuchen Sie, Ihr nächstes Projekt mit den Prjkitive-Typen zu machen ... Das ist richtig, schreiben Sie Ihre eigene String-Klasse usw. und sagen Sie mir, wie hilfreich eine Standard-Sprache ist, ohne dass libs verfügbar sind ...
Tags und Links java .net multiplatform