Mono è pronto per la prima serata? [chiuso]

Qualcuno ha usato Mono, l'implementazione .NET open source su un progetto di medie o grandi dimensioni? Mi chiedo se sia pronto per il mondo reale, gli ambienti di produzione. È stabile, veloce, compatibile, ... abbastanza da usare? Ci vuole molto sforzo per trasferire i progetti sul runtime Mono, o è davvero abbastanza compatibile da prendere ed eseguire il codice già scritto per il runtime di Microsoft?

Ci sono un paio di scenari da considerare: (a) se stai eseguendo il porting di un'applicazione esistente e ti stai chiedendo se Mono è abbastanza buono per questo compito; (b) stai iniziando a scrivere un nuovo codice e vuoi sapere se Mono è abbastanza maturo.

Per il primo caso, è possibile utilizzare lo strumento Mono Migration Analyzer (Moma) per valutare la distanza di esecuzione dell'applicazione su Mono. Se la valutazione ritorna a pieni voti, è necessario iniziare i test e il controllo qualità e prepararsi alla spedizione.

Se la tua valutazione ritorna con un rapporto che evidenzia le funzioni mancanti o che differiscono in modo significativo nella loro semantica in Mono, dovrai valutare se il codice può essere adattato, riscritto o nel peggiore dei casi se la tua applicazione può funzionare con funzionalità ridotta.

Secondo le nostre statistiche Moma basate sugli invii degli utenti (questo è dalla memoria), circa il 50% delle applicazioni funziona immediatamente, circa il 25% richiede circa una settimana di lavoro (refactoring, adattamento), un altro 15% richiede un serio impegno a rifare pezzi del tuo codice, e il resto non vale la pena disturbare il porting poiché sono così incredibilmente legati a Win32. A quel punto, o inizi da zero, o una decisione commerciale spingerà gli sforzi per rendere il tuo codice portatile, ma stiamo parlando di mesi di lavoro (almeno dai rapporti che abbiamo).

Se inizi da zero, la situazione è molto più semplice, perché utilizzerai solo le API presenti in Mono. Fintanto che rimani con lo stack supportato (che è praticamente .NET 2.0, oltre a tutti gli aggiornamenti di base in 3.5 inclusi LINQ e System.Core, oltre a qualsiasi API multipiattaforma Mono), starai bene.

Di tanto in tanto potresti imbatterti in bug in Mono o limitazioni e potresti doverli aggirare, ma questo non è diverso da qualsiasi altro sistema.

Per quanto riguarda la portabilità: le applicazioni ASP.NET sono le più facili da trasferire, in quanto hanno poca o nessuna dipendenza da Win32 e puoi persino usare SQL Server o altri database popolari (ci sono molti fornitori di database in bundle con Mono).

Il porting di Windows.Forms a volte è più complicato perché agli sviluppatori piace sfuggire alla sandbox .NET e P / Invocare il cervello per configurare le cose utili come cambiare il tasso di lampeggiamento del cursore espresso come due punti più bezier codificati in forma BCD in un wParam. O qualche spazzatura del genere.

Ha una copertura piuttosto estesa fino a .NET 4.0 e include anche alcune funzionalità delle API .NET 4.5, ma ci sono alcune aree che abbiamo scelto di non implementare a causa del deprezzamento delle API, della creazione di nuove alternative o dell'ambito troppo grande. Le seguenti API non sono disponibili in Mono:

• Windows Presentation Foundation
• Windows Workflow Foundation (nessuna delle due versioni)
• Entity Framework
• Gli "componenti aggiuntivi" WSE1 / WSE2 nello stack di servizi Web standard

Inoltre, la nostra implementazione WCF è limitata a ciò che Silverlight ha supportato.

Il modo più semplice per verificare il progetto specifico è eseguire Mono Migration Analyzer (MoMA) . Il vantaggio è che notificherà al team Mono i problemi che ti impediranno di utilizzare Mono (se presente), il che consente loro di dare priorità al loro lavoro.

Di recente ho eseguito il MoMA su SubSonic e ho riscontrato solo un problema: uno strano uso dei tipi Nullable. Questa è una grande base di codice, quindi la copertura è stata piuttosto impressionante.

Mono è in uso attivo in numerosi prodotti commerciali e open source . È utilizzato in alcune grandi applicazioni, come Wikipedia e il Mozilla Developer Center , ed è stato utilizzato in applicazioni integrate come i lettori MP3 Sansa e alimenta migliaia di giochi pubblicati.

A livello di lingua, il compilatore Mono è pienamente conforme alle specifiche del linguaggio C # 5.0 .

