ネクロマンシング。
実際の答えを提供します。
.Net CoreとMonoの違いは何ですか？
.NET Coreは、公式には.NETの未来です。ASP.NET MVCフレームワークとサーバーアプリケーションを含むコンソールアプリケーションの書き直しから始まりました。（それはチューリング完全であり、C dllとの相互運用性をサポートしているので、絶対に望めば、たとえばAvaloniaのようなサードパーティライブラリを介して独自のデスクトップアプリケーションを作成することもできます、これは私が最初にこれを書いた時点では非常に基本的でした。つまり、Webやサーバーに限定されていました。）時間の経過とともに、多くのAPIが.NET Coreに追加され、バージョン3.1以降、 .NET Coreはバージョン5.0にジャンプし、「コア」なしの.NET 5.0として知られています。それが.NET Frameworkの未来です。以前は完全な.NET Frameworkであったものが、メンテナンスモードで数十年もの間、完全な.NET Framework 4.8.xとして存続します。言い換えれば、.NET Coreは.NETの未来であり、完全な.NET FrameworkはDodo / Silverlight / WindowsPhoneの道を行くでしょう。
.NET Coreの主なポイントは、マルチプラットフォームサポートとは別に、パフォーマンスを向上させ、「ネイティブコンパイル」/自己完結型デプロイメントを有効にすることです（したがって、ターゲットマシンに.NET Framework / VMをインストールする必要はありません） 。
これは、一方ではLinuxでのdocker.ioサポートを意味し、もう一方では「クラウドコンピューティング」で自己完結型のデプロイメントが便利です。これにより、好きなバージョンのdotnet-COREフレームワークを使用できます。また、sysadminが実際にインストールした.NETフレームワークのバージョンについて心配する必要はありません。
.NET Coreランタイムは複数のオペレーティングシステムとプロセッサをサポートしていますが、SDKは別の話です。また、SDKは複数のOSをサポートしていますが、SDKに対するARMのサポートは現在も進行中です。.NET CoreはMicrosoftによってサポートされています。Dotnet-Coreには、WinFormsやWPFなどは付属していません。
- バージョン3.0以降、WinFormsとWPFは.NET Coreでもサポートされていますが、WindowsとC＃でのみサポートされています。VB.NETによるものではありません（VB.NETのサポートは2020年にv5で計画されています）。また、.NET CoreにはForms Designerはありません。VisualStudioの更新と共に、不特定の時期に出荷されます。
- WebFormsはまだ.NET Coreでサポートされておらず、サポートする予定もありません（Brazorはそのための新しい町です）。
- .NET Coreには、mscorelibに代わるSystem.Runtimeも付属しています。
- 多くの場合、.NET CoreはSystem.Runtime / mscorelib（およびその他いくつか）のラッパーのビットであるNetStandardと混同され、.NET Core、完全な.NET Framework、およびXamarin（iOS / Android）、すべて同時に。
- .NET Core SDKは、少なくとも前回チェックしたときではなく、ARMでは機能しませんでした。
「The Mono Project」は.NET Coreよりもはるかに古いものです。
Monoはスペイン語で、Monkeyを意味します。副次的なコメントとして、名前は単核球症とは関係ありません（ヒント：http://primates.ximian.com / でスタッフのリストを取得できます）。
Monoは、Linux用の.NET Framework（Ximian / SuSe / Novell）の実装として、2005年にMiguel de Icaza（GNOMEを始めた人とその他数人）によって開始されました。Monoには、Webフォーム、Winforms、MVC、オリーブ、MonoDevelopと呼ばれるIDEが含まれています（Xamarin StudioまたはVisual Studio Macとも呼ばれます）。基本的には（OpenJDK）JVMおよび（OpenJDK）JDK / JRE（SUN / Oracle JDKとは対照的）に相当します。これを使用して、ASP.NET-WebForms + WinForms + ASP.NET-MVCアプリケーションをLinuxで動作させることができます。
Monoは、Microsoftではなく、Xamarin（Linux市場ではなく、モバイル市場に焦点を当てたときのXimianの新しい会社名）によってサポートされています。
（XamarinはMicrosoftによって購入されたため、技術的には（ただし文化的には）Microsoftです。）
通常、C＃のものはモノラルでコンパイルできますが、VB.NETのものはコンパイルできません。
MonoはWSE / WCFやWebPartsのようないくつかの高度な機能を見逃しています。
Mono実装の多くは不完全である（たとえば、ECDSA暗号化でNotImplementedExceptionをスローする）、バグがある（たとえば、Firebirdを使用したODBC / ADO.NET）、. NET（たとえば、XMLシリアル化）とは異なる動作をするか、その他の不安定な（ASP.NET MVC）許容できないほど遅い（正規表現）。利点として、MonoツールチェーンはARMでも動作します。
.NET Coreに関する限り、クロスプラットフォームと言っても、ElasticSearchの場合と同様に、クロスプラットフォームがARM-Linuxに.NET Coreを実際にapt-getでインストールできることを期待しないでください。フレームワーク全体をソースからコンパイルする必要があります。
つまり、その容量がある場合（合計HDが16〜32 GBのChromebookなど）。
また、以前はOpenSSL 1.1およびlibcurlとの非互換性の問題がありました。
これらは、.NET Coreバージョン2.2の最新バージョンで修正されています。
クロスプラットフォームについてはこれで終わりです。
公式サイトで、「そのために書かれたコードは、Monoなどのアプリケーションスタック間でも移植可能」という声明を見つけました。
そのコードがWinAPI呼び出し、Windows-dll-pinvokes、COM-Components、大文字と小文字を区別しないファイルシステム、default-system-encoding（コードページ）に依存せず、ディレクトリセパレーターの問題がない限り、それは正しい。ただし、.NET CoreコードはMonoではなく.NET Coreで実行されます。したがって、2つを混合することは困難です。また、Monoは（Webアプリケーションの場合）非常に不安定で低速であるため、とにかくお勧めしません。.NETコアで画像処理を試してください。たとえば、WebPやGIFやmultipage-tiffを移動したり、画像にテキストを書き込んだりすると、きっと驚くでしょう。
注：
.NET Core 2.0以降、System.Drawingのほとんどの機能を含むSystem.Drawing.Common（NuGet）があります。.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年2月中旬には、イメージングにスキアシャープを使用できました（例）（まだ使用できます）。
.net-core 2.0を投稿すると、SixLabors ImageSharpSystem.Drawingは必ずしも安全ではなく、多くの潜在的または実際のメモリリークがあるため、WebアプリケーションでGDIを使用しないでください。ネイティブライブラリを使用するため、SkiaSharpはImageSharpよりもはるかに高速であることに注意してください（これも欠点になる可能性があります）。また、GDI +はLinuxとMacで動作しますが、iOS / Androidで動作するとは限りません。
.NET（非コア）用に書かれていないコードは、.NETコアに移植できません。
つまり、PDFSharpのようなGPL以外のC＃ライブラリでPDFドキュメントを作成する（ごくありふれた）場合は、運が悪い（現時点では）（もうありません）。Windows-pInvokesを使用するReportViewerコントロールを気にしないでください（COMを介して暗号化、mcdfドキュメントを作成し、フォント、文字、カーニング、フォント埋め込み情報を取得し、文字列を測定して改行し、実際に許容できる品質のティフを描画します）。 、LinuxのMonoでも動作しません
（私はそれに取り組んでいます）。
また、.NET Coreで記述されたコードはMonoに移植できません。これは、Monoには.NET Coreランタイムライブラリ（これまでのところ）がないためです。
私の目標は、C＃、LINQ、EF7、ビジュアルスタジオを使用して、Linuxで実行/ホストできるWebサイトを作成することです。
これまでに試したバージョンのEFは非常に遅い（1つの左結合を持つ1つのテーブルのような単純なものでも）ので、Windowsではなく、お勧めしません。
一意の制約、またはvarbinary / filestream / hierarchyid列を持つデータベースがある場合は、EFを特にお勧めしません。（schema-updateの場合
も同様です。）また、DBパフォーマンスが重要な状況（たとえば、10 +から100+の同時ユーザー）ではありません。
また、LinuxでWebサイト/ Webアプリケーションを実行すると、遅かれ早かれデバッグする必要があります。
Linuxでは.NET Coreのデバッグサポートはありません。（もうありませんが、JetBrains Riderが必要です。）
MonoDevelopは.NET Coreプロジェクトのデバッグを（まだ）サポートしていません。
あなたが問題を抱えているなら、あなたは一人でいます。広範なロギングを使用する必要があります。
特にプログラムが無限ループまたは再帰に入る場合は、大規模なロギングによってすぐにディスクがいっぱいになることに注意してください。
ログインはlogfile-spaceを必要とするため、Webアプリがrootとして実行されている場合、これは特に危険です。空き容量が残っていない場合、ログインできなくなります。
（通常、ディスクスペースの約5％はユーザーroot [別名Windowsの管理者]用に予約されているため、少なくともディスクがほぼいっぱいであれば、管理者はログインできます。ただし、アプリケーションがrootとして実行されている場合、その制限は適用されません。それらのディスク使用量、およびログファイルが残りの空き領域の100％を使用できるようにするため、管理者でさえもログインできなくなります。）
したがって、そのディスクを暗号化しない方がいいです。つまり、データ/システムを重視する場合です。
「モノラル」にしたいと誰かが言ったが、それが何を意味するのか私にはわからない。
これは、.NET Coreを使用したくないか、Linux / MacでC＃を使用したいだけのどちらかです。私の推測では、彼はLinux上のWebアプリにC＃を使用したいと考えているだけです。.NET Coreは、C＃で実行したい場合に最適です。「モノプロパー」ではいけません。表面的には、最初は機能しているように見えますが、MonoのASP.NET MVCは、サーバーが長期間（1日より長く）実行されると安定しないため、後悔するでしょう-これで警告が表示されました。techempowerベンチマークでMonoのパフォーマンスを測定する場合は、「完全ではなかった」リファレンスも参照してください。
上記のテクノロジーで.Net Core 1.0フレームワークを使用したいことはわかっています。また、「fast cgi」を使用したいと述べました。それが何を意味するのかもわかりません。
それは彼がnginx（Engine-X）のような高性能のフル機能のWebサーバー、おそらくApacheを使いたいということを意味します。
その後、仮想名ベースのホスティング（同じIP上の複数のドメイン名）や負荷分散を使用して、mono / dotnetCoreを実行できます。彼はまた、Webサーバーで別のポート番号を必要とせずに、他のテクノロジで他のWebサイトを実行することもできます。これは、ウェブサイトがfastcgiサーバーで実行され、nginxがfastcgiプロトコルを介して特定のドメインに対するすべてのウェブリクエストをそのサーバーに転送することを意味します。これは、ウェブサイトがfastcgi-pipelineで実行されていることも意味します。たとえば、ファイルを転送するときにHTTP 1.1を使用できないなど、操作には注意が必要です。
そうしないと、宛先でファイルが文字化けします。こちらとこちら
もご覧ください。
結論として：
現在（.net-2016-09-28）の.NET Coreは実際には移植可能ではなく、クロスプラットフォーム（特にデバッグツール）でもありません。
特にARMの場合、ネイティブコンパイルも簡単ではありません。
そして、私にとっても、その開発が「本当に終わった」ようには見えません。
たとえば、System.Data.DataTable / DataAdaper.Updateがありません...
（.NET Core 2.0ではもうありません）
System.Data.Common.IDB *インターフェイスと一緒に。（.NET Core 1.1ではもうありません）
頻繁に使用されるクラスが1つあった場合、DataTable / DataAdapterはそれです...
また、少なくとも私のマシンでは、Linuxインストーラー（.deb）が失敗します。その問題を抱えているのは私だけではない。
ARMでビルドできる場合は、おそらくVisual Studio Codeを使用してデバッグします（私はなんとかできました- スコットハンセルマンのブログの投稿には従わないでください -githubのVS-Codeのwikiにハウツーがあります）。実行可能ファイルは提供されません。
ヨーマンも失敗します。（インストールしたnodejsのバージョンと関係があると思います-VS Codeには1つのバージョンとYeomanが必要です...しかし、同じコンピューターで実行する必要があります。かなりラメ
デフォルトで出荷されているノードバージョンで実行する必要はありません。OS上で。
そもそもNodeJSに依存してはならないことを気にしないでください。
kestellサーバーも進行中です。
そして、私のモノプロジェクトでの経験から判断すると、FastCGIで.NET Coreをテストしたことがないか、またはFastCGIサポートがフレームワークに何を意味するのか、そしてすべてをテストして「すべてが機能する」 」実際、.NET Coreでfastcgiアプリケーションを作成しようとしたところ、.NET Core "RTM"用のFastCGIライブラリがないことに気づきました...
したがって、nginxの背後で.NET Core "RTM"を実行する場合、ケストレル（その半完成のnodeJS派生Webサーバー）へのプロキシリクエストによってのみ実行できます。現在、.NET Coreにはfastcgiのサポートはありません。 「RTM」、AFAIK。.netコアfastcgiライブラリーもサンプルもないため、fastcgiが期待どおりに動作することを確認するためにフレームワークでテストを行った人はほとんどいないでしょう。
パフォーマンスにも疑問があります。
中（仮）techempower-ベンチマーク（ラウンド13） 、最高のパフォーマンスを25％の相対的な上aspnetcore-Linuxのランク、しばらく同等のピーク性能の96.9パーセントでゴー（golang）ランクのようなフレームワーク（およびファイルなしで平文を返すときには、 -システムアクセスのみ）。.NET CoreはJSONシリアライゼーションを少し改善しますが、説得力もありません（ピーク時の98.5％、. NET Core 65％に達します）。とはいえ、「モノプロパー」よりも悪くなることはありません。
また、まだ比較的新しいので、すべての主要ライブラリが（まだ）移植されているわけではなく、それらの一部が移植されることはないと思います。
画像処理のサポートにも問題があります。
暗号化については、代わりにBouncyCastleを使用してください。
これらすべての用語を理解するのを手伝ってくれませんか、そして私の期待が現実的かどうか教えてください。
私はあなたがこれらすべての用語をもっと理解するのを手伝ってくれることを願っています。
限り、あなたのexpecationsが行くように：
Linuxについて何も知らなくても、Linuxアプリケーションを開発する最初の場所で、本当に愚かな考えである、そしてまた、いくつかの恐ろしい方法一つの方法または他に必ず失敗するです。そうは言っても、Linuxにはライセンス費用がかからないので、原則的には良い考えですが、あなたが 何をしているのかを知っている場合に限ってください。
アプリケーションをデバッグできないプラットフォーム向けのアプリケーションを開発することは、別の本当に悪い考えです。
どんな影響があるのかを知らずにfastcgi向けに開発することは、もう1つの本当に悪い考えです。
プロジェクトが単なる個人のホームページではない場合、「実験的」プラットフォームでこれらのすべてを、そのプラットフォームの詳細を知らず、デバッグサポートなしで行うことは自殺です。一方、学習目的で個人のホームページを使用すると、おそらく非常に良い経験になると思います。それで、フレームワークとフレームワーク以外の問題が何であるかを知ることができます。
たとえば、プログラムで大文字と小文字を区別しないfat32、hfs、またはJFSをループマウントして、大文字と小文字の区別に関する問題を回避できます（本番環境ではループマウントは推奨されません）。
要約すると、
現時点（2016-09-28）では、.NET Core（本番環境での使用）は避けます。おそらく1〜2年で、別の見方をすることができますが、おそらく以前はそうではありません。
開発する新しいWebプロジェクトがある場合は、モノではなく.NET Coreで開始します。
Linux（x86 / AMD64 / ARMhf）およびWindowsおよびMacで動作するフレームワークが必要な場合、依存関係はありません。つまり、静的リンクのみで、.NET、Java、またはWindowsへの依存関係はありません。代わりにGolangを使用してください。より成熟しており、そのパフォーマンスは証明されており（Baiduは100万人の同時ユーザーで使用しています）、golangのメモリフットプリントは大幅に低くなっています。また、golangはリポジトリにあり、.debは問題なくインストールされ、ソースコードは（変更を必要とせずに）コンパイルされ、golang（当面）はdelveおよびJetBrainsでデバッグをサポートしています。Linux（およびWindowsとMac）上のGogland。Golangのビルドプロセス（およびランタイム）もNodeJSに依存していません。
モノに関しては、近づかないでください。
モノがどれほど進歩したかは驚くべきことではありませんが、残念ながら、それは本番アプリケーションのパフォーマンス/スケーラビリティと安定性の問題に代わるものではありません。
また、モノ開発は完全に死んでいます。Xamarinが収益を上げているのは、AndroidとiOSに関連する部分のみを開発しているためです。
Web開発が一流のXamarin / Mono市民であるとは期待しないでください。
.NET Coreは価値があるかもしれませんが、新しいプロジェクトを開始する場合、既存の大規模なWebフォームプロジェクトの場合、移植はほとんど問題外であり、必要な変更は膨大です。MVCプロジェクトがある場合、元のアプリケーション設計が適切であれば、変更の量は管理可能かもしれません。これは、ほとんどの既存のいわゆる「歴史的に成長した」アプリケーションには当てはまりません。
2016年12月の更新：
ネイティブコンパイルは.NET Coreプレビューから削除されました。まだ準備ができていないためです...
生のテキストファイルベンチマークではかなり改善されているようですが、一方でかなりバグがあります。また、JSONベンチマークではさらに悪化しました。また、エンティティフレームワークはDapperよりも更新が高速であることにも興味があります。これが本当である可能性は非常に低いです。ハントするバグはまだいくつかあるようです。
また、Linux IDEの前面には安心感があるようです。
JetBrainsは、Visual Studioプロジェクトファイルを処理できるLinux（およびMacとWindows）用のC＃/。NET Core IDEの早期アクセスプレビューである「Project Rider」をリリースしました。最後に、使用可能で地獄ほど遅くないC＃IDEです。
結論：2017年に入ると、.NET Coreはまだプレリリース品質のソフトウェアです。ライブラリを移植しますが、フレームワークの品質が安定するまで、本番環境で使用しないでください。
プロジェクトライダーにも注目してください。
2017年の更新現在
、私の（弟の）ホームページを.NET Coreに移行しています。
これまでのところ、Linuxのランタイムは（少なくとも小規模なプロジェクトでは）十分に安定しているようです。負荷テストは簡単に成功しました。monoはそうではありませんでした。
また、.NET-Core-nativeと.NET-Core-self-contained-deploymentを混在させているようです。自己完結型のデプロイメントは機能しますが、それは非常に簡単です（ビルド/パブリッシュツールは少し不安定ですが、「正の数が必要です。-ビルドが失敗しました。」-同じコマンドをもう一度実行してください）そしてそれは動作します）。
あなたは走ることができます
dotnet restore -r win81-x64
dotnet build -r win81-x64
dotnet publish -f netcoreapp1.1 -c Release -r win81-x64
注：.NET Core 3 に従って、縮小されたすべてのものを1 つのファイルとして公開できます。
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 MBになります。
そして、（publishディレクトリにある）自己完結型の.exeファイルを取得します。これは、.NETフレームワークがインストールされていないWindows 8.1マシンに移動して実行できます。いいね。dotNET-Coreが面白くなり始めたのはここです。（ギャップを気にしてください、SkiaSharp はWindows 8.1 / Windows Server 2012 R2では動作しません、[まだ]-エコシステムが最初に追いつく必要があります-しかし興味深いことに、Skia-dll-load-failはサーバー全体をクラッシュさせません/アプリケーション-したがって、他のすべてが機能します）
（注：Windows 8.1のSkiaSharpには、適切なVCランタイムファイル-msvcp140.dllおよびvcruntime140.dllがありません。それらをpublish-directoryにコピーしてください。SkiaはWindows 8.1で動作します。）
2017年8月アップデート
.NET Core 2.0がリリースされました。
注意してください-認証に（大幅な互換性のない）変更が付属しています...
利点として、DataTable / DataAdaper / DataSetクラスなどが復活しました。Mobiusはまだ移植されていない
ため、実現された.NET CoreにはまだApache SparkSQLのサポートがありません。それは悪いことです。つまり、IoT Cassandraクラスターに対するSparkSQLサポートがないため、参加できません...
実験的なARMサポート（実行時のみ、SDKではない-私のChromebookでの開発にはあまりにも悪い-2.1または3.0を楽しみにしています）。PdfSharpは、実験的に.NET Coreに移植されました。JetBrainsライダー
左EAP。これで、Linuxでの.NET Coreの開発とデバッグに使用できます。ただし、これまでのところ、.NET Core 2.0サポートのアップデートが公開されるまでは、.NET Core 1.1のみです。
2018年5月の
.NET Core 2.1リリースの差し迫った更新。多分これはLinuxのNTLM認証を修正するでしょう（NTLM認証はLinuxで（そしておそらくMac}で.NET-Core 2.0で動作しません）。通常はms-exchangeで送信されるnegotiateなどの複数の認証ヘッダーがあり、それらは明らかにv2.1でのみ修正され、2.0のバグ修正リリースはありません。
しかし、私は自分のマシンにプレビューリリースをインストールしていません。待ってます。
v2.1は、コンパイル時間を大幅に削減するとも言われています。それが良いでしょう。
また、Linuxでは、.NET Coreは64ビットのみです。
Linuxには.NET Coreのx86-32バージョンはなく、今後もありません。
また、ARMポートはARM-32のみです。ARM-64はまだありません。
そしてARMでは、（現時点では）ランタイムしかなく、dotnet-SDKはありません。
そしてもう1つ：
.NET-CoreはOpenSSL 1.0を使用しているため、Linux上の.NET CoreはArch Linuxでは実行できません。また、派生によってManjaro（現時点で最も人気のあるLinuxディストリビューション）では実行できません。 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はWindows-APIを使用するため、WinFormsおよびWPFは.NET Coreですが、.NET-Core内のWinFormsおよびWPFは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 tools telemetry @ https://aka.ms/dotnet-cli-telemetryについて詳しく読むことができ
ます。
私は、monodevelop（別名Xamarin Studio、Mono IDE、またはVisual Studio MacがMacで呼ばれるようになった）は非常にうまく進化し、その間、大部分は使用可能だと思います。
ただし、JetBrains Rider（現時点での2018 EAP）は、はるかに優れており、信頼性が高い（そして、含まれている逆コンパイラはライフセーフです）。つまり、LinuxまたはMacで.NET-Coreを開発した場合です。ただし、MSはデバッグAPI dllのライセンスを取得していないため（VisualStudio Macを除く...）、MonoDevelopは.NET CoreのLinuxでのDebug-StepThroughをサポートしていません。ただし、使用することができ、.NETのコアのためのサムスンのデバッガを経由MonoDevelopのためのサムスンデバッガのための.NETのコアのデバッガ拡張機能
免責事項：
私はMacを使用していないので、ここで書いた内容がFreeBSD-UnixベースのMacにも当てはまるかどうかはわかりません。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バージョン上）を使用したWebアプリケーションの実行、およびXMLシリアル化に関係します。 -処理の特殊性、およびかなり遅いWinForms、特に正規表現に関連しています（ASP.NET-MVCはルーティングにも正規表現を使用します）。
モノ2.x、3.x、4.xに関する私の経験について書いているとき、それは必ずしもこれらの問題が現在、またはあなたがこれを読んでいる時点でも解決されていないことを意味するわけではありません。これらのバグ/機能のいずれかを再導入する後退が発生しないように修正しました。また、mono-runtimeを埋め込むと、（dev）システムのmonoランタイムを使用した場合と同じ結果が得られるという意味でもありません。また、モノランタイム（どこでも）の埋め込みが必ずしも無料であるという意味ではありません。
必ずしもモノがiOSやAndroidに不適切である、または同じ問題があることを必ずしも意味しません。私はAndroidやIOSでモノを使用していません。そのため、これらのプラットフォームでの安定性、使いやすさ、コスト、パフォーマンスについては何も言っていません。もちろん、Androidで.NETを使用する場合は、既存のコードをJavaに移植するためのコストと時間に対するxamarinのコストの重み付けなど、他にもいくつかのコストに関する考慮事項があります。Androidでモノラルと聞いて、IOSはかなり良いものになるでしょう。一粒の塩と一緒に服用してください。1つは、default-system-encodingがandroid / iosとWindowsで同じであることを期待しないでください。また、androidファイルシステムで大文字と小文字が区別されないことを期待しないでください。また、Windowsフォントが存在することを期待しないでください。 。