.NET Core vs Mono

Ответ 1

Necromancing.
Предоставление актуального ответа.

В чем разница между .Net Core и Mono?

.NET Core теперь официально является будущим .NET. Он начался по большей части с переписывания ASP.NET MVC каркаса и консольных приложений, которые, конечно, включают серверные приложения. (Так как он завершает гастроли и поддерживает взаимодействие с C-dll, вы можете, если вам абсолютно необходимо, также написать с ним свои собственные настольные приложения, например, через сторонние библиотеки, такие как Avalonia, где немного основополагающий в то время, когда я впервые написал это, что означало, что вы были в значительной степени ограничены веб или серверными вещами.) Со временем многие API были добавлены в .NET Core, настолько, что после версии 3.1.NET Core перейдет на версию 5.0, и это будет будущее .NET Framework. То, что раньше было полной .NET Framework, будет сохраняться в режиме обслуживания как Full.NET Framework 4.8.x в течение нескольких десятилетий, пока не умрет (возможно, еще будут некоторые обновления, но я сомневаюсь в этом). Другими словами,.NET Core - это будущее .NET, а Full.NET Framework пойдет по пути Dodo/Silverlight/WindowsPhone.

Основная задача .NET Core, основанного на поддержке нескольких платформ, заключается в повышении производительности и включении "собственной компиляции"/самостоятельного развертывания (поэтому вам не нужно устанавливать .NET Framework/VM на целевом компьютере)..
С одной стороны, это означает поддержку docker.io в Linux, а с другой - автономное развертывание полезно в "облачных вычислениях", так как тогда вы можете просто использовать любую версию платформы dotnet-CORE, которая вам нравится, и вам не нужно беспокоиться о том, какую версию (ы).NET Framework на самом деле установил системный администратор.

Хотя среда выполнения .NET Core поддерживает несколько операционных систем и процессоров, - SDK - это отдельная история. И хотя SDK поддерживает несколько ОС, поддержка ARM для SDK все еще продолжается..NET Core поддерживается Microsoft. Dotnet-Core не поставляется с WinForms, WPF или чем-то подобным.

• Начиная с версии 3.0, WinForms и WPF также поддерживаются .NET Core, но только в Windows и только в С#. Не от VB.NET (поддержка VB.NET запланирована для v5 в 2020 году). И в .NET Core нет Forms-Designer, он поставляется с обновлением Visual Studio позже, в неуказанное время.
• Веб-формы до сих пор не поддерживаются .NET Core, , и нет никаких планов поддерживать их, когда-либо (Blazor является новым ребенком в этом отношении).
• .NET Core также поставляется с System.Runtime, который заменяет mscorelib
• Часто .NET Core смешивается с NetStandard, который является своего рода оберткой вокруг System.Runtime/mscorelib (и некоторых других), которая позволяет вам писать библиотеки для .NET Core, Full.NET Framework и Xamarin (iOS/Android), все одновременно
• .NET-Core SDK не работает/не работает на ARM, по крайней мере, в прошлый раз, когда я проверял

