Некромантування.
Надання фактичної відповіді.
Чим відрізняється .Net Core від Mono?
.NET Core зараз офіційно - це майбутнє .NET. Почалося це здебільшого з переписування рамкових та консольних програм ASP.NET MVC , до яких, звичайно, належать серверні програми. (Оскільки він є повним Turing і підтримує взаємодію з C dlls, ви можете, якщо ви абсолютно хотіли, також написати свої власні настільні програми з ним, наприклад, через сторонні бібліотеки, такі як Avalonia, які були дуже елементарними в той час, як я вперше писав це, а це означало, що ви значно обмежені в Інтернеті або сервері.) З часом до .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, а повна .NET Framework піде шляхом Dodo / Silverlight / WindowsPhone .
Основним моментом .NET Core, окрім підтримки на декількох платформах, є підвищення продуктивності та включення "нативної компіляції" / автономного розгортання (тому вам не потрібно .NET Framework / VM встановлювати на цільовій машині .
з одного боку, це означає docker.io підтримка на Linux, а з іншого, самодостатнім розгортанням корисно в «хмарні обчислення», так як тоді ви можете просто використовувати ту версію рамок DotNet-CORE ви хочете, і вам не потрібно турбуватися про те, яку версію (-ів) рамки .NET фактично встановлено sysadmin.
Хоча час виконання .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 немає форм-дизайнера: він постачається з оновленням 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, принаймні не останній раз, коли я перевіряв.
"Проект моно " набагато старший за .NET Core.
Моно є іспанською і означає Мавпа, і як побічне зауваження, назва не має нічого спільного з мононуклеозом (натяк: ви можете отримати список співробітників за адресою http://primates.ximian.com /).
Моно було започатковано у 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) і неприпустимо повільний (Регекс). Зверху набір інструментів Mono також працює на 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 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, тому що він використовує нативні бібліотеки (що також може бути недоліком). Також зауважте, що GDI + працює на Linux та Mac, це не означає, що він працює на iOS / Android.
Код, не написаний для .NET (не Core), не переноситься на .NET Core.
Значить, якщо ви хочете, щоб бібліотека, що не містить GPL C #, як PDFSharp, створювала PDF-документи (дуже звична), вам не пощастило(на даний момент)(вже не ). Не забувайте про контроль ReportViewer, який використовує Windows-pInvokes (для шифрування, створення mcdf документів за допомогою COM, а також для отримання шрифту, символів, кернінгу, вбудовування інформації в шрифт, вимірювання рядків і здійснення розбиття рядків, а також для фактичного малювання вирівнювань прийнятної якості) , і навіть не працює на Mono в Linux
( я працюю над цим ).
Крім того, код, написаний у .NET Core, не переноситься на Mono, оскільки Mono не має бібліотек виконання .NET Core (поки що).
Моя мета - використовувати C #, LINQ, EF7, візуальну студію для створення веб-сайту, який можна керувати / розміщувати в Linux.
EF у будь-якій версії, яку я намагався до цього часу, був настільки проклятим повільним (навіть у таких простих речах, як одна таблиця з одним лівим з’єднанням), я б не рекомендував її ніколи - не і в Windows.
Я б особливо не рекомендував EF, якщо у вас є база даних з унікальними обмеженнями, або varbinary / filestream / hierarchyid стовпцями. (Також не для оновлення схем.)
А також не в ситуації, коли продуктивність БД є критичною (скажімо, від 10+ до 100+ одночасних користувачів).
Також запуск веб-сайту / веб-додатку в Linux рано чи пізно означатиме, що вам доведеться налагоджувати його.
Немає підтримки налагодження .NET Core в Linux.(Більше, але вимагає JetBrains Rider.)
MonoDevelop не (ще) підтримує налагодження .NET Core проектів.
Якщо у вас є проблеми, ви самостійно. Вам доведеться використовувати обширний журнал.
Будьте уважні, радимо, що обширна реєстрація заповнить ваш диск за короткий час, особливо якщо програма переходить у нескінченний цикл або рекурсію.
Це особливо небезпечно, якщо ваш веб-додаток працює як root, тому що для входу потрібен простір logfile - якщо не залишилося вільного місця, ви більше не зможете увійти.
(Зазвичай, близько 5% дискового простору зарезервовано для кореневого користувача користувача (він же адміністратор у 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". Я також не знаю, що це означає.
Це означає, що він хоче використовувати високоефективний повнофункціональний веб-сервер на зразок nginx (Engine-X), можливо Apache.
Тоді він може запустити моно / dotnetCore з хостингом на основі віртуальних імен (декілька доменних імен на одному IP-адресі) та / або балансуванням завантаження. Він також може запускати інші веб-сайти з іншими технологіями, не вимагаючи іншого номера порту на веб-сервері. Це означає, що ваш веб-сайт працює на сервері fastcgi, а nginx пересилає всі веб-запити для певного домену через протокол 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 іншу ... але він повинен працювати на тому ж комп'ютері. Досить кульгавий
Неважливо, що він повинен працювати на версії вузла, що постачається за замовчуванням на ОС.
Не забувайте, що в першу чергу не повинно бути залежності від NodeJS.
Сервер kestell також працює.
І судячи з мого досвіду роботи з монопроектом, я дуже сумніваюся, що вони коли-небудь тестували .NET Core на FastCGI або що вони мають будь-яке уявлення, що означає підтримка FastCGI для їхньої бази, не кажучи вже про те, що вони перевірили її, щоб переконатися, що "все працює" ". Насправді я просто спробував зробити Fastcgi-додаток з .NET Core і щойно зрозумів, що немає. Бібліотека FastCGI для .NET Core "RTM" ...
Отже, коли ви збираєтеся запускати .NET Core "RTM" за nginx, ви можете це зробити, лише надіславши запити на kestrell (той напівфабрикатний nodeJS-похідний веб-сервер) - на даний момент у .NET Core немає підтримки fastcgi "RTM", AFAIK. Оскільки в бібліотеці .cct не є ядра fastcgi і немає зразків, також малоймовірно, що хтось зробив тестування на рамках, щоб переконатися, що fastcgi працює, як очікувалося.
Я також сумніваюся у виконанні.
У (попередньому) тестовому контрольному показнику (13 раунд) aspnetcore-linux займає 25% відносно найкращої продуктивності, тоді як порівнянні рамки, такі як Go (golang), займають 96,9% пікової продуктивності (і це при поверненні простого тексту без файлу -системний доступ лише). .NET Core трохи краще підходить до JSON-серіалізації, але він також не виглядає переконливим (піти досягає 98,5% піку, .NET core 65%). Однак це не може бути гірше, ніж "моно належним".
Крім того, оскільки це все ще відносно нове, не всі основні бібліотеки були перенесені (поки що), і я сумніваюся, що деякі з них коли-небудь будуть перенесені.
Підтримка зображень також в кращому випадку сумнівна.
Для будь-якого шифрування використовуйте BouncyCastle замість цього.
Чи можете ви допомогти мені осмислити всі ці терміни і якщо мої очікування реалістичні ?
Я сподіваюся, що я допоміг вам зробити більше сенсу з усіма цими умовами.
Що стосується ваших очікувань:
розробка додатка Linux, не знаючи нічого про Linux, в першу чергу є справді дурною ідеєю, і вона також так чи інакше може зазнати краху. Однак це означає, що оскільки Linux не вимагає ліцензійних витрат, це в принципі хороша ідея, АЛЕ ТОЛЬКО ЯКЩО ВИ ЗНАЄМО, ЩО РОБИТИ.
Розробка програми для платформи, де ви не можете налагоджувати свою програму, - це ще одна дуже погана ідея.
Розробка для fastcgi, не знаючи, які наслідки є, є ще однією дійсно поганою ідеєю.
Робити всі ці речі на "експериментальній" платформі без будь-якого знання специфіки цієї платформи та без підтримки налагодження - це самогубство, якщо ваш проект є не лише особистою домашньою сторінкою. З іншого боку, я думаю, що це зробити з вашою особистою домашньою сторінкою для навчальних цілей, можливо, було б дуже хорошим досвідом - тоді ви дізнаєтесь, що таке рамки та які не рамкові проблеми.
Ви можете, наприклад, (програматично) вмонтувати в петлю нечутливий до регістру жир32, hfs або JFS для вашої програми, щоб усунути проблеми чутливості до регістру (монтування циклу не рекомендується у виробництві).
Підводячи підсумок
На даний момент (2016-09-28) я б тримався осторонь .NET Core (для використання у виробництві). Можливо, через один-два роки ви можете поглянути ще раз, але, мабуть, не раніше.
Якщо у вас є новий веб-проект, який ви розробляєте, запустіть його в .NET Core, а не моно.
Якщо ви хочете, щоб фреймворк, який працює в Linux (x86 / AMD64 / ARMhf) та Windows і Mac, не має залежностей, тобто лише статичне посилання та відсутність .NET, Java чи Windows, використовуйте Golang замість цього. Він більш зрілий, і його продуктивність доведена (Baidu використовує його з 1 мільйоном одночасних користувачів), і golang має значно менший слід пам’яті. Також golang є у сховищах.Gogland в Linux (і Windows і Mac). Процес (і час виконання) Golang також не залежить від NodeJS, що є ще одним плюсом.
Що стосується моно, тримайтеся подалі від нього.
Не дивовижно, як далеко дійшло моно, але, на жаль, це не замінює його продуктивності / масштабованості та стабільності для виробничих застосувань.
Крім того, моно-розробка досить мертва, вони значною мірою розробляють лише ті частини, які вже стосуються Android та iOS, адже саме там Xamarin заробляє свої гроші.
Не чекайте, що веб-розробка стане першокласним громадянином Xamarin / mono.
.NET Core, можливо, того вартує, якщо ви запускаєте новий проект, але для існуючих великих проектів веб-форм перенесення даних багато в чому не підлягає сумніву, необхідні зміни величезні. Якщо у вас є проект MVC, кількість змін може бути керованою, якби ваша оригінальна програма додатків була розумною, що, як правило, не стосується більшості існуючих так званих "історично вирощених" додатків.
Оновлення грудня 2016 року:
Рідна компіляція була вилучена з попереднього перегляду .NET Core, оскільки вона ще не готова ...
Схоже, вони сильно покращилися на сировинному орієнтирі текстових файлів, але, з іншого боку, він став досить баггі. Крім того, він ще більше погіршився у показниках JSON. Цікаво також, що структура суті буде швидшою для оновлень, ніж Dapper, хоча і те, і інше на рекордному рівні. Це дуже навряд чи буде правдою. Схоже, на полювання ще є лише кілька помилок.
Крім того, схоже, полегшення з'явиться на фронті Linux IDE.
JetBrains випустив "Project Rider", попередній перегляд доступу до C # /. NET Core IDE для Linux (і Mac та Windows), який може обробляти файли Visual Studio Project. Нарешті, C # IDE, який є корисним і не повільним, як пекло.
Висновок: .NET Core все-таки є програмним забезпеченням для якості попереднього випуску, коли ми рухаємось у 2017 році. Перекладіть свої бібліотеки, але тримайтеся подалі від нього для використання у виробництві, поки якість якості не стабілізується.
І слідкуйте за Project Rider.
Оновлення 2017 На даний момент
перенесено домашню сторінку мого (брата) на .NET Core.
Поки здається, що час роботи в Linux є досить стабільним (принаймні, для невеликих проектів) - він легко пережив тест навантаження - моно ніколи цього не робив.
Крім того, схоже, я змішав розширення .NET-Core і .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, це не статично пов’язаний виконуваний файл, а саморозпаковується поштовий файл, тому при розгортанні ви можете зіткнутися з проблемами, особливо якщо темп-каталог заблоковано груповою політикою чи деякими іншими проблемами . Хоча чудово працює для привітної програми світу. І якщо ви не мінімізуєте, розмір виконавчого файлу матиме приблизно 100 МБ.
І ви отримуєте автономний .exe-файл (у каталозі публікацій), який ви можете перенести на машину Windows 8.1 без встановленої .NET Framework та дозволити її працювати. Приємно. Саме тут 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 ще не перенесений. Це погано, бо це означає, що для мого кластера IoT Cassandra не підтримується SparkSQL, тому не приєднується ...
Експериментальна підтримка 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, і вони, мабуть, виправлення лише в v2.1, відсутність виправлення помилок для 2.0).
Але я не встановлюю попередні випуски на свою машину. Тож чекаємо.
Версія v2.1 також значно скорочує час компіляції. Це було б добре.
Також зауважте, що в Linux, .NET Core 64-бітний !
Немає, і не буде, версія x86-32 .NET Core в Linux .
А порт ARM - лише ARM-32. АРМ-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 використовуватиме API-Windows.
Примітка:
.NET Core 3.0 зараз вийшов (RTM), є підтримка 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 збирають дані про використання з метою покращення вашого досвіду.
Дані є анонімними та не включають аргументи командного рядка.
Дані збираються корпорацією Майкрософт та передаються спільноті.
Ви можете відмовитися від телеметрії, встановивши змінну середовища DOTNET_CLI_TELEMETRY_OPTOUT на 1 за допомогою улюбленої оболонки.
Ви можете прочитати більше про телеметричні інструменти .NET Core @
https://aka.ms/dotnet-cli-telemetry .
Я подумав згадати, що я думаю, що монодевелоп (він же Xamarin Studio, Mono IDE або Visual Studio Mac, як його зараз називають на Mac) розвивався досить приємно, і тим часом - значною мірою придатний для використання.
Однак JetBrains Rider (2018 EAP на даний момент часу), безумовно, набагато приємніший і надійніший (а включений декомпілятор є безпечнішим для життя), тобто якщо ви розробляєте .NET-Core на Linux або Mac. MonoDevelop не підтримує Debug-StepThrough на Linux у .NET Core, оскільки MS не ліцензує їх API налагодження API (за винятком VisualStudio Mac ...). Однак ви можете використовувати налагоджувач Samsung для .NET Core через розширення відладчика .NET Core для відладчика Samsung для MonoDevelop
Відмова від відповідальності:
я не використовую Mac, тому не можу сказати, чи те, що я написав тут, стосується і Mac на базі FreeBSD-Unix. Я переглядаю версію JetBrains Rider для Linux (Debian / Ubuntu / Mint), моно, MonoDevelop / VisualStudioMac / XamarinStudio та .NET-Core. Крім того, Apple розглядає можливість переходу від процесорів Intel до самостійно виготовлених процесорів ARM (ARM-64?), Тому значна частина того, що зараз стосується Mac, може не стосуватися Mac у майбутньому (2020+).
Крім того, коли я пишу "моно досить нестабільно і повільно", нестабільний стосується програм WinFroms & WebForms, зокрема виконання веб-додатків через fastcgi або з XSP (на версії 4.x моно), а також XML-серіалізації - особливості керування, і досить повільний стосується WinForms, зокрема регулярних виразів (ASP.NET-MVC також використовує регулярні вирази для маршрутизації).
Коли я пишу про свій досвід щодо моно 2.x, 3.x і 4.x, це також не означає, що ці проблеми не вирішені до цього часу, або до того часу, коли ви це читаєте, а також якщо вони є Виправлено, що пізніше не може бути регресії, яка б вводила будь-який з цих помилок / функцій. Це також не означає, що якщо ви вбудовуєте моно-час виконання, ви отримаєте ті самі результати, що і при використанні моно-режиму виконання (dev) системи. Це також не означає, що вбудовування моно-режиму виконання (де завгодно) є необхідним безкоштовно.
Все, що не означає, що моно не підходить для iOS або Android, або що там є ті самі проблеми. Я не використовую моно на Android або IOS, тому не можу нічого говорити про стабільність, зручність використання, витрати та продуктивність на цих платформах. Очевидно, що якщо ви користуєтесь .NET на Android, у вас є також інші міркування щодо витрат, такі як зважування xamarin-витрат порівняно з витратами та часом перенесення існуючого коду на Java. Один чує моно на Android та IOS, це буде дуже добре. Візьміть його з зерном солі. Для одного, не очікуйте, що кодування системи за замовчуванням буде однаковим для android / ios vs. Windows, і не очікуйте, що файлова система Android буде нечутливою до регістру, і не очікуйте, що будь-які шрифти Windows будуть присутніми .