Necromancing.
Предоставление актуального ответа.
В чем разница между .Net Core и Mono?
.NET Core теперь официально является будущим .NET. Это началось по большей части с переписывания ASP.NET MVC и консольных приложений, которые, конечно, включают серверные приложения. (Так как он Turing-complete и поддерживает взаимодействие с C dll, вы можете, если вы абсолютно хотите, также создавать собственные настольные приложения с ним, например, через сторонние библиотеки, такие как Avalonia., которые были довольно просты в то время, когда я впервые писал это, а это означало, что вы были в значительной степени ограничены веб- или серверными вещами.) Со временем в API .NET Core было добавлено много API, настолько, что после версии 3.1 .NET Core перейдет на версию 5.0, известную как .NET 5.0 без «Core», и это станет будущим .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 и только в C #. Не для VB.NET (поддержка VB.NET запланирована для v5 в 2020 году). И в .NET Core нет Forms Designer: он поставляется с обновлением Visual Studio позже, в неуказанное время.
- WebForms до сих пор не поддерживаются .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.
«Mono» по-испански означает «обезьяна», и в качестве дополнительного примечания название не имеет ничего общего с мононуклеозом (подсказка: список сотрудников можно получить по адресу http://primates.ximian.com/ ).
Mono был запущен в 2005 году Мигелем де Иказой (парнем, который основал GNOME - и несколькими другими) как реализация .NET Framework для Linux (Ximian / SuSe / Novell). Mono включает веб-формы, 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.)
Вы обычно получаете свои C # -компилируемые компоненты для моно, но не VB.NET.
Mono пропускает некоторые расширенные функции, такие как WSE / WCF и WebParts.
Многие из реализаций Mono являются неполными (например, сгенерировать исключение NotImplementedException при шифровании ECDSA), глючить (например, ODBC / ADO.NET с Firebird), вести себя иначе, чем в .NET (например, XML-сериализация) или нестабильно по другим причинам (ASP.NET MVC) и недопустимо медленно (Regex). С другой стороны, набор инструментов Mono также работает на ARM.
Что касается .NET Core, то, когда они говорят о кроссплатформенности, не ожидайте, что кроссплатформенность означает, что вы можете просто получить и установить .NET Core на ARM-Linux, как вы можете это сделать с ElasticSearch. Вам придется скомпилировать весь фреймворк из исходного кода.
То есть, если у вас есть это место (например, на Chromebook, который имеет от 16 до 32 ГБ HD).
Он также имел проблемы несовместимости с OpenSSL 1.1 и libcurl.
Они были исправлены в последней версии .NET Core версии 2.2.
Так много для кроссплатформенности.
На официальном сайте я нашел заявление, в котором говорилось: «Код, написанный для него, также переносим через все стеки приложений, такие как Mono».
Пока этот код не использует WinAPI-вызовы, Windows-dll-pinvokes, COM-компоненты, нечувствительную к регистру файловую систему, кодировку системы по умолчанию (кодовую страницу) и не имеет проблем с разделителем каталогов, это верный. Однако код .NET Core работает на .NET Core, а не на Mono. Так что смешивать их будет сложно. А поскольку Mono довольно нестабилен и медленен (для веб-приложений), я бы не стал его рекомендовать. Попробуйте обработать изображение на ядре .NET, например, WebP или перемещение GIF или многостраничный тиф или написание текста на изображении, и вы будете удивлены.
Примечание.
Начиная с .NET Core 2.0 существует System.Drawing.Common (NuGet), который содержит большую часть функциональных возможностей System.Drawing. Он должен быть более или менее полнофункциональным в .NET-Core 2.1. Тем не менее, System.Drawing.Common использует GDI +, и , следовательно , не будет работать на Azure (System.Drawing библиотеки доступны в Azure Cloud Service [ в основном только VM], но не в Azure Web App [ в основном виртуальный хостинг?])
Так Пока 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-библиотеки (что также может быть недостатком). Также обратите внимание, что хотя GDI + работает на Linux и Mac, это не значит, что он работает на iOS / Android.
Код, написанный не для .NET (не-Core), не переносится на .NET Core.
Это означает, что если вам нужна библиотека C # не из GPL, такая как PDFSharp, для создания PDF-документов (очень часто), вам не повезло(в данный момент)( больше нет ). Не берите в голову элемент управления ReportViewer, который использует Windows-pInvokes (для шифрования, создания документов mcdf через COM, а также для получения информации о шрифтах, символах, кернинге, встраивании шрифтов, измерении строк и переносе строк, а также для рисования символов приемлемого качества) и даже не работает на Mono в Linux
( я работаю над этим ).
Кроме того, код, написанный на .NET Core, не переносим в Mono, поскольку в Mono отсутствуют библиотеки времени выполнения .NET Core (пока).
Моя цель - использовать 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 дня) - вас предупредили. См. Также ссылки «не завершено» при измерении производительности Mono в тестах 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 Code, если вы можете построить ее на ARM (мне удалось это сделать - НЕ следуйте блог-сообщению Скотта Хансельмана, если вы это делаете - в вики VS-кода на github есть инструкция), потому что они не предлагают исполняемый файл.
Йоман тоже терпит неудачу. (Я полагаю, это как-то связано с установленной версией nodejs - VS Code требует одну версию, Yeoman - другую ... но она должна работать на том же компьютере. Довольно хромая.
Не берите в голову, что она должна работать на версии узла, поставляемой по умолчанию. в ОС.
Не берите в голову, что не должно быть никакой зависимости от 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 для своего приложения, чтобы обойти проблемы чувствительности к регистру (циклическое монтирование не рекомендуется в производстве).
Подводя итоги
В настоящее время (2016-09-28) я бы держался подальше от .NET Core (для производственного использования). Может быть, через один-два года вы можете взглянуть еще раз, но, вероятно, не раньше.
Если у вас есть новый веб-проект, который вы разрабатываете, запустите его в .NET Core, а не в моно.
Если вам нужна среда, работающая на Linux (x86 / AMD64 / ARMhf) и Windows и Mac, которая не имеет зависимостей, то есть только статическое связывание и не зависит от .NET, Java или Windows, используйте вместо этого Golang. Он более зрелый, и его производительность доказана (Baidu использует его с 1 миллионом одновременно работающих пользователей), а у golang значительно меньше памяти. Также golang находится в репозиториях, .deb устанавливается без проблем, исходный код компилируется - без внесения изменений - и golang (тем временем) имеет поддержку отладки с delve и JetBrainsGogland на Linux (и Windows и Mac). Процесс сборки Golang (и время выполнения) также не зависит от NodeJS, что является еще одним плюсом.
Что касается моно, держись подальше от него.
Не удивительно, насколько далеко продвинулась моно, но, к сожалению, это не заменит ее проблем производительности / масштабируемости и стабильности для производственных приложений.
Кроме того, моно-разработка довольно мертва, они в основном разрабатывают только части, относящиеся к Android и iOS, потому что именно там Xamarin делает свои деньги.
Не ожидайте, что веб-разработка будет первоклассным гражданином Xamarin / моно.
.NET Core может стоить того, если вы начинаете новый проект, но для существующих крупных проектов веб-форм перенос по большей части исключен, требуемые изменения огромны. Если у вас есть MVC-проект, количество изменений может быть управляемым, если ваш оригинальный дизайн приложения был вменяемым, что в большинстве случаев не относится к большинству существующих так называемых «исторически выросших» приложений.
Обновление за декабрь 2016:
встроенная компиляция была удалена из предварительного просмотра .NET Core, поскольку она еще не готова ...
Похоже, что они значительно улучшились в тесте необработанного текстового файла, но, с другой стороны, он стал довольно глючным. Кроме того, это еще больше ухудшилось в тестах JSON. Любопытно также, что структура сущностей должна быть быстрее для обновлений, чем Dapper, хотя и то и другое с рекордной медленностью. Это вряд ли будет правдой. Похоже, есть еще несколько ошибок, на которые нужно охотиться.
Кроме того, на фронте Linux IDE появляется облегчение.
JetBrains выпустила «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
Примечание. В соответствии с .NET Core 3 вы можете опубликовать все минимизированное в виде одного файла :
dotnet publish -r win-x64 -c Release /p:PublishSingleFile=true
dotnet publish -r linux-x64 -c Release /p:PublishSingleFile=true
Однако, в отличие от go, это не статически связанный исполняемый файл, а самораспаковывающийся zip-файл, поэтому при развертывании вы можете столкнуться с проблемами, особенно если временный каталог заблокирован групповой политикой, или некоторыми другими проблемами . Работает нормально для программы hello-world, хотя. И если вы не уменьшите, размер исполняемого файла будет около 100 МБ.
И вы получаете автономный .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 2.2+ поддерживает OpenSSL 1.1. Так что вы можете использовать его на Arch или (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 сейчас отсутствует (окончательная первоначальная версия), и есть поддержка WinForms и WPF, но только для C # (в Windows). Нет WinForms-Core-Designer . Дизайнер, в конце концов, придет с обновлением Visual Studio, когда-нибудь. Поддержка WinForms для VB.NET не поддерживается , но планируется для .NET 5.0 когда-нибудь в 2020 году .
PS:
echo "DOTNET_CLI_TELEMETRY_OPTOUT=1" >> /etc/environment
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 Debugger для MonoDevelop
Отказ от ответственности:
я не использую 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 также использует регулярные выражения для маршрутизации).
Когда я пишу о своем опыте с моно 2.x, 3.x и 4.x, это также не обязательно означает, что эти проблемы не были решены ни к настоящему времени, ни к тому времени, когда вы читаете это, ни к тому, если они Исправлено: теперь не может быть регрессии, которая вновь вводит какие-либо из этих ошибок / функций. Это также не означает, что если вы встраиваете моно-среду выполнения, вы получите те же результаты, что и при использовании моно-среды системы (dev). Это также не означает, что встраивание моно-среды (где угодно) обязательно бесплатно.
Все, что не обязательно означает, что моно не подходит для iOS или Android, или что у него есть те же проблемы там. Я не использую моно на Android или IOS, поэтому я не собираюсь ничего говорить о стабильности, удобстве использования, стоимости и производительности на этих платформах. Очевидно, что если вы используете .NET на Android, у вас есть и другие соображения, связанные с затратами, такие как взвешивание затрат xamarin и затрат и времени на перенос существующего кода на Java. Один слышит моно на Android, и IOS будет довольно хорошим. Возьми это с зерном соли. Во-первых, не ожидайте, что кодировка системы по умолчанию будет одинаковой на android / ios против Windows, и не ожидайте, что файловая система android будет нечувствительной к регистру, и не ожидайте присутствия каких-либо шрифтов Windows ,