Per le soluzioni enterprise basate su Windows, a volte .NET è la scelta migliore. Come viene guardato Mono dalle aziende che devono usare Linux (o piuttosto preferiscono usare Linux)? Supponendo che gli sviluppatori non siano un problema e abbiano familiarità con .NET / Mono e altri possibili concorrenti come Java.
Un'azienda di medie / grandi dimensioni eseguirà Mono sui propri server come opposto a tecnologie come Java? Conosci qualche compagnia del genere?
Risposte:
L'abbiamo usato nella grande società in cui lavoro. Non l'abbiamo pianificato dall'inizio del progetto, ma ha funzionato in quel modo.
Avevamo un progetto interno che abbiamo sviluppato in .NET, una volta entrato in UAT, il proprietario dell'azienda voleva aprire l'app fino ad alcuni clienti e allo staff interno. La maggior parte dei nostri server esterni (DMZ) sono basati su Linux e i server Windows che si trovano nella DMZ non erano adatti (troppo vicini alla capacità). Invece di acquistare nuovo hardware qualcuno ha suggerito di eseguire l'app su Mono. Abbiamo trascorso un paio di giorni a fare i nostri test e quindi abbiamo rilasciato l'app per il QA, quindi UAT. Non abbiamo avuto problemi.
Se all'inizio del progetto ci fosse stato dato il requisito, potremmo non aver scelto di scriverlo in .NET, ma questo è stato un bel risultato di una modifica molto, molto tardiva. Ora siamo abbastanza fiduciosi che se si ripresentasse potremmo implementare con successo su Mono (anche se penso che alla fine dovremmo modificare un po 'di codice, penso che siamo stati fortunati).
Non ho usato il mono in commercio, ma lo uso in privato, perché lavoro in un'azienda Windows, ma privatamente sono un utente Linux (quindi posso riutilizzare ciò che faccio al lavoro).
Nel complesso, concordo con Miguel de Icaza che afferma:
- Il 25% delle applicazioni .NET funziona subito con mono
- un altro 25% può essere fatto funzionare entro un giorno o meno
- ulteriore 25% può essere fatto funzionare entro una settimana
- L'ultimo 25% richiede una riscrittura completa dell'applicazione (WinForms / COM)
Mono funziona abbastanza bene, ma ci sono alcuni problemi:
- Supporto VB.NET solo per .NET <= 2.0
- Autenticazione di Windows non implementata
- WPF non implementato
- Supporto WCF incompleto
- Entity Framework non implementato e nessun piano da implementare
- "Web part ASP.NET" non implementata
- Nessun supporto di interoperabilità COM
- La connessione Sybase per la versione 15.5 (più recente) non funziona
- Bug e incompletezza nella libreria di classe C # (ad es. XML era buggy in mono <2.6)
- Il controllo del browser Web Linux richiede GTK #
Quindi i problemi minori:
- Windows Form funziona, ma non viene sempre visualizzato correttamente
- MonoDevelop non è in grado di progettare moduli Windows
- Il debug 'step through' di MonoDevelop non funziona davvero
- Arresti anomali del servizio singolo dopo 5 ore ...
Forma quello che posso dire:
- I servizi Web funzionano in modo eccellente
- Se si esegue un'applicazione Web, funziona abbastanza bene (se non utilizza WebParts).
- Se esegui WindowsForms, non sarà sempre molto bello (per non dire altro).
- Non esiste un equivalente funzionante per Microsoft Reporting Service (FYIreporting è la cosa più vicina ad esso, ma è lenta, buggy e molto incompleta, oltre a nessuna attività da più di un anno)
- Si verificheranno problemi se è necessario creare documenti Word o Excel.
Se vuoi sviluppare .NET su Linux
- È possibile sviluppare ASP.NET lì (debug e passaggio funziona molto male)
- Non puoi davvero sviluppare WinForms su Linux
- Devi usare GTK # invece di WinForms
In altre parole:
- Mono ha il suo posto nell'esecuzione di applicazioni Web e WebServices e MailServer.
- Ma non è possibile eseguire applicazioni WindowsForms, è necessario scrivere applicazioni con GTK #
- Manca una soluzione di reportistica e supporto per il formato di file MS (o quindi librerie funzionanti)
Modifica (aggiornamento 2015):
volevo aggiungere che ormai, il debug 'step through' funziona in modo eccellente e puoi usare MonoDevelop per sviluppare applicazioni web su Linux, anche con dipendenze nuGet. Anche il problema con le librerie Excel e Word è scomparso e il framework entità è ora open-source. Il resto è praticamente "così com'è" (non so se il mono-servizio è stato risolto, ma lo spero).
Ciò che è anche migliorato è che ora puoi avere i pacchetti attuali per la tua distribuzione, il che significa che non devi aspettare fino alla prossima versione di, diciamo Debian / Ubuntu, fino a ottenere l'ultima versione mono (senza doverli compilare da soli ). Questo è un grande risparmio di tempo.
Inoltre, con il rilascio di Roslyn, il supporto VB.NET dovrebbe migliorare molto nel prossimo futuro.
La mia azienda sviluppa un'importante applicazione desktop principalmente-.NET e rilascia versioni Linux in esecuzione su Mono, quindi direi di sì, c'è sicuramente un posto per Mono nelle soluzioni basate su Windows aziendali.
Impacchettiamo Mono con l'installazione della nostra applicazione, senza richiedere agli utenti di installarla separatamente (e in questo modo controlliamo anche la versione).
Penso che la principale preoccupazione che avrebbero molte aziende siano i problemi di licenza tra Mono e Microsoft. La mia comprensione è che, sebbene Microsoft abbia formalmente convenuto che Mono può utilizzare le tecnologie .NET di base, ma al di fuori di questo, incluso circa roba molto comunemente usata, è più un'area grigia legalmente con Microsoft che non afferma alcuna posizione ferma su di essa in un modo o altro.
Ciò ovviamente lascia aperta la possibilità che, in fondo, richiederanno canoni di licenza o semplicemente faranno causa per violazione di brevetto. È improbabile che uno dei due si verifichi dal modo in cui si stanno comportando in questo momento, ma alla maggior parte delle aziende non piace quel tipo di incertezza, in particolare non quando si tratta di potenziali passività e costi collegati.
Non penso che ci sia molto spazio per Mono lì:
Java è già una piattaforma consolidata su Linux, con una vasta comunità e abbondanza di librerie e strumenti di qualità aziendale, sia commerciali che open source. Non vedo alcun motivo per scegliere Mono su Java quando si avvia un nuovo progetto destinato a Linux (o Mac), a meno che non ci siano circostanze specifiche (vedere la risposta di Walter).
Prima di usare mono, dobbiamo assicurarci che nel programma non sia presente alcun codice hardcoded '\' per la stringa di percorso (usa il prefisso Path.Combine ()) o "COM" (accetta semplicemente la stringa anziché l'intero) per la porta seriale.
Cosa funziona bene:
Problemi riscontrati:
È meglio usare il mono internamente (come il sistema ERP) come ambiente controllato.
Mono è un'ottima alternativa se si dispone già di un codice .NET che deve essere eseguito su un ambiente multipiattaforma. Mono è ampiamente utilizzato nel mondo degli affari proprio per risolvere questo problema.
Discuterei contro l'uso dell'esistenza di Mono come scusa per l'avvio di un progetto con .NET che sapete dovrà essere multipiattaforma. La ragione di ciò è il ritardo tra lo stato dell'arte con .NET e la velocità di sviluppo di Mono.
D'altra parte, se non intende utilizzare Mono in un progetto futuro, vorrei si cautela di indirizzare il quadro Mono ed eseguito su .NET come alternativa secondaria poiché Mono è in gran parte un sottoinsieme della piena funzionalità .NET.