Mono è spesso usato per dire "Sì, .NET è multipiattaforma". Quanto è valido questo reclamo? [chiuso]

In Cosa sceglieresti per il tuo progetto tra .NET e Java in questo momento? Dico che considererei "Distribuirai sempre su Windows?" l'unica decisione tecnica più importante da prendere in considerazione in un nuovo progetto Web e, se la risposta è "no", consiglierei Java invece di .NET.

Un contro-argomento molto comune è che "Se mai avessimo voglia di correre su Linux / OS X / qualunque cosa, avremmo semplicemente eseguito Mono" ¹ , che è un argomento molto convincente in superficie, ma non sono d'accordo per diversi motivi.

• OpenJDK e tutto il fornitore fornito da JVM hanno superato il Sun TCK ufficiale garantendo che le cose funzionino correttamente. Non sono a conoscenza di Mono che passa un Microsoft TCK.
• Mono tiene traccia delle versioni .NET. Quale livello .NET è attualmente pienamente supportato?
• Tutti gli elementi della GUI (WinForms?) Funzionano correttamente in Mono?
• Le aziende potrebbero non voler dipendere da framework Open Source come piano ufficiale B.

Sono consapevole che con la nuova governance di Java di Oracle, il futuro non è sicuro, ma ad esempio IBM fornisce JDK per molte piattaforme , incluso Linux. Non sono semplicemente open source.

Quindi, in quali circostanze Mono è una valida strategia aziendale per le applicazioni .NET?

