Mono を深く見てから数年が経ちました。私が最後に見たとき、BCL の実装と利用可能なツールが限られている限り、それほどではありませんでした。私は今、いくつかのクロス プラットフォーム開発を行う特定の必要性を持っており、企業での選択肢としての Mono についてコミュニティがどのように考えているのか疑問に思っていました。過去数年間、開発作業のほとんどを .Net で行ってきたので、Mono を選択するのは当然の選択のようです。ただし、テストに耐えられないテクノロジーをプッシュしたくはありません。
注: 小規模または中規模のプロジェクトについて話しているわけではありません。サービス指向のアプローチを利用して、グローバルに分散される大規模なエンタープライズ アプリケーションについて話しています。また、Mono プラットフォームで作成されたサービスはどれくらい安定していますか?
ご意見をお待ちしております。
私は昨年の夏、Mono 1.91 を搭載した Mac OS X で動作する .NET 2.0 (+/- 50 000 行のコード) プロジェクトを取得するために作業しました。Mono-Winforms の実装は Mac では見栄えが悪いため、Monocj でインターフェイスを書き直す必要がありました。しかし、非 UI コードについては、特定の Win32 呼び出しへの依存関係を削除した後、すべてがうまく機能しました。
2.0が出たので、それはあると思います。現在のビルド システムはこれに依存しており、非常に満足しています。さて、実際の製品をリリースするにあたり、.NET 2.0 ですべて実行できますか? ならそうだと思います。
モノラルの堅牢性は、ヘビーデューティーのasp.netサイトに適したものに改善されました。2.0リリースでは、安定性を向上させるための多くのバグ修正が行われました。
それだけでなく、スタックの全体的なスケーラビリティを向上させるためにかなりの作業を行いました。
そのほとんどは2.0リリースになりましたが、一部はその後に発生し、今年後半に予定されている2.2のキューに入れられます。
これは非常に過負荷な用語であるため、エンタープライズ向けの raedy と呼ぶものに本当に依存していると思います。
同様の質問に関する私の投稿を参照してください: Mono はプライムタイムの準備ができていますか?
クロスプラットフォーム開発の「特定のニーズ」がある場合は、Monoが本当に唯一の選択肢だと思います:)しかし、述べたように、それは本当に長い道のりを歩んできました。
前回調べたところ、いくつかの制限がありました。それは数年前のことです。スケーラビリティが当時の私たちの課題でした。