「はい、.NETはクロスプラットフォームです」と言うのによく使われます。その主張はどの程度有効ですか？[閉まっている]

では何がこの時点で、.NETとJava間のプロジェクトのために選びますか？「常にWindowsに展開しますか？」を検討すると言います。新しいWebプロジェクトで先行するための単一の最も重要な技術的決定であり、答えが「いいえ」であれば、.NETではなくJavaをお勧めします。

非常に一般的な反論は、「Linux / OS X / Whateverで実行したい場合は、Monoを実行するだけです」^1です。これは表面的には非常に説得力のある議論ですが、理由。

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

オラクルによるJavaの新しいガバナンスでは、将来は安全ではないことを認識していますが、たとえばIBMは Linuxを含む多くのプラットフォームにJDKを提供しています。それらはオープンソースではありません。

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

¹ _{マーク・Hは、としてそれをまとめた「主張があることである場合：『私は.NETで書かれたWindowsアプリケーションを持っている』、それはモノで実行する必要があり、その後ではない、それは有効な請求ではありません-しかしモノは、このようなアプリケーションを移植作るための努力をしていますよりシンプルです。」}

Sparkieの答えはそれを理解しました。少し補足させてください。

「.NET is cross platform」は、フレームワークと元々作成された世界の両方が変化し進化したため、あまりにも曖昧な声明です。

短い答えは次のとおりです。

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

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

考えてみてください：プログラマーはWindows PCやUnixサーバーをターゲットにしなくなりました。世界は、PC、ゲーム機、強力な携帯電話、セットトップボックス、大型サーバー、分散したマシンクラスターなど、魅力的なプラットフォームに囲まれています。 すべてのプラットフォームに適合するサイズは、小さなデバイスでは肥大化しただけで、大規模なシステムでは力不足に感じるだけです。

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

現在では、主要なメインストリームOS、電話、モバイルデバイス、組み込みシステム、およびサーバーをすべて.NETベースのテクノロジーでターゲットにできます。各ケースで使用する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オペレーティングシステムで完全なMonoを実行する
  • PS3、Wii、またはその他の組み込みシステムで組み込みMonoを実行します。
  • 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プロファイルのモノ
• Androidプロフィールのモノ
• PS3プロファイルのモノラル
• Wiiプロファイルのモノ
• Moonlightプロファイル（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の世界では多くのことが変更される可能性があります。

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

Core Runtime Engine [どこでも]

