Mono a-t-il une place dans le monde de l'entreprise?

Pour les solutions d'entreprise basées sur Windows, .NET est parfois le meilleur choix. Comment Mono est-il perçu par les entreprises qui doivent utiliser Linux (ou préfèrent plutôt utiliser Linux)? En supposant que les développeurs ne sont pas un problème et qu'ils connaissent bien .NET / Mono et d'autres concurrents possibles tels que Java.

Une moyenne / grande entreprise exécuterait-elle Mono sur leurs serveurs contrairement à des technologies telles que Java? Connaissez-vous une telle entreprise?

Nous l'avons utilisé dans la grande entreprise où je travaille. Nous ne l'avions pas prévu dès le début du projet, mais cela a fonctionné de cette façon.

Nous avions un projet interne que nous avons développé dans .NET, une fois entré dans UAT, le propriétaire de l'entreprise voulait ouvrir l'application à certains clients ainsi qu'au personnel interne. La majorité de nos serveurs externes (DMZ) sont basés sur Linux et les serveurs Windows qui sont dans la DMZ n'étaient pas adaptés (trop près de la capacité). Au lieu d'acheter du nouveau matériel, quelqu'un a suggéré d'exécuter l'application sur Mono. Nous avons passé quelques jours à faire nos propres tests, puis nous avons lancé l'application sur QA, puis sur UAT. Nous n'avons eu aucun problème.

Si nous avions reçu l'exigence au début du projet, nous n'aurions peut-être pas choisi de l'écrire dans .NET, mais c'était un bon résultat pour un changement d'exigence très, très tardif. Maintenant, nous sommes assez confiants que si cela revenait, nous pourrions déployer avec succès sur Mono (bien que je pense que nous devrons éventuellement modifier un peu de code, je pense que nous avons juste eu de la chance).

Je n'ai pas utilisé le mono commercialement, mais je l'utilise en privé, car je travaille dans une entreprise Windows, mais en privé je suis un utilisateur Linux (donc je peux réutiliser ce que je fais au travail).

Dans l'ensemble, je suis d'accord avec Miguel de Icaza qui dit:

• 25% des applications .NET fonctionnent avec le mono
• 25% supplémentaires peuvent être mis au travail en moins d'une journée
• 25% supplémentaires peuvent être mis au travail en une semaine
• Les 25% restants nécessitent une réécriture complète de l'application (WinForms / COM)

Mono fonctionne assez bien, mais il y a quelques problèmes:

• Prise en charge de VB.NET uniquement pour .NET <= 2.0
• Authentification Windows non implémentée
• WPF non implémenté
• Prise en charge WCF incomplète
• Entity Framework non implémenté et aucun plan à implémenter
• "WebPart ASP.NET" non implémenté
• Pas de prise en charge COM-interop
• La connexion Sybase pour la version 15.5 (la plus récente) ne fonctionne pas
• Bogues et incomplétude dans la bibliothèque de classes C # (par exemple, XML était bogué en mono <2.6)
• Le contrôle du navigateur Web Linux nécessite GTK #

Ensuite, les problèmes mineurs:

• Windows Forms fonctionne, mais n'est pas toujours rendu correctement
• MonoDevelop ne peut pas concevoir de formulaires Windows
• Le débogage pas à pas de MonoDevelop ne fonctionne pas vraiment
• Mono-Service plante après 5 heures ...

Formez ce que je peux dire:

• Les WebServices fonctionnent parfaitement
• Si vous exécutez une WebApplication, elle fonctionne assez bien (si elle n'utilise pas WebParts).
• Si vous exécutez WindowsForms, cela ne sera pas toujours très joli (pour dire le moins).
• Il n'y a pas d'équivalent fonctionnel pour Microsoft Reporting Service (FYIreporting est la chose la plus proche, mais c'est lent, bogué et très incomplet, plus aucune activité depuis plus d'un an)
• Vous rencontrerez des problèmes si vous devez créer des documents Word ou Excel.

Si vous souhaitez développer .NET sous Linux

• Vous pourriez y développer ASP.NET (le débogage et les étapes fonctionnent très mal)
• Vous ne pouvez pas vraiment développer WinForms sur Linux
• Vous devez utiliser GTK # au lieu de WinForms

En d'autres termes:

• Mono a sa place dans l'exécution des applications Web et des WebServices et MailServers.
• Mais il n'est pas viable d'exécuter des applications WindowsForms, vous devez écrire des applications avec GTK #
• Il manque une solution de reporting et une prise en charge du format de fichier MS (ou des bibliothèques de travail par conséquent)

Edit (mise à jour 2015):
Je voulais ajouter que le débogage `` étape par étape '' fonctionne parfaitement et que vous pouvez utiliser MonoDevelop pour développer des applications Web sur Linux, même avec des dépendances nuGet. Le problème avec les bibliothèques Excel et Word a également disparu, et l'entité-framework est maintenant open-source. Le reste est à peu près "tel quel" (je ne sais pas si le mono-service est fixe, mais j'espère bien).
Ce qui s'est également amélioré, c'est que vous pouvez maintenant avoir des packages actuels pour votre distribution, ce qui signifie que vous n'avez pas besoin d'attendre la prochaine version de, disons Debian / Ubuntu, jusqu'à ce que vous obteniez la dernière version mono (sans avoir à les compiler vous-même) ). C'est un temps plus sûr.

De plus, avec la sortie de Roslyn, le support VB.NET devrait s'améliorer beaucoup dans un avenir proche.

Mon entreprise développe une application de bureau majoritairement basée sur .NET et publie des versions Linux fonctionnant sur Mono, donc je dirais que oui, il y a certainement une place pour Mono dans les solutions Windows d'entreprise.

Nous emballons Mono avec l'installation de notre application, sans exiger que les utilisateurs l'installent séparément (et de cette façon nous contrôlons également la version).

Je pense que la principale préoccupation de nombreuses entreprises concerne les problèmes de licence entre Mono et Microsoft. D'après ce que je comprends, bien que Microsoft ait officiellement accepté que Mono puisse utiliser les technologies de base .NET, mais en dehors de cela, y compris à propos de choses très couramment utilisées, il s'agit plus d'une zone grise légalement avec Microsoft ne déclarant aucune position ferme à ce sujet dans un sens ou autre.

Cela laisse évidemment ouverte la possibilité qu'en fin de compte, ils exigeront des frais de licence ou poursuivront en justice pour violation de brevet. Il est peu probable que cela se produise en raison de leur comportement actuel, mais la plupart des entreprises n'aiment pas ce genre d'incertitude, en particulier pas en ce qui concerne les responsabilités et les coûts potentiels.

Je ne pense pas qu'il y ait beaucoup d'espace pour Mono:

Java est déjà une plate-forme établie sur Linux, avec une communauté énorme et une abondance de bibliothèques et d'outils de qualité d'entreprise, à la fois commerciaux et open-source. Je ne vois aucune raison de choisir Mono sur Java lors du démarrage d'un nouveau projet ciblant Linux (ou Mac), sauf en cas de circonstances spécifiques (voir la réponse de Walter).

Avant d'utiliser mono, nous devons nous assurer qu'aucun «\» codé en dur pour la chaîne de chemin d'accès (utilisez Path.Combine ()) ou le préfixe «COM» (acceptez simplement la chaîne au lieu de l'entier) pour le port série est dans le programme.

Ce qui fonctionne bien:

• Application console
• Web App

Les problèmes rencontrés:

• WinForms non stable: plantage aléatoire.
• Prise en charge linguistique: la communauté peut ne pas bien connaître toutes les langues, en particulier les dialectes de certains pays / villes. Les paramètres régionaux / collations correspondants peuvent être manqués.
• Les méthodes rarement utilisées peuvent avoir un comportement incompatible avec .NET.
• xsp ne prend en charge que HTTP 1.0. Actuellement, il ne prend pas en charge HTTP 1.1.
• Le contrôle du navigateur ne fonctionne pas bien.

Il est préférable d'utiliser mono en interne (comme le système ERP) comme environnement contrôlé.

Mono est une excellente alternative si vous avez déjà du code .NET qui doit s'exécuter sur un environnement multiplateforme. Mono est utilisé assez largement dans le monde des affaires spécifiquement pour résoudre ce problème.

Je m'oppose à l'utilisation de l'existence de Mono comme excuse pour démarrer un projet avec .NET qui, vous le savez, devra être multiplateforme. La raison en est le décalage entre l'état de l'art avec .NET et la vitesse de développement de Mono.

D'autre part, si vous avez l' intention d'utiliser Mono dans un projet futur, je vous mets en garde pour cibler le cadre Mono et exécuter sur .NET comme une alternative secondaire depuis Mono est en grande partie un sous - ensemble de la fonctionnalité complète de .NET.