Per le soluzioni basate su Windows aziendali, .NET è a volte la scelta migliore. Come viene guardato Mono dalle imprese che devono usare Linux (o meglio preferiscono usare Linux)? Supponendo che gli sviluppatori non siano un problema e abbiano familiarità con .NET / Mono e altri possibili concorrenti come Java.
Una società di medie / grandi dimensioni eseguirà Mono sui propri server come opposto a tecnologie come Java? Conosci una compagnia simile?
L'abbiamo usato nella grande azienda in cui lavoro. Non l'abbiamo progettato dall'inizio del progetto, ma ha funzionato in quel modo.
Avevamo un progetto interno che abbiamo sviluppato in .NET, una volta entrato in UAT, l'imprenditore desiderava 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 vicino alla capacità). Invece di acquistare nuovo hardware, qualcuno ha suggerito di eseguire l'app su Mono. Abbiamo passato un paio di giorni a fare i nostri test e poi abbiamo rilasciato l'app a QA, poi a 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 buon risultato per un cambio di requisiti molto, molto tardi. 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 mono commercialmente, ma lo uso privatamente, perché lavoro in un'azienda Windows, ma in privato sono un utente Linux (quindi posso riutilizzare quello che faccio al lavoro).
Nel complesso, sono d'accordo con Miguel de Icaza che dice:
- 25 % of .NET applications work out of the box with mono
- another 25% can be made to work within a day or less
- further 25% can be made to work within a week
- The last 25% require a complete rewrite of the application (WinForms/COM)
Mono funziona abbastanza bene, ma ci sono alcuni problemi:
- VB.NET support only for .NET <= 2.0
- Windows authentication not implemented
- WPF not implemented
- WCF support incomplete
- Entity Framework not implemented and no plans to implement
- "ASP.NET Web Parts" not implemented
- No COM-interop support
- Sybase connection for version 15.5 (latest) doesn't work
- Bugs and incompleteness in the C# class library (e.g. XML was buggy in mono < 2.6)
- The Linux web-browser control requires GTK#
Quindi i problemi minori:
- Windows Forms work, but aren't always rendered properly
- MonoDevelop can't design windows forms
- MonoDevelop 'step through' debugging doesn't really work
- Mono-Service crashes after 5 hours...
Formare quello che posso dire:
- WebServices function excellently
- If you run a WebApplication, it works fairly well (if it doesn't use WebParts).
- If you run WindowsForms, it won't always look very nice (to say the least).
- There is no working equivalent for Microsoft Reporting Service (FYIreporting is the closest thing to it, but it's slow, buggy and very incomplete, plus no activity since more than a year)
- You will experience problems if you need to create Word or Excel documents.
Se vuoi sviluppare .NET su Linux
- You could develop ASP.NET there (debugging & step through works very badly)
- You can't really develop WinForms on Linux
- You need to use GTK# instead of WinForms
In altre parole:
- Mono has it's place in running web applications and WebServices and MailServers.
- But it's not viable to run WindowsForms applications, you need to write applications with GTK#
- It lacks a reporting solution and MS file format support (or working libraries therefore)
Modifica (aggiornamento 2015):
Volevo aggiungere che ormai il debugging "step through" funziona ottimamente, e puoi usare MonoDevelop per sviluppare applicazioni web su Linux, anche con le dipendenze di nuGet. Il problema con le librerie Excel e Word è sparito, e il framework delle entità ora è open-source. Il resto è praticamente "così com'è" (non so se il mono-servizio è corretto, ma lo spero).
Ciò che è migliorato è che ora puoi avere i pacchetti correnti per la tua distribuzione, il che significa che non devi aspettare la prossima versione di Debian / Ubuntu, fino a quando non ottieni l'ultima versione mono (senza doverli compilare da soli) ). Questo è un tempo molto più sicuro.
Inoltre, con il rilascio di Roslyn, il supporto VB.NET dovrebbe migliorare molto nel prossimo futuro.
La mia azienda sviluppa un'importante applicazione desktop prevalentemente-.NET e rilascia versioni di Linux in esecuzione su Mono, quindi direi di sì, c'è sicuramente un posto per Mono nelle soluzioni aziendali basate su Windows.
Mettiamo Mono con l'installazione della nostra applicazione, non richiedendo agli utenti di installarlo separatamente (e in questo modo controlliamo anche la versione).
Penso che la principale preoccupazione di molte aziende sia la questione della licenza tra Mono e Microsoft. La mia comprensione è che, mentre Microsoft ha formalmente concordato che Mono può utilizzare le tecnologie .NET di base, ma al di fuori di questo, incluso quello di cose molto comunemente utilizzate, è più un'area grigia legalmente con Microsoft che non dichiara una posizione ferma su di esso in un modo o altro.
Ciò lascia ovviamente aperta la possibilità che in futuro chiederanno canoni di licenza o semplicemente citeranno per violazione di brevetto. È improbabile che entrambi accadano 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 associati.
Non penso che ci sia molto spazio per Mono lì:
Java è già una piattaforma consolidata su Linux, con un'enorme community e un'abbondanza di librerie e strumenti di qualità enterprise, sia commerciali che open-source. Non vedo alcun motivo per scegliere Mono su Java quando si inizia un nuovo progetto di targeting per Linux (o Mac), a meno che non vi sia una circostanza specifica (vedere la risposta di Walter).
Prima di usare mono, dobbiamo assicurarci che non ci sia "\" codificato per la stringa del percorso (usa Path.Combine ()) o Il prefisso "COM" (accetta semplicemente stringa invece di numero intero) per la porta seriale è nel programma.
Che cosa funziona bene:
Problemi riscontrati:
È meglio usare il mono internamente (come il sistema ERP) come ambiente controllato.
Mono è un'ottima alternativa se hai già un codice .NET che deve essere eseguito su un ambiente multipiattaforma. Mono è usato abbastanza estesamente nel mondo degli affari per risolvere proprio questo problema.
Direi di non utilizzare l'esistenza di Mono come scusa per avviare un progetto con .NET che, come sai, dovrà essere multipiattaforma. La ragione di ciò è il ritardo tra lo stato dell'arte con .NET e la velocità di sviluppo di Mono.
D'altro canto, se do intende utilizzare Mono in un progetto futuro, ti chiederei di scegliere come target il framework Mono ed eseguirlo su .NET come alternativa secondaria poiché Mono è in gran parte un sottoinsieme della funzionalità .NET completa.