Это старый вопрос (с уже выбранным ответом), но я не верю, что на этот вопрос действительно был получен хороший ответ.
Сначала немного фона ...
Как работает .NET?
Традиционный Windows-файл .EXE - это двоичный файл, представляющий серию инструкций на машинном языке, которые понимает ваш компьютер, и выполняющих вызовы в Win32 API, которые являются частью Windows и предоставляют службы, которые могут использовать приложения. Используемый машинный язык очень специфичен для вашего типа компьютера, а вызовы Win32 делают исполняемый файл очень зависимым от Windows. Исполняемый файл .NET не такой.
Важно понимать, что исполняемый файл .NET (файл .EXE) на самом деле не является родным приложением Windows. Сама Windows не понимает, как запустить код в исполняемом файле .NET. Ваш компьютер тоже не понимает.
Подобно Java, приложение .NET состоит из инструкций на языке CIL (Common Intermediate Language), который вы можете рассматривать как машинный язык для идеализированного компьютера, которого на самом деле не существует. В .NET программная реализация этой идеализированной машины называется Common Language Runtime (CLR). Эквивалент в мире Java называется виртуальной машиной Java (JVM). В Java эквивалент CIL называется байт-кодом Java. CIL иногда называют MSIL (Microsoft Intermediate Language).
CIL предназначен для работы на CLR (идеализированный компьютер), но в остальном он не зависит от платформы, что означает, что CIL не заботится о том, какой у вас компьютер или какая операционная система у вас установлена.
Так же, как вам нужна собственная версия Java JVM на каждой платформе, на которой вы хотите запустить Java, вам нужна собственная версия CLR для запуска исполняемых файлов .NET CIL. CLR является родным приложением Windows, так же как и традиционные файлы Win32 EXE, описанные выше Сам CLR специфичен для реализации Windows и компьютерной архитектуры, на которой он был разработан.
Неважно, с какого языка .NET вы начинаете (C #, VisualBasic, F #, IronPython, IronRuby, Boo и т. Д.), Все они компилируются в байт-код CIL. Вы можете легко «разобрать» CIL-программу в форму объектно-ориентированного языка ассемблера, который легко читается человеком. Вы можете сами написать программу на CIL, но мало кто это делает.
В Windows CLR компилирует этот код CIL Just-in-Time (JIT) прямо при запуске исполняемого файла - непосредственно перед тем, как код фактически будет запущен. Это означает, что байт-код CIL преобразуется (компилируется) в фактический машинный код, который изначально выполняется на вашем компьютере. Эта часть CLR называется JIT-компилятором или часто просто JIT.
На сегодняшний день Microsoft выпустила четыре версии CLR: 1.0, 1.1, 2.0 и 4.0. Вам нужно иметь правильную версию CLR, установленную на вашем компьютере, если вы хотите запускать исполняемые файлы .NET, ориентированные на эту среду выполнения. CLR 2.0 поддерживает приложения .NET 2.0, 3.0 и 3.5. Для других версий .NET версия .NET четко отображается на версию CLR.
В дополнение к JIT / CLR .NET предоставляет множество библиотек (сборок), которые составляют остальную часть .NET Framework и предоставляют множество возможностей и служб, к которым могут обращаться приложения .NET. Подавляющее большинство этих сборок - это чистый код CIL, который работает на CLR. В Windows некоторые делают вызовы в Win32 API. При установке .NET вы устанавливаете CLR, библиотеки классов (фреймворк) и несколько инструментов разработки. Каждая версия CLR обычно требует полного набора этих «каркасных» сборок. В некоторых версиях .NET (например, 3.0 и 3.5) добавлены дополнительные сборки каркаса без обновления CLR или существующих сборок, связанных с этим CLR.
Формат файла Portable Executable (PE), в который поставляется файл .EXE Windows, содержит заголовок, который описывает исполняемый файл и определяет файл как файл .NET или собственный файл Win32. Когда Windows пытается запустить файл .NET, она видит этот заголовок и автоматически вызывает CLR от вашего имени. Вот почему .NET EXE-файлы запускаются в Windows.
Хорошо, как работает Mono?
Mono реализует CLR на Linux, Mac и других платформах. Среда исполнения Mono (CLR) - это нативное приложение, написанное в основном на языке C и скомпилированное в код машинного языка для компьютерной системы, на которой он предназначен. Как и в Windows, среда выполнения Mono зависит от операционной системы и типа используемой машины.
Как и в Windows, среда выполнения Mono (CLR) компилирует байт-код CIL в исполняемый файл .NET «точно в срок» в собственный код, который ваш компьютер может понять и выполнить. Таким образом, файл .NET является таким же «родным» для Linux, как и для Windows.
Чтобы перенести Mono на новую архитектуру, вам нужно перенести JIT / CLR. Это похоже на перенос любого нативного приложения на новую платформу.
Насколько хорошо .NET-код работает в Linux или Mac, на самом деле просто вопрос того, насколько хорошо CLR реализован в этих системах. Теоретически, Mono CLR может выполнять .NET-код в этих системах гораздо лучше, чем MS-версия .NET в Windows. На практике реализация MS обычно лучше (хотя и не во всех случаях).
В дополнение к CLR Mono предоставляет большую часть остальных библиотек (сборок), составляющих .NET Framework. Как и в версии Microsoft .NET (на самом деле, тем более), сборки Mono предоставляются в виде байт-кода CIL. Это позволяет взять файл * .dll или * .exe из Mono и запустить его без изменений в 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, имитирующую часть GDI + Win32 API на Linux. Эта библиотека называется libgdiplus. Если вы скомпилируете Mono из исходного кода, вы заметите, что вам нужно собрать этот файл 'libgdiplus', прежде чем вы сможете собрать 'mono'. Вам не нужно «libgdiplus» в Windows, потому что часть WinD API GDI + уже является частью Windows. Полный порт Mono для новых платформ требует, чтобы эта библиотека 'libgdiplus' также была портирована.
В тех областях, где дизайн библиотеки .NET сильно зависит от дизайна Windows и плохо подходит для таких систем, как Mac или Linux, команда Mono написала расширения для платформы .NET. Расширения Mono также являются просто байт-кодом CIL и, как правило, отлично работают в .NET.
В отличие от Windows, Linux обычно не обнаруживает исполняемые файлы .NET и запускает CLR по умолчанию. Пользователь обычно должен запускать CLR напрямую, набрав «mono appname.exe» или что-то подобное. Здесь «mono» - это приложение, которое реализует CLR, а «appname.exe» - это файл EXE, который содержит код .NET, который нужно выполнить.
Для упрощения работы пользователей приложения Mono часто заключаются в сценарий оболочки, запускающий CLR. Это скрывает тот факт, что CLR используется так же, как в Windows. Также можно указать Linux запустить CLR при обнаружении файла, использующего формат PE. Обычно этого не делается, поскольку формат файла PE также используется для собственных исполняемых файлов Windows Win32, которые, конечно, CLR (Mono) не поддерживает.
Нет технической причины, по которой средство запуска PE не может использоваться Linux, которая затем запускает систему, которая понимает собственный код Windows (например, Wine) или CLR (Mono), в зависимости от ситуации. Насколько я знаю, этого просто не было сделано.
Назад и вперед
Любой код .NET, который привязан к «полностью управляемому» коду, что означает, что он не обращается к не-.NET коду, должен нормально работать на Mono на всех платформах. Я обычно использую скомпилированные сборки .NET из Windows (для которых у меня нет кода) в Linux и Mac.
Я также могу взять любой код, скомпилированный в Mono, и запустить его в .NET в Windows. Я могу предоставить клиенту некоторый код, который я скомпилировал с Mono, и не беспокоиться, если он, например, в 32-битной или 64-битной Windows. Клиент должен иметь правильную версию .NET (правильный CLR), установленный для курса. CLR 2.0 существует очень давно, и вы можете поспорить, что почти все пользователи Windows установили его. Компиляторы Mono и другой код также являются просто исполняемыми файлами CIL, поэтому они отлично работают в Windows, если хотите.
Моно-совместимость достаточно хороша, так что большие куски реального кода Microsoft, такие как ASP.NET MVC, могут быть взяты (где это допустимо) из реальной версии MS .NET для MS и работают на Mac или Linux. В общем, команда Mono проделала большую работу по внедрению как CLR, так и остальной части фреймворка (библиотеки классов / сборки).
ASP.NET
В Windows Internet Information Server (IIS) знает, как вызвать CLR для выполнения .NET как части веб-приложения. В Linux / Mac есть модуль Apache (mod_mono), который предоставляет возможности, аналогичные веб-серверу Apache. Это приложение написано на C и должно быть перенесено на новые архитектуры.
Портирование Mono
В этом обсуждении были определены части Mono, которые созданы как «собственные» исполняемые файлы и должны существовать в системе, в которой вы хотите запускать приложения .NET.
- CLR (включая JIT-компилятор) - обычно известный как Mono
- libgdiplus (для систем, которые изначально не поддерживают API GDI + [только в Windows])
- mod_mono (чтобы Apache мог вызывать CLR для веб-приложений .NET)
Эти три компонента, с добавлением библиотек классов, обеспечивают среду .NET, которая выглядит "родной" для исполняемых файлов .NET, которые необходимо запустить.
Вот как работает Mono.