¹ _{Mark H lo ha riassunto come : "Se l'affermazione è che " Ho un'applicazione Windows scritta in .NET, dovrebbe funzionare su mono " , quindi non è un'affermazione valida - ma Mono ha fatto sforzi per effettuare il porting di tali applicazioni più semplice ".}

La risposta di Sparkie è arrivata, mi permetta di completare un po '.

".NET è multipiattaforma" è un'affermazione troppo ambigua in quanto sia il framework che il mondo per cui è stato originariamente creato sono cambiati e si sono evoluti.

La risposta breve è:

Il motore sottostante che alimenta .NET e i suoi derivati, Common Language Infrastructure Standard, è multipiattaforma e, come se volessi portare il tuo codice su più piattaforme, devi pianificare l'utilizzo delle API giuste sulla piattaforma giusta per offrire la migliore esperienza su ogni piattaforma.

La famiglia CLI non ha provato l'approccio "Scrivi una volta, esegui ovunque", poiché le differenze tra un telefono e un mainframe sono troppo grandi. Invece è emerso un universo di API e funzionalità di runtime che sono specifiche della piattaforma per offrire agli sviluppatori gli strumenti giusti per creare grandi esperienze in ciascuna piattaforma.

Pensaci: i programmatori non prendono più di mira PC Windows o server Unix. Il mondo, ora più che mai, è circondato da affascinanti piattaforme da PC, console di gioco, telefoni potenti, set-top box, grandi server e cluster distribuiti di macchine. Una misura unica su tutta la piattaforma si sentirebbe semplicemente gonfia su piccoli dispositivi e si sentirà sottodimensionata su sistemi di grandi dimensioni .

Il prodotto .NET Framework di Microsoft non è multipiattaforma, funziona solo su Windows. Esistono varianti di .NET Framework di Microsoft che funzionano su altri sistemi come Windows Phone 7, XBox360 e browser tramite Silverlight, ma sono tutti profili leggermente diversi.

Oggi puoi scegliere come target tutti i principali sistemi operativi, telefoni, dispositivi mobili, sistemi e server tradizionali mainstream con tecnologie basate su .NET. Ecco un elenco che mostra l'implementazione della CLI da utilizzare in ciascun caso (questo elenco non è completo, ma dovrebbe coprire il 99% dei casi):

• Computer PC basati su x86 e x86-64:
  • con Windows -> In genere esegui .NET o Silverlight, ma puoi anche utilizzare Mono completo qui.
  • con Linux, BSD o Solaris -> Si esegue Mono o Silverlight completo
  • con MacOS X -> Esegui Mono o Silverlight
  • con Android -> Esegui un sottoinsieme Mono / Android
• Computer ARM:
  • Esecuzione di Windows Phone 7: esegui Compact Framework 2010
  • Esecuzione di Windows 6.5 e versioni precedenti: si esegue il vecchio Compact Framework
  • Dispositivi Android: esegui Mono / Android
• Computer PowerPC:
  • Esegui Mono completo per sistemi operativi Linux, BSD o Unix completi
  • Esegui Mono incorporato per PS3, Wii o altri sistemi integrati.
  • Su XBox360, esegui CompactFramework
• Computer S390, S390x, Itanium, SPARC:
  • Corri in modalità Mono
• Altri sistemi operativi integrati:
  • Esegui .NET MicroFramework o Mono con il profilo mobile.

A seconda delle esigenze, quanto sopra potrebbe essere sufficiente o meno. Difficilmente otterrai lo stesso codice sorgente da eseguire ovunque. Ad esempio, il codice XNA non verrà eseguito su tutti i desktop, mentre il software .NET Desktop non verrà eseguito su XNA o sul telefono. In genere è necessario apportare modifiche al codice per l'esecuzione in altri profili di .NET Framework. Ecco alcuni dei profili di cui sono a conoscenza:

• Profilo .NET 4.0
• Profilo Silverlight
• Profilo di Windows Phone 7
• Profilo XBox360
• Profilo mono core: segue il profilo .NET ed è disponibile su Linux, MacOS X, Solaris, Windows e BSD.
• .NET Micro Framework
• Mono sul profilo iPhone
• Mono su profilo Android
• Mono sul profilo PS3
• Mono sul profilo Wii
• Profilo Moonlight (compatibile con Silverlight)
• Profilo esteso Moonlight (Silverlight + accesso API .NET 4 completo)

Quindi ognuno di quei profili è in realtà leggermente diverso, e questa non è una brutta cosa. Ogni profilo è progettato per adattarsi alla propria piattaforma host ed esporre le API che hanno senso e rimuovere quelle che non hanno senso.

Ad esempio, le API di Silverlight per controllare il browser host non hanno senso sul telefono. E gli shader in XNA non hanno senso sull'hardware del PC a cui manca il supporto equivalente.

Prima ti rendi conto che .NET non è una soluzione per isolare lo sviluppatore dalle capacità sottostanti dell'hardware e della piattaforma nativa, meglio sarai.

Detto questo, alcune API e stack sono disponibili in più piattaforme, ad esempio ASP.NET può essere utilizzato su Windows, Linux, Solaris, MacOS X perché tali API esistono sia su .NET che Mono. ASP.NET non è disponibile su alcune delle piattaforme supportate da Microsoft come XBox o Windows Phone 7 e non è supportato su altre piattaforme supportate da Mono come Wii o iPhone.

Le seguenti informazioni sono corrette solo dal 21 novembre e molte cose nel mondo Mono probabilmente cambieranno.

Gli stessi principi possono essere applicati ad altri stack, un elenco completo richiederebbe una tabella corretta, che non ho idea di come presentare qui, ma ecco un elenco di tecnologie che potrebbero non essere presenti su una particolare piattaforma. Puoi presumere che tutto ciò che non è elencato qui sia disponibile (sentiti libero di inviarmi le modifiche per le cose che ho perso):

Core Runtime Engine [ovunque]

• Supporto Reflection.Emit [ovunque, tranne WP7, CF, Xbox, MonoTouch, PS3]
• Supporto SIMD CPU [Linux, BSD, Solaris, MacOS X; Presto PS3, MonoTouch e MonoDroid]
• Continuazioni - Mono.Tasklets [Linux, BSD, Solaris, MacOS, PS3, Wii]
• Scaricamento assembly [solo Windows]
• Iniezione di VM [Linux, BSD, MacOS X, Solaris]
• DLR [Windows, Linux, MacOS X, Solaris, MonoDroid]
• Generics [alcune limitazioni su PS3 e iPhone].

Le lingue

• C # 4 [ovunque]
• Compilatore C # come servizio (Linux, MacOS, Solaris, BSD, Android)
• IronRuby [ovunque, esegui WP7, CF, Xbox, MonoTouch, PS3]
• IronPython [ovunque, eseguito WP7, CF, Xbox, MonoTouch, PS3]
• F # [ovunque, esegui WP7, CF, Xbox, MonoTouch, PS3]

Stack di server

• ASP.NET [Windows, Linux, MacOS, BSD, Solaris]
• ADO.NET [ovunque]
• LINQ to SQL [ovunque]
• Entity Framework [ovunque]
• Stack XML principale [ovunque]
  • Serializzazione XML [ovunque, tranne WP7, CF, Xbox)
• LINQ to XML (ovunque)
• System.Json [Silverlight, Linux, MacOS, MonoTouch, MonoDroid]
• System.Messaging [Windows; su Linux, MacOS e Solaris richiede RabbitMQ]
• .NET 1 Enterprise Services [solo Windows]
• WCF [completo su Windows; piccolo sottoinsieme su Silverlight, Solaris, MacOS, Linux, MonoTouch, MonoDroid]
• Flusso di lavoro di Windows [solo Windows]
• Identità spazio carte [solo Windows]

Stack della GUI

• Silverlight (Windows, Mac, Linux - con Moonlight)
• WPF (solo Windows)
• GTK # (Windows, Mac, Linux, BSD)
• Windows.Forms (Windows, Mac, Linux, BSD)
• MonoMac - Integrazione Mac nativa (solo Mac)
• MonoTouch - Integrazione nativa con iPhone (solo iPhone / iPad)
• MonoDroid - Integrazione Android nativa (solo Android)
• API di Media Center: solo Windows
• Clutter (Windows e Linux)

Librerie grafiche

• GDI + (Windows, Linux, BSD, MacOS)
• Al quarzo (MacOS X, iPhone, iPad)
• Il Cairo (Windows, Linux, BSD, MacOS, iPhone, iPad, MacOS X, PS3, Wii)

Librerie mono: multipiattaforma, possono essere utilizzate in .NET ma richiedono la compilazione manuale

• Compilatore C # 4 come servizio
• Cecil - CIL Manipolazione, flusso di lavoro, strumentazione di CIL, Linker
• Librerie RelaxNG
• Fornitori di database Mono.Data. *
• System.Xaml completo (per l'utilizzo in configurazioni in cui .NET non offre lo stack)

MonoTouch significa Mono in esecuzione su iPhone; MonoDroid significa Mono in esecuzione su Android; Le porte PS3 e Wii sono disponibili solo per sviluppatori qualificati Sony e Nintendo.

Mi scuso per la mancanza di formalità.

Innanzitutto, è necessario fare una distinzione tra Common Language Infrastructure (lo standard aperto) e .NET (l'implementazione di Microsoft di tale standard). Mono è un'implementazione della CLI e non ha mai affermato di essere un ".NET portatile". Inoltre, il linguaggio C # è uno standard aperto e non è strettamente legato a .NET.

Non sono a conoscenza del fatto che Microsoft disponga di uno strumento per convalidare la conformità di un'implementazione, ma se lo fanno, sono abbastanza sicuro che i ragazzi mono lo abbiano e lo utilizzino.

Mono è dietro di .Net, ma a malapena. Mono può eseguire il codice C # 4.0 (versione corrente di .NET). Inoltre, Microsoft ha recentemente reso open source tutto il codice DLR e le librerie (sotto la licenza Apache 2.0), che ha permesso a mono di utilizzare linguaggi come IronPython, IronRuby e F # è stato reso open source solo la scorsa settimana. Inoltre, Microsoft rilascia regolarmente CTP delle funzionalità imminenti in .NET, che consente agli sviluppatori mono di tenersi aggiornati con le versioni di rilascio correnti.

Esistono numerosi strumenti ed estensioni in .NET, ad esempio Contratti di codice. Questi non sono sempre implementati completamente in mono. (Al momento, penso che ci sia un validatore di contratto parziale per i contratti di richiesta). Questi non sono comunque comunemente utilizzati nelle app .NET, ma se la loro popolarità aumentasse, anche la velocità con cui verranno implementati in mono.

WinForms non è (interamente) portatile. Sono specifici di .NET e non fanno parte della CLI. L'interfaccia della riga di comando non specifica alcun set di widget specifico. Esistono però set di widget multipiattaforma (GTK # e Silverlight). Se scrivessi un'applicazione da zero pensando alla portabilità, utilizzeresti una di queste anziché Winforms / WPF. Inoltre, mono fornisce un wrapper sottile per l'API Winforms, che consente di trasferire più facilmente le app esistenti di Winforms in GTK # (senza riscrittura completa).

Mono fornisce uno strumento, Mono Migration Analyzer (MoMA), che può prendere un'applicazione .Net esistente e raccontarti della sua portabilità. (ad esempio, identificare librerie non portabili utilizzate, P / Invoke ecc.).

Per le aziende che non vogliono dipendere da Open Source - mono può essere ri-concesso in licenza. La proprietà del codice aggiunto a mono viene ceduta a Novell, che può concederlo in licenza in modi alternativi diversi dalla normale licenza LGPL (che comunque ha pochissime restrizioni).

Per quanto riguarda l'affermazione ".NET è portatile", penso che questa possa essere un'affermazione valida se stai scrivendo codice da zero e sei consapevole dei problemi di portabilità con il framework. Se l'affermazione è che "Ho un'applicazione Windows scritta in .NET, dovrebbe funzionare su mono", allora no, non è un reclamo valido - ma Mono ha fatto degli sforzi per rendere più semplice il porting di tali applicazioni.

Punto per punto:

• OpenJDK e tutto il fornitore fornito da JVM hanno superato il Sun TCK ufficiale assicurando che le cose funzionino correttamente. Non sono a conoscenza di Mono che passa un Microsoft TCK.
  Esiste una specifica a cui il CLR Microsoft è conforme. Mono non è un clone del CLR di Microsoft, ma piuttosto un'implementazione della stessa specifica. Da un lato, c'è la possibilità che ciò si traduca in un'incompatibilità ancora maggiore. In pratica, questo ha funzionato molto bene per il mono.
• Mono tiene traccia delle versioni .NET. Quale livello .NET è attualmente pienamente supportato?
  Poiché la documentazione per .Net precede la versione effettiva, mono aveva effettivamente completato (non una versione beta) il supporto per .Net 4 prima della versione ufficiale di Microsoft. Inoltre, mono fa un ottimo lavoro nel documentare quali cose non sono supportate e hanno alcuni strumenti che puoi eseguire contro progetti esistenti per aiutarti a individuare luoghi con potenziale incompatibilità.
• Tutti gli elementi della GUI (WinForms?) Funzionano correttamente in Mono?
  La stragrande maggioranza dei winform funziona bene. WPF, non così tanto. Ho sentito che lo stesso vale per Java: molti dei toolkit avanzati di widget / gui non sono altrettanto supportati su tutte le piattaforme.
• Le aziende potrebbero non voler dipendere da framework Open Source come piano ufficiale B.
  In tal caso, sicuramente non andranno con Java, quindi, poiché questo aumenta ulteriormente il framework open source al piano A.

In sintesi, se vuoi creare un'app multipiattaforma in questo momento , non c'è nulla di sbagliato nel cominciare con mono fin dall'inizio e utilizzarlo come framework. Puoi anche distribuire mono su Windows se vuoi.

D'altra parte, se stai cercando di costruire un'app di Windows oggi che ritieni possa dover essere multipiattaforma in un punto sconosciuto in futuro, probabilmente vorrai andare con i widget e gli strumenti nativi di Windows. .Net fa un lavoro molto migliore qui rispetto a Java, e mono è un fallback perfettamente accettabile in questo scenario.

In altre parole: Sì, .Net se multipiattaforma in tutti i modi che contano per la tua domanda. No, mono non eseguirà immediatamente tutti i programmi .Net, ma la tua domanda è nel contesto di un nuovo progetto. Non ci vuole molto lavoro per mantenere i nuovi progetti fuori dai guai ed evitare problemi di compatibilità, specialmente se si pensa in termini di sviluppo per mono piuttosto che di sviluppo per .Net.

Soprattutto, tuttavia, penso che questa sia la domanda sbagliata in primo luogo. A meno che tu non stia costruendo un nuovo team di sviluppo da zero, stai iniziando con programmatori che hanno esperienza in un'area o in un'altra. I tuoi migliori risultati saranno raggiunti andando con ciò che i tuoi programmatori già sanno. Per quanto possa sembrare importante la creazione di un'app multipiattaforma, se hai un team pieno di programmatori .Net con poca esperienza java, è improbabile che tu li licenzi o faccia imparare a tutti java per il tuo prossimo progetto. Se hai una squadra piena di programmatori Java, non chiederai loro di imparare .Net per un progetto solo per Windows. Entrambi sarebbero pazzi.

Ho lavorato con Mono e direi che è il massimo che puoi ottenere con una piattaforma alternativa open source e non direttamente supportata da Microsoft. Se ti senti a tuo agio con una piattaforma open source alternativa come Clojure o Scala, probabilmente potresti essere a tuo agio con l'uso di Mono.

Il livello di .NET supportato da Mono è sempre disponibile nella pagina Roadmap di Mono .

Tutti gli elementi della GUI funzionano? Per quanto ne so, lo fanno, anche se non ho provato esaustivamente ogni elemento.

Mono è identico a .NET? No. Sospetto che ci saranno piccole (e forse maggiori) modifiche necessarie qua e là. Al momento non è possibile eseguire Entity Framework con esso, ad esempio.

Come obiettivo, l'universo .NET / mono si muove molto velocemente .

Ogni pochi anni, Microsoft presenta alcune interessanti modifiche e innovazioni riguardanti la lingua, il runtime e l'infrastruttura che circondano .NET. Ad esempio: Generics, LINQ, DLR, Entity Framework - con ogni nuova revisione di Visual Studio, c'è generalmente un aumento piuttosto significativo nel set di funzionalità e nell'utilità del framework a cui si rivolge.

Mentre il costante miglioramento del framework è il benvenuto, è anche problematico se si desidera la compatibilità su più piattaforme. Le piattaforme di supporto a lungo termine come Red Hat Enterprise Linux procedono glacialmente lentamente per quanto riguarda l'adozione di nuove tecnologie e, in un dato momento, ci saranno miglioramenti significativi nella piattaforma Mono che si sono verificati proprio negli ultimi mesi. Quindi, se vuoi eseguire le cose che i ragazzi fantastici stanno costruendo, dovrai compilare Mono da zero e gestire le tue patch e i tuoi aggiornamenti. Questo non e buono.

Java, d'altra parte, è stagnante come una piscina per bambini. Soprattutto ora che è di proprietà di una società che voleva semplicemente Java per le cause sui brevetti, puoi essere abbastanza certo che non ci saranno cambiamenti rilevabili nella lingua o nel runtime nel prossimo futuro. Java è una piattaforma stabile come FORTRAN. Non va bene se speravi in ​​qualche tipo di miglioramento, ma non tanto se cercavi di distribuire un'applicazione enterprise.

Dal punto di vista dell'utente, Mono fa schifo nel rendere le app di Windows .NET compatibili con Linux. Se in realtà provi a eseguire qualsiasi app Windows decentemente scritta in Mono, non funzionerebbe.

Dal punto di vista di un packager (ero solito fare un po 'di lavoro su PortableApps), .NET può essere sia una benedizione che una maledizione. Se sei solo su Windows, .NET rende la distribuzione molto più semplice perché più librerie significano meno cose dipendenti dal sistema (in particolare tra le versioni di Windows, credo) ma è anche estremamente confusa anche su Windows perché le versioni .NET non sono né all'indietro -compatibile o compatibile in avanti. Devi scaricare diverse versioni di .NET per programmi diversi.

Detto questo, Mono è un ottimo punto di partenza per realizzare programmi C # multipiattaforma. Basta non impacchettare il programma con l'ultimo WINE e chiamarlo fatto però. Guarda dove ha portato Picasa.

Come per la stabilità politica delle due lingue / piattaforme, RMS probabilmente inizierebbe a parlare di come Mono è guidato da Novell, la cui luna di miele con Microsoft è piuttosto nota. Entrambe le piattaforme possono essere considerate politicamente instabili in questo momento.

Se vuoi davvero una facile piattaforma multipiattaforma, il percorso provato e vero è QT che è abbastanza stabile politicamente sin da ora è a) LGPL'd, b) fatto con i suoi principali problemi di licenza anni fa ec) supportato da Nokia, che vende telefoni molto popolari.

Mono non è una porta 1: 1 di Microsoft .net. Ci sono tecnologie che Mono semplicemente non implementerà o non ha in programma di farlo (ad esempio, Workflow Foundation o WPF ) mentre d'altra parte hanno alcune tecnologie proprie che Microsoft .NET non fa, ad esempio SIMD Extensions .

Risposta breve: Mono e Microsoft .NET si basano sulla stessa base sottostante - CIL e BCL - ma sono progetti separati.

Piccolo commento alle dichiarazioni nel post originale. Sosterrò che il TCK rimane uno strumento teorico che consente a Oracle di affermare che Java è uno standard aperto. Perché se notate, Apache Harmony ha cercato di ottenere la certificazione "Java" ormai da diversi anni, senza successo. È chiaro che Oracle non è davvero interessato a un'implementazione open source oltre a quella a cui sono affiliati e più o meno controllo (OpenJDK), che tra l'altro. molto simile a Mono, non è completo (ovvero non è supportato Java Web Start) e manca alcune ottimizzazioni disponibili nell'implementazione di HotSpot a sorgente chiuso.

Quindi, probabilmente, a partire dal 2010; (la maggior parte di) Java è open source ma non uno standard aperto, mentre (la maggior parte di) .NET non è open source ma uno standard aperto. Ci sono ovviamente delle eccezioni, DLR, IronPython, IronRuby e F # sono in realtà open source. Mono è interessante perché offre il meglio dei due mondi, implementazioni open source di standard aperti.

Mettendo da parte tutti i tecnicismi, una parte molto importante ha luogo quando si scrive effettivamente il codice.

Come con qualsiasi tecnologia multipiattaforma (che si tratti di Java, Python, Ruby ...), se il codice non è stato scritto pensando alla portabilità, dovresti supporre che non ci siano praticamente possibilità che il codice funzioni correttamente (anche se tale possibilità è in realtà molto, molto più in alto), dato che lo strano comportamento scorretto potrebbe essere piuttosto critico. Leggi: non prendere l'assembly casuale ed eseguirlo in Mono.

Eppure, per un nuovo progetto (o uno che puoi riformattare facilmente), scegliere .Net / Mono come un runtime potenzialmente portatile ha senso, ma ti risparmi un sacco di problemi testando il tuo codice su Mono molto presto, anche se il progetto ha solo un leggero cambiamento nel diventare multipiattaforma. Se si utilizza un server di integrazione continua, questo può essere semplice come impostare un nodo di compilazione Mono. Durante lo sviluppo, molti problemi possono essere risolti semplicemente prendendo l'abitudine (come la creazione di stringhe di percorso) e una parte enorme del codice può essere portatile e testata in unità su Mono solo usando pratiche sane e un po 'di riflessione. Il resto (ovvero i test unitari falliti) è quindi specifico della piattaforma (come il codice che utilizza PInvoke) ma dovrebbe essere incapsulato abbastanza da essere in grado di fornire un'implementazione alternativa per piattaforma target.

Naturalmente, l'utilizzo di una libreria non disponibile (.Net) o compatibile (di terze parti) in Mono preclude tutto ciò, ma nel mio campo questo non è stato ancora visto. Questa è la strategia che effettivamente utilizziamo sul lavoro e quando la applica non ho paura di affermare che .Net + Mono è multipiattaforma.

Varia la risposta onesta. Ho visto piccole cose del server Web spostate da IIS ad Apache, che giravano in mono senza quasi nessuna difficoltà. Ho eseguito applicazioni Windows .Net invariate usando Win Forms su Linux con successo.

Tuttavia, sebbene possa funzionare, se stai utilizzando una chiamata API non implementata su mono, non funzionerà e le uniche soluzioni sono riscrivere la tua applicazione, restare con Windows o scrivere le cose extra in mono.