Monoは、「はい、.NETはクロスプラットフォームです」とよく使われます。その主張はどの程度有効ですか？

Question

プロジェクトの.NETとJava）の間で何を選択しますか？「常にWindowsに展開しますか？ "新しいWebプロジェクトで最初に行う最も重要な技術的決定。答えが"いいえ "の場合、.NETではなくJavaをお勧めします。

非常に一般的な反論は、「Linux/OS X/Whateverで実行したい場合は、Monoを実行する」というものです。¹、これは表面上非常に説得力のある議論ですが、私はいくつかの理由で同意しません。

OpenJDKおよびベンダーが提供するすべてのJVMは、正常に動作することを保証する公式のSun TCKに合格しています。 MonoがMicrosoft TCKを通過することは知りません。
Monoは.NETリリースを追跡します。現在完全にサポートされている.NETレベルは何ですか？
すべてのGUI要素（WinForms？）はMonoで正しく動作しますか？
企業は、公式計画Bとしてオープンソースフレームワークに依存したくない場合があります。

Javaの新しいガバナンスでは、将来は安全ではありませんが、たとえば IBMは多くのプラットフォームにJDKを提供しています（Linuxを含む）。オープンソース。

では、Monoが.NETアプリケーションの有効なビジネス戦略となるのはどのような状況ですか。

¹_{Mark Hは次のように要約しました：「主張がそうである場合」。NETで記述されたWindowsアプリケーションがある場合、モノで実行する必要があります」では、そうではありません。それは有効な主張ではありません-しかし、Monoはそのようなアプリケーションの移植をより簡単にするために努力を重ねてきました。」}

miguel.de.icaza · Accepted Answer

Sparkieの回答わかりました。少し補足します。

".NET is cross platform"は、フレームワークとそれが最初に作成された世界の両方が変化し、進化したため、あいまいな発言です。

短い答えは：

.NETとその派生物であるCommon Language Infrastructure Standardを強化する基盤となるエンジンはクロスプラットフォームであり、コードを複数のプラットフォームに移動させたい場合と同様に使用を計画する必要があります適切なプラットフォームで適切なAPIを使用して、各プラットフォームで最高のエクスペリエンスを提供します。

電話からメインフレームまでの違いが大きすぎるため、CLIファミリは「1回書き込み、どこでも実行」アプローチを試みていません。代わりに、プラットフォーム固有のAPIとランタイム機能のユニバースが出現し、開発者は各プラットフォームで素晴らしいエクスペリエンスを作成するための適切なツールを利用できます。

考えてみてください。プログラマはもはやWindows PCやUnixサーバーをターゲットにしていません。 PCからゲームコンソール、強力な電話、セットトップボックス、大きなサーバー、マシンの分散クラスターに至るまで、世界は今までになく魅力的なプラットフォームに囲まれています。 すべてのプラットフォームに1サイズで収まると、小さなデバイスでは肥大化し、大規模なシステムでは力不足と感じます。

Microsoftの.NET Framework製品はクロスプラットフォームではなく、Windowsでのみ動作します。 Microsoftの.NET Frameworkには、Windows Phone 7、XBox360、Silverlightを介したブラウザーなど、他のシステムで動作するバリエーションがありますが、すべてわずかに異なるプロファイルです。

今日では、.NETベースのテクノロジーを使用して、すべての主要な主流OS、電話、モバイルデバイス、組み込みシステム、およびサーバーをターゲットにできます。以下は、各ケースで使用するCLI実装を示すリストです（このリストは包括的ではありませんが、ケースの99％をカバーするはずです）。