Sul lato desktop, Mono funziona alla grande se ti impegni a utilizzare GTK #. L'implementazione di Windows.Forms è ancora un po 'buggy (ad esempio, TrayIcon non funziona) ma ha fatto molta strada. Inoltre, GTK # è un toolkit migliore di Windows Form così com'è.

Sul lato web, Mono ha implementato abbastanza ASP.NET per eseguire perfettamente la maggior parte dei siti. La difficoltà qui è trovare un host con mod_mono installato su apache o farlo da soli se si dispone dell'accesso shell al proprio host.

In entrambi i casi, Mono è eccezionale e stabile.

Elementi chiave da ricordare durante la creazione di un programma multipiattaforma:

• Usa GTK # invece di Windows.Forms
• Assicurati di inserire correttamente i nomi dei file
• Usa Path.Separatorinvece di hardcoding "\", usa anche Environment.NewLineinvece di "\n".
• Non utilizzare chiamate P / Invoked all'API Win32.
• Non utilizzare il registro di Windows.

Personalmente uso Mono in un ambiente di prima serata. Gestisco server mono che si occupano di giga-byte di attività relative all'elaborazione dei dati udp / tcp e non potrebbero essere più felici.

Ci sono peculiarità e una delle cose più fastidiose è che non puoi semplicemente "costruire" i tuoi file msbuild a causa dello stato attuale di Mono:

• MonoDevelop (l'IDE) ha un supporto parziale per msbuild, ma fondamentalmente funzionerà su qualsiasi conf "REAL" build oltre a un semplice ciao-mondo (attività di build personalizzate, "proprietà" dinamiche come $ (SolutionDir), configurazione reale per citarne alcuni morti -ends)
• xbuild che DOVREBBE essere stato il sistema di compilazione mono-fornito-msbuild-completamente compatibile è ancora più orribile, quindi la costruzione dalla riga di comando è in realtà un'esperienza peggiore rispetto all'utilizzo della GUI, che è uno stato molto "non ortodosso" del unione per ambienti Linux ...

Una volta / Durante la realizzazione effettiva delle tue cose, potresti vedere alcune aree selvagge anche per il codice che DOVREBBE essere supportato come:

• il compilatore viene bloccato su alcuni costrutti
• e alcune classi .NET più avanzate / nuove che ti lanciano inaspettatamente (XLinq qualcuno?)
• alcune "funzionalità" di runtime immaturo (limite heap di 3 GB su x64 ... WTF!)

ma ansia ha detto che le cose in generale iniziano a funzionare molto rapidamente e le soluzioni / soluzioni alternative sono abbondanti .

Dopo aver superato quegli ostacoli iniziali, la mia esperienza è quella ROCKS mono e continua a migliorare con ogni iterazione .

Ho avuto server in esecuzione con mono, elaborando 300 GB di dati al giorno, con tonnellate di p / invoke e in generale facendo MOLTO lavoro e rimanendo attivi per 5-6 mesi, anche con il "bleeding edge" mono.

Spero che questo ti aiuti.

Le raccomandazioni per la risposta accettata sono un po 'obsolete ora.

• L'implementazione dei moduli di Windows è piuttosto buona ora. (Vedi Paint-Mono per una porta di Paint.net che è un'applicazione Windows Form piuttosto coinvolta. Tutto ciò che era richiesto era un livello di emulazione per alcune delle chiamate di sistema P-Invoke e non supportate).
• Path.Combine e Path.Seperator per unire percorsi e nomi di file.
• Il registro di Windows è OK, purché lo si usi solo per l'archiviazione e il recupero di dati dalle applicazioni (ovvero non è possibile ottenere alcuna informazione su Windows da esso, poiché è fondamentalmente un registro per le applicazioni Mono).

Se vuoi usare WPF non sei fortunato, al momento Mono non ha in programma di implementarlo.

http://www.mono-project.com/WPF

Bene, il mono è fantastico, ma per quanto posso vedere, è instabile. Funziona, ma non funziona quando si dà al processo mono un lavoro serio da fare.

TL; DR - Non utilizzare mono se:

• utilizzare AppDomains (Assembly Load \ Unload) in ambienti multithread
• Impossibile sostenere il modello "let-it-fail"
• Sperimenta eventi occasionali di carichi pesanti durante l'esecuzione del processo

Quindi, i fatti.

Usiamo mono-2.6.7 (.net v 3.5) su RHEL5, Ubuntu e, dal mio punto di vista, è la versione più stabile costruita da Novell. Ha un problema con Unloading AppDomains (segfaults), tuttavia fallisce molto raramente e questo, di gran lunga, è accettabile (da noi).

