.NET Core против Mono
В чем разница между.NET Core и Mono?
На официальном сайте я нашел заявление, в котором говорилось: "Код, написанный для него, также переносим через все стеки приложений, такие как Mono".
Моя цель - использовать C#, LINQ, EF7 и Visual Studio для создания веб-сайта, который можно запускать / размещать в Linux.
Кто-то сказал мне, что он хотел, чтобы это было "в моно", но я не знаю, что это значит. Я знаю, что хочу использовать.NET Core 1.0 с технологиями, которые я перечислил выше. Он также сказал, что хочет использовать "быстрый CGI". Я тоже не знаю, что это значит.
Можете ли вы помочь мне разобраться во всех этих терминах и реалистичны ли мои ожидания?
9 ответов
Necromancing.
Предоставление актуального ответа.
В чем разница между.Net Core и Mono?
.NET Core по большей части переписывает среду ASP.NET MVC (и консольные приложения), чтобы уменьшить зависимости, сделать ее более модульной и повысить производительность.
<edit>Console Applications: this includes server applications IMHO</edit>
Суть в том, чтобы включить "собственную компиляцию" / автономное развертывание (поэтому вам не нужно устанавливать.NET framework/VM на целевой машине.
Это полезно в "облачных вычислениях", так как тогда вы можете просто использовать любую версию фреймворка dotnet-CORE, которая вам нравится, и вам не нужно беспокоиться о том, какую версию (ы).NET-фреймворка на самом деле имеет системный администратор установлены.
Кроме того,.NET Core поддерживает несколько операционных систем.
Это поддерживается Microsoft.
Dotnet Core не поставляется с Winforms или WPF или чем-то подобным.
Mono - это реализация.NET Framework для Linux (включая Web-Forms, Winforms, MVC). В основном эквивалент JVM (OpenJDK) и JDK/JRE (OpenJDK) (в отличие от JDK SUN/Oracle). Вы можете использовать его, чтобы заставить приложения ASP.NET-WebForms + WinForms + ASP.NET-MVC работать в Linux.
Он поддерживается Xamarin, а не Microsoft.
(поскольку Xamarin был куплен Microsoft, это технически, но не совсем Microsoft).
Вы обычно получаете ваши C# вещи для компиляции на моно, но не на VB.NET.
Некоторые расширенные функции, такие как WSE/WCF и WebParts отсутствуют.
Многие из реализаций являются неполными (например, генерируют NotImplementedException в шифровании ECDSA), содержат ошибки (например, ODBC/ADO.NET с Firebird), ведут себя иначе, чем в.NET (например, XML-сериализация) или нестабильны по другим причинам (ASP.NET MVC) и недопустимо медленно (Regex) .
Тем не менее, не ожидайте, что кроссплатформенность означает, что вы можете просто установить и установить.NET Core на ARM-Linux, как вы можете сделать с asticsearch. Вам придется скомпилировать всю фреймворк из исходного кода.
То есть, если у вас есть это место (например, на Chromebook, который имеет от 16 до 32 ГБ HD).
Так много для кроссплатформенности.
На официальном сайте я нашел заявление, в котором говорилось: "Код, написанный для него, также переносим через все стеки приложений, такие как Mono".
Пока этот код не использует WinAPI-вызовы, Windows-dll-pinvokes, COM-компоненты, нечувствительную к регистру файловую систему и не имеет проблем с разделителем каталогов, это правильно. Однако код.NET Core работает на ядре.NET, а не на моно. Так что смешивать их будет сложно. А поскольку моно довольно нестабильно и медленно, я бы не стал его рекомендовать. Попробуйте обработать изображение на ядре.NET, например, WebP или перемещение GIF или многостраничный тиф или написание текста на изображении, и вы будете удивлены.
<edit> По состоянию на середину февраля 2017 года: вы можете использовать SkiaSharp для этого сейчас (пример) </edit>
Замечания:
Начиная с.NET Core 2.0 существует System.Drawing.Common (nuget), который содержит большую часть функциональных возможностей System.Drawing. Он должен быть более или менее полнофункциональным в.NET-Core 2.1. Однако System.Drawing.Common использует GDI+ и, следовательно, не будет работать в Azure (библиотеки System.Drawing доступны в облачной службе Azure [в основном просто виртуальная машина], но не в веб-приложении Azure [в основном, на виртуальном хостинге?])
Пока что System.Drawing.Common отлично работает на Linux/Mac.
Код, не написанный для.NET (не основной), не переносим на ядро .NET.
То есть, если вы хотите использовать не-GPL C# библиотеку, такую как PDFSharp, для создания PDF-документов (очень часто), вам не повезло (в данный момент) ( больше нет). Не берите в голову элемент управления ReportViewer, который использует Windows-pInvokes (по любой причине) и даже не работает на моно в Linux
( Я работаю над этим).
Кроме того, код, написанный на ядре.NET, нельзя переносить в моно, потому что в моно отсутствуют библиотеки времени выполнения ядра.NET (пока).
Моя цель - использовать C#, LINQ, EF7, visual studio для создания веб-сайта, который можно запускать / размещать в Linux.
EF в любой версии, которую я пробовал до сих пор, был чертовски медленным (даже на таких простых вещах, как одна таблица с одним левым соединением), я бы не рекомендовал ее никогда - не на Windows.
Я бы особенно не рекомендовал EF, если у вас есть база данных с уникальными ограничениями или столбцы varbinary/filestream/ierarchyid. (не для обновления схемы)
И также не в ситуации, когда производительность БД критична (скажем, от 10+ до 100+ одновременных пользователей).
Кроме того, запуск веб-сайта / веб-приложения в Linux рано или поздно означает, что вам придется его отлаживать. В Linux нет поддержки отладки для.NET Core. (больше нет, но требуется JetBrains Rider)
MonoDevelop (пока) не поддерживает отладку проектов.NET-Core.
Если у тебя есть проблемы, ты сам по себе. Вам придется использовать обширную регистрацию.
Будьте осторожны, имейте в виду, что обширное ведение журнала заполнит ваш диск в кратчайшие сроки, особенно если ваша программа входит в бесконечный цикл или рекурсию.
Это особенно опасно, если ваше веб-приложение запускается с правами root, поскольку для входа в систему требуется пространство logfile - если свободного места не осталось, вы больше не сможете войти в систему.
(Обычно около 5% дискового пространства зарезервировано для пользователя root [он же администратор в Windows], поэтому, по крайней мере, администратор может войти в систему, если диск почти заполнен. Но если ваши приложения работают как root, это ограничение не распространяется на их использование диска, и поэтому их лог-файлы могут использовать 100% оставшегося свободного пространства, поэтому даже администратор не сможет войти в систему.)
Поэтому лучше не шифровать этот диск, то есть, если вы цените свои данные / систему.
Кто-то сказал мне, что он хотел, чтобы это было "в моно", но я не знаю, что это значит.
Это либо означает, что он не хочет использовать.NET Core, либо он просто хочет использовать C# в Linux/Mac. Я думаю, он просто хочет использовать C# для веб-приложения на Linux. .NET Core - способ пойти на это, если вы абсолютно хотите сделать это в C#. Не идите с "Моно собственно"; на первый взгляд, это может сработать на первый взгляд, но, поверьте, вы пожалеете об этом, потому что ASP.NET MVC mono не стабильна, когда ваш сервер работает долго (дольше 1 дня) - вас предупредили. См. Также ссылки "не завершено" при измерении монофонической производительности в тестах Techempower.
Я знаю, что хочу использовать среду.Net Core 1.0 с технологиями, которые я перечислил выше. Он также сказал, что хочет использовать "быстрый CGI". Я тоже не знаю, что это значит.
Это означает, что он хочет использовать высокопроизводительный полнофункциональный Web-сервер, такой как nginx (Engine-X), возможно, Apache.
Затем он может запустить mono/dotnetCore с виртуальным хостингом на основе имен (несколько доменных имен на одном IP) и / или балансировкой нагрузки. Он также может запускать другие веб-сайты с другими технологиями, не требуя другого номера порта на веб-сервере. Это означает, что ваш сайт работает на сервере fastcgi, а nginx перенаправляет все веб-запросы для определенного домена через протокол fastcgi на этот сервер. Это также означает, что ваш сайт работает в fastcgi-конвейере, и вы должны быть осторожны в своих действиях, например, вы не можете использовать HTTP 1.1 при передаче файлов.
В противном случае файлы будут искажены в месте назначения.
Смотрите также здесь и здесь.
Заключить:
.NET Core в настоящее время не является действительно переносимым и не является кроссплатформенным (в частности, инструменты отладки).
Также нативная компиляция не легка, особенно для ARM.
И для меня это также не похоже, что его разработка "действительно закончена", пока. Например, отсутствует System.Data.DataTable/DataAdaper.Update... (больше не с.NET Core 2.0) Вместе с интерфейсами System.Data.Common.IDB*. (больше не с.NET Core 1.1)
если когда-либо был один класс, который часто используется, DataTable/DataAdapter был бы им...
Кроме того, Linux-установщик (.deb) не работает, по крайней мере, на моей машине, и я уверен, что я не единственный, у кого есть эта проблема.
Отладка, может быть, с помощью Visual Studio Code, если вы можете построить ее на ARM (мне удалось это сделать - НЕ следуйте блог-сообщению Скотта Хансельмана, если вы это делаете - в вики VS-кода на github есть инструкция), потому что они не предлагают исполняемый файл.
Йоман тоже терпит неудачу. (Я полагаю, это как-то связано с установленной вами версией nodejs - VS Code требует одну версию, Yeoman - другую... но она должна работать на том же компьютере.
Не берите в голову, что это должно работать на версии узла, поставляемой по умолчанию на OS.
Не берите в голову, что не должно быть никакой зависимости от NodeJS во-первых.
Сервер Kestell также находится в стадии разработки.
И, судя по моему опыту работы с монопроектом, я очень сомневаюсь, что они когда-либо тестировали.NET Core на FastCGI или что они имеют какое-либо представление о том, что означает поддержка FastCGI для их инфраструктуры, не говоря уже о том, что они тестировали ее, чтобы убедиться, что "все работает". ". На самом деле, я только что попытался создать fastcgi-приложение с.NET Core и просто понял, что библиотеки FastCGI для.NET Core "RTM" нет...
Поэтому, когда вы собираетесь запускать.NET Core "RTM" за nginx, вы можете делать это только через прокси-запросы к kestrell (этот полуфабрикат, производный от nodeJS веб-сервера) - в настоящее время в.NET Core нет поддержки fastcgi "РТМ", AFAIK. Поскольку нет библиотеки FastCGI для ядра.net и примеров, также маловероятно, чтобы кто-либо проводил какое-либо тестирование на платформе, чтобы убедиться, что fastcgi работает должным образом.
Я также подвергаю сомнению производительность.
В (предварительном) тесте techempower (раунд 13) aspnetcore-linux оценивается на 25% относительно лучшей производительности, в то время как сопоставимые фреймворки, такие как Go (golang), оцениваются на 96,9% пиковой производительности (то есть при возврате открытого текста без файла). -системный доступ только).NET Core немного лучше работает с JSON-сериализацией, но тоже не выглядит убедительно (go достигает 98,5% от пика, ядро .NET - 65%). Тем не менее, это не может быть хуже, чем "моно собственно".
Кроме того, поскольку он все еще относительно новый, не все основные библиотеки были портированы (пока), и я сомневаюсь, что некоторые из них когда-либо будут портированы.
Поддержка изображений также сомнительна в лучшем случае.
Для любого шифрования используйте BouncyCastle.
Можете ли вы помочь мне разобраться во всех этих терминах и реалистичны ли мои ожидания?
Я надеюсь, что помог вам разобраться со всеми этими терминами.
Насколько ваши ожидания идут:
Разработка приложения для Linux, ничего не зная о Linux, - это действительно глупая идея, и она так или иначе неизбежно потерпит неудачу. Тем не менее, поскольку Linux не требует затрат на лицензирование, это в принципе хорошая идея, НО ТОЛЬКО ЕСЛИ ВЫ ЗНАЕТЕ, ЧТО ДЕЛАЕТЕ.
Разработка приложения для платформы, на которой вы не можете отлаживать приложение, - еще одна очень плохая идея.
Разработка для fastcgi, не зная, к каким последствиям это приводит, является еще одной действительно плохой идеей.
Делать все это на "экспериментальной" платформе, не зная специфики этой платформы и не поддерживая отладку, - самоубийство, если ваш проект - это не просто домашняя страница. С другой стороны, я полагаю, что сделать это с вашей личной домашней страницей в учебных целях было бы очень полезным для вас - тогда вы узнаете, что такое фреймворк и что такое не-фреймворк.
Например, вы можете (программно) монтировать циклически нечувствительные к регистру fat32, hfs или JFS для своего приложения, чтобы обойти проблемы чувствительности к регистру (циклическое монтирование не рекомендуется в производстве).
Подвести итоги
В настоящее время я бы держался подальше от.NET Core (для производственного использования). Может быть, через один-два года вы можете взглянуть еще раз, но, вероятно, не раньше.
Если у вас есть новый веб-проект, который вы разрабатываете, запустите его в.NET Core, а не в моно.
Если вам нужна среда, работающая в Linux (x86/AMD64/ARMhf) и Windows и Mac, которая не имеет зависимостей, то есть только статическое связывание и не зависит от.NET, Java или Windows, используйте вместо этого Golang. Он более зрелый, и его производительность доказана (Baidu использует его с 1 миллионом одновременно работающих пользователей), а у golang значительно меньше памяти. Также golang находится в репозиториях,.deb устанавливается без проблем, исходный код компилируется - без внесения изменений - и golang (тем временем) имеет поддержку отладки с помощью delve и JetBrains Gogland в Linux (а также в Windows и Mac). Процесс сборки Golang (и время выполнения) также не зависит от NodeJS, что является еще одним плюсом.
Что касается моно, держись подальше от него.
Не удивительно, как далеко продвинулась моно, но, к сожалению, это не заменит ее проблем производительности / масштабируемости и стабильности для производственных приложений.
Кроме того, моно-разработка довольно мертва, они в основном разрабатывают только части, относящиеся к Android и iOS, потому что именно там Xamarin делает свои деньги.
Не ожидайте, что веб-разработка будет первоклассным гражданином Xamarin/ моно.
.NET Core может стоить того, если вы начинаете новый проект, но для существующих крупных проектов веб-форм перенос по большей части исключен, требуемые изменения огромны. Если у вас есть MVC-проект, количество изменений может быть управляемым, если ваш первоначальный дизайн приложения был вменяемым, что в большинстве случаев не относится к большинству существующих так называемых "исторически выросших" приложений.
Обновление за декабрь 2016 года:
Собственная компиляция была удалена из предварительного просмотра.NET Core, так как она еще не готова...
Похоже, что они значительно улучшились в исходном тесте для текстовых файлов, но, с другой стороны, он стал довольно глючным. Кроме того, это еще больше ухудшилось в тестах JSON. Любопытно также, что структура сущностей должна быть быстрее для обновлений, чем Dapper, хотя и то и другое с рекордной медленностью. Это очень маловероятно, чтобы быть правдой. Похоже, есть еще несколько ошибок, на которые нужно охотиться.
Кроме того, на фронте Linux IDE появляется облегчение.
IntelliJ выпустил "Project Rider", предварительный предварительный просмотр доступа к C#/.NET Core IDE для Linux (и Mac и Windows), который может обрабатывать файлы проекта Visual Studio. Наконец, C# IDE, которая пригодна для использования и которая не такая уж и медленная.
Заключение..NET Core по-прежнему является предварительным выпуском качественного программного обеспечения на период до 2017 года. Перенесите свои библиотеки, но держитесь подальше от них для производственного использования, пока качество среды не стабилизируется.
И следите за Project Rider.
Обновление 2017
Переместили домашнюю страницу моего (брата) на.NET Core сейчас.
Пока что среда выполнения в Linux кажется достаточно стабильной (по крайней мере, для небольших проектов) - она с легкостью выдержала нагрузочный тест - mono никогда не справлялся.
Кроме того, похоже, что я перепутал.NET-Core-native и.NET-Core-автономное развертывание. Автономное развертывание работает, но оно немного недокументировано, хотя это очень просто (инструменты сборки / публикации немного нестабильны, но, если вы столкнулись с "Требуется положительное число. - Сбой сборки".), Повторите эту же команду еще раз, и это работает).
Вы можете запустить
dotnet restore -r win81-x64
dotnet build -r win81-x64
dotnet publish -f netcoreapp1.1 -c Release -r win81-x64
И вы получаете автономный.exe-файл (в каталоге публикации), который вы можете переместить на компьютер с Windows 8.1 без установленной платформы.NET и запустить. Ницца. Именно здесь dotNET-Core только начинает становиться интересным. (учтите пробелы, SkiaSharp не работает на Windows 8.1 / Windows Server 2012 R2, [пока] - экосистема должна сначала догнать - но, что интересно, Skia-dll-load-fail не приводит к сбою всего сервера / приложение - так все остальное работает)
(Примечание. В SkiaSharp в Windows 8.1 отсутствуют соответствующие файлы среды выполнения VC - msvcp140.dll и vcruntime140.dll. Скопируйте их в каталог публикации, и Skia будет работать в Windows 8.1.)
Август 2017 Обновление
Выпущен.NET Core 2.0.
Будьте осторожны - идет с (огромными) изменениями в аутентификации...
С другой стороны, он вернул классы DataTable/DataAdaper/DataSet и многое другое.
Реализовано.NET Core по-прежнему отсутствует поддержка Apache SparkSQL, потому что Mobius еще не перенесен. Это плохо, потому что это означает, что SparkSQL не поддерживает мой IoT Cassandra Cluster, поэтому нет присоединений...
Экспериментальная поддержка ARM (только во время выполнения, но не SDK - слишком плохо для разработки на моем Chromebook - с нетерпением жду 2.1 или 3.0).
PdfSharp теперь экспериментально портирован на.NET Core.
JetBrains Rider покинул EAP. Теперь вы можете использовать его для разработки и отладки.NET Core в Linux - хотя пока только.NET Core 1.1, пока не появится обновление для поддержки.NET Core 2.0.
Май 2018 Обновление
Выпуск.NET Core 2.1 неизбежен. Возможно, это исправит NTLM-аутентификацию в Linux (NTLM-аутентификация не работает в Linux {и, возможно, Mac} в.NET-Core 2.0 с несколькими заголовками аутентификации, такими как согласование, обычно отправляемое с помощью ms-exchange, и они, очевидно, только исправление в v2.1, без исправления ошибок для 2.0).
Но я не устанавливаю предварительные версии на моей машине. Так что жду.
Также сказано, что v2.1 значительно сокращает время компиляции. Что было бы хорошо.
Также обратите внимание, что в Linux.NET Core только 64-битный!
Нет и не будет x86-32 версии.NET Core для Linux.
И порт ARM только ARM-32. Нет ARM-64, пока.
А на ARM у вас (на данный момент) есть только среда выполнения, а не dotnet-SDK.
И еще кое-что:
Поскольку.NET-Core использует OpenSSL 1.0, .NET Core в Linux не работает в Arch Linux, а не в Manjaro (наиболее популярном дистрибутиве Linux на данный момент), потому что Arch Linux использует OpenSSL 1.1. Так что если вы используете Arch Linux, вам не повезло (с Gentoo тоже).
С другой стороны, производительность определенно улучшилась: 
.NET Core 3:
Говорят, что.NET-Core v 3.0 переносит WinForms и WPF в.NET-Core.
Однако, хотя WinForms и WPF будут.NET Core, WinForms и WPF в.NET-Core будут работать только под Windows, поскольку WinForms/WPF будет использовать Windows-API.
PS:
export DOTNET_CLI_TELEMETRY_OPTOUT=1
Если вы использовали его на Windows, вы, вероятно, никогда не видели это:
Инструменты.NET Core собирают данные об использовании для улучшения вашего опыта.
Данные являются анонимными и не содержат аргументов командной строки.
Данные собираются Microsoft и передаются сообществу.
Вы можете отказаться от телеметрии, установив для переменной среды DOTNET_CLI_TELEMETRY_OPTOUT значение 1, используя вашу любимую оболочку.
Вы можете узнать больше о.NET Core инструменты телеметрии @ https://aka.ms/dotnet-cli-telemetry.
Я подумал, что упомяну, что я думаю, что monodevelop (он же Xamarin Studio, моно IDE) эволюционировал довольно хорошо, и в то же время - в значительной степени пригоден для использования.
Тем не менее, JetBrains Rider (2018 EAP на данный момент) определенно намного приятнее и надежнее (а включенный декомпилятор безопаснее для жизни), то есть если вы разрабатываете.NET-Core на Linux или Mac.
Отказ от ответственности:
Я не использую Mac, поэтому я не могу сказать, применимо ли то, что я здесь написал, к Mac на базе FreeBSD-Unix. Я ссылаюсь на Linux (Debian/Ubuntu/Mint) версию JetBrains Rider, mono, MonoDevelop/VisualStudioMac/XamarinStudio и.NET-Core. Кроме того, Apple обдумывает переход от процессоров Intel к процессорам собственного производства на базе ARM(ARM-64?), Поэтому многое из того, что относится к Mac прямо сейчас, может не относиться к Mac в будущем (2020+).
Кроме того, когда я пишу "моно довольно нестабильно и медленно", нестабильность относится к приложениям WinFroms и WebForms, в частности, к выполнению веб-приложений через fastcgi или с XSP (в версии 4.x mono), а также к XML-сериализации. Обработка особенностей, и довольно медленный относится к WinForms, и в частности к регулярным выражениям (ASP.NET-MVC также использует регулярные выражения для маршрутизации).
Когда я пишу о своем опыте с mono 4.x, это также не обязательно означает, что эти проблемы не были решены ни к настоящему времени, ни к тому времени, когда вы читаете это, ни к тому, что, если они исправлены сейчас, что не может быть быть регрессом позже, который вновь вводит любую из этих ошибок / функций. Это также не означает, что если вы встраиваете моно-среду выполнения, вы получите те же результаты, что и при использовании моно-среды системы (dev). Это также не означает, что встраивание моно-среды (где угодно) обязательно бесплатно.
Все, что не обязательно означает, что mono не подходит для IOS или Android, или что у него есть такие же проблемы. Я не использую моно на Android или IOS, поэтому я не собираюсь ничего говорить о стабильности, удобстве использования, стоимости и производительности на этих платформах. Очевидно, что если вы используете.NET на Android, у вас есть и другие соображения, связанные с затратами, такие как взвешивание затрат на xamarin и затрат и времени на перенос существующего кода на Java. Один слышит моно на Android и IOS будет довольно хорошо. Возьми это с зерном соли. Во-первых, не ожидайте, что кодировка системы по умолчанию будет одинаковой на android/ios против Windows, и не ожидайте, что файловая система android будет нечувствительна к регистру.
В мире.NET существует два типа CLR: "полные" CLR и Core CLR, и это совершенно разные вещи.
Существует две "полных" реализации CLR, родная.NET CLR от Microsoft (для Windows) и Mono CLR (которая сама имеет реализации для Windows, Linux и Unix (Mac OS X и FreeBSD)). Полный CLR - это как раз то, что вам нужно. Таким образом, "полные" CLR имеют тенденцию быть большими по размеру.
Основные CLR, с другой стороны, вырублены и намного меньше. Поскольку они являются лишь базовой реализацией, вряд ли в них будет все, что вам нужно, поэтому в Core CLR вы добавляете наборы функций в CLR, которую использует ваш конкретный программный продукт, с использованием NuGet. В миксе есть реализации Core CLR для Windows, Linux (различные) и Unix (Mac OS X и FreeBSD). Корпорация Microsoft также имеет или проводит реорганизацию библиотек.NET Framework для Core CLR, чтобы сделать их более переносимыми для основного контекста. Учитывая присутствие mono в ОС *nix, было бы удивительно, если бы в CLR Core для *nix не было базы моно-кода, но только сообщество Mono и Microsoft могли бы сказать нам об этом наверняка.
Кроме того, я согласен с Нико в том, что Core CLR являются новыми - я думаю, что именно на RC2. Я бы не зависел от этого для производственного кода еще.
Чтобы ответить на ваш вопрос, вы можете доставить свой сайт в Linux, используя Core CLR или Mono, и это два разных способа сделать это. Если вы хотите сделать безопасную ставку прямо сейчас, я бы пошел с моно на Linux, а затем перенесу, если хотите, на Core.
Это больше не.NET Core vs. Mono. Это едино.
Обновление от ноября 2020 г. - выпущена.NET 5, объединяющая.NET Framework и.NET Core
.NET и Mono будут объединены под.NET 6, который будет выпущен в ноябре 2021 года.
- .NET 6.0 добавит
net6.0-iosиnet6.0-android. - Имена ОС могут включать номера версий ОС, например
net6.0-ios14.
Проверьте ссылки ниже:
Вы выбрали не только реалистичный путь, но и, возможно, одну из лучших экосистем, сильно поддерживаемых (также X-платформами) MS. Еще вам стоит учесть следующие моменты:
- Обновление: Главный документ о стандарте платформы.Net находится здесь: https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md
- Обновление: текущая версия Mono 4.4.1 не может работать с последней версией Asp.Net core 1.0 RTM
- Хотя моно более полнофункционально, его будущее неясно, потому что MS владеет им уже несколько месяцев, и для него это дублирующая работа. Но MS определенно привержена.Net Core и делает большие ставки на это.
- Хотя ядро .Net выпущено, сторонняя экосистема не совсем там. Например, Nhibernate, Umbraco и т. Д. Пока не могут работать на ядре.Net. Но у них есть план.
- В.Net Core отсутствуют некоторые функции, такие как System.Drawing, вам следует искать сторонние библиотеки.
- Вы должны использовать nginx в качестве переднего сервера с kestrelserver для приложений asp.net, потому что kestrelserver не совсем готов к работе. Например, HTTP/2 не реализован.
Я надеюсь, что это помогает
.Net Core не требует моно в смысле моно фреймворка. .Net Core - это фреймворк, который будет работать на нескольких платформах, включая Linux. Ссылка https://dotnet.github.io/.
Однако ядро .Net может использовать моно-фреймворк. Ссылка https://docs.asp.net/en/1.0.0-rc1/getting-started/choosing-the-right-dotnet.html (обратите внимание, что документ rc1 не доступен для rc2), однако mono не является поддерживаемой платформой Microsoft и рекомендовал бы использовать поддерживаемые рамки
Теперь структура сущности 7 теперь называется Entity Framework Core и доступен на нескольких платформах, включая Linux. Ссылка https://github.com/aspnet/EntityFramework (обзор дорожной карты)
В настоящее время я использую обе эти платформы, но вы должны понимать, что они все еще находятся в стадии подготовки к выпускуRC2 это текущая версия), и в кандидатах на бета-версию и релиз произошли огромные изменения, которые обычно заканчиваются тем, что вы почесываете голову.
Вот руководство по установке MVC .Net Core в Linux. https://docs.asp.net/en/1.0.0-rc1/getting-started/installing-on-linux.html
Наконец, у вас есть выбор веб-серверов (где я предполагаю, fast cgi Ссылка пришла от), чтобы разместить ваше приложение на Linux. Вот ориентир для установки в среде Linux. https://docs.asp.net/en/1.0.0-rc1/publishing/linuxproduction.html
Я понимаю, что этот пост в основном является ссылками на документацию, но на данный момент это ваши лучшие источники информации. Ядро.Net все еще является относительно новым в сообществе.Net, и до его полного выпуска я не решался бы использовать его в среде продукта, учитывая существенные изменения между выпущенной версией.
Этот вопрос особенно актуален, поскольку вчера Microsoft официально объявила о выпуске.NET Core 1.0. Предполагая, что Mono реализует большинство стандартных библиотек.NET, различие между Mono и ядром.NET можно увидеть через разницу между.NET Framework и.NET Core:
- API -.NET Core содержит много таких же, но меньше API, что и.NET Framework, и с другим факторингом (имена сборок
разные; Форма шрифта отличается в ключевых случаях). Эти различия
в настоящее время обычно требуются изменения в порте источника на.NET Core. .NET Core реализует API.NET Standard Library, который вырастет до
со временем добавьте больше API.NET Framework BCL.- Подсистемы -.NET Core реализует подмножество подсистем в.NET Framework с целью более простой реализации и
модель программирования. Например, Code Access Security (CAS) не является
поддерживается, а отражение поддерживается.
Если вам нужно быстро что-то запустить, используйте Mono, потому что в настоящее время (июнь 2016 г.) это более зрелый продукт, но если вы создаете долгосрочный веб-сайт, я бы предложил.NET Core. Он официально поддерживается Microsoft, и разница в поддерживаемых API, вероятно, скоро исчезнет, принимая во внимание усилия Microsoft по разработке.NET Core.
Моя цель - использовать C#, LINQ, EF7, visual studio для создания веб-сайта, который можно запускать / размещать в Linux.
Linq и Entity Framework включены в.NET Core, так что вы можете сделать снимок.
Чтобы быть простым,
Mono - сторонняя реализация.Net framework для Linux / Android / iOs
.Net Core - собственная реализация Microsoft для того же самого.
.Net Core - это будущее. и Моно будет мертв в конце концов. Сказав, что.Net Core не достаточно зрелый. Я изо всех сил пытался реализовать его с помощью IBM Bluemix и позже отказался от этой идеи. Время простоя (может быть 1-2 года) должно быть лучше.
Это одна из моих любимых тем, и содержание здесь было просто потрясающим. Я подумал, будет ли целесообразно или эффективно сравнивать методы, доступные в Runtime и Mono. Надеюсь, я правильно понял свои условия, но я думаю, вы понимаете, что я имею в виду. Чтобы иметь несколько лучшее представление о том, что каждая среда выполнения поддерживает в настоящее время, имеет ли смысл сравнивать методы, которые они предоставляют? Я понимаю, что реализации могут различаться, и я не рассматривал библиотеки классов Framework или множество других библиотек, доступных в одной среде по сравнению с другой. Я также понимаю, что кто-то, возможно, уже сделал эту работу еще более эффективно. Я был бы очень признателен, если бы вы сообщили мне, чтобы я мог просмотреть его. Я чувствую, что было бы полезно провести различие между результатами такой деятельности, и хотел бы узнать, как к этому относятся более опытные разработчики. и будут ли они давать полезные рекомендации. Когда-то я играл с отражением и написал несколькостроки , которые проходят через каталог .net, и перечисляют сборки.
В двух словах:
Mono = компилятор для C#
Mono Develop = Компилятор + IDE
.Net Core = ASP-компилятор
Текущий пример использования.Net Core - это веб, только когда он примет какой-то открытый стандарт winform и более широкое распространение языка, он, наконец, может стать мощным средством Microsoft killer dev. Учитывая недавний переход Oracle на лицензирование Java, у Microsoft есть огромное время, чтобы проявить себя.