Für Windows-basierte Unternehmenslösungen ist .NET manchmal die beste Wahl. Wie sieht Mono bei den Unternehmen aus, die Linux einsetzen müssen (oder lieber Linux einsetzen)? Vorausgesetzt, die Entwickler sind kein Problem und sie kennen .NET / Mono und andere mögliche Konkurrenten wie Java.
Würde ein mittelständisches oder großes Unternehmen Mono auf seinen Servern im Gegensatz zu Technologien wie Java ausführen? Kennen Sie eine solche Firma?
Antworten:
Wir haben es in der großen Firma benutzt, in der ich arbeite. Wir haben es von Anfang an nicht geplant, aber es hat einfach so geklappt.
Wir hatten ein internes Projekt, das wir in .NET entwickelt haben, als wir zu UAT kamen, wollte der Geschäftsinhaber die App für einige Kunden sowie für die internen Mitarbeiter öffnen. Die meisten unserer externen (DMZ) Server basieren auf Linux, und die Windows-Server in der DMZ waren nicht gut geeignet (zu dicht an der Kapazität). Anstatt neue Hardware zu kaufen, schlug jemand vor, die App auf Mono auszuführen. Wir haben ein paar Tage damit verbracht, unsere eigenen Tests durchzuführen, und dann die App für die Qualitätssicherung und dann für UAT freigegeben. Wir hatten keine Probleme.
Wenn wir die Anforderung zu Beginn des Projekts erhalten haben, haben wir uns möglicherweise nicht dafür entschieden, sie in .NET zu schreiben, aber dies war ein gutes Ergebnis für eine sehr, sehr späte Anforderungsänderung. Jetzt sind wir ziemlich zuversichtlich, dass wir Mono erfolgreich bereitstellen könnten, wenn es wieder auftaucht (obwohl ich denke, dass wir irgendwann etwas Code optimieren müssten, ich denke, wir haben einfach Glück).
Ich habe Mono nicht kommerziell genutzt, aber ich benutze es privat, weil ich in einer Windows-Firma arbeite, aber privat ein Linux-Benutzer bin (damit ich das, was ich bei der Arbeit mache, wiederverwenden kann).
Insgesamt stimme ich Miguel de Icaza zu, der sagt:
- 25% der .NET-Anwendungen funktionieren standardmäßig mit Mono
- Weitere 25% können innerhalb eines Tages oder weniger zur Arbeit gebracht werden
- weitere 25% können innerhalb einer Woche zur Arbeit gebracht werden
- Die letzten 25% erfordern ein vollständiges Umschreiben der Anwendung (WinForms / COM)
Mono funktioniert ziemlich gut, aber es gibt einige Probleme:
- VB.NET-Unterstützung nur für .NET <= 2.0
- Windows-Authentifizierung nicht implementiert
- WPF nicht implementiert
- WCF-Unterstützung unvollständig
- Entity Framework nicht implementiert und keine Pläne zur Implementierung
- "ASP.NET-Webparts" nicht implementiert
- Keine COM-Interop-Unterstützung
- Sybase-Verbindung für Version 15.5 (aktuell) funktioniert nicht
- Fehler und Unvollständigkeiten in der C # -Klassenbibliothek (zB XML war in mono <2.6 fehlerhaft)
- Das Linux-Webbrowser-Steuerelement erfordert GTK #
Dann die kleinen Probleme:
- Windows Forms funktioniert, wird jedoch nicht immer ordnungsgemäß gerendert
- MonoDevelop kann keine Windows-Formulare entwerfen
- MonoDevelop 'step through' Debugging funktioniert nicht wirklich
- Mono-Service stürzt nach 5 Stunden ab ...
Bilden Sie, was ich sagen kann:
- WebServices funktionieren hervorragend
- Wenn Sie eine WebApplication ausführen, funktioniert diese recht gut (wenn WebParts nicht verwendet wird).
- Wenn Sie WindowsForms ausführen, sieht es (gelinde gesagt) nicht immer gut aus.
- Es gibt kein funktionierendes Äquivalent für Microsoft Reporting Service (FYIreporting ist am nächsten dran, aber es ist langsam, fehlerhaft und sehr unvollständig, plus keine Aktivität seit mehr als einem Jahr)
- Wenn Sie Word- oder Excel-Dokumente erstellen müssen, treten Probleme auf.
Wenn Sie .NET unter Linux entwickeln möchten
- Sie könnten dort ASP.NET entwickeln (Debuggen und Durcharbeiten funktioniert sehr schlecht)
- Sie können WinForms unter Linux nicht wirklich entwickeln
- Sie müssen GTK # anstelle von WinForms verwenden
Mit anderen Worten:
- Mono hat seinen Platz in der Ausführung von Webanwendungen sowie von WebServices und MailServern.
- Es ist jedoch nicht möglich, WindowsForms-Anwendungen auszuführen. Sie müssen Anwendungen mit GTK # schreiben.
- Es fehlt eine Reporting-Lösung und MS-Dateiformat-Unterstützung (oder Arbeitsbibliotheken dafür)
Edit (Update 2015):
Ich wollte hinzufügen, dass das 'Step-through'-Debugging jetzt hervorragend funktioniert und Sie MonoDevelop verwenden können, um Webanwendungen unter Linux zu entwickeln, auch mit NuGet-Abhängigkeiten. Das Problem mit Excel- und Word-Bibliotheken ist ebenfalls behoben, und das Entity-Framework ist jetzt Open Source. Der Rest ist so ziemlich "wie er ist" (ich weiß nicht, ob Mono-Service behoben ist, aber ich würde es hoffen).
Was sich ebenfalls verbessert hat, ist, dass Sie jetzt aktuelle Pakete für Ihre Distribution haben können, was bedeutet, dass Sie nicht bis zur nächsten Veröffentlichung von Debian / Ubuntu warten müssen, bis Sie die neueste Mono-Version erhalten (ohne sie selbst kompilieren zu müssen) ). Dies ist eine große Zeit sicherer.
Mit der Veröffentlichung von Roslyn dürfte der VB.NET-Support in naher Zukunft noch viel besser werden.
Mein Unternehmen entwickelt hauptsächlich .NET-Desktopanwendungen und veröffentlicht Linux-Versionen, die auf Mono ausgeführt werden. Ich würde also sagen, dass es in Windows-basierten Unternehmenslösungen definitiv einen Platz für Mono gibt.
Wir packen Mono mit der Installation unserer Anwendung, ohne dass die Benutzer sie separat installieren müssen (und auf diese Weise steuern wir auch die Version).
Ich denke, die Hauptsorge vieler Unternehmen sind die Lizenzprobleme zwischen Mono und Microsoft. Mein Verständnis ist, dass Microsoft zwar offiziell zugestimmt hat, dass Mono die .NET-Kerntechnologien verwenden kann, aber außerhalb dessen, einschließlich einiger sehr häufig verwendeter Dinge, rechtlich eher eine Grauzone ist, in der Microsoft keine feste Position in der einen oder anderen Richtung angibt andere.
Das lässt natürlich die Möglichkeit offen, dass sie Lizenzgebühren verlangen oder nur wegen Patentverletzung klagen. Es ist unwahrscheinlich, dass beides von der Art und Weise ausgeht, wie sie sich gerade verhalten, aber die meisten Unternehmen mögen diese Art von Unsicherheit nicht, insbesondere nicht, wenn es um potenzielle Verbindlichkeiten und damit verbundene Kosten geht.
Ich glaube, da ist nicht viel Platz für Mono:
Java ist bereits eine unter Linux etablierte Plattform mit einer riesigen Community und einer Fülle von Bibliotheken und Tools in Unternehmensqualität, sowohl kommerziell als auch als Open Source. Ich sehe keinen Grund, Mono über Java zu wählen, wenn ich ein neues Projekt für Linux (oder Mac) starte, es sei denn, es gibt einen bestimmten Umstand (siehe Walters Antwort).
Bevor Sie Mono verwenden, müssen Sie sicherstellen, dass sich kein fest codiertes '\' für Pfadzeichenfolgen (verwenden Sie Path.Combine ()) oder das Präfix "COM" (akzeptieren Sie einfach Zeichenfolgen anstelle von Ganzzahlen) für die serielle Schnittstelle im Programm befindet.
Was funktioniert gut:
Probleme aufgetreten:
Es ist besser, Mono intern (z. B. ERP-System) als kontrollierte Umgebung zu verwenden.
Mono ist eine großartige Alternative, wenn Sie bereits über .NET-Code verfügen, der in einer plattformübergreifenden Umgebung ausgeführt werden muss. Mono wird in der Geschäftswelt ziemlich häufig verwendet, um genau dieses Problem zu lösen.
Ich würde dagegen argumentieren, die Existenz von Mono als Ausrede für das Starten eines Projekts mit .NET zu verwenden, von dem Sie wissen, dass es plattformübergreifend sein muss. Der Grund dafür ist die Verzögerung zwischen dem Stand der Technik bei .NET und der Entwicklungsgeschwindigkeit von Mono.
Auf der anderen Seite, wenn Sie tun Mono beabsichtigen , in einem zukünftigen Projekt zu verwenden, würde ich Dich warnen , den Mono - Framework und laufe auf .NET Ziel als eine sekundäre Alternative , da Mono weitgehend eine Teilmenge der vollständigen .NET - Funktionalität ist.