.NET Core vs Mono 質問する

.Net Core と Mono の違いは何ですか?

.NET Core は今や公式に .NET の未来です。その大半はASP.NET MVCフレームワークとコンソール アプリケーション (もちろんサーバー アプリケーションも含む) の書き直しから始まりました。(チューリング完全で C DLL との相互運用性をサポートしているため、どうしても必要な場合は、たとえばサードパーティ ライブラリなどを使用して独自のデスクトップ アプリケーションを作成することもできます。アヴァロニア、これは私がこれを最初に書いた当時はかなり基本的なもので、Web やサーバーのものに限定されていました。) 時間の経過とともに、多くの API が .NET Core に追加され、バージョン 3.1 の後、.NET Core はバージョン 5.0 にジャンプし、「Core」なしの .NET 5.0 として知られるようになり、それが .NET Framework の将来になります。以前は完全な .NET Framework だったものは、メンテナンス モードで完全な .NET Framework 4.8.x として数十年にわたって残り、その後廃止されます (アップグレードはまだあるかもしれませんが、私はそうは思いません)。言い換えれば、.NET Coreは.NETの未来であり、Full .NET FrameworkはDodo/Silverlight/WindowsPhoneと同じ道をたどることになる。。

.NET Core の主なポイントは、マルチプラットフォームのサポートとは別に、パフォーマンスの向上と、「ネイティブ コンパイル」/自己完結型デプロイメント (ターゲット マシンに .NET Framework/VM がインストールされている必要がない) を可能にすることです。
一方では、これは Linux での docker.io サポートを意味し、他方では、自己完結型デプロイメントは「クラウド コンピューティング」で役立ちます。なぜなら、その場合、dotnet-CORE フレームワークの任意のバージョンを使用でき、システム管理者が実際にインストールした .NET Framework のバージョンを気にする必要がないためです。

.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 にはフォーム デザイナーがありません。これは、Visual Studio の更新プログラムとともに、後で未定の時期に出荷される予定です。
• WebForms は .NET Core ではまだサポートされておらず、今後もサポートする予定はありません(ブレザー（その意味では町に来た新参者です）。
• .NET Core には、mscorelib に代わる System.Runtime も付属しています。
• .NET Coreは、多くの場合、ネットスタンダードこれは、System.Runtime/mscorelib (およびその他) のラッパーのようなもので、.NET Core、Full .NET Framework、Xamarin (iOS/Android) を同時に対象とするライブラリを作成できます。
• .NET Core SDK は、少なくとも私が最後に確認したときは、ARM では動作しませんでした。

「モノプロジェクト」.NET Coreよりずっと古いです。Mono
はスペイン語でサルを意味しますが、余談ですが、この名前は単核球症とは何の関係もありません（ヒント：スタッフのリストはhttp://primates.ximian.com/）。Mono
は2005年にミゲル・デ・イカサ（始めた男グノーム- およびその他いくつかの)は、Linux (Ximian/SuSe/Novell) 用の .NET Framework の実装です。Mono には、Web フォーム、Winforms、MVC、Olive、および 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# のものは mono でコンパイルできますが、VB.NET のものはできません。Monoに
は、WSE/WCF や WebParts などの高度な機能がありません。
Mono 実装の多くは不完全 (例: ECDSA 暗号化で NotImplementedException をスローする)、バグがある (例: Firebird を使用した ODBC/ADO.NET)、.NET とは異なる動作をする (例: XML シリアル化)、不安定 (ASP.NET MVC)、許容できないほど遅い (Regex) などの問題があります。ただし、良い点としては、Mono ツールチェーンは ARM でも動作するということです。

