Как работает Mono
https://stackoverflow.com/questions/216841
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Я использовал C # в Visual Studio с .NET и немного поиграл с Mono на openSUSE Linux, но я не совсем понимаю, как он работает.
Если я напишу приложение в Windows на .NET, как это будет связано с Mono? Я не могу просто выполнить Windows .exe файл в Linux без Wine, поэтому он не помогает мне запускать приложения, разработанные в Windows.
Является ли целью просто иметь эквивалентную библиотеку .NET в Linux (и других), чтобы упростить кроссплатформенную разработку? Например, если я занимался бизнесом и хотел привлечь клиентов Linux, но действительно хотел использовать .NET, тогда Mono должен быть моим выбором? Или я скучаю по чему-то большему?
Решение
EXE-файл Windows содержит несколько «частей». Упрощенно , .net-код (= MSIL) - это только часть EXE-файла, и также существует «реальный» код. Собственная часть Windows внутри EXE-файла, которая служит своего рода средством запуска для .net Framework, который затем выполняет MSIL.
Mono просто возьмет MSIL и выполнит его, игнорируя встроенные средства запуска Windows.
Опять же, это упрощенный обзор.
Edit: Боюсь, что мое понимание глубоких и глубоких деталей недостаточно для очень подробной детализации (я примерно знаю, что такое PE Header, но не совсем детали), но я нашел их Полезные ссылки:
Другие советы
Это старый вопрос (с уже выбранным ответом), но я не верю, что на этот вопрос действительно был получен хороший ответ.
Во-первых, немного фона ...
Как работает .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.d in содержит заголовок, который описывает исполняемый файл и определяет файл как файл .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.
Моно версии до версии 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. Это скрывает
На самом деле вы можете запустить файл .NET .exe с Mono в Linux. Это не требует вина. Фактически, Mono компилирует программы в файлы .exe, которые могут запускаться с Mono в Linux или как исполняемый файл в Windows.
Mono - это реализация Microsoft .NET CLR с открытым исходным кодом (Common Language Runtime). Это то, что запускает часть программ .NET, которые написаны не на собственном коде, а на CIL (Common Intermediate Language), языке и машинно-нейтральном промежуточном языке. Среда выполнения берет этот промежуточный код и переводит его в машинный код.
В текущем состоянии Mono вы можете брать программы .NET, которые используют основные части .NET (mscorlib.dll), и запускать их везде, где работает Mono, а не только в Windows.
Но, как уже упоминалось, Mono является открытым исходным кодом, и вы не можете просто полагать, что это будет полная реализация .NET, у него есть некоторые неработающие элементы управления, вы должны быть осторожны с P /. приложение будет использовать, например, ваше приложение будет взаимодействовать с MCI (интерфейс мультимедийного контроллера) под win32. Но я также использовал моно для написания GTK # Applications, но я также использовал свои приложения для Windows, которые работали без перекомпиляции, как упоминалось выше, как наши коллеги-программисты, то есть mono - это альтернатива Microsoft .NET с открытым исходным кодом, и по умолчанию, если вы создаете либо WinForms, либо Gtk # приложения, mono скомпилирует и создаст сборку .exe для каждого файла, и, конечно, если вы захотите, то создаст динамическую библиотеку ссылок (DLL), почти так же, как это делается в .NET. Просто для предложения попробуйте написать Gtk # (в MonoDevelop IDE со встроенным графическим интерфейсом stetic). И, конечно же, mono может стать отличной заменой веб-служб, которые вы можете создавать в .NET и размещать в Apache (поскольку хостинг Linux в настоящее время дешевле, чем в Windows), веб-сервисы и другие приложения asp.net будут работать в apache с модулем mod_mono, который должен быть включен в apache.
Немного не в тему, но я просто хотел рассказать вам о моем опыте.
Также вы можете взглянуть на MoMA (если ваша цель - портировать приложения с Win на Lin).
Моно-миграционный анализатор (MoMA) инструмент поможет вам определить проблемы, которые вы можете есть при портировании вашего .Net приложение к моно. Это помогает точно определить специфичные для платформы вызовы (P / Invoke) и области, которые еще не поддерживаются Моно проект.
Вот веб-приложение, в котором сравниваются типы BCL, уже реализованные в Mono и .NET Framework 3.5
http://mono.ximian.com/class -status / 2,0-против-3,5 / index.html
Чтобы продолжить ответ Михаэля, я думаю, вам придется перекомпилировать Mono, чтобы приложение работало во время выполнения Mono. Исключения могут существовать. Я только немного поиграл с Mono и всегда перекомпилировал исходный код. Я никогда не пытался запустить приложение .NET непосредственно в Mono.
Кроме того, Mono 1.9 должен быть полностью совместимым с .NET 2.0. Предполагается, что Mono Olive и Moonlight добавят функциональность .NET 3.0 (меньше WPF) и Silverlight.
Это может помочь вам, Как работает компилятор C # Mono? , а также Общие сведения о компиляторе Mono C # книга.
