Sowohl Mono als auch .NET sind Supersets der ECMA / ISO CLI-Familie von Spezifikationen. Weder .NET noch Mono sind Teilmengen der anderen. Sowohl Mono als auch .NET fügen Funktionen zusätzlich zu ECMA / ISO CLI hinzu, aber während Mono viele Zusätze von .NET implementiert, implementiert .NET keine Zusätze von Mono.
Hier ein paar Beispiele:
Beachten Sie jedoch, dass (abgesehen von den Arrays) alle diese durch ihre Namespaces klar unterscheidbar sind, da keiner von ihnen in den Namespaces System oder Microsoft lebt.
EDIT: Eigentlich sind die meisten der oben genannten Erweiterungen explizit auch auf .NET ausgelegt. Zum Beispiel läuft Mono.Simd auch auf .NET, aber ohne die Laufzeit-Unterstützung, die die Mono-VM hat, ist sie unbrauchbar langsam. (Grundsätzlich sind alle SIMD-Operationen in C # implementiert, aber der Mono-Compiler erkennt diese Aufrufe und ersetzt sie durch ihre entsprechenden Assembler-Anweisungen. So arbeiten sie an .NET, aber ohne die spezielle Behandlung sind sie wesentlich langsamer.) Auch Die C # -Repl wird derzeit zusätzlich zu Reflection.Emit neu implementiert (im Moment ruft sie den Mono-Compiler direkt auf), so dass sie zukünftig in .NET funktionieren wird. Gtk # funktioniert problemlos unter Windows und .NET.
Nur die Bibliothek Mono.Tasklet kann nicht in .NET implementiert werden, da sie VM-Level-Unterstützung für Fortsetzungen erfordert.
Nein. Mono enthält mehrere alternative UI-Frameworks (Gtk #, wxWindows für .NET usw.).
Wenn Sie nur von Microsoft definierte Klassen verwenden, sollten Sie in Ordnung sein.
Mono ist eine Implementierung des CLI -Standards, ebenso wie das CLR .
Es enthält viele der Bibliotheken, die Sie in der .NET BCL finden würden, aber keine, die windowsspezifisch sind (WMI ist eine ganze Domäne, die Ihnen in den Sinn kommt).
Solange Sie sich an Funktionen halten, die nicht Windows-spezifisch sind, sollten Sie in Ordnung sein.
Das mono-Team hat ein Tool erstellt, mit dem Sie überprüfen können, ob Ihr Code auf mono - MoMA , dem Mono Migration Analyzer, funktioniert .
Was die Verwendung von Monocode mit den Microsoft-Compilern angeht, so sollten Sie, solange Sie die Bibliotheken, die Sie verwenden, und keine pInvokes unter Linux ausführen, in Ordnung sein.
Mono erweitert die BCL-APIs nicht, zumindest nicht im Namespace System . Daher können Sie ziemlich sicher sein, dass eine Anwendung, die nur Typen aus dem Namespace System verwendet, ohne Neukompilierung von Mono zu .NET portierbar ist. Natürlich werden Sie im Namespace Mono nichts mehr finden, sobald Sie in der .NET-Welt sind.
Aus der Mono-FAQ :
Planen Sie, .NET zu umarmen und zu erweitern?
Eine gute Technologie zu akzeptieren ist gut. Erweiterung von Technologien inkompatibel Wege sind schlecht für die Benutzer, also tun wir es nicht planen, unvereinbar zu machen Änderungen an den Technologien.
Wenn Sie innovative Ideen haben und wollen um neue Klassen zu schaffen, ermutigen wir Sie, um diese Klassen zu betreiben richtig gut in Mono und .NET. Heute wird Mono mit einer Anzahl von extra Bibliotheken, die entwickelt wurden entweder von Mitgliedern des Mono Gemeinschaft oder andere Gruppen. In einigen Fälle, wir haben die Bits aus gefunden Microsoft unvollständig zu sein, aber wir Vermeiden Sie die API zu brechen, anstatt wir stellen Sie die fehlende Funktionalität in neue Assemblys (siehe Mono.Security)