.NET Core に関して言えば、クロスプラットフォームと言っても、ElasticSearch のように .NET Core を ARM-Linux に apt-get でインストールするだけでよいということではありません。フレームワーク全体をソースからコンパイルする必要があります。
つまり、それだけのスペースがある場合です (たとえば、合計 16 ～ 32 GB の HD を搭載した Chromebook など)。
また、OpenSSL 1.1 および libcurl との非互換性の問題もありました。
これらは、最新バージョンの .NET Core バージョン 2.2 で修正されました。
クロスプラットフォームについては以上です。

公式サイトに、「これ用に記述されたコードは、Mono などのアプリケーション スタック間でも移植可能です」という記述を見つけました。

そのコードが WinAPI 呼び出し、Windows dll ピン呼び出し、COM コンポーネント、大文字と小文字を区別しないファイル システム、既定のシステム エンコーディング (コード ページ) に依存しておらず、ディレクトリ区切り文字の問題がない限り、それは正しいです。ただし、.NET Core コードは .NET Core 上で実行され、Mono 上では実行されません。そのため、この 2 つを混在させることは困難です。また、Mono は非常に不安定で遅い (Web アプリケーションの場合) ため、いずれにしてもお勧めしません。WebP や動く GIF、マルチページ TIFF、画像へのテキスト書き込みなど、.NET Core での画像処理を試してみると、驚くことになるでしょう。

注:
.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以降では、シックスラボ イメージシャープSystem.Drawing は必ずしも安全ではなく、多くの潜在的または実際のメモリ リークがあるため、これが正しい方法です。そのため、Web アプリケーションでは GDI を使用しないでください。SkiaSharp はネイティブ ライブラリを使用するため (これも欠点になる場合があります)、ImageSharp よりもはるかに高速であることに注意してください。また、GDI+ は Linux と Mac で動作しますが、iOS/Android で動作するとは限りません。

.NET（非Core）用に書かれていないコードは、.NET Coreに移植できません。
つまり、PDFSharpのような非GPL C#ライブラリを使用してPDFドキュメントを作成したい場合（非常に一般的です）、運が悪いことになります。 （現時点で） （もうない）。Windows-pInvokes（暗号化、COM 経由で mcdf ドキュメントの作成、フォント、文字、カーニング、フォント埋め込み情報の取得、文字列の測定、改行、許容可能な品質の TIFF の描画）を使用する ReportViewer コントロールは気にしないでください。また、Linux 上の Mono でも動作しません
（私はそれに取り組んでいます）。

また、Mono には .NET Core ランタイム ライブラリがないため (現時点では)、.NET Core で記述されたコードは Mono に移植できません。

私の目標は、C#、LINQ、EF7、Visual Studio を使用して、Linux で実行/ホストできる Web サイトを作成することです。

これまで試したどのバージョンの EF も、非常に遅かったので (1 つのテーブルに 1 つの左結合があるような単純なものでも)、絶対にお勧めしません。Windows でも同じです。
特に、一意制約や varbinary/filestream/hierarchyid 列のあるデータベースの場合は、EF はお勧めしません (スキーマ更新の場合も同様です)。
また、DB パフォーマンスが重要な状況 (10 人以上から 100 人以上の同時ユーザーなど) にもお勧めしません。
また、Linux で Web サイトや Web アプリケーションを実行すると、遅かれ早かれデバッグが必要になります。
Linux 上の .NET Core にはデバッグ サポートがありません。 (現在はサポートされていませんが、JetBrains Rider が必要です。)
MonoDevelop は (まだ) .NET Core プロジェクトのデバッグをサポートしていません。
問題がある場合は、自己責任となります。詳細なログ記録を使用する必要があります。
詳細なログ記録は、特にプログラムが無限ループまたは再帰に入ると、すぐにディスクをいっぱいにするので注意してください
。これは、Web アプリが root として実行されている場合に特に危険です。ログインにはログファイルのスペースが必要になるためです。空きスペースが残っていない場合は、ログインできなくなります。
(通常、ディスクスペースの約 5% がユーザー root (Windows では管理者) 用に予約されているため、ディスクがほぼいっぱいになっても、少なくとも管理者はログインできます。ただし、アプリケーションが root として実行されている場合、その制限はディスク使用量には適用されず、ログファイルは残りの空きスペースの 100% を使用できるため、管理者でさえログインできなくなります。)
したがって、データ/システムを重視する場合は、そのディスクを暗号化しない方がよいでしょう。

誰かが「モノラルで」やりたいと言っていましたが、それが何を意味するのか分かりません。

これは、.NET Core を使いたくないか、Linux/Mac で C# を使いたいだけかのどちらかを意味します。私の推測では、Linux の Web アプリに C# を使いたいだけでしょう。どうしても C# でやりたいのであれば、.NET Core が最適です。「Mono 正規版」は使用しないでください。一見、最初はうまく機能するように見えますが、サーバーを長期間 (1 日以上) 実行すると Mono の ASP.NET MVC が安定しないため、後悔することになるでしょう。これで警告が出ました。techempower ベンチマークで Mono のパフォーマンスを測定する場合は、「完了しなかった」という参照も参照してください。

私は、上記に挙げたテクノロジーで .Net Core 1.0 フレームワークを使いたいと考えています。また、彼は「高速 CGI」を使いたいとも言っていました。私もそれが何を意味するのか分かりません。

これは、nginx (Engine-X)、おそらく Apache のような高性能でフル機能の Web サーバーを使用したいことを意味します。
その後、仮想名ベースのホスティング (同じ IP 上の複数のドメイン名) や負荷分散を使用して mono/dotnetCore を実行できます。また、Web サーバーで別のポート番号を必要とせずに、他のテクノロジを使用して他の Web サイトを実行することもできます。これは、Web サイトが fastcgi サーバー上で実行され、nginx が fastcgi プロトコルを介して特定のドメインのすべての Web リクエストをそのサーバーに転送することを意味します。また、Web サイトが fastcgi パイプラインで実行されるため、ファイルの送信時に HTTP 1.1 を使用できないなど、注意が必要です。そう
しないと、送信先でファイルが文字化けします。
ここそしてここ。

結論として、
現在 (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 を使用してデバッグしてください (私はなんとかできました。その場合は Scott Hanselman のブログ投稿に従わないでください。github の VS-Code の wiki にハウツーがあります)。実行可能ファイルは提供されていないためです。Yeoman
も失敗します。 (インストールした nodejs のバージョンに関係があると思います。VS Code には 1 つのバージョンが必要で、Yeoman には別のバージョンが必要です... ただし、同じコンピューターで実行する必要があります。かなり残念です。OS
にデフォルトで出荷されている node バージョンで実行する必要があることは気にしないでください
。そもそも NodeJS に依存しないはずであることも気にしないでください。kestell
サーバーも進行中です。
また、mono プロジェクトでの私の経験から判断すると、FastCGI で .NET Core をテストしたことがないこと、または FastCGI サポートがフレームワークにとって何を意味するのかを彼らが理解していること、ましてや「すべてが機能する」ことを確認するためにテストしたことは疑わしいです。実際、.NET Core で fastcgi アプリケーションを作成しようとしたところ、.NET Core "RTM" 用の FastCGI ライブラリがないことに気付きました...

したがって、nginx の背後で .NET Core "RTM" を実行する場合は、リクエストを kestrell (半完成の nodeJS 派生 Web サーバー) にプロキシすることによってのみ実行できます。私の知る限り、.NET Core "RTM" では現在 fastcgi はサポートされていません。.net core fastcgi ライブラリもサンプルもないため、fastcgi が期待どおりに動作することを確認するためにフレームワークでテストを行った人はおそらくいないでしょう。

パフォーマンス
にも疑問を感じます。(予備) techempower-benchmark (ラウンド 13)aspnetcore-linux は最高パフォーマンスの 25% にランクされていますが、Go (golang) などの同等のフレームワークはピーク パフォーマンスの 96.9% にランクされています (これは、ファイル システム アクセスのみなしでプレーン テキストを返す場合です)。.NET Core は JSON シリアル化で少し優れていますが、魅力的ではありません (go はピークの 98.5% に達し、.NET Core は 65%)。とはいえ、「mono 本体」よりも悪いということはあり得ません。

また、まだ比較的新しいため、主要なライブラリのすべてが移植されているわけではなく (まだ)、そのうちのいくつかは今後も移植されないのではないかと思います。
イメージングのサポートも、せいぜい疑わしいものです。
暗号化に関しては、代わりに BouncyCastle を使用してください。

これらすべての用語の意味を理解し、私の期待が現実的であるかどうかを教えていただけますか?

これらすべての用語の意味をより理解するのに役立つことを願っています。
あなたの期待についてですが、
Linux について何も知らないまま Linux アプリケーションを開発するのは、そもそも本当に愚かな考えであり、いずれにせよ、何らかのひどい方法で失敗することになります。とはいえ、Linux はライセンス コストがかからないため、原則的には良い考えですが、自分が何をしているかわかっている場合に限ります。
アプリケーションをデバッグできないプラットフォーム用にアプリケーションを開発するのも、非常に悪い考えです。
どのような結果になるか知らずに fastcgi 用に開発するのも、非常に悪い考えです。

プロジェクトが単なる個人ホームページ以上のものである場合、そのプラットフォームの詳細に関する知識がなく、デバッグ サポートもない「実験的な」プラットフォームでこれらすべてのことを実行するのは自殺行為です。一方、学習目的で個人のホームページで実行することは、おそらく非常に良い経験になると思います。そうすれば、フレームワークが何であるか、フレームワーク以外の問題が何であるかを知ることができます。
たとえば、大文字と小文字を区別しない fat32、hfs、または JFS をアプリケーション用に (プログラムで) ループ マウントして、大文字と小文字を区別する問題を回避できます (ループ マウントは運用環境では推奨されません)。

まとめ
現在 (2016-09-28)、私は .NET Core は避けるつもりです (本番環境での使用)。1、2 年後にはもう一度検討できるかもしれませんが、それより前はおそらく無理でしょう。
開発する新しい Web プロジェクトがある場合は、mono ではなく .NET Core で開始してください。Linux

(x86/AMD64/ARMhf)、Windows、Mac で動作し、依存関係のないフレームワーク (静的リンクのみで、.NET、Java、Windows に依存しないフレームワーク) が必要な場合は、代わりに Golang を使用してください。Golang はより成熟しており、パフォーマンスが実証されています (Baidu は 100 万人の同時ユーザーで使用しています)。また、Golang はメモリ フットプリントが大幅に小さくなっています。また、Golang はリポジトリにあり、.deb は問題なくインストールされ、ソースコードは変更なしでコンパイルされ、Golang (当面) は delve と JetBrains によるデバッグ サポートを備えています。ゴーグランドLinux (および Windows と Mac) では、Golang のビルド プロセス (およびランタイム) も NodeJS に依存しないため、これもまた利点の 1 つです。

mono に関しては、近づかないでください。mono
がここまで進歩したことは驚くべきことですが、残念ながら、実稼働アプリケーションのパフォーマンス/スケーラビリティと安定性の問題を補うことはできません。
また、mono 開発は完全に衰退しており、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 は依然としてプレリリース品質のソフトウェアです。ライブラリを移植しますが、フレームワークの品質が安定するまでは、本番環境での使用は控えてください。
また、Project Rider にも注目してください。

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

dotnet publish -r win-x64 -c Release /p:PublishSingleFile=true
dotnet publish -r linux-x64 -c Release /p:PublishSingleFile=true

echo "DOTNET_CLI_TELEMETRY_OPTOUT=1" >> /etc/environment
export DOTNET_CLI_TELEMETRY_OPTOUT=1