https://stackoverflow.com/questions/216841
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
Visual Studioで.NETを使用してC＃を使用し、openSUSE LinuxでMonoを少し試してみましたが、どのように動作するのかよくわかりません。
.NET上のWindowsでアプリを作成する場合、これはMonoとどのように関係しますか？ LinuxでWineなしでWindows .exeファイルを実行することはできないため、Windowsで開発されたアプリを実行するのに役立ちません。
純粋な目的は、クロスプラットフォーム開発を容易にするために、Linux（およびその他）に相当する.NETライブラリを用意することですか？たとえば、私がビジネスをしていて、Linuxの顧客にリーチしたいが、実際に.NETを使用したい場合、Monoを選択する必要がありますか？それとも私が見逃しているものがありますか？
解決
Windows EXEには、複数の「パーツ」が含まれています。 簡略化 、. netコード（= MSIL）はEXEの一部にすぎず、「本当」もあります。 .NET Frameworkのランチャーとして機能するEXE内のネイティブWindowsパーツ。MSILを実行します。
Monoは、MSILを取得して実行するだけで、ネイティブのWindowsランチャーなどを無視します。
これも簡単な概要です。
編集：深い詳細についての理解は、実際の詳細には十分ではないのではないかと心配しています（PEヘッダーとは何であるかは大体わかっていますが、実際には詳細ではありません）役立つリンク：
他のヒント
これは古い質問です（既に選択された回答があります）が、質問が本当によく回答されたとは思わない。
最初に、ちょっとした背景...
.NETの仕組み
従来のWindows .EXEファイルは、コンピューターが理解し、アプリケーションが利用できるサービスを提供するWindowsの一部であるWin32 APIを呼び出す一連の機械語命令を表すバイナリファイルです。使用される機械語は、ご使用のコンピューターに固有のものであり、Win32呼び出しにより、実行可能ファイルはWindowsに非常に依存します。 .NET実行可能ファイルはそうではありません。
.NET実行可能ファイル（.EXEファイル）は、実際にはネイティブのWindowsアプリケーションではないことを認識することが重要です。 Windows自体は、.NET実行可能ファイルでコードを実行する方法を理解していません。コンピューターもそれを理解していません。
Javaと同様に、.NETアプリケーションはCIL（Common Intermediate Language）と呼ばれる言語の命令で構成されており、実際には存在しない理想化されたコンピューターの機械語と考えることができます。 .NETでは、この理想的なマシンのソフトウェア実装は、共通言語ランタイム（CLR）と呼ばれます。 Javaの世界で同等のものは、Java仮想マシン（JVM）と呼ばれます。 Javaでは、CILに相当するものはJavaバイトコードと呼ばれます。 CILは、MSIL（Microsoft Intermediate Language）と呼ばれることもあります。
CILはCLR（理想化されたマシン）で実行するように設計されていますが、プラットフォームに依存しないため、CILは使用しているコンピューターの種類や実行しているオペレーティングシステムを気にしません。
Javaを実行する各プラットフォームでJava JVMのネイティブバージョンが必要なのと同様に、.NET CIL実行可能ファイルを実行するにはCLRのネイティブバージョンが必要です。 CLRは、上記の従来のWin32 EXEファイルとまったく同じネイティブWindowsアプリケーションです。 CLR自体は、実行するように設計されたWindows実装とコンピューターアーキテクチャに固有です。
どの.NET言語（C＃、VisualBasic、F＃、IronPython、IronRuby、Booなど）で開始するかは関係ありません。これらはすべてCILバイトコードにコンパイルされます。簡単に「分解」できます。 CILプログラムを、人間が簡単に読み取れるオブジェクト指向アセンブリ言語の形式に変換します。 CILで直接プログラムを作成できますが、作成する人はほとんどいません。
Windowsでは、実行可能ファイルを実行すると、CLRはこのCILコードをジャストインタイム（JIT）でコンパイルします（コードが実際に実行される直前）。つまり、CILバイトコードは、コンピューターでネイティブに実行される実際のマシンコードに変換（コンパイル）されます。 CLRのこの部分は、JITコンパイラー、または単にJITと呼ばれます。
これまでに、MicrosoftはCLRの4つのバージョン、1.0、1.1、2.0、および4.0をリリースしました。そのランタイムを対象とする.NET実行可能ファイルを実行する場合は、適切なバージョンのCLRがマシンにインストールされている必要があります。 CLR 2.0は、.NET 2.0、3.0、および3.5アプリケーションをサポートします。 .NETの他のバージョンの場合、.NETバージョンはCLRバージョンに完全にマッピングされます。
JIT / CLRに加えて、.NETは、残りの.NETフレームワークを構成し、.NETアプリケーションが呼び出すことができる機能とサービスのホストを提供するライブラリ（アセンブリ）のホストを提供します。これらのアセンブリの大部分は、CLRで実行される純粋なCILコードです。 Windowsでは、Win32 APIへの呼び出しも行います。 .NETをインストールすると、CLR、クラスライブラリ（フレームワーク）、および多数の開発ツールがインストールされます。通常、CLRの各バージョンには、これらの「フレームワーク」の完全なセットが必要です。アセンブリ。 .NETの一部のバージョン（3.0および3.5など）では、CLRまたはそのCLRに関連付けられた既存のアセンブリを更新せずに追加のフレームワークアセンブリを追加しました。
Windows .EXEファイルが配信されるPortable Executable（PE）ファイル形式d inには、実行可能ファイルを説明し、ファイルを.NETファイルまたはネイティブWin32ファイルとして識別するヘッダーが含まれています。 Windowsが.NETファイルを実行しようとすると、このヘッダーが表示され、ユーザーに代わってCLRが自動的に呼び出されます。これが、.NET EXEファイルがWindowsでネイティブに実行されるように見える理由です。
OK、それではMonoはどのように機能しますか
Monoは、Linux、Mac、およびその他のプラットフォームでCLRを実装しています。 Monoランタイム（CLR）は、主にC言語で記述されたネイティブアプリケーションであり、実行するように設計されたコンピューターシステムのマシン言語コードにコンパイルされます。 Windowsと同様に、Monoランタイムは使用しているオペレーティングシステムとマシンの種類に固有です。
Windowsと同様に、Monoランタイム（CLR）は.NET実行可能ファイルのCILバイトコードを、コンピューターが理解して実行できるネイティブコードにコンパイルします。このように、.NETファイルは「ネイティブ」と同じです。 LinuxからWindowsへ。
Monoを新しいアーキテクチャに移植するには、JIT / CLRを移植する必要があります。これは、ネイティブアプリケーションを新しいプラットフォームに移植するようなものです。
.NETコードがLinuxまたはMacでどれだけうまく動作するかは、これらのシステムでCLRがどれだけうまく実装されているかという問題にすぎません。理論的には、Mono CLRは、MSバージョンの.NETがWindowsで実行するよりも、これらのシステムで.NETコードを実行することができます。実際には、MSの実装は一般的に優れています（ただし、すべての場合ではありません）。
CLRに加えて、Monoは、.NETフレームワークを構成する残りのライブラリ（アセンブリ）のほとんどを提供します。 Microsoftバージョンの.NETと同様に（実際にはもっと）、MonoアセンブリはCILバイトコードとして提供されます。これにより、Monoから* .dllまたは* .exeファイルを取得し、Windows、Mac、またはLinuxで変更せずに実行できます。CILは「ネイティブ」であるためです。これらのシステムでのCLR実装の言語。
Windowsと同様に、Monoは複数のバージョンのCLRと関連するアセンブリをサポートしています：
Monoの非常に初期のバージョン（1.2以前？）は、CLR 1.0または1.1のみをサポートしていました。 Monoは、2.0バージョンになるまで2.0フレームワークの大きな部分をサポートしていませんでした。
Monoバージョン2.4までは、CLR 1.1とCLR 2.0の両方のアプリケーションをサポートしていました。
Mono 2.6以降、CLR 4.0が追加されましたが、CLR 2.0がデフォルトのままでした。
Mono 2.8以降、CLR 4.0がデフォルトになり、CLR 1.1はサポートされなくなりました。
Mono 2.10は引き続きデフォルトとしてCLR 4.0を使用し、CLR 2.0もサポートします。
実際の.NETと同様に（ただし、はるかに少ない場合）、ネイティブライブラリを呼び出すMonoアセンブリがいくつかあります。 System.DrawingアセンブリをMonoで動作させるために、MonoチームはLinuxプログラムを作成して、Linux上のWin32 APIのGDI +部分をシミュレートしました。このライブラリは「libgdiplus」と呼ばれます。ソースからMonoをコンパイルする場合、「mono」をビルドする前にこの「libgdiplus」ファイルをビルドする必要があることに気付くでしょう。 Win32 APIのGDI +部分はすでにWindowsの一部であるため、Windowsで「libgdiplus」は必要ありません。 Monoを新しいプラットフォームに完全に移植するには、この「libgdiplus」ライブラリも移植する必要があります。
.NETライブラリの設計がWindowsの設計に過度に影響され、MacやLinuxなどのシステムにはあまり適さない分野では、Monoチームは.NETフレームワークの拡張機能を作成しました。 Mono拡張もCILバイトコードであり、一般に.NETで正常に機能します。
Windowsとは異なり、Linuxは一般に.NET実行可能ファイルを検出せず、デフォルトでCLRを起動します。ユーザーは通常、「mono appname.exe」または同様のコマンドを入力して、CLRを直接実行する必要があります。ここで、「mono」はCLRを実装するアプリケーションであり、「appname.exe」は実行する.NETコードを含むEXEファイルです。
ユーザーの作業を容易にするために、MonoアプリケーションはCLRを起動するシェルスクリプトでラップされることがよくあります。これはfaを隠します
実際には、Linux上のMonoで.NET .exeファイルを実行できます。これにはWineは必要ありません。実際、Monoはプログラムを.exeファイルにコンパイルします。これは、LinuxではMonoで、Windowsでは実行可能ファイルとして実行できます。
Monoは、Microsofts .NET CLR（Common Language Runtime）のオープンソース実装です。これは、ネイティブコードではなく、言語およびマシンに中立な中間言語であるCIL（Common Intermediate Language）である.NETプログラムの一部を実行するものです。ランタイムは、その中間コードを取得してマシンコードに変換します。
Monoの現在の状態では、.NETの主要部分（mscorlib.dll）を使用する.NETプログラムを、WindowsだけでなくMonoが実行されているすべての場所で実行できます。
しかし、Monoはオープンソースであり、完全な.NET実装になることだけに頼ることはできませんが、機能しないコントロールがいくつかあるため、P / Invokesにも注意する必要があります。たとえば、アプリケーションはwin32でMCI（Multimedia Controller Interface）と通信します。しかし、私はモノを書くGTK＃アプリケーションも使用していましたが、上記の仲間のプログラマーが述べたように、再コンパイルなしで動作するWindowsアプリケーションも使用しました。つまり、monoはMicrosoftの.NETのオープンソースの代替であり、デフォルトではWinFormsまたはGtk＃アプリケーションのいずれかを構築している場合、monoはコンパイルされ、各ファイルの.exeアセンブリを作成します。もちろん、必要に応じて、.NETで行われるのとほぼ同じようにダイナミックリンクライブラリ（DLL）を作成します。提案のために、Gtk＃を書いてみてください（MonticDevelop IDEにはsteticと呼ばれる組み込みのGUIデザイナーがあります）。そしてもちろん、monoはWebサービスの優れた代替となり、.NETで作成でき、Apacheでホストできます（最近のLinuxホスティングはWindowsのものより安いため）。Webサービスやその他のasp.netアプリは、 mod_monoモジュールを備えたapache。apacheに含める必要があります。
少し話題から外れていますが、私の経験からご紹介したいと思います。
また、MoMAを見ることができます（目的がWinからLinにアプリケーションを移植することである場合）。
Mono Migration Analyzer（MoMA） ツールを使用すると、問題を特定できます あなたの.Netを移植するときに持っている Monoへのアプリケーション。それはピンポイントに役立ちます プラットフォーム固有の呼び出し（P / Invoke）および まだサポートされていないエリア Monoプロジェクト。
これは、Monoと.NET Framework 3.5によって既に実装されているBCLのタイプを比較するwebappです
http://mono.ximian.com/class -status / 2.0-vs-3.5 / index.html
Michaelの応答をさらに進めるには、Monoランタイムでアプリを実行するには、Monoで再コンパイルする必要があると思います。例外が存在する場合があります。私はMonoで少し遊んだだけで、いつもソースを再コンパイルしました。 Monoで.NETアプリを直接実行しようとしたことはありません。
また、Mono 1.9は.NET 2.0に完全に準拠するはずです。 Mono OliveとMoonlightは、.NET 3.0（WPF未満）とSilverlight機能を追加することになっています。
それはあなたを助けるかもしれません、 MonoのC＃コンパイラはどのように機能しますか？および Mono C＃コンパイラについて本。