Va bene. Ma se si desidera utilizzare le funzionalità di .net 4.0, è necessario passare alle versioni 2.10.xo 3.x, ed è qui che iniziano i problemi.

Rispetto alla 2.6.7, le nuove versioni sono semplicemente inaccettabili. Ho scritto una semplice applicazione di stress test per testare installazioni mono.

È qui, con le istruzioni per l'uso: https://github.com/head-thrash/stress_test_mono

Utilizza i thread di lavoro del pool di thread. Il lavoratore carica la dll su AppDomain e prova a fare un po 'di matematica. Alcuni lavori sono molti thread, alcuni sono singoli. Quasi tutto il lavoro è associato alla CPU, anche se ci sono alcune letture di file dal disco.

I risultati non sono molto buoni. In effetti, per la versione 3.0.12:

• sgen GC segfaults processa quasi immediatamente
• mono con boehm vive più a lungo (da 2 a 5 ore), ma alla fine segfault

Come accennato in precedenza, sgen gc non funziona (mono costruito dalla fonte):

* Assertion: should not be reached at sgen-scan-object.h:111

Stacktrace:


Native stacktrace:

    mono() [0x4ab0ad]
    /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0) [0x2b61ea830cb0]
    /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35) [0x2b61eaa74425]
    /lib/x86_64-linux-gnu/libc.so.6(abort+0x17b) [0x2b61eaa77b8b]
    mono() [0x62b49d]
    mono() [0x62b5d6]
    mono() [0x5d4f84]
    mono() [0x5cb0af]
    mono() [0x5cb2cc]
    mono() [0x5cccfd]
    mono() [0x5cd944]
    mono() [0x5d12b6]
    mono(mono_gc_collect+0x28) [0x5d16f8]
    mono(mono_domain_finalize+0x7c) [0x59fb1c]
    mono() [0x596ef0]
    mono() [0x616f13]
    mono() [0x626ee0]
    /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a) [0x2b61ea828e9a]
    /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x2b61eab31ccd]

Per quanto riguarda boehm segfauls - ad esempio (Ubuntu 13.04, mono costruito dalla fonte):

mono: mini-amd64.c:492: amd64_patch: Assertion `0' failed.
Stacktrace:
at <unknown> <0xffffffff>
at System.Collections.Generic.Dictionary`2.Init (int,System.Collections.Generic.IEqualityComparer`1<TKey>) [0x00012] in /home/bkmz/my/mono/mcs/class/corlib/System.Collections.Generic/Dictionary.cs:264
at System.Collections.Generic.Dictionary`2..ctor () [0x00006] in /home/bkmz/my/mono/mcs/class/corlib/System.Collections.Generic/Dictionary.cs:222
at System.Security.Cryptography.CryptoConfig/CryptoHandler..ctor (System.Collections.Generic.IDictionary`2<string, System.Type>,System.Collections.Generic.IDictionary`2<string, string>) [0x00014] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/Crypto
Config.cs:582
at System.Security.Cryptography.CryptoConfig.LoadConfig (string,System.Collections.Generic.IDictionary`2<string, System.Type>,System.Collections.Generic.IDictionary`2<string, string>) [0x00013] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/CryptoCo
nfig.cs:473
at System.Security.Cryptography.CryptoConfig.Initialize () [0x00697] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:457
at System.Security.Cryptography.CryptoConfig.CreateFromName (string,object[]) [0x00027] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:495
at System.Security.Cryptography.CryptoConfig.CreateFromName (string) [0x00000] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:484
at System.Security.Cryptography.RandomNumberGenerator.Create (string) [0x00000] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/RandomNumberGenerator.cs:59
at System.Security.Cryptography.RandomNumberGenerator.Create () [0x00000] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/RandomNumberGenerator.cs:53
at System.Guid.NewGuid () [0x0001e] in /home/bkmz/my/mono/mcs/class/corlib/System/Guid.cs:492

Oppure (RHEL5, mono è preso da rpm qui ftp://ftp.pbone.net/mirror/ftp5.gwdg.de/pub/opensuse/repositories/home%3A/vmas%3A/mono-centos5 )

Assertion at mini.c:3783, condition `code' not met
Stacktrace:
at <unknown> <0xffffffff>
at System.IO.StreamReader.ReadBuffer () [0x00012] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.IO/StreamReader.cs:394
at System.IO.StreamReader.Peek () [0x00006] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.IO/StreamReader.cs:429
at Mono.Xml.SmallXmlParser.Peek () [0x00000] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/Mono.Xml/SmallXmlParser.cs:271
at Mono.Xml.SmallXmlParser.Parse (System.IO.TextReader,Mono.Xml.SmallXmlParser/IContentHandler) [0x00020] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/Mono.Xml/SmallXmlParser.cs:346
at System.Security.Cryptography.CryptoConfig.LoadConfig (string,System.Collections.Generic.IDictionary`2<string, System.Type>,System.Collections.Generic.IDictionary`2<string, string>) [0x00021] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptog
raphy/CryptoConfig.cs:475
at System.Security.Cryptography.CryptoConfig.Initialize () [0x00697] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:457
at System.Security.Cryptography.CryptoConfig.CreateFromName (string,object[]) [0x00027] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:495
at System.Security.Cryptography.CryptoConfig.CreateFromName (string) [0x00000] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:484
at System.Security.Cryptography.RandomNumberGenerator.Create (string) [0x00000] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptography/RandomNumberGenerator.cs:59
at System.Security.Cryptography.RandomNumberGenerator.Create () [0x00000] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptography/RandomNumberGenerator.cs:53
at System.Guid.NewGuid () [0x0001e] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System/Guid.cs:483
at System.Runtime.Remoting.RemotingServices.NewUri () [0x00020] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Runtime.Remoting/RemotingServices.cs:356
at System.Runtime.Remoting.RemotingServices.Marshal (System.MarshalByRefObject,string,System.Type) [0x000ba] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Runtime.Remoting/RemotingServices.cs:329
at System.AppDomain.GetMarshalledDomainObjRef () [0x00000] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System/AppDomain.cs:1363

Entrambi i guasti sono in qualche modo collegati alla logica di AppDomains, quindi, dovresti stare lontano da loro in mono.

A proposito, il programma testato ha funzionato 24 ore su macchina Windows in MS .NET 4.5 env senza errori.

Quindi, in conclusione, vorrei dire: usa mono con cautela. Funziona a prima vista, ma può facilmente fallire ogni volta. Saresti lasciato con un sacco di discariche fondamentali e una grande perdita di fiducia nei progetti open source.

Il MoMA è un ottimo strumento per questo, come suggerito da qualcun altro. Le maggiori fonti di incompatibilità in questi giorni sono le applicazioni che DllImport (o P / Invoke) nelle librerie Win32. Alcuni assembly non sono implementati, ma la maggior parte di essi è solo per Windows e non avrebbe davvero senso su Linux. Penso che sia abbastanza sicuro dire che la maggior parte delle applicazioni ASP.NET possono essere eseguite su Mono con modifiche limitate.

(Rivelazione: ho contribuito a Mono stesso, così come alle app scritte che girano sopra di esso.)

In molti casi, puoi prendere il codice esistente ed eseguirlo su Mono, in particolare se stai eseguendo il porting di un'applicazione ASP.NET.

In alcuni casi, potresti aver bisogno di intere nuove sezioni di codice per farlo funzionare. Se si utilizza System.Windows.Forms, ad esempio, l'applicazione non funzionerà senza modifiche. Allo stesso modo se si utilizza un codice specifico di Windows (ad esempio il codice di accesso al registro). Ma penso che il peggior colpevole sia il codice dell'interfaccia utente. Ciò è particolarmente negativo sui sistemi Macintosh.

Lo abbiamo utilizzato per un progetto qui al lavoro che doveva essere eseguito su Linux ma riutilizzare alcune librerie .NET che abbiamo creato in Managed C ++. Sono stato molto sorpreso da come ha funzionato. Il nostro eseguibile principale è stato scritto in C # e possiamo semplicemente fare riferimento ai nostri binari Managed C ++ senza problemi. L'unica differenza nel codice C # tra Windows e Linux è il codice della porta seriale RS232.

L'unico grosso problema che mi viene in mente è successo circa un mese fa. La build di Linux presentava una perdita di memoria che non si vedeva nella build di Windows. Dopo aver eseguito il debug manuale (i profiler di base per Mono su Linux non sono stati di grande aiuto), siamo riusciti a restringere il problema a uno specifico blocco di codice. Abbiamo finito per correggere una soluzione alternativa, ma ho ancora bisogno di trovare un po 'di tempo per tornare indietro e capire qual è stata la causa principale della perdita.

Sai quanto è buono il supporto dell'anteprima di Mono 2.0 per Windows Forms 2.0?

Da quel poco che ci ho giocato, mi è sembrato relativamente completo e quasi utilizzabile. Non sembrava proprio giusto in alcuni punti ed è ancora un po 'incostante nel complesso. Mi ha sorpreso il fatto che ha funzionato bene come alcune delle nostre forme, anche se onestamente.

Sì, lo è sicuramente (se stai attento) Supportiamo Mono in Ra-Ajax (la libreria Ajax si trova su http://ra-ajax.org ) e per lo più non abbiamo alcun problema. Devi stare attento con alcune delle "cose ​​più folli" di .Net come WSE ecc., E probabilmente anche alcuni dei tuoi progetti esistenti non saranno compatibili al 100% Mono, ma i nuovi progetti se li testerai durante lo sviluppo lo faranno per lo più essere compatibile senza problemi con Mono. E il vantaggio derivante dal supporto di Linux ecc. Tramite Mono è davvero interessante;)

Gran parte del segreto del supporto di Mono penso sia usare gli strumenti giusti sin dall'inizio, ad esempio ActiveRecord, log4net, ra-ajax ecc ...

Sfortunatamente per il tipo di applicazione che stiamo realizzando Mono non sembra pronto per la produzione. Siamo rimasti colpiti nel complesso e impressionati dalle sue prestazioni sia su Windows che su macchine EC2, tuttavia, il nostro programma si è bloccato in modo coerente con errori di garbage collection sia su Windows che su Linux.

Il messaggio di errore è: "errori fatali in GC: troppe sezioni di heap", ecco un link a qualcun altro che ha riscontrato il problema in un modo leggermente diverso:

http://bugzilla.novell.com/show_bug.cgi?id=435906

Il primo pezzo di codice che abbiamo eseguito in Mono è stata una semplice sfida di programmazione che avevamo sviluppato ... Il codice carica circa 10 MB di dati in alcune strutture di dati (ad esempio HashSet), quindi esegue 10 query sui dati. Abbiamo eseguito le query 100 volte al fine di cronometrarle e ottenere una media.

Il codice si è arrestato in modo anomalo attorno alla 55a query su Windows. Su Linux ha funzionato, ma non appena ci siamo spostati in un set di dati più grande, si sarebbe bloccato anche.

Questo codice è molto semplice, ad esempio inserire alcuni dati in Hashset e quindi interrogare tali Hashset ecc., Tutti i c # nativi, niente di pericoloso, nessuna chiamata API. Sul CLR Microsoft non si arresta mai in modo anomalo e funziona su enormi set di dati 1000 volte bene.

Uno dei nostri ragazzi ha inviato un'email a Miguel e ha incluso il codice che ha causato il problema, nessuna risposta ancora. :(

Sembra anche che molte altre persone abbiano riscontrato questo problema senza soluzione: una soluzione è stata suggerita per ricompilare Mono con impostazioni GC diverse, ma ciò sembra solo aumentare la soglia prima della quale si blocca.

Basta visitare www.plasticscm.com. Tutto (client, server, GUI, strumenti di unione) è scritto su mono.

Dipende molto dagli spazi dei nomi e dalle classi che si stanno utilizzando dal framework .NET. Mi interessava convertire uno dei miei servizi Windows in modo che funzionasse sul mio server di posta elettronica, che è Suse, ma ci siamo imbattuti in diversi blocchi stradali con API che non erano state completamente implementate. C'è un grafico da qualche parte sul sito Web Mono che elenca tutte le classi e il loro livello di completamento. Se l'applicazione è coperta, allora provaci.

Come qualsiasi altra applicazione, fai prototipazione e test prima di prendere un impegno completo, ovviamente.

Un altro problema che abbiamo riscontrato è il software concesso in licenza: se si fa riferimento alla DLL di qualcun altro, non è possibile aggirare le incompatibilità che sono sepolte in tale assembly.

Immagino quindi se si dispone di un'applicazione con alcuni componenti di terze parti che potrebbero essere riempiti. Dubito che molti venditori si svilupperanno pensando a Mono

Esempio: http://community.devexpress.com/forums/p/55085/185853.aspx

No, il mono non è pronto per un lavoro serio. Ho scritto alcuni programmi su Windows usando F # e li ho eseguiti su Mono. Quei programmi usavano il disco, la memoria e la CPU piuttosto intensamente. Ho visto arresti anomali nelle librerie mono (codice gestito), arresti anomali nel codice nativo e arresti anomali nella macchina virtuale. Quando mono funzionava, i programmi erano almeno due volte più lenti rispetto a .Net in Windows e utilizzavano molta più memoria. Stare lontano dal mono per lavori seri.