Monoはプライムタイムの準備ができていますか？[閉まっている]

大規模または中規模のプロジェクトでオープンソースの.NET実装であるMonoを使用した人はいますか？実世界の実稼働環境に対応できるかどうか疑問に思っています。安定していて、高速で、互換性がありますか？...使用するのに十分ですか？それはMonoランタイムにポートプロジェクトに多くの労力がかかる、または本当に、あるいは本当にただの取るとMicrosoftのランタイムのため、すでに書かれたコードを実行するための互換性は十分？

考慮すべきシナリオがいくつかあります。（a）既存のアプリケーションを移植していて、Monoがこのタスクに十分かどうか疑問に思っている場合。（b）新しいコードを書き始めており、Monoが十分に成熟しているかどうかを知りたい場合。

最初のケースでは、Mono Migration Analyzerツール（Moma）を使用して、アプリケーションがMonoで実行されている距離を評価できます。評価がフライングカラーで戻ってきた場合は、テストとQAを開始して、出荷の準備をする必要があります。

Monoでのセマンティクスが欠落しているか、セマンティクスが大幅に異なる機能を強調表示するレポートが評価に戻った場合は、コードを適合、書き換え、または最悪の場合、アプリケーションが機能制限で動作するかどうかを評価する必要があります。

ユーザーの提出（これはメモリからのもの）に基づくMoma統計によると、アプリケーションの約50％はそのままで動作し、約25％は約1週間の作業（リファクタリング、適応）を必要とし、さらに15％はコードのチャンクをやり直してください。残りはWin32に非常に強く結びついているので、ポーティングを行う価値はありません。その時点で、ゼロから始めるか、ビジネス上の意思決定によりコードを移植可能にするための努力が駆り立てられますが、私たちは数か月分の作業（少なくとも私たちの報告から）について話し合っています。

最初から始める場合、Monoに存在するAPIのみを使用するため、状況ははるかに単純になります。サポートされているスタック（ほぼ.NET 2.0、およびLINQとSystem.Coreを含む3.5のすべてのコアアップグレード、およびMonoクロスプラットフォームAPI）を使用している限り、問題はありません。

たまに、Monoのバグや制限に遭遇したり、回避したりする必要があるかもしれませんが、それは他のどのシステムとも変わりません。

移植性について：ASP.NETアプリケーションは移植が簡単です。Win32への依存性がほとんどまたはまったくなく、SQLサーバーやその他の一般的なデータベースを使用することもできます（Monoにバンドルされたデータベースプロバイダーがたくさんあります）。

開発者は.NETサンドボックスをエスケープしてP / Invokeを実行し、wParamのBCDフォームにエンコードされた2つのベジエポイントとして表されるカーソルの点滅速度を変更するのと同じくらい便利なものを構成したいため、Windows.Formsの移植は扱いにくいことがあります。またはそのようないくつかのジャンク。

これは.NET 4.0までかなり広範囲をカバーし、.NET 4.5 APIの一部の機能さえも含みますが、APIが非推奨になった、新しい代替案が作成された、スコープが広すぎるため、実装しないことを選択したいくつかの領域があります大。次のAPIはMonoでは使用できません。

• Windows Presentation Foundation
• Windows Workflow Foundation（2つのバージョンのどちらでもない）
• エンティティフレームワーク
• 標準WebサービススタックへのWSE1 / WSE2「アドオン」

さらに、WCFの実装はSilverlightがサポートするものに限定されます。

特定のプロジェクトを確認する最も簡単な方法は、Mono Migration Analyzer（MoMA）を実行することです。利点は、Mono（存在する場合）の使用を妨げる問題をMonoチームに通知し、Monoチームが作業の優先順位を付けることができることです。

私は最近、SubSonicでMoMAを実行しましたが、Nullable型の奇妙な使用という1つの問題しか見つかりませんでした。これは大きなコードベースなので、カバレッジはかなり印象的でした。

Monoは、いくつかの商用およびオープンソース製品で積極的に使用されています。WikipediaやMozilla Developer Centerなどのいくつかの大規模なアプリケーションで使用されており、Sansa MP3プレーヤーなどの組み込みアプリケーションで使用されており、数千もの公開されているゲームを強化しています。

言語レベルでは、MonoコンパイラはC＃5.0言語仕様に完全に準拠しています。

デスクトップ側では、GTK＃を使用することを約束した場合、Monoは適切に機能します。Windows.Formsの実装はまだ少しバグがあります（たとえば、TrayIconが機能しない）が、長い道のりを歩んできました。さらに、GTK＃はWindowsフォームよりも優れたツールキットです。

Web側では、Monoはほとんどのサイトを完全に実行するのに十分なASP.NETを実装しています。ここでの問題は、apacheにmod_monoがインストールされているホストを見つけること、またはホストへのシェルアクセスがある場合は自分で行うことです。

いずれにせよ、Monoは素晴らしく、安定しています。

クロスプラットフォームプログラムを作成するときに覚えておくべき重要な点：

• Windows.Formsの代わりにGTK＃を使用する
• ファイル名を適切に大文字小文字を区別するようにしてください
• 利用Path.Separator代わりにハードコーディングの"\"使用も、Environment.NewLine代わりのを"\n"。
• Win32 APIへのP / Invoked呼び出しを使用しないでください。
• Windowsレジストリは使用しないでください。

私はプライムタイムの環境で個人的にMonoを使用しています。ギガバイトのudp / tcpデータ処理に関連するタスクを処理するモノサーバーを実行しているため、満足できません。

いくつかの特徴があり、Monoの現在の状態が原因で、msbuildファイルを単に「ビルド」することができないことが最も厄介なことの1つです。

• MonoDevelop（IDE）は一部のmsbuildサポートを備えていますが、基本的には単純なhello-world（カスタムビルドタスク、$（SolutionDir）のような動的な「プロパティ」、いくつかのデッドを指定する実際の設定）を超える「REAL」ビルドconf -終了）
• xbuild されている必要があり、コマンドラインから構築するのは非常に「非正統的な」状態である、実際にGUIを使用したよりも悪い経験であるので、モノ供給-MSBuildの-完全互換のビルド・システムは、さらに恐ろしいですLinux環境のユニオン...

一度/実際にビルドするときに、次のようにサポートする必要があるコードであっても、いくつかの荒野が見られることがあります。

• コンパイラーが特定の構成要素で失敗する
• 予期しないがらくたを投げる特定のより高度な/新しい.NETクラス（XLinq誰か？）
• いくつかの未熟なランタイムの「機能」（x64での3GBのヒープ制限... WTF！）

しかし、ヒービングは、一般的に言えば物事は非常に迅速に機能し始め、解決策/回避策は豊富であると述べました。

これらの最初のハードルを乗り越えたら、私の経験はそのモノROCKSであり、反復ごとに改善され続けます。

私はサーバーをモノで実行し、1日あたり300 GBのデータを処理し、大量のp / invokesを実行し、一般的に言って大量の作業を行い、「最先端の」モノでも5〜6か月間稼働し続けました。

お役に立てれば。

受け入れられた回答の推奨事項は、少し古くなっています。

• Windowsフォームの実装は、今ではかなり良いです。（かなり複雑なWindowsフォームアプリケーションであるPaint.netのポートについては、Paint-Monoを参照してください。必要なのは、一部のP-Invokeおよびサポートされていないシステムコールのエミュレーションレイヤーだけでした）。
• Path.CombineおよびPath.Seperatorは、パスとファイル名を結合します。
• Windowsレジストリは、アプリケーションからのデータの格納と取得にのみ使用している限り、問題ありません（つまり、基本的にはMonoアプリケーションのレジストリであるため、Windowsに関する情報を取得できません）。

WPFを使用したい場合、運が悪いのでMonoには現在実装する予定はありません。

http://www.mono-project.com/WPF

まあ、モノは素晴らしいですが、私が見る限り、それは不安定です。動作しますが、モノプロセスに真剣な作業をさせると失敗します。

TL; DR-次の場合はモノラルを使用しないでください。

• マルチスレッド環境でAppDomains（Assembly Load \ Unload）を使用する
• 「失敗」モデルを維持できない
• プロセス実行中に高負荷イベントが時々発生する

それで、事実。

私たちはRHEL5、Ubuntuでmono-2.6.7（.net v 3.5）を使用しており、私の見解では、Novellによって構築された最も安定したバージョンです。AppDomains（segfaults）のアンロードに問題がありますが、失敗することはまれであり、これは（私たちにとって）許容範囲です。

はい。しかし、.net 4.0の機能を使用したい場合は、バージョン2.10.xまたは3.xに切り替える必要があり、そこから問題が始まります。

2.6.7と比較すると、新しいバージョンを使用することはできません。モノのインストールをテストするための簡単なストレステストアプリケーションを作成しました。

これは、使用手順とともにここにあります：https : //github.com/head-thrash/stress_test_mono

スレッドプールワーカースレッドを使用します。ワーカーはdllをAppDomainにロードし、いくつかの数学作業を実行しようとします。一部の作業はマルチスレッドであり、一部は単一です。ディスクからのファイルの読み取りがいくつかありますが、ほとんどすべての作業はCPUに依存しています。

結果はあまり良くありません。実際、バージョン3.0.12の場合：

• sgen GC segfaultsはほぼ即座に処理されます
• ベーム付きのモノラルは、より長い寿命（2〜5時間）ですが、最終的にはセグメンテーション違反が発生します

上記のように、sgen gcは機能しません（ソースからビルドされたモノ）。

* Assertion: should not be reached at sgen-scan-object.h:111

Stacktrace:


Native stacktrace:

    mono() [0x4ab0ad]
    /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0) [0x2b61ea830cb0]
    /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35) [0x2b61eaa74425]
    /lib/x86_64-linux-gnu/libc.so.6(abort+0x17b) [0x2b61eaa77b8b]
    mono() [0x62b49d]
    mono() [0x62b5d6]
    mono() [0x5d4f84]
    mono() [0x5cb0af]
    mono() [0x5cb2cc]
    mono() [0x5cccfd]
    mono() [0x5cd944]
    mono() [0x5d12b6]
    mono(mono_gc_collect+0x28) [0x5d16f8]
    mono(mono_domain_finalize+0x7c) [0x59fb1c]
    mono() [0x596ef0]
    mono() [0x616f13]
    mono() [0x626ee0]
    /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a) [0x2b61ea828e9a]
    /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x2b61eab31ccd]

boehm segfaulsの場合-たとえば（Ubuntu 13.04、ソースからビルドされたモノ）：

mono: mini-amd64.c:492: amd64_patch: Assertion `0' failed.
Stacktrace:
at <unknown> <0xffffffff>
at System.Collections.Generic.Dictionary`2.Init (int,System.Collections.Generic.IEqualityComparer`1<TKey>) [0x00012] in /home/bkmz/my/mono/mcs/class/corlib/System.Collections.Generic/Dictionary.cs:264
at System.Collections.Generic.Dictionary`2..ctor () [0x00006] in /home/bkmz/my/mono/mcs/class/corlib/System.Collections.Generic/Dictionary.cs:222
at System.Security.Cryptography.CryptoConfig/CryptoHandler..ctor (System.Collections.Generic.IDictionary`2<string, System.Type>,System.Collections.Generic.IDictionary`2<string, string>) [0x00014] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/Crypto
Config.cs:582
at System.Security.Cryptography.CryptoConfig.LoadConfig (string,System.Collections.Generic.IDictionary`2<string, System.Type>,System.Collections.Generic.IDictionary`2<string, string>) [0x00013] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/CryptoCo
nfig.cs:473
at System.Security.Cryptography.CryptoConfig.Initialize () [0x00697] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:457
at System.Security.Cryptography.CryptoConfig.CreateFromName (string,object[]) [0x00027] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:495
at System.Security.Cryptography.CryptoConfig.CreateFromName (string) [0x00000] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:484
at System.Security.Cryptography.RandomNumberGenerator.Create (string) [0x00000] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/RandomNumberGenerator.cs:59
at System.Security.Cryptography.RandomNumberGenerator.Create () [0x00000] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/RandomNumberGenerator.cs:53
at System.Guid.NewGuid () [0x0001e] in /home/bkmz/my/mono/mcs/class/corlib/System/Guid.cs:492

または（RHEL5、モノはrpmからここに取得されますftp://ftp.pbone.net/mirror/ftp5.gwdg.de/pub/opensuse/repositories/home%3A/vmas%3A/mono-centos5）

Assertion at mini.c:3783, condition `code' not met
Stacktrace:
at <unknown> <0xffffffff>
at System.IO.StreamReader.ReadBuffer () [0x00012] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.IO/StreamReader.cs:394
at System.IO.StreamReader.Peek () [0x00006] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.IO/StreamReader.cs:429
at Mono.Xml.SmallXmlParser.Peek () [0x00000] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/Mono.Xml/SmallXmlParser.cs:271
at Mono.Xml.SmallXmlParser.Parse (System.IO.TextReader,Mono.Xml.SmallXmlParser/IContentHandler) [0x00020] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/Mono.Xml/SmallXmlParser.cs:346
at System.Security.Cryptography.CryptoConfig.LoadConfig (string,System.Collections.Generic.IDictionary`2<string, System.Type>,System.Collections.Generic.IDictionary`2<string, string>) [0x00021] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptog
raphy/CryptoConfig.cs:475
at System.Security.Cryptography.CryptoConfig.Initialize () [0x00697] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:457
at System.Security.Cryptography.CryptoConfig.CreateFromName (string,object[]) [0x00027] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:495
at System.Security.Cryptography.CryptoConfig.CreateFromName (string) [0x00000] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:484
at System.Security.Cryptography.RandomNumberGenerator.Create (string) [0x00000] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptography/RandomNumberGenerator.cs:59
at System.Security.Cryptography.RandomNumberGenerator.Create () [0x00000] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptography/RandomNumberGenerator.cs:53
at System.Guid.NewGuid () [0x0001e] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System/Guid.cs:483
at System.Runtime.Remoting.RemotingServices.NewUri () [0x00020] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Runtime.Remoting/RemotingServices.cs:356
at System.Runtime.Remoting.RemotingServices.Marshal (System.MarshalByRefObject,string,System.Type) [0x000ba] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Runtime.Remoting/RemotingServices.cs:329
at System.AppDomain.GetMarshalledDomainObjRef () [0x00000] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System/AppDomain.cs:1363

どちらの障害もAppDomainsロジックに何らかの形で関連しているため、モノラルでそれらに近づかないようにする必要があります。

ところで、テストされたプログラムは、WindowsマシンでMS .NET 4.5 envで24時間問題なく動作しました。

結論として、私は言いたいと思います-モノを注意して使用してください。一見すると機能しますが、いつでも簡単に失敗する可能性があります。オープンソースプロジェクトでは、大量のコアダンプと大きな信仰の喪失が残ります。

他の誰かが示唆したように、MoMAはこのための優れたツールです。最近の非互換性の最大の原因は、Win32ライブラリにDllImport（またはP / Invoke）するアプリケーションです。一部のアセンブリは実装されていませんが、それらのほとんどはWindowsのみであり、実際にはLinuxでは意味がありません。ほとんどのASP.NETアプリケーションは、制限付きの変更でMono上で実行できると言っても、かなり安全だと思います。

（開示：Mono自体、およびその上で実行される記述されたアプリに貢献しました。）

多くの場合、特にASP.NETアプリケーションを移植する場合は、既存のコードを取得してMonoで実行できます。

場合によっては、機能させるためにまったく新しいコードセクションが必要になることがあります。たとえば、System.Windows.Formsを使用する場合、アプリケーションは変更せずに動作しません。同様に、Windows固有のコード（たとえば、レジ​​ストリアクセスコード）を使用する場合。しかし、最悪の違反者はUIコードだと思います。これはMacintoshシステムでは特に悪いことです。

Linuxで実行する必要がある作業中のプロジェクトでそれを使用してきましたが、Managed C ++で構築したいくつかの.NETライブラリを再利用しています。それがどれほどうまく機能しているかに私は非常に驚いています。メインの実行可能ファイルはC＃で記述されており、Managed C ++バイナリを問題なく参照できます。WindowsとLinuxのC＃コードの唯一の違いは、RS232シリアルポートコードです。

私が考えることができる唯一の大きな問題は、約1か月前に起こりました。Linuxビルドには、Windowsビルドでは見られなかったメモリリークがありました。手動でデバッグを行った後（Linux上のMonoの基本的なプロファイラーはあまり役に立たなかった）、問題を特定のコードのチャンクに絞り込むことができました。回避策をパッチすることになりましたが、私はまだ戻って、リークの根本的な原因が何であるかを理解するための時間を見つける必要があります。

Mono 2.0プレビューのサポートがWindows Forms 2.0でどれほど優れているか知っていますか？

私がそれで遊んだ少しから、それは比較的完全でほとんど使いそうに見えました。一部の場所では見た目がよくなく、全体的に少しヒットまたはミスしています。正直なところ、私たちのフォームのいくつかと同じように機能するのに驚きました。

確かにそうです（ただし注意してください）。Ra-Ajax（http://ra-ajax.orgにある Ajaxライブラリ）でMonoをサポートしており、ほとんど問題は発生していません。WSEなどの.Netからの「最も狂ったもの」のいくつかに注意する必要があります。また、おそらく既存のプロジェクトのかなりのいくつかは100％Mono互換ではありませんが、開発中にテストすると、新しいプロジェクトはほとんどMonoと問題なく互換性があります。そして、Monoを使用してLinuxなどをサポートすることによる利益は本当に素晴らしいです;）

Monoをサポートする秘訣の大部分は、ActiveRecord、log4net、ra-ajaxなど、最初から適切なツールを使用することだと思います...

残念ながらMonoを作成している種類のアプリケーションでは、本番環境での準備ができていないようです。全体的に感銘を受け、WindowsとEC2マシンの両方のパフォーマンスに感銘を受けましたが、プログラムはWindowsとLinuxの両方のガベージコレクションエラーで一貫してクラッシュしました。

エラーメッセージは次のとおりです：「GCでの致命的なエラー：ヒープセクションが多すぎます」、これは少し異なる方法で問題が発生している他の誰かへのリンクです：

http://bugzilla.novell.com/show_bug.cgi?id=435906

Monoで実行した最初のコードは、開発した簡単なプログラミングの課題でした...コードは、約10MBのデータを一部のデータ構造（HashSetなど）にロードし、そのデータに対して10個のクエリを実行します。クエリを100回実行して時間を計り、平均を取得しました。

コードは、Windowsの55番目のクエリでクラッシュしました。Linuxでは動作しましたが、より大きなデータセットに移動するとすぐにクラッシュします。

このコードは非常に単純です。たとえば、一部のデータをHashSetに入れてから、それらのHashSetなどをクエリします。すべてネイティブのc＃であり、安全ではなく、API呼び出しもありません。Microsoft CLRでは、クラッシュすることはなく、膨大なデータセットで数千回も問題なく実行されます。

私たちの1人がMiguelにメールを送り、問題の原因となったコードを含めましたが、まだ応答はありません。:(

また、他の多くの人々がこの問題に解決策なしで遭遇したようです-異なるGC設定でMonoを再コンパイルする1つの解決策が提案されていますが、クラッシュする前にしきい値を増やすように見えます。

www.plasticscm.comを確認してください。すべて（クライアント、サーバー、GUI、マージツール）はモノで書かれています。

実際には、.NETフレームワークから使用している名前空間とクラスに依存します。私は自分のWindowsサービスの1つをEメールサーバー（Suse）で実行するように変換することに興味がありましたが、完全に実装されていないAPIでいくつかのハードロードブロッキングに遭遇しました。MonoのWebサイトのどこかに、すべてのクラスとその完了レベルを示すグラフがあります。あなたのアプリケーションがカバーされているなら、それのために行きます。

もちろん、他のアプリケーションと同様に、完全なコミットメントを行う前にプロトタイピングとテストを行ってください。

私たちが遭遇したもう1つの問題は、ライセンスソフトウェアです。他の誰かのDLLを参照している場合、そのアセンブリに埋め込まれている非互換性を回避する方法をコーディングすることはできません。

その場合、サードパーティのコンポーネントを含むアプリケーションがあると、詰め込まれてしまう可能性があると思います。多くのベンダーがMonoを念頭に置いて開発を行うとは思いません

例：http : //community.devexpress.com/forums/p/55085/185853.aspx

いいえ、モノは本格的な作業の準備ができていません。WindowsでF＃を使用していくつかのプログラムを作成し、Monoで実行しました。これらのプログラムは、ディスク、メモリ、CPUをかなり集中的に使用していました。モノライブラリ（マネージコード）でのクラッシュ、ネイティブコードでのクラッシュ、仮想マシンでのクラッシュを確認しました。Monoが機能したとき、プログラムはWindowsの.Netの場合よりも少なくとも2倍遅く、はるかに多くのメモリを使用していました。真面目な仕事のためにモノから離れてください。