• Reflection.Emitのサポート[WP7、CF、Xbox、MonoTouch、PS3を除くすべての場所]
• CPU SIMDサポート[Linux、BSD、Solaris、MacOSX。まもなく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 [どこでも、WP7、CF、Xbox、MonoTouch、PS3]
• F＃[どこでも、execpt WP7、CF、Xbox、MonoTouch、PS3]

サーバースタック

• ASP.NET [Windows、Linux、MacOS、BSD、Solaris]
• ADO.NET [どこでも]
• LINQ to SQL [どこでも]
• Entity Framework [どこでも]
• コアXMLスタック[どこでも]
  • XMLシリアル化[どこでも、WP7、CF、Xboxを除く]
• LINQ to XML（どこでも）
• System.Json [Silverlight、Linux、MacOS、MonoTouch、MonoDroid]
• System.Messaging [Windows; Linux、MacOS、およびSolarisではRabbitMQが必要です]
• .NET 1エンタープライズサービス[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のみ
• クラッター（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ポートは、ソニーおよび任天堂の資格を持つ開発者のみが利用できます。

正式性の欠如をおIび申し上げます。

まず、Common Language Infrastructure（オープンスタンダード）と.NET（Microsoftによるそのスタンダードの実装）を区別する必要があります。MonoはCLIの実装であり、「ポータブル.NET」であると主張したことはありません。また、C＃言語はオープンスタンダードであり、.NETに厳密には結び付けられていません。

Microsoftが実装が準拠していることを検証するツールを持っているかどうかは知りませんが、もしそうなら、モノの人はそれを持っていると確信し、それを使用します。

Monoは.Netの背後にありますが、ほとんどありません。MonoはC＃4.0コード（現在の.NETバージョン）を実行できます。また、Microsoftは最近、すべてのDLRコードとライブラリを（Apache 2.0ライセンスの下で）オープンソースにしました。さらに、Microsoftは.NETの今後の機能のCTPを定期的にリリースしています。これにより、モノの開発者は最新のリリースバージョンを最新の状態に保つことができます。

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

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

Monoは、Mono Migration Analyzer（MoMA）というツールを提供します。このツールは、既存の.Netアプリケーションを利用して、その移植性について通知することができます。（たとえば、使用されている移植不可能なライブラリの識別、P / Invokesなど）。

オープンソースに依存したくない企業の場合、モノのライセンスを再取得できます。monoに追加されたコードの所有権はnovellに引き継がれ、novellは通常のLGPLライセンス（とにかく制限がほとんどない）以外の方法でライセンスを付与できます。

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

ポイントごと：

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

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

あなたはあなたが考えていること、今日のWindowsアプリケーションを構築する見ている一方、かもしれない将来的にいくつかの未知の点でクロスプラットフォームである必要があり、あなたはおそらく、ネイティブのWindowsのウィジェットやツールと一緒に行きたいです。ここでは、.Netの方がJavaの場合よりもはるかに優れた機能を発揮します。このシナリオでは、モノは完全に受け入れ可能なフォールバックです。

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

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

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

Monoがサポートする.NETのレベルは、Monoロードマップページで常に確認できます。

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

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

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

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

フレームワークの絶え間ない改善は歓迎されますが、複数のプラットフォーム間で互換性が必要な場合にも問題があります。Red Hat Enterprise Linuxのような長期サポートプラットフォームは、新しいテクノロジーの採用に関してはゆっくりと動きます。また、いずれの時点でも、Monoプラットフォームには過去数か月以内に大幅な改善が見られます。したがって、クールな子供たちが構築しているものを実行したい場合は、Monoをゼロからコンパイルし、独自のパッチと更新を管理する必要があります。それは、いけてないねえ。

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

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

パッケージャの観点から（私はPortableAppsで少し仕事をしていました）、. NETは祝福であり呪いでもあります。Windowsのみを使用している場合、ライブラリが多いほどシステム依存性が低くなるため（特にWindowsのバージョン間）、. NETバージョンは後方ではないため非常に混乱するため、。 -compatibleまたはforwards compatible。プログラムごとに異なるバージョンの.NETをダウンロードする必要があります。

とは言っても、MonoはC＃プログラムをクロスプラットフォームにするための素晴らしい出発点です。ただし、プログラムを最新のWINEでパッケージ化せずに、完了済みと呼んでください。Picasaがどこにかかったのか見てみましょう。

2つの言語/プラットフォームの政治的安定性と同様に、RMSはおそらく、Microsoftとの新婚旅行が非常に悪名高いNovellがMonoを率いる方法について暴言を始めるでしょう。両方のプラットフォームは、現在政治的に不安定であると見なすことができます。

簡単なクロスプラットフォームが本当に必要な場合、試行された真の道はQTであり、現時点ではa）LGPLであり、b）数年前の主要なライセンス問題を処理し、c）Nokiaが支援しているため、本当に人気のある携帯電話を販売しています。

Monoは、Microsoftの.netの1：1ポートではありません。Monoが単に実装しない、または実装する予定のないテクノロジ（Workflow FoundationやWPFなど）がありますが、一方で、Microsoft .NETにはない独自のテクノロジ（SIMD Extensionsなど）があります。 。

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

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

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

すべての技術を別にすれば、実際にコードを記述するときに非常に重要な部分が発生します。

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

ただし、新しいプロジェクト（または簡単にリファクタリングできるプロジェクト）の場合、.Net / Monoを移植可能なランタイムとして選択することは理にかなっていますが、Monoでコードをテストすることで、プロジェクトがマルチプラットフォーム化のわずかな変更のみ。継続的インテグレーションサーバーを使用する場合、これはMonoビルドノードのセットアップと同じくらい簡単です。多くの問題は、開発中に習慣を作ることで解決できます（パス文字列を構築するなど）。コードの大部分は、健全な実践と少しの先見の明を使用するだけで、Monoで移植および単体テストできます。残り（つまり、ユニットテストの失敗）はプラットフォーム固有（PInvokeを使用するコードなど）ですが、ターゲットプラットフォームごとに代替実装を提供できるように十分にカプセル化する必要があります。

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

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

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