"Проект Mono " намного старше, чем .NET Core.
"Моно" по-испански означает "Обезьяна", и в качестве дополнительного примечания название не имеет ничего общего с мононуклеозом (подсказка: список сотрудников можно найти в http://primates.ximian.com/).
Mono был запущен в 2005 году Мигелем де Иказой (парнем, который начал GNOME - и несколькими другими) в качестве реализации .NET Framework для Linux (Ximian/SuSe/Novell), Mono включает Web-формы, Winforms, MVC, Olive и IDE под названием MonoDevelop (также известный как Xamarin Studio или Visual Studio Mac). В основном эквивалент (OpenJDK) JVM и (OpenJDK) JDK/JRE (в отличие от SUN/Oracle JDK). Вы можете использовать его, чтобы заставить приложения ASP.NET-WebForms + WinForms + ASP.NET-MVC работать в Linux.

Mono поддерживается Xamarin (новое название компании, которая раньше была Ximian, когда они фокусировались на рынке мобильных устройств, а не на рынке Linux), а не Microsoft.
(поскольку Xamarin был куплен Microsoft, это технически [но не культурно] Microsoft.)
Вы обычно получаете ваши С# вещи для компиляции на моно, но не на VB.NET.
Mono пропускает некоторые расширенные функции, такие как WSE/WCF и WebParts.
Многие из реализаций Mono являются неполными (например, сгенерировать исключение NotImplementedException при шифровании ECDSA), глючат (например, ODBC/ADO.NET с Firebird), ведут себя иначе, чем в .NET (например, XML-сериализация) или нестабильны по другим причинам (ASP.NET MVC) и недопустимо медленно (Regex). С другой стороны, монохромный набор инструментов также работает на ARM.

Что касается .NET Core, когда они говорят о кроссплатформенности, не ожидайте, что кроссплатформенность означает, что вы действительно можете просто установить .NET Core на ARM-Linux, как вы можете это сделать с ElasticSearch. Вам придется скомпилировать весь фреймворк из исходного кода.
То есть, если у вас есть это место (например, на Chromebook, у которого общее HD составляет от 16 до 32 ГБ).
Он также имел проблемы несовместимости с OpenSSL 1.1 и libcurl.
Они были исправлены в последней версии .NET Core версии 2.2.
Так много для кроссплатформенности.

Я нашел выражение на официальном сайте, где говорилось: "Кодекс написан для он также переносим между стеками приложений, такими как Mono ".

Пока этот код не использует WinAPI-вызовы, Windows-dll-pinvokes, COM-компоненты, нечувствительную к регистру файловую систему, кодировку системы по умолчанию (кодовая страница) и не имеет проблем с разделителем каталогов, это правильно. Однако код .NET Core работает на ядре .NET, а не на моно. Так что смешивать их будет сложно. А поскольку моно довольно нестабильно и медленно (для веб-приложений), я бы не стал его рекомендовать. Попробуйте обработать изображение на .NET core, например WebP или перемещение GIF или многостраничный TIFF или написание текста на изображении, вы будете неприятно удивлены.

Примечание:
Начиная с .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, но имеет проблемы с iOS/Android - если он вообще работает, то есть.
До .NET Core 2.0, то есть где-то в середине февраля 2017 года, вы могли использовать SkiaSharp для создания изображений (пример) (вы все еще можете).
После выпуска .net-core 2.0 вы заметите, что SixLabors ImageSharp - это путь, так как System.Drawing не обязательно безопасен и имеет много потенциальных или реальных утечек памяти, которые поэтому не следует использовать GDI в веб-приложениях; Обратите внимание, что SkiaSharp намного быстрее, чем ImageSharp, потому что он использует native-библиотеки (что также может быть недостатком). Также обратите внимание, что while GDI+ работает на Linux & Mac, это не значит, что он работает на iOS/Android.

Код, не написанный для .NET (не основной), не переносим на ядро .NET.
То есть, если вам нужна библиотека С# не из GPL, такая как PDFSharp, для создания PDF-документов (очень часто), вам не повезло (на данный момент) (больше нет). Не берите в голову элемент управления ReportViewer, который использует Windows-pInvokes (для шифрования,  создавать документы mcdf через COM, а также получать шрифт, символ, кернинг, информацию о встраивании шрифта, измерять строки и разбивать строки, а также фактически рисовать tif файлы приемлемого качества) и даже не работать на моно в Linux
(Я работаю над этим).

Кроме того, код, написанный на ядре .NET, нельзя переносить в моно, потому что в моно отсутствуют библиотеки времени выполнения ядра .NET (пока).

Моя цель - использовать С#, LINQ, EF7, visual studio для создания веб-сайта. которые могут быть запущены/размещены в Linux.

EF в любой версии, которую я пробовал до сих пор, был чертовски медленным (даже на таких простых вещах, как одна таблица с одним левым соединением), я бы никогда не порекомендовал ее - не на Windows.
Я бы особенно не рекомендовал EF, если у вас есть база данных с уникальными ограничениями или столбцы varbinary/filestream/ierarchyid. (не для обновления схемы)
И также не в ситуации, когда производительность БД критична (скажем, от 10+ до 100+ одновременных пользователей).
Кроме того, запуск веб-сайта/веб-приложения в Linux рано или поздно означает, что вам придется отлаживать его.
В Linux нет поддержки отладки для .NET Core. (больше нет, но требуется JetBrains Rider)
MonoDevelop (пока) не поддерживает отладку проектов .NET-Core.
Если у тебя есть проблемы, ты сам по себе. Вам придется использовать обширную регистрацию.
Будьте осторожны, имейте в виду, что расширенное ведение журнала заполнит ваш диск в кратчайшие сроки, особенно если ваша программа входит в бесконечный цикл или рекурсию.
Это особенно опасно, если ваше веб-приложение запускается от имени пользователя root, поскольку для входа в систему требуется пространство файла журнала - если свободного места не осталось, вы больше не сможете войти в систему.
(Обычно около 5% дискового пространства зарезервировано для пользователя root [он же администратор в windows], поэтому, по крайней мере, администратор может войти в систему, если диск почти заполнен. Но если ваши приложения запускаются как root, это ограничение не распространяется на их использование диска, и поэтому их лог файлы могут использовать 100% оставшегося свободного пространства, поэтому даже администратор не может войти в систему.)
Поэтому лучше не шифровать этот диск, то есть, если вы цените свои данные/систему.

Кто-то сказал мне, что он хотел, чтобы это было "в моно", но я не знаю что это значит.

Это либо означает, что он не хочет использовать .NET Core, либо он просто хочет использовать С# в Linux/Mac. Я думаю, он просто хочет использовать С# для веб-приложения на Linux..NET Core - способ пойти на это, если вы абсолютно хотите сделать это в С#. Не идите с "Моно собственно"; на первый взгляд, это может показаться сработавшим на первый взгляд, но, поверьте, вы пожалеете об этом, потому что моно ASP.NET MVC не стабильно, если ваш сервер работает долго (дольше 1 дня) - вас предупредили. См. также ссылки "не завершено" при измерении монофонической производительности в тестах Techempower.

Я знаю, что хочу использовать .Net Core 1.0 с технологиями Я перечислил выше. Он также сказал, что хочет использовать "быстрый CGI". Я не знаю что это значит тоже.

Это означает, что он хочет использовать высокопроизводительный полнофункциональный Web-сервер, такой как nginx (Engine-X), возможно, Apache.
Затем он может запустить mono/dotnetCore с виртуальным хостингом на основе имен (несколько доменных имен на одном и том же IP) и/или балансировкой нагрузки. Он также может запускать другие веб-сайты с другими технологиями, не требуя другого номера порта на веб-сервере. Это означает, что ваш сайт работает на сервере fastcgi, и nginx перенаправляет все веб-запросы для определенного домена через протокол fastcgi на этот сервер. Это также означает, что ваш сайт работает в fastcgi-конвейере, и вы должны быть осторожны в своих действиях, например. Вы не можете использовать HTTP 1.1 при передаче файлов.
В противном случае файлы будут искажены в месте назначения.
См. также здесь и здесь.

В заключение:
.NET Core в настоящее время (2016-09-28) не является действительно переносимым и не является кроссплатформенным (в частности, инструменты отладки).
Кроме того, нативная компиляция не легка, особенно для ARM.
И для меня это также не выглядит, как будто его разработка "действительно завершена", пока.
Например, отсутствует System.Data.DataTable/DataAdaper.Update...  (больше не с .NET Core 2.0)
Вместе с интерфейсами System.Data.Common.IDB *. (больше не для .NET Core 1.1)
если бы когда-либо был один класс, который часто используется, DataTable/DataAdapter был бы им...
Кроме того, Linux-установщик (.deb) не работает, по крайней мере, на моей машине, и я уверен, что я не единственный, у кого есть эта проблема.
Отладка, возможно, с помощью кода Visual Studio, если вы можете построить его на ARM (мне удалось это сделать - , НЕ следуйте блог-сообщению Скотта Хансельмана, если вы сделаете это - в вики VS - инструкции). Код на github), потому что они не предлагают исполняемый файл.
Йоман тоже терпит неудачу. (Я думаю, это как-то связано с установленной вами версией nodejs - VS Code требует одну версию, Yeoman - другую... но она должна работать на том же компьютере. Довольно хромая
Не берите в голову, что это должно работать на версии узла, поставляемой по умолчанию на OS.
Не берите в голову, что не должно быть никакой зависимости от NodeJS во-первых.
Сервер Kestell также находится в стадии разработки.
И, судя по моему опыту работы с монопроектом, я очень сомневаюсь, что они когда-либо тестировали .NET Core на FastCGI или что они имеют какое-либо представление о том, что означает поддержка FastCGI для их инфраструктуры, не говоря уже о том, что они тестировали ее, чтобы убедиться, что "все работает". ". На самом деле, я только что попытался сделать fastcgi-приложение с .NET Core и просто понял, что для .NET Core "RTM" нет библиотеки FastCGI...

Поэтому, когда вы собираетесь запускать .NET Core "RTM" за nginx, вы можете делать это только через прокси-запросы к kestrell (тот полуфабрикат, производный от nodeJS веб-сервера) - в настоящее время в .NET Core нет поддержки fastcgi "РТМ", AFAIK. Поскольку нет библиотеки FastCGI для ядра .net и примеров, также маловероятно, чтобы кто-либо проводил какое-либо тестирование на платформе, чтобы убедиться, что fastcgi работает должным образом.

Я также подвергаю сомнению производительность.
В (предварительном) тесте производительности электроэнергии (раунд 13)aspnetcore-linux оценивается на 25% относительно лучшей производительности, в то время как сопоставимые фреймворки, такие как Go (golang), оцениваются на 96,9% пиковой производительности (и это при возврате открытого текста без доступа только к файловой системе)..NET Core немного лучше работает с JSON-сериализацией, но тоже не выглядит убедительно (go достигает 98,5% от пика, ядро .NET - 65%). Тем не менее, это не может быть хуже, чем "моно собственно".

Кроме того, поскольку он все еще относительно новый, не все основные библиотеки были портированы (пока), и я сомневаюсь, что некоторые из них когда-либо будут портированы.
Поддержка изображений также сомнительна в лучшем случае.
Для любого шифрования используйте BouncyCastle.

Можете ли вы помочь мне разобраться во всех этих терминах и, если мои ожидания реалистичны?

Я надеюсь, что помог вам разобраться со всеми этими условиями.
Насколько ваши ожидания идут:
Разработка приложения для Linux, ничего не зная о Linux, - это действительно глупая идея, и она так или иначе неизбежно потерпит неудачу. Тем не менее, поскольку Linux не требует затрат на лицензирование, это хорошая идея в принципе, , НО ТОЛЬКО ЕСЛИ ВЫ ЗНАЕТЕ, ЧТО ВЫ ДЕЛАЕТЕ.
Разработкаприложения для платформы, на которой вы не можете отлаживать приложение, - еще одна очень плохая идея.
Разработка для fastcgi, не зная, к каким последствиям это приведет, является еще одной действительно плохой идеей.

Делать все это на "экспериментальной" платформе, не зная специфики этой платформы и не поддерживая отладку, - самоубийство, если ваш проект - это не просто персональная домашняя страница. С другой стороны, я полагаю, что сделать это на своей личной домашней странице в учебных целях было бы очень хорошим опытом - тогда вы узнаете, что такое фреймворк и что такое не-фреймворк.
Например, вы можете (программно) монтировать циклически нечувствительные к регистру fat32, hfs или JFS для своего приложения, чтобы обойти проблемы чувствительности к регистру (циклическое монтирование не рекомендуется в производстве).

Подводя итог
В настоящее время (2016-09-28) я бы держался подальше от .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 появляется облегчение.
JetBrains выпустила "Project Rider", предварительный предварительный просмотр доступа к С#/.NET Core IDE для Linux (и Mac и Windows), который может обрабатывать файлы проекта Visual Studio. Наконец, С# IDE, которая может быть использована & это не медленно, как ад.

Заключение..NET Core по-прежнему является предварительным выпуском качественного программного обеспечения на период до 2017 года. Перенесите свои библиотеки, но держитесь подальше от них для производственного использования, пока качество среды не стабилизируется.
И следите за Project Rider.

Обновление 2017 года
Переместили домашнюю страницу моего (брата) в .NET Core сейчас.
Пока что среда выполнения в Linux кажется достаточно стабильной (по крайней мере, для небольших проектов) - она с легкостью выдержала нагрузочный тест - моно никогда не справлялся.
Кроме того, похоже, что я перепутал .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-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 2. 2+ поддерживает OpenSSL 1.1. Так что вы можете использовать это на Арке или (k) Ubuntu 19. 04+. Возможно, вам придется использовать .NET-Core установить скрипт хотя, потому что пока нет пакетов.

С другой стороны, производительность определенно улучшилась:

.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.

Примечание:
.NET Core 3.0 уже вышел (RTM), и есть поддержка WinForms и WPF, но только для С# (в Windows). Нет WinForms-Core-Designer. Дизайнер, в конце концов, придет с обновлением Visual Studio, когда-нибудь. Поддержка WinForms для VB.NET не поддерживается, но запланирована на .NET 5.0 когда-то в 2020 году.

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, Mono IDE или Visual Studio Mac в том виде, как он теперь называется на Mac) эволюционировал довольно хорошо и, в настоящее время, в основном, пригоден для использования.
Тем не менее, JetBrains Rider (2018 EAP на данный момент) определенно намного приятнее и надежнее (а включенный декомпилятор безопаснее для жизни), то есть если вы разрабатываете .NET-Core на Linux или Mac. MonoDevelop не поддерживает Debug-StepThrough в Linux в .NET Core, так как MS не лицензирует их dll API отладки (за исключением VisualStudio Mac...). Однако вы можете использовать отладчик Samsung для .NET Core через расширение отладчика .NET Core для отладчика Samsung для MonoDevelop

