Monoは、エンタープライズの世界で活躍していますか？

エンタープライズWindowsベースのソリューションの場合、.NETが最良の選択である場合があります。Linuxを使用しなければならない（またはLinuxを使用することを好む）企業はMonoをどのように見ていますか？開発者が問題ではなく、.NET / MonoやJavaなどの競合他社に精通していると仮定します。

中規模または大規模の会社は、Javaなどのテクノロジーとは反対に、サーバーでMonoを実行しますか？そのような会社を知っていますか？

私が働いている大企業で使用しました。私たちはプロジェクトの最初からそれを計画していませんでしたが、それはちょうどそのようにうまくいきました。

.NETで開発した内部プロジェクトがあり、UATを取得した後、ビジネスオーナーは一部の顧客と内部スタッフにアプリを公開したいと考えました。当社の外部（DMZ）サーバーの大部分はLinuxベースであり、DMZにあるWindowsサーバーは適切ではありませんでした（容量に近すぎます）。新しいハードウェアを購入する代わりに、Monoでアプリを実行することを提案しました。数日かけて独自のテストを行い、アプリをQA、次にUATにリリースしました。問題ありませんでした。

プロジェクトの開始時に要件が与えられていた場合は、.NETで作成することを選択しなかった可能性がありますが、これは非常に遅い要件変更に対する良い結果の1つでした。今度は、Monoに正常に展開できると確信しています（最終的にはコードを微調整する必要があると思いますが、幸運になったと思います）。

私はモノラルを商業的に使用していませんが、私はWindows会社で働いているので個人的に使用しますが、個人的にはLinuxユーザーです（したがって、仕事で行ったことを再利用できます）。

全体的に、ミゲル・デ・イカザは次のように言っています。

• 25％の.NETアプリケーションは、モノですぐに動作します
• さらに25％を1日以内に機能させることができます
• さらに25％を1週間以内に稼働させることができます
• 最後の25％は、アプリケーション（WinForms / COM）の完全な書き換えが必要です。

Monoはかなりうまく機能しますが、いくつかの問題があります。

• .NET <= 2.0のみのVB.NETサポート
• Windows認証が実装されていません
• WPFは実装されていません
• WCFサポートが不完全です
• Entity Frameworkは実装されておらず、実装する計画もありません
• 「ASP.NET Webパーツ」は実装されていません
• COM相互運用サポートなし
• バージョン15.5（最新）のSybase接続が機能しない
• C＃クラスライブラリのバグと不完全性（たとえば、モノラル<2.6ではXMLにバグがありました）
• Linux WebブラウザーコントロールにはGTK＃が必要です

次に、マイナーな問題：

• Windowsフォームは機能しますが、常に適切にレンダリングされるとは限りません
• MonoDevelopはWindowsフォームを設計できません
• MonoDevelopの「ステップスルー」デバッグが実際に機能しない
• 5時間後にモノサービスがクラッシュする...

私が言えることを形作る：

• WebServicesは優れた機能を発揮します
• WebApplicationを実行する場合、（WebPartsを使用しない場合）かなりうまく機能します。
• WindowsFormsを実行する場合、常に見栄えがよくなるとは限りません（控えめに言っても）。
• Microsoft Reporting Serviceに相当する機能はありません（FYIreportingはそれに最も近いものですが、遅く、バグがあり、非常に不完全であり、1年以上アクティビティがありません）
• WordまたはExcelドキュメントを作成する必要がある場合、問題が発生します。

Linuxで.NETを開発する場合

• そこでASP.NETを開発できます（デバッグとステップスルーは非常にひどく動作します）
• Linux上でWinFormsを実際に開発することはできません
• WinFormsの代わりにGTK＃を使用する必要があります

言い換えると：

• Monoは、Webアプリケーション、WebServices、およびMailServerの実行に適しています。
• しかし、WindowsFormsアプリケーションを実行することは実行可能ではありません。GTK＃でアプリケーションを書く必要があります
• レポートソリューションとMSファイル形式のサポート（または作業ライブラリ）が不足している

編集（2015年の更新）：
これまでに追加したかったのは、「ステップスルー」デバッグが非常に優れていることです。MonoDevelopを使用して、nuGet依存関係があってもLinux上でWebアプリケーションを開発できます。ExcelおよびWordライブラリの問題もなくなり、エンティティフレームワークはオープンソースになりました。残りはほとんど「現状のまま」です（モノサービスが修正されるかどうかはわかりませんが、そうすることを望みます）。
同様に改善されたのは、現在のディストリビューションのパッケージを入手できることです。つまり、Debian / Ubuntuなどの次のリリースまで、最新のモノバージョンを入手するまで待つ必要はありません（自分でコンパイルする必要はありません） ）。これは主要な時間の安全です。

また、Roslynのリリースにより、VB.NETのサポートは近い将来さらに良くなるはずです。

私の会社は、主に.NETデスクトップアプリケーションを開発し、Monoで実行するLinuxバージョンをリリースしています。そのため、エンタープライズWindowsベースのソリューションには、Monoが間違いなく存在します。

Monoをアプリケーションのインストールと共にパッケージ化します。ユーザーが個別にインストールする必要はありません（このようにしてバージョンも制御します）。

多くの企業が抱える主な懸念は、MonoとMicrosoftの間のライセンスの問題だと思います。私の理解では、MicrosoftはMonoがコア.NETテクノロジーを使用できることに正式に同意しましたが、それ以外では、非常に一般的に使用されるものを含め、法的にはMicrosoftが一方的に確固たる地位を表明していない灰色の領域ですその他。

それは明らかに、彼らがライセンス料を要求するか、単に特許違反で訴える可能性を残している。どちらかが現在の振る舞いから生じることはまずありませんが、ほとんどの企業はそのような不確実性を好みません。特に潜在的な負債とコストが伴う場合はそうではありません。

Monoには十分なスペースがないと思います。

JavaはすでにLinux上で確立されたプラットフォームであり、巨大なコミュニティと豊富なエンタープライズ品質のライブラリおよびツール（商用およびオープンソースの両方）を備えています。特定の状況がない限り、Linux（またはMac）をターゲットとする新しいプロジェクトを開始するときに、JavaではなくMonoを選択する理由はありません（Walterの回答を参照）。

モノを使用する前に、シリアルポートのパス文字列（Path.Combine（）を使用）または "COM"プレフィックス（単純に整数ではなく文字列を受け入れる）にハードコードされた '\'がプログラムにないことを確認する必要があります。

うまくいくもの：

• コンソールアプリ
• Webアプリ

発生した問題：

• WinFormsが安定していない：ランダムにクラッシュします。
• 言語サポート：コミュニティはすべての言語、特に一部の国/都市の方言を十分に理解していない場合があります。対応するロケール/照合が欠落している可能性があります。
• まれに使用されるメソッドは、.NETと互換性のない動作をする場合があります。
• xspはHTTP 1.0のみをサポートします。現在、HTTP 1.1はサポートされていません。
• ブラウザコントロールがうまく機能しません。

制御された環境として内部でモノ（ERPシステムなど）を使用することをお勧めします。

クロスプラットフォーム環境で実行する必要のある.NETコードが既にある場合、Monoは優れた代替手段です。Monoは、まさにこの問題を解決するために、ビジネスの世界で非常に広く使用されています。

クロスプラットフォームである必要があることがわかっている.NETでプロジェクトを開始するための口実としてMonoの存在を使用することに反対します。この理由は、最先端の.NETとMonoの開発速度の間の遅れです。

あなたは一方、ない将来のプロジェクトでモノを使用する予定のモノ以来二の選択肢は、主に完全な.NET機能のサブセットであるとして、私はモノのフレームワークをターゲットと.NET上で実行するように警告します。