it-swarm.it

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

In Cosa sceglieresti per il tuo progetto tra .NET e Java in questo momento? Dico che considererei "Distribuirai sempre su Windows? "la 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"1, 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 assicurando 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 es. IBM fornisce JDK per molte piattaforme , incluso Linux. open source.

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


1Mark H lo ha riassunto come : "Se il reclamo è che " Ho un'applicazione Windows scritta in .NET, dovrebbe funzionare su mono ", quindi no, non è un reclamo valido, ma Mono ha fatto degli sforzi per semplificare il porting di tali applicazioni. "

171
user1249

Risposta di Sparkie capito, lasciami integrare un po '.

".NET è multipiattaforma" è un'affermazione troppo ambigua poiché 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 far passare il tuo codice su più piattaforme, devi pianificare l'utilizzo le API giuste sulla piattaforma giusta per offrire la migliore esperienza su ciascuna 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 i PC Windows o i 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):

  • 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
    • running Android -> Esegui un sottoinsieme Mono/Android
  • Computer ARM:
    • Esecuzione di Windows Phone 7: esegui Compact Framework 2010
    • Esecuzione di Windows 6.5 e 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
  • 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 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 funzionalità 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 modifiche per cose che mi sono 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 nativa per Mac (solo Mac)
  • MonoTouch - Integrazione nativa con iPhone (solo iPhone/iPad)
  • MonoDroid - Native Android di Android (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à.

195
miguel.de.icaza

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 offre 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 ha comunque 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'affermazione valida, ma Mono ha fatto degli sforzi per rendere più semplice il porting di tali applicazioni.

115
Mark H

Punto per punto:

  • OpenJDK e tutti i fornitori forniti da JVM hanno superato il Sun TCK ufficiale garantendo che le cose funzionino correttamente. Non sono a conoscenza del fatto che Mono abbia passato 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 out prima la 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.
    Se questo è il 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'è niente di sbagliato nel cominciare con mono fin dall'inizio e usarlo come il tuo quadro. Puoi anche distribuire mono su Windows se vuoi.

D'altra parte, se stai cercando di costruire un'app di Windows oggi che ritieni potrebbe dover essere multipiattaforma in un punto sconosciuto del 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 tenere 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 un team pieno di Java programmatori, non chiederai loro di imparare .Net per un progetto solo per Windows. Entrambi sarebbero pazzi.

14
Joel Coehoorn

Ho lavorato con Mono e direi che è buono come puoi ottenere con una piattaforma alternativa che è 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 Mono.

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

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.

11
Robert Harvey

Come target, 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 circonda .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 un pool per bambini. Soprattutto ora che è di proprietà di una società che voleva solo Java per le cause sui brevetti, puoi sii 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 miglioramenti, ma non così male se si sta tentando di distribuire un'applicazione aziendale.

9
tylerl

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 infastidire su come Mono è guidato da Novell, la cui luna di miele con Microsoft è abbastanza 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 al momento è a) LGPL'd, b) fatto con i suoi principali problemi di licenza anni fa ec) supportato da Nokia, che vende telefoni molto popolari.

7
digitxp

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 ne hanno tecnologie proprie che Microsoft .NET non utilizza, ad esempio SIMD Extensions.

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

4
Michael Stum

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 supporta Java Web Start) e manca alcune ottimizzazioni disponibili nell'implementazione di HotSpot di origine chiusa.

Quindi, probabilmente, a partire dal 2010; (la maggior parte) 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é fornisce il meglio dei due mondi, implementazioni open source di standard aperti.

2
Casper Bang

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'Assemblea 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 non riusciti) è 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. In questo modo, quando alla fine il progetto viene portato in porto, una buona parte del lavoro è stata eseguita quasi a costo zero e il resto deve essere sviluppato Just In Time.

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 è ancora stato visto. Questa è la strategia che effettivamente utilizziamo sul lavoro e quando la applica non ho paura di affermare che .Net + Mono è multipiattaforma.

1
Lloeki

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

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

0
Michael Shaw