.Отказ от ответственности:
Яне использую Mac, поэтому я не могу сказать, применимо ли то, что я здесь написал, к Mac на базе FreeBSD-Unix. Я ссылаюсь на Linux (Debian/Ubuntu/Mint) версию JetBrains Rider, mono, MonoDevelop/VisualStudioMac/XamarinStudio и .NET-Core. Кроме того, Apple обдумывает переход от процессоров Intel к процессорам ARM (ARM-64?) -based собственного производства, поэтому многое из того, что относится к Mac прямо сейчас, может не применяться к Mac в будущем (2020+).

Кроме того, когда я пишу "моно довольно нестабильно и медленно", нестабильность относится к WinFroms & Приложения WebForms, в частности, выполняющие веб-приложения через fastcgi или с XSP (в версии 4.x mono), а также особенности обработки XML-сериализации, и довольно медленный относится к WinForms и, в частности, к регулярным выражениям (ASP).NET-MVC также использует регулярные выражения для маршрутизации).

Когда я пишу о своем опыте с моно 2.x, 3.x и 4.x, это также не обязательно означает, что эти проблемы не были решены ни к настоящему времени, ни к тому времени, когда вы читаете это, ни к тому, если они Исправлено: теперь не может быть регрессии, которая вновь вводит какие-либо из этих ошибок/функций. Это также не означает, что если вы внедрите моно-среду выполнения, вы получите те же результаты, что и при использовании (dev) системы моно-среды выполнения. Это также не означает, что внедрение моно-времени выполнения (где угодно) обязательно бесплатно.