x86およびx86-64ベースのPCコンピューター：
- windowsの実行->通常、.NETまたはSilverlightを実行しますが、ここでは完全なMonoを使用することもできます。
- linux、BSD、またはSolarisを実行している->フルMonoまたはSilverlightを実行している
- macOS Xを実行している->フルMonoまたはSilverlightを実行している
- 実行中Android-> Mono/Androidサブセットを実行します
ARMコンピュータ：
- Windows Phone 7の実行：Compact Framework 2010を実行します
- Windows 6.5以前を実行している：古いCompact Frameworkを実行している
- Androidデバイス：Mono/Androidを実行します
PowerPCコンピュータ：
- フルLinux、BSD、またはUnixオペレーティングシステムでフルモノを実行している
- PS3、Wii、またはその他の組み込みシステム用の組み込みモノを実行します。
- XBox360では、CompactFrameworkを実行します
S390、S390x、Itanium、SPARCコンピューター：
- あなたは完全なモノを実行します
その他の組み込みオペレーティングシステム：
- .NET MicroFrameworkまたはMonoをモバイルプロファイルで実行します。

ニーズに応じて、上記で十分な場合とそうでない場合があります。どこでも同じソースコードを実行することはほとんどできません。たとえば、XNAコードはすべてのデスクトップで実行されませんが、.NETデスクトップソフトウェアはXNAまたは電話で実行されません。通常、.NET Frameworkの他のプロファイルで実行するには、コードを変更する必要があります。ここに私が知っているいくつかのプロファイルがあります：

.NET 4.0プロファイル
Silverlightプロファイル
Windows Phone 7プロファイル
XBox360プロファイル
モノコアプロファイル-.NETプロファイルに従い、Linux、MacOS X、Solaris、WindowsおよびBSDで利用できます。
.NET Micro Framework
IPhoneプロファイルのMono
Mono Androidプロフィール
PS3プロファイルのモノラル
Mono on Wiiプロファイル
月光プロファイル（Silverlightと互換性あり）
Moonlight拡張プロファイル（Silverlight +完全な.NET 4 APIアクセス）

したがって、これらのプロファイルのそれぞれは実際にはわずかに異なり、これは悪いことではありません。各プロファイルは、ホストプラットフォームに適合し、意味のあるAPIを公開し、意味のないAPIを削除するように設計されています。

たとえば、ホストブラウザーを制御するSilverlightのAPIは、電話では意味がありません。また、XNAのシェーダーは、同等のサポートが欠けているPCハードウェアでは意味がありません。

.NETが、開発者をハードウェアおよびネイティブプラットフォームの基盤となる機能から分離するためのソリューションではないことをすぐに理解すれば、より良い結果が得られます。

つまり、一部のAPIとスタックは複数のプラットフォームで使用できます。たとえば、ASP.NETはWindows、Linux、Solaris、MacOS Xで使用できます。これらのAPIは.NETとMonoの両方に存在するためです。 ASP.NETは、XBoxやWindows Phone 7など、Microsoftがサポートする一部のプラットフォームでは使用できません。また、WiiやiPhoneなど、Monoがサポートする他のプラットフォームでもサポートされていません。

以下の情報は11月21日の時点でのみ正しいものであり、Monoの世界の多くのものが変更される可能性があります。

同じ原則を他のスタックにも適用できます。完全なリストには適切なテーブルが必要ですが、ここに提示する方法はわかりませんが、特定のプラットフォームには存在しない可能性のあるテクノロジーのリストを次に示します。ここに記載されていないものはすべて利用可能であると想定できます（見逃したものについては編集を送ってください）：

コアランタイムエンジン[どこでも]

Reflection.Emitサポート[WP7、CF、Xbox、MonoTouch、PS3を除くすべての場所]
CPU SIMDサポート[Linux、BSD、Solaris、MacOS X; PS3、MonoTouchおよびMonoDroid]
継続-Mono.Tasklets [Linux、BSD、Solaris、MacOS、PS3、Wii]
アセンブリのアンロード[Windowsのみ]
VMインジェクション[Linux、BSD、MacOS X、Solaris]
DLR [Windows、Linux、MacOS X、Solaris、MonoDroid]
ジェネリック[PS3とiPhoneのいくつかの制限]。

言語