Все, что не обязательно означает, что моно не подходит для iOS или Android, или что у него есть те же проблемы там. Я не использую моно на Android или IOS, поэтому я не собираюсь ничего говорить о стабильности, удобстве использования, стоимости и производительности на этих платформах. Очевидно, что если вы используете .NET на Android, у вас есть и другие соображения, связанные с затратами, такие как взвешивание затрат xamarin и затрат и времени на перенос существующего кода на Java. Один слышит моно на Android и IOS будет довольно хорошо. Возьми это с зерном соли. Во-первых, не ожидайте, что кодировка системы по умолчанию будет одинаковой на android/ios против Windows, и не ожидайте, что файловая система android будет нечувствительной к регистру.

Ответ 2

В мире .NET существуют два типа CLR, "полные" CLR и Core CLR, и это совсем другие вещи.

Существуют две "полные" реализации CLR, родной .NET CLR для Microsoft (для Windows) и Mono CLR (который сам имеет реализации для Windows, Linux и Unix (Mac OS X и FreeBSD)). Полная CLR - это именно то, что вам нужно. Таким образом, "полные" CLR имеют большой размер.

Core CLR, с другой стороны, сокращаются и намного меньше. Поскольку они представляют собой лишь основную реализацию, у них вряд ли будет все, что вам нужно, поэтому в Core CLR вы добавите на CLR набор функций, которые использует ваш конкретный программный продукт, используя NuGet. Существуют основные возможности CLR для Windows, Linux (различные) и unix (Mac OS X и FreeBSD) в миксе. Microsoft имеет или рефакторирует библиотеки .NET Framework для Core CLR, чтобы сделать их более переносимыми для основного контекста. Учитывая моноприложение на ОС * nix, было бы неожиданностью, если бы Core CLR для * nix не включали некоторую базовую базу, но только сообщество Mono и Microsoft могли бы нам это точно сказать.

Кроме того, я согласен с Нико в том, что Core CLR новы - это на RC2 в тот момент, когда я думаю. Я бы не стал зависеть от этого для производственного кода.

Чтобы ответить на ваш вопрос, вы можете отправить свой сайт на Linux с помощью Core CLR или Mono, и это два разных способа сделать это. Если вы хотите получить безопасную ставку прямо сейчас, я бы пошел с моно на linux, а затем порт, если вы захотите позже, в Core.

Ответ 3

Вы выбрали не только реалистичный путь, но, возможно, одну из лучших экосистем, сильно поддерживаемых (также X-платформы) MS. Тем не менее вы должны учитывать следующие моменты:

• Обновление: основной документ о стандарте платформы .Net находится здесь: https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md
• Обновление: текущее Mono 4.4.1 не может запускать последнюю версию RTM RTF для Asp.Net
• Несмотря на то, что моно более полно завершено, его будущее неясно, потому что MS владеет им уже несколько месяцев и его дублирующая работа для их поддержки. Но MS определенно привержена .Net Core и делает ставку на него.
• Хотя ядро ​​.NET выпущено, экосистема сторонних разработчиков не совсем там. Например, Nhibernate, Umbraco и т.д. Еще не могут работать .Net. Но у них есть план.
• В .NET Core есть некоторые функции, такие как System.Drawing, вы должны искать сторонние библиотеки.
• Вы должны использовать nginx в качестве переднего сервера с kestrelserver для приложений asp.net, потому что kestrelserver не совсем готов к производству. Например, HTTP/2 не реализован.

Я надеюсь, что это поможет

Ответ 4

.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 documentatiopn no rc2 доступно), однако моно не поддерживает Microsoft и рекомендует используя поддерживаемую инфраструктуру

Теперь сущность framework 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, и пока его полностью не выпустят, я бы не решался использовать его в среде продукта, учитывая разрыва между выпущенной версией.

Ответ 5

Этот вопрос особенно актуальен, потому что вчера официально официальная объявила о выпуске .NET Core 1.0. Предполагая, что Mono реализует большинство стандартных библиотек .NET, различие между ядром Mono и .NET можно увидеть по разнице между .NET Framework и .NET Core:

• API..NET Core содержит многие из тех же, , но меньше, API-интерфейсов как .NET Framework и с другим факторингом (имена сборки - это другой; тип формы отличается в ключевых случаях). Эти различия
  в настоящее время обычно требуются изменения в источнике порта для .NET Core..СЕТЬ Core реализует API стандартной библиотеки .NET, который будет расти до включают в себя больше API-интерфейсов BCL.NET Framework с течением времени.
• Подсистемы -.NET Core реализует подмножество подсистем в .NET Framework с целью более простой реализации и
  модель программирования. Например, защита доступа к коду (CAS) не используется поддерживается, а отражение поддерживается.

Если вам нужно что-то быстро запустить, пойдите с Mono, потому что в настоящее время (июнь 2016 года) более зрелый продукт, но если вы строите долгосрочный веб-сайт, я бы предложил .NET Core. Он официально поддерживается Microsoft, и различие в поддерживаемых API, скорее всего, скоро исчезнет, ​​учитывая усилия Microsoft по разработке .NET Core.

Моя цель - использовать С#, LINQ, EF7, визуальную студию для создания веб-сайта который может быть запущен/размещен в Linux.

Структура Linq и Entity включены в .NET Core, поэтому вы можете сделать снимок.

Ответ 6

Чтобы быть простым,

Mono - сторонняя реализация .Net framework для Linux/Android/Иос

.Net Core - это собственная реализация Microsoft для того же самого.

.Net Core - будущее. и Mono в конечном итоге будет мертв. Сказав, что .Net Core недостаточно созрел. Я изо всех сил пытался реализовать его с IBM Bluemix, а позже отказался от этой идеи. Вниз время (может быть 1-2 года), это должно быть лучше.

Ответ 7

В двух словах:

Mono = компилятор для С#

Mono Develop = Компилятор + IDE

.Net Core = ASP-компилятор

Текущий пример использования .Net Core - это веб, только когда он примет какой-то открытый стандарт winform и более широкое распространение языка, он, наконец, может стать мощной разработкой Microsoft killer dev. Учитывая недавний переход Oracle на лицензирование Java, у Microsoft есть огромное время, чтобы проявить себя.