C＃4 [どこでも]
サービスとしてのC＃コンパイラ（Linux、MacOS、Solaris、BSD、Android）
IronRuby [どこでも、execpt WP7、CF、Xbox、MonoTouch、PS3]
IronPython [どこでも、execpt WP7、CF、Xbox、MonoTouch、PS3]
F＃[どこでも、execpt WP7、CF、Xbox、MonoTouch、PS3]

サーバースタック

ASP.NET [Windows、Linux、MacOS、BSD、Solaris]
ADO.NET [どこでも]
LINQ to SQL [どこでも]
エンティティフレームワーク[どこでも]
コアXMLスタック[どこでも]
- XMLシリアル化[WP7、CF、Xboxを除くすべての場所]
LINQ to XML（どこでも）
System.Json [Silverlight、Linux、MacOS、MonoTouch、MonoDroid]
System.Messaging [Windows; Linux、MacOS、およびSolarisでは、RabbitMQが必要です]
.NET 1 Enterprise Services [Windowsのみ]
WCF [Windowsで完了; Silverlight、Solaris、MacOS、Linux、MonoTouch、MonoDroidの小さなサブセット]
Windowsワークフロー[Windowsのみ]
カードスペースID [Windowsのみ]

GUIスタック

Silverlight（Windows、Mac、Linux-Moonlightを使用）
WPF（Windowsのみ）
Gtk＃（Windows、Mac、Linux、BSD）
Windows.Forms（Windows、Mac、Linux、BSD）
MonoMac-ネイティブMac統合（Macのみ）
MonoTouch-ネイティブiPhone統合（iPhone/iPadのみ）
MonoDroid-ネイティブAndroid統合（Androidのみ）
Media Center API-Windowsのみ
Clutter（WindowsおよびLinux）

グラフィックライブラリ

GDI +（Windows、Linux、BSD、MacOS）
クォーツ（MacOS X、iPhone、iPad）
カイロ（Windows、Linux、BSD、MacOS、iPhone、iPad、MacOS X、PS3、Wii）

モノライブラリー-クロスプラットフォーム、.NETで使用できますが、手動で構築する必要があります

サービスとしてのC＃4コンパイラ
Cecil-CIL操作、ワークフロー、CILの計測、リンカー
RelaxNGライブラリ
Mono.Data。*データベースプロバイダー
完全なSystem.Xaml（.NETがスタックを提供しないセットアップで使用）

MonoTouchは、iPhone上で実行されるMonoを意味します。 MonoDroidは、Android上で実行されるMonoを意味します。 PS3およびWiiポートは、ソニーおよび任天堂の認定開発者のみが利用できます。

形式の欠如をお詫び申し上げます。

Mark H · Answer

まず、共通言語インフラストラクチャ（オープンスタンダード）と.NET（Microsoftによるそのスタンダードの実装）を区別する必要があります。 MonoはCLIの実装であり、「ポータブル.NET」であると主張したことはありません。また、C＃言語はオープンスタンダードであり、.NETに厳密に関連付けられていません。

マイクロソフトが実装が準拠していることを検証するためのツールがあるかどうかはわかりませんが、準拠している場合は、モノの人たちが準拠していることを確認して使用しています。

Monoは.Netの後ろを追っていますが、やっとです。 MonoはC＃4.0コード（現在の.NETバージョン）を実行できます。また、Microsoftは最近、すべてのDLRコードとライブラリを（Apache 2.0ライセンスの下で）オープンソースにしました。これにより、monoはIronPython、IronRubyなどの言語を利用できるようになり、F＃は先週だけオープンソースになりました。さらに、Microsoftは.NETの今後の機能のCTPを定期的にリリースしています。これにより、mono開発者は現在のリリースバージョンを最新の状態に保つことができます。

.NETには、たとえばコードコントラクトなど、多くのツールと拡張機能があります。これらは常に完全にモノで実装されているわけではありません。（現時点では、Requires契約の部分的なバリデーターがあると思います）。いずれにせよ、これらは.NETアプリでは一般的に使用されていませんが、人気が高まると、モノで実装される割合も増えます。

WinFormsは（完全に）移植可能ではありません。これらは.NET固有であり、CLIの一部ではありません。 CLIは特定のウィジェットセットを指定しません。ただし、クロスプラットフォームウィジェットセットがあります（GTK＃およびSilverlight）。移植性を考慮して最初からアプリケーションを作成している場合は、Winforms/WPFではなく、これらのいずれかを使用します。さらに、monoはWinforms APIのシンラッパーを提供します。これにより、既存のWinformsアプリをGTK＃に簡単に移植できるようになります（全体を書き直す必要はありません）。

Monoは、既存の.Netアプリケーションを取得して、その移植性を通知できるツール、Mono Migration Analyzer（MoMA）を提供します。（たとえば、使用されている移植できないライブラリ、P /呼び出しなどを特定します）。

オープンソースに依存したくないビジネスのために-モノは再ライセンスすることができます。モノに追加されたコードの所有権はノベルに渡され、ノベルは通常のLGPLライセンス（とにかくほとんど制限がない）以外の方法でライセンスを取得できます。

したがって、「。NETは移植可能」という主張については、ゼロからコードを作成していて、フレームワークの移植性の問題を認識している場合、これは有効なアサーションになると思います。「Windowsアプリケーションは.NETで作成されているので、monoで実行する必要がある」という主張である場合、それは有効な主張ではありません。

Joel Coehoorn · Answer

ポイントごと：

OpenJDKとベンダーが提供するすべてのJVMが公式のSun TCKに合格し、物事が正しく機能することを確認しています。MonoがMicrosoft TCKを渡すことは知りません。
Microsoft CLRが準拠する仕様があります。 MonoはMicrosoftのCLRのクローンではなく、同じ仕様の実装です。一方では、これがさらに大きな非互換性をもたらす可能性があります。実際には、これはモノに対して非常にうまく機能しています。
Monoは.NETリリースを追跡します。現在完全にサポートされている.NETレベルは何ですか？
。Netのドキュメントは実際のリリースの前にあるため、monoは実際に（ベータリリースではなく）.Net 4のサポートを完了しましたbefore公式のMicrosoftリリース。さらに、monoはサポートされていないものを文書化する非常に優れた機能を果たし、既存のプロジェクトに対して実行できるいくつかのツールを備えており、非互換性の可能性がある場所を特定するのに役立ちます。
すべてのGUI要素（WinForms？）はMonoで正しく動作しますか？
Winformの大部分は問題なく動作します。 WPF、それほどではありません。同じことがJavaにも当てはまると聞きました。高度なウィジェット/ GUIツールキットの多くは、すべてのプラットフォームでサポートされているわけではありません。
企業は、オープンソースフレームワークに公式の計画Bとして依存したくない場合があります。
それが事実である場合、彼らは間違いなくJavaを使用しません。それは、それがオープンソースフレームワークを計画Aでさらに高くするためです。

要約すると、クロスプラットフォームアプリを今すぐ作成したい場合、get-goからmonoで開始し、それを次のように使用することに何の問題もありません。あなたのフレームワーク。必要に応じて、Windowsにモノをデプロイすることもできます。

一方、今日Windowsアプリを構築している場合、mightが、将来、おそらくネイティブのWindowsウィジェットとツールを使いたいと思うでしょう。ここでは、.NetはJavaよりもはるかに優れており、monoはこのシナリオでは完全に許容できるフォールバックです。

言い換えれば、はい、あなたの質問に関係するあらゆる方法でクロスプラットフォームの場合は.Netです。いいえ、monoはすべての.Netプログラムをそのまま実行するわけではありませんが、あなたの質問は新しいプロジェクトのコンテキストにあります。特に.Netではなくモノラルで開発することを考える場合、新しいプロジェクトを問題なく保ち、互換性の問題を回避するのに多くの作業は必要ありません。

しかし、何よりも、これはそもそも間違った質問だと思います。新しい開発チームをゼロから構築する場合を除き、いずれかの分野で専門知識を持つプログラマーから始めます。プログラマーがすでに知っていることを行うことで、最良の結果が得られます。クロスプラットフォームアプリの作成と同じくらい重要なように思えるかもしれませんが、Javaの経験がほとんどない.Netプログラマーでいっぱいのチームがある場合、それらを起動したり、全員に学習させることはほとんどありませんJava次のプロジェクトに使用します。 Javaプログラマーでいっぱいのチームがある場合、Windows専用プロジェクトの.Netを学ぶように彼らに頼むつもりはありません。それらのどちらかがナッツになります。

Robert Harvey · Answer

私はMonoを使用してきましたが、オープンソースであり、Microsoftによって直接サポートされていない代替プラットフォームを使用するのと同じくらい良いと思います。 ClojureやScalaのような代替のオープンソースプラットフォームを快適に使用できる場合は、おそらくMonoを使用することに慣れているでしょう。

Monoがサポートする.NETのレベルは、常に Mono Roadmap ページにあります。

すべてのGUI要素は機能しますか？私の知る限りでは、すべての要素を徹底的に試したわけではありませんが、そうです。

Monoは.NETと同じですか？いいえ。あちこちでマイナー（そしておそらくメジャー）の微調整が必要になると思います。たとえば、現在、それを使用してEntity Frameworkを実行することはできません。

tylerl · Answer

ターゲットとして、.NET /モノユニバースは非常に速く移動します。

Microsoftは数年ごとに、.NETを取り巻く言語、ランタイム、インフラストラクチャに関するいくつかの説得力のある変更と革新を発表しています。例：Generics、LINQ、DLR、Entity Framework-Visual Studioの新しいリビジョンごとに、対象となるフレームワークの機能セットと有用性が大幅に向上しています。

フレームワークの継続的な改善は歓迎されますが、複数のプラットフォーム間での互換性が必要な場合にも問題があります。 Red Hat Enterprise Linuxのような長期サポートプラットフォームは、新しいテクノロジーの採用に関して氷河期の速度で動きが鈍く、Monoプラットフォームでは、ここ数か月以内に大幅な改善が見られます。したがって、クールな子供たちが作成しているものを実行したい場合は、Monoを最初からコンパイルし、独自のパッチと更新を管理する必要があります。それはクールではない。

一方、Javaは子供プールのように停滞しています。特に、特許訴訟のためだけにJava=を求めていた会社が所有しているため、近い将来、言語やランタイムに検出可能な変更がないことをかなり確信してください。Javaは、FORTRANと同じくらい安定したプラットフォームです。それは、改善されていますが、エンタープライズアプリケーションをデプロイしようとしている場合はそれほど悪くはありません。

digitxp · Answer

ユーザーの観点から見ると、MonoはWindows .NETアプリをLinuxと互換性のあるものにするのが苦手です。きちんと書かれたWindowsアプリをMonoで実際に実行しようとしても、機能しません。

パッケージャーの観点から（以前はPortableAppsで少し作業を行っていました）、. NETは祝福と呪いの両方になり得ます。 Windowsのみを使用している場合、ライブラリが多いほどシステム依存の要素が少なくなるため（特にWindowsのバージョン間で特に顕著です）、. NETのバージョンは逆でもないため、.NETは展開を非常に簡単にしますが、Windowsでも非常に混乱します。 -compatibleまたは前方互換。プログラムごとに異なるバージョンの.NETをダウンロードする必要があります。

そうは言っても、MonoはC＃プログラムをクロスプラットフォームにするための優れた出発点です。プログラムを最新のWINEでパッケージ化しないでください。それがPicasaをとったところを見てください。

2つの言語/プラットフォームの政治的安定性と同様に、RMSは、MonoがMicrosoftとの新婚旅行が非常に悪名高いNovellによってどのように率いられているかについて、おそらく怒り始めるでしょう。。

簡単なクロスプラットフォームが本当に必要な場合、実証済みの真のパスはQTです。これは現時点では政治的に非常に安定しています。これは、a）LGPL、b）過去の主要なライセンスの問題、c）Nokiaによるサポートです。本当に人気のある携帯電話を販売しています。

Michael Stum · Answer

Monoは、Microsoftの.netの1：1ポートではありません。 Monoが実装しない、または実装する予定のないテクノロジがあります（たとえば、Workflow Foundationまたは [〜＃〜] wpf [〜＃〜] ）。 Microsoft .NETが実行しない独自のテクノロジ（SIMD拡張機能など）。

短い回答：MonoとMicrosoft .NETは、同じ基礎となる基盤（CILとBCL）に基づいていますが、別々のプロジェクトです。

Casper Bang · Answer

元の投稿のステートメントに対する小さなコメント。 TCKは、OracleがJavaがオープンスタンダードであると主張することを可能にする理論上のツールであり続けると主張します。お気づきかもしれませんが、Apache Harmonyは数年前から「Java」の認定を取得しようとして失敗しています。オラクルが実際に関連しているものや多かれ少なかれコントロール（OpenJDK）を除いて、オープンソースの実装に本当に興味がないのは明らかです。 Monoとよく似ていますが、完全ではなく（つまり、Java Web Startのサポートはありません）、クローズドソースのHotSpot実装で利用できるいくつかの最適化がありません。

したがって、おそらく2010年の時点で。（ほとんど）Javaはオープンソースですがオープンスタンダードではありませんが、（ほとんど）.NETはオープンソースではなくオープンスタンダードです。もちろん例外はありますが、DLR、IronPython、IronRuby、F＃は実際にはオープンソースです。 Monoは、オープンスタンダードのオープンソース実装である両方の世界の最高のものを提供するので興味深いものです。

Lloeki · Answer

すべての専門性はさておき、実際にコードを書くときに非常に重要な部分が発生します。

他のクロスプラットフォームテクノロジー（Java、Python、Rubyなど）と同様に、移植性を考慮してコードが記述されていない場合、コードが適切に実行される可能性は基本的にゼロであると想定する必要があります（そのような可能性があっても実際には、はるかに高い）、奇妙な誤動作が非常に重大になる可能性があるためです。読む：ランダムなアセンブリを取得せず、Monoで実行してください。

しかし、新しいプロジェクト（または簡単にリファクタリングできるプロジェクト）の場合、.Net/Monoを移植可能な可能性のあるランタイムとして選択することは理にかなっていますが、プロジェクトが非常に早い段階でMonoでコードをテストすることで、多くの手間を節約できます。マルチプラットフォーム化のわずかな変更のみ。継続的インテグレーションサーバーを使用する場合、これはMonoビルドノードの設定と同じくらい簡単です。開発中に多くの問題を解決できます（パス文字列の構築など）の習慣を身に付けるだけで、コードの巨大なチャンクをポータブルにして、Monoでユニットテストすることができます。残り（つまり、ユニットテストの失敗）はプラットフォーム固有（PInvokeを使用するコードなど）ですが、ターゲットプラットフォームごとに代替実装を提供できるように十分にカプセル化する必要があります。この方法でプロジェクトが最終的に移植されるようになると、ほとんどの作業はほとんど無料で行われ、残りはジャストインタイムで開発されます。

もちろん、Monoで利用できないライブラリ（.Net）または互換性のあるライブラリ（サードパーティ）を使用すると、これらのいずれも除外されますが、私のフィールドはまだ確認されていません。それが私たちが実際に仕事で使用する戦略であり、それを適用するとき、.Net + Monoがクロスプラットフォームであると主張することには恐れがありません。

Michael Shaw · Answer

正直な答えはさまざまです。小さなWebサーバーのものをIIS= Apacheに移動し、ほとんど問題なくモノの下で実行しています。Linux上でWin Formsを使用して、変更されていないWindows .Netアプリケーションを正常に実行しました。

ただし、機能することはできますが、monoに実装されていないAPI呼び出しを使用している場合は機能しません。唯一の解決策は、アプリケーションを書き直すか、ウィンドウに固執するか、monoで追加のものを書き込むことです。