.NET CoreとMono
.NET CoreとMonoの違いは何ですか？
私は公式サイト上で次のような声明を見つけました。
私の目標は、C＃、LINQ、EF7、およびVisual Studioを使用して、Linux上で実行/ホストできるWebサイトを作成することです。
誰かがそれを「モノの中」にしたいと言ってくれましたが、それがどういう意味かわかりません。私は、.NET Core 1.0を上記のテクノロジと共に使用したいと思っています。彼はまた "fast CGI"を使いたいと言った。それがどういう意味なのかもわかりません。
私の期待が現実的であるならば、あなたは私がこれらすべての用語を理解するのを手伝うことができますか？
ネクロマンシング。
実際の答えを提供します。
.Net CoreとMonoの違いは何ですか？
.NET Core は、ほとんどの場合、依存関係を減らすためにASP.NET MVC フレームワーク（およびコンソールアプリケーション）を書き直したものです。 、よりモジュール化し、パフォーマンスを向上させます。
<edit>Console Applications: this includes server applications IMHO</edit>
主なポイントは、「ネイティブコンパイル」/自己完結型デプロイメントを有効にすることです（したがって、ターゲットマシンに.NET framework/VMをインストールする必要はありません。
これは「クラウドコンピューティング」で役立ちます。これは、好きなバージョンのdotnet-COREフレームワークを使用でき、.NETのバージョンを気にする必要がないためです。 sysadminが実際にインストールしたフレームワーク。
。NET Coreは、サイドショーとして複数のオペレーティングシステムもサポートしています。
Microsoftによってサポートされています。
Dotnet Coreには、WinformsやWPFなどが付属していません。
Mono は、Linux用の.NET Frameworkの実装です（Webフォーム、Winforms、MVCを含む）。基本的に（OpenJDK）JVMおよび（OpenJDK）JDK/JREと同等（Sun/Oracle JDKとは対照的）。これを使用して、ASP.NET-WebForms + WinForms + ASP.NET-MVCアプリケーションをLinux上で動作させることができます。
Microsoftではなく、Xamarinでサポートされています。
（XamarinはMicrosoftに買収されたため、技術的にではありますが、実際にはMicrosoftではありません。）
通常、C＃のものをモノでコンパイルしますが、VB.NETのものはコンパイルしません。
WSE/WCFやWebPartsなどの一部の高度な機能がありません。
。 .NET MVC）および容認できないほど遅い（正規表現）.
ただし、クロスプラットフォームとは、elasticsearchの場合のように、ARM-Linuxに.NET Coreを実際にapt-getインストールできることを意味するものではありません。ソースからフレームワーク全体をコンパイルする必要があります。
つまり、そのスペースがある場合（例：合計16〜32 GBのHDを搭載したChromebook）。
クロスプラットフォームに。
公式サイトで「そのために書かれたコードは、Monoなどのアプリケーションスタック間でも移植可能です」という声明を見つけました。
そのコードがWinAPI呼び出し、Windows-dll-pinvokes、COMコンポーネント、大文字と小文字を区別しないファイルシステムに依存しておらず、ディレクトリセパレーターの問題がない限り、それは正しいです。ただし、.NET Coreコードは、モノではなく.NETコアで実行されます。したがって、この2つを混合することは困難です。そして、モノは非常に不安定で遅いため、とにかくお勧めしません。 .NETコアで画像処理を試してください。 WebPやGIFの移動、マルチページTIFF、画像上へのテキストの書き込みなど、意外なことに驚くでしょう。
<edit>2017年2月中旬：現在、 SkiaSharp を使用できます （例）</edit>
注意：
。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で正常に動作します。
.NET（非コア）用に記述されていないコードは、.NETコアに移植できません。
PDFSharpなどの非GPL C＃ライブラリでPDFドキュメントを作成する（非常に一般的）場合は、運が悪い （現時点では） （ もうない ）。 （何らかの理由で）Windows-pInvokesを使用し、Linuxのモノでも実行しないReportViewerコントロールを気にしないでください
（ 私はそれに取り組んでいます ）。
また、.NETコアで記述されたコードは、モノに移植性がありません。これは、モノには.NETコアランタイムライブラリがまだないためです。
私の目標は、C＃、LINQ、EF7、Visual Studioを使用して、Linuxで実行/ホストできるWebサイトを作成することです。
私がこれまでに試したどのバージョンでも、EFは非常に遅い（1つの左結合を持つ1つのテーブルのような単純なものでも）ので、Windowsでもそうではありません。
データベースにunique-constrains、またはvarbinary/filestream/hierarchyid列がある場合、EFは特にお勧めしません。 （スキーマ更新用ではありません）
また、DBパフォーマンスが重要な状況ではありません（10〜100人以上の同時ユーザーなど）。
また、LinuxでWebサイト/ Webアプリケーションを実行すると、遅かれ早かれデバッグする必要があります。Linux上の.NET Coreのデバッグサポートはありません。 （もうありませんが、JetBrains Riderが必要です）
MonoDevelopは（まだ）.NET-Coreプロジェクトのデバッグをサポートしていません。
問題がある場合は、自分で対処してください。広範囲のログを使用する必要があります。
注意してください、特にプログラムが無限ループまたは再帰に入った場合、大規模なロギングがディスクをすぐにいっぱいにすることに注意してください。
これは、Webアプリケーションがrootとして実行されている場合に特に危険です。ログインにはlogfile-spaceが必要になるためです。空き領域が残っていない場合、ログインできなくなります。
（通常、ディスクスペースの約5％はユーザールート[Windowsの管理者]のために予約されているため、少なくとも管理者はディスクがほぼいっぱいの場合でもログインできます。ただし、アプリケーションがルートとして実行される場合、ディスク使用量には適用されないため、ログファイルは残りの空き容量の100％を使用できるため、管理者でさえログインできなくなります。）
したがって、そのディスクを暗号化しないこと、つまりデータ/システムを重視する場合の方が良いでしょう。
誰かがそれを「モノラル」にしたいと言ったが、それが何を意味するのか分からない。
つまり、彼は.NET Coreを使用したくないか、Linux/MacでC＃を使用したいだけです。私の推測では、彼はLinux上のWebアプリにC＃を使用したいだけです。 .NET Coreは、C＃で絶対にやりたい場合に、そのための手段です。 「適切なモノ」ではいけません。表面的には、最初は動作しているように見えますが、サーバーが長期間（1日以上）稼働している場合、monoのASP.NET MVCは安定していないため、後悔すると思います-あなたは今警告を受けています。 techempowerベンチマークでモノのパフォーマンスを測定する場合は、「完全ではない」参照も参照してください。
上記のテクノロジで.Net Core 1.0フレームワークを使用したいと思っています。彼はまた、「高速cgi」を使用したいと述べました。それが何を意味するのか分かりません。
これは、nginx（Engine-X）、おそらくApacheのような高性能でフル機能のWebサーバーを使用したいということです。
その後、仮想名ベースのホスティング（同じIP上の複数のドメイン名）および/または負荷分散でmono/dotnetCoreを実行できます。また、Webサーバーで別のポート番号を必要とせずに、他のテクノロジーを使用して他のWebサイトを実行できます。 Webサイトがfastcgi-serverで実行され、nginxが特定のドメインのすべてのweb要求をfastcgi-protocol経由でそのサーバーに転送することを意味します。また、Webサイトがfastcgiパイプラインで実行されていることを意味します。ファイルを送信するときにHTTP 1.1を使用することはできません。
それ以外の場合、ファイルは宛先で文字化けします。
here および here も参照してください。
結論：
。NET Coreは現在、実際には移植性がなく、実際にはクロスプラットフォームでもありません（特にデバッグツール）。
Norは、特にARM向けのネイティブコンパイルが容易です。
そして私にとっても、その開発はまだ「本当に完了」しているようには見えません。たとえば、System.Data.DataTable/DataAdaper.Updateが見つかりません... （.NET Core 2.0ではもうありません）System.Data.Common.IDB *インターフェースと一緒に。 （.NET Core 1.1ではもうありません）
よく使用されるクラスが1つあった場合、DataTable/DataAdapterはそれでしょう...
また、Linuxインストーラー（.deb）は、少なくとも私のマシンでは失敗します。この問題を抱えているのは私だけではないはずです。
デバッグ、おそらくVisual Studio Codeを使用して、ARMでビルドできる場合（そうすることができました- Scott Hanselmanのブログ投稿をフォローしないでくださいthat -git-hubのVS-Codeのwikiにハウツーがあります）。実行可能ファイルを提供していないためです。
Yeomanも失敗します。 （インストールしたnodejsのバージョンと何か関係があると思います-VS Codeには1つのバージョンが必要で、Yeomanは別のバージョンです...しかし同じコンピューターで実行する必要があります。
OSでデフォルトで出荷されているノードバージョンで実行する必要があることに注意してください。
そもそもNodeJSに依存してはならないということは気にしないでください。
kestellサーバーも進行中です。
そして、モノプロジェクトでの私の経験から判断すると、FastCGIで.NET Coreをテストしたことや、FastCGI-supportがフレームワークに何を意味するのか、ましてや「すべてが機能する」ことを確認してください。実際、.NET Coreでfastcgiアプリケーションを作成しようとしましたが、.NET Core "RTM"用のFastCGIライブラリがないことに気付きました...
したがって、nginxの背後で.NET Core "RTM"を実行する場合、kestrell（その半完成したnodeJS派生Webサーバー）へのリクエストをプロキシすることによってのみ実行できます。NETCoreには現在fastcgiのサポートはありません。 「RTM」、知る限り。 .netコアのfastcgiライブラリもサンプルもないため、fastcgiが期待どおりに動作することを確認するためにフレームワークでテストを行った可能性は非常に低いです。
パフォーマンスにも疑問があります。
（暫定）techempower-benchmark（ラウンド13） では、aspnetcore-linuxは最高のパフォーマンスに対して25％でランク付けされていますが、Go（golang）のような同等のフレームワークはランク付けされていますピークパフォーマンスの96.9％で（ファイルシステムアクセスのみなしでプレーンテキストを返す場合）。 .NET Coreは、JSONシリアル化で少し良くなりますが、魅力的ではありません（ピークの98.5％、. NET core 65％に達します）。とは言っても、それは「適切なモノ」よりも悪くなることはないでしょう。
また、まだ比較的新しいので、主要なライブラリのすべてが（まだ）移植されているわけではなく、それらの一部が移植されることはないでしょう。
イメージングのサポートもせいぜい疑問です。
暗号化には、代わりにBouncyCastleを使用します。
これらすべての用語の意味を理解するのを手伝ってもらえますか、私の期待が現実的かどうか
これらのすべての用語について、より理にかなったものにしたことを願っています。
あなたの期待に関する限り：
Linuxについて何も知らずにLinuxアプリケーションを開発することは、そもそも本当に馬鹿げたアイデアであり、何らかの方法で恐ろしい方法で失敗することにもなります。とはいえ、Linuxにはライセンス費用がかからないため、原則としてをお勧めします。ただし、あなたが何をしているのかを知っている場合に限ります。
アプリケーションをデバッグできないプラットフォーム用のアプリケーションを開発することも、非常に悪い考えです。
結果が何であるかを知らずにfastcgi向けに開発することは、さらに悪い考えです。
プロジェクトが個人のホームページ以上のものである場合、「実験」プラットフォームでこれらのすべてをプラットフォームの詳細を知らずに、デバッグサポートなしで行うことは自殺です。一方、学習目的で個人のホームページでそれを行うことは、おそらくあなたにとって非常に良い経験になると思います-そうすれば、フレームワークと非フレームワークの問題が何であるかを知ることができます。
たとえば、大文字と小文字を区別しないfat32、hfs、またはJFSを（プログラムで）アプリケーションにループマウントして、大文字と小文字の区別の問題を回避できます（運用ではループマウントは推奨されません） 。
要約するには
現時点では、.NET Coreから離れます（本番環境での使用）。たぶん1〜2年後には、もう一度見直すことができますが、おそらくそうではありません。
新しいWebプロジェクトを開発する場合は、モノではなく.NET Coreで開始してください。
Linux（x86/AMD64/ARMhf）とWindowsおよびMacで動作するフレームワークが必要な場合、依存関係はありません。つまり、静的リンクのみ、.NETへの依存関係はありません、JavaまたはWindowsでは、代わりにGolangを使用します。より成熟しており、パフォーマンスが実証されており（Baiduは100万人の同時ユーザーで使用しています）、golangのメモリフットプリントは大幅に低くなっています。また、golangはリポジトリにあり、.debは問題なくインストールされ、ソースコードは変更を必要とせずにコンパイルされます。また、golang（とりあえず）は、Linux上のdelveおよびJetBrains Gogland およびWindowsおよびMac）。 Golangのビルドプロセス（およびランタイム）もNodeJSに依存していませんが、これはもう1つのプラスです。
モノに関しては、近づかないでください。
モノラルがどれだけ進歩したかは驚くに値しますが、残念ながら、実稼働アプリケーションのパフォーマンス/スケーラビリティおよび安定性の問題に代わるものではありません。
また、モノ開発は完全に死んでいます。彼らは主にAndroidとiOSに関連する部分のみを開発しています。
Web-Developmentが一流のXamarin/mono市民になることを期待しないでください。
。NET Coreは価値があります。新しいプロジェクトを開始する場合、既存の大規模なWebフォームプロジェクトの場合、移植はほとんど問題にならず、必要な変更は膨大です。 MVCプロジェクトがある場合、元のアプリケーション設計が正しければ、変更の量は管理可能かもしれません。これは、ほとんどの既存のいわゆる「歴史的に成長した」アプリケーションにはほとんど当てはまりません。
2016年12月の更新：
ネイティブコンパイルはまだ準備ができていないため、.NET Coreプレビューから削除されました...
生のテキストファイルのベンチマークではかなり改善されているようですが、一方で、かなりバグが多くなっています。また、JSONベンチマークでさらに悪化しました。また、エンティティフレームワークはDapperよりも更新が高速であることにも興味がありますが、どちらも記録的な速度ではありません。これが真実である可能性は非常に低いです。まだいくつかの狩りをするバグ以上のものがあるように見えます。
また、LinuxのIDEの面でも安心感がありそうです。
JetBrainsは、Visual Studio Projectファイルを処理できるLinux（およびMacとWindows）用のC＃/。NET Core IDEの早期アクセスプレビューである "Project Rider"をリリースしました。最後に、C＃IDEが使用可能であり、それは地獄ほど遅くはありません。
結論：.NET Coreは2017年に向けてリリース前の品質のソフトウェアです。フレームワークの品質が安定するまで、ライブラリを移植してください。
そしてProject Riderに注目してください。
2017アップデート
今のところ、私の（兄弟の）ホームページを.NET Coreに移行しました。
これまでのところ、Linuxのランタイムは（少なくとも小規模なプロジェクトでは）十分に安定しているようです-簡単に負荷テストを乗り切りました-モノは決してしませんでした。
また、.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
また、（発行ディレクトリにある）自己完結型の.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 はまだ移植されていないため、Apache SparkSQLのサポートはまだ実現されていません。悪いのは、それは私のIoT Cassandraクラスターに対してSparkSQLがサポートされていないことを意味しているため、参加できません...
実験的なARMサポート（ランタイムのみで、SDKではなく、Chromebookの開発作業にはあまりにも悪い-2.1または3.0を楽しみにしています）。
PdfSharpは実験的に.NET Coreに移植されました。
JetBrains Rider 左EAP。 Linux上で.NET Coreを開発およびデバッグするために使用できるようになりました。ただし、.NET Core 2.0サポートの更新が公開されるまでは.NET Core 1.1のみです。
2018年5月更新
。NET Core 2.1リリースが間近です。たぶん、これはLinuxでのNTLM認証を修正します（NTLM認証は、ネゴシエートなどの複数の認証ヘッダー（通常はms-exchangeで送信されます） v2.1でのみ修正し、2.0のバグ修正リリースはありません）。
しかし、マシンにプレビューリリースをインストールしていません。待ってます。
v2.1は、コンパイル時間を大幅に短縮すると言われています。それが良いでしょう。
また、Linuxでは、.NET Coreは 64ビットのみです。
x86-32バージョンの.NET Core on Linux はありません。
そして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 3：
。NET-Core v 3.0は、WinFormsとWPFを.NET-Coreにもたらすと言われています。
。
PS：
export DOTNET_CLI_TELEMETRY_OPTOUT=1
Windowsで使用したことがあるなら、おそらくこれを見たことがないでしょう：
.NET Coreツールは、エクスペリエンスを向上させるために使用状況データを収集します。
データは匿名であり、コマンドライン引数は含まれません。
データはマイクロソフトによって収集され、コミュニティと共有されます。
お気に入りのシェルを使用してDOTNET_CLI_TELEMETRY_OPTOUT環境変数を1に設定することにより、テレメトリーをオプトアウトできます。
。NET Coreツールのテレメトリー@ https://aka.ms/dotnet-cli-telemetry の詳細をご覧ください。
Monodevelop（別名Xamarin Studio、mono IDE）は非常にうまく進化したと思いますが、その間はほとんど使用可能です。
ただし、JetBrains Rider（現時点では2018 EAP）は間違いなくずっと優れており、信頼性が高いです（含まれている逆コンパイラーは安全です）。つまり、.NET-Coreを開発する場合LinuxまたはMacで。
免責事項：
私は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（monoの4.xバージョン）を介したWebアプリケーションの実行、およびXMLシリアル化に関連します。 -処理の特性、および非常に遅いことはWinForms、および特に正規表現に関連しています（ASP.NET-MVCはルーティングにも正規表現を使用します）。
モノ4.xについての私の経験について書いているとき、それは必ずしもこれらの問題が今までに、またはあなたがこれを読んでいる時までに解決されていないことを意味するわけではありません。これらのバグ/機能のいずれかを再導入する後の回帰になります。また、モノランタイムを埋め込んだ場合、（dev）システムのモノランタイムを使用した場合と同じ結果が得られることも意味しません。また、モノランタイム（どこでも）の埋め込みが必ずしも無料であることも意味しません。
これは、必ずしもモノがIOSやAndroidに不適切であること、または同じ問題があることを意味するわけではありません。私はAndroidまたはIOSでモノを使用しないので、安定性、使いやすさ、 costs およびこれらのプラットフォームのパフォーマンスについて何も言うつもりはありません。明らかに、Androidで.NETを使用する場合、既存のコードをJavaに移植するためのコストと時間に対するxamarinコストの重み付けなど、コストに関する他の考慮事項もあります。 Androidでモノラルが聞こえ、IOSは非常に良好です。塩の粒でそれを取る。 1つは、Android/iosとWindowsでdefault-system-encodingが同じであることを期待しないでください。また、Androidファイルシステムが大文字と小文字を区別しないことを期待しないでください。
.NETの世界では、「フル」CLRとコアCLRの2種類のCLRがありますが、これらはまったく異なるものです。
Microsoftのネイティブ.NET CLR（Windows用）とMono CLR（それ自体がWindows、linux、およびunix（Mac OS XおよびFreeBSD）用の実装を持つ）という2つの「完全な」CLR実装があります。完全なCLRはまさにそれです - すべて、ほとんど、あなたが必要とするもの。そのため、「フル」CLRはサイズが大きくなる傾向があります。
一方、コアCLRは削減され、はるかに小さくなりました。これらはコア実装にすぎないため、必要なものがすべて揃っているとは考えにくいので、Core CLRでは、NuGetを使用して、特定のソフトウェア製品が使用するCLRに機能セットを追加します。 Windows、linux（さまざま）、およびunix（Mac OS XとFreeBSD）用のコアCLR実装が混在しています。マイクロソフトは、コアコンテキスト向けに移植性を高めるために、コアCLR用の.NETフレームワークライブラリも持っているかリファクタリングしています。 * nix OS上でのmonoの存在を考えると、* nix用のCore CLRにモノコードベースが含まれていないのであれば、驚くことでしょう。MonoコミュニティとMicrosoftだけがそれを確実に言ってくれます。
また、Core CLRは新しいということでNicoに同意すると思います。現在はRC2にいると思います。私はまだプロダクションコードには依存しません。
あなたの質問に答えるには、Core CLRかMonoを使ってあなたのサイトをLinuxで配信することができます、そしてこれらはそれをする2つの異なる方法です。あなたが今安全な賭けをしたいのなら、私はLinux上でモノラルを使います、そして、もしあなたが後でしたいならば、Coreに移植してください。
あなたは現実的な道を選ぶだけでなく、間違いなくMSによって強く支持された（またX-プラットフォーム）最も良いエコシステムのうちの1つを選びました。それでも、次の点を考慮する必要があります。
- 更新：.Netプラットフォーム標準に関する主な文書はこちらです： https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md
- アップデート：現在のMono 4.4.1は最新のAsp.Netコア1.0 RTMを実行できない
- モノはより機能が充実していますが、MSは現在数ヶ月間それを所有しており、それをサポートするための重複作業であるため、その将来は不明です。しかし、MSは確実に.NET Coreに献身的に取り組んでいます。
- .NETコアはリリースされていますが、サードパーティのエコシステムはそれほどありません。たとえば、Nhibernate、Umbracoなどは、.Netコア上ではまだ実行できません。しかし、彼らは計画を立てています。
- System.Drawingのような.Net Coreに欠けているいくつかの機能があります、あなたはサードパーティ製のライブラリを探すべきです
- Keprelserverは実運用に向けた準備が整っていないため、asp.netアプリケーション用のkestrelserverと一緒にnginxをフロントサーバーとして使用する必要があります。たとえば、HTTP/2は実装されていません。
私はそれが役立つことを願っています
.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は使用可能）、ただし mono はマイクロソフトがサポートするフレームワークではないため、サポートされているフレームワークの使用をお勧めします。
現在、エンティティフレームワーク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/installation-on-linux.html
最後に、Linux上でアプリケーションをホストするためのWebサーバー（ここではfast cgiの参照が由来していると想定しています）を選択できます。これは、Linux環境にインストールするための参照点です。 https://docs.asp.net/en/1.0.0-rc1/publishing/linuxproduction.html
この記事は主にドキュメントへのリンクになっていることに気付きましたが、現時点ではこれらはあなたにとって最良の情報源です。 .NETコアは、.NETコミュニティではまだ比較的新しいものであり、完全にリリースされるまでは、リリースされたバージョン間で大きな変更があることを考えると、製品環境で使用するのは躊躇します。
昨日のMicrosoftが正式に{ .NET Core 1.0リリースを発表した _しているので、この質問は特に現実的です。 Monoが標準的な.NETライブラリのほとんどを実装していると仮定すると、Monoと.NETコアの違いは、.NET Frameworkと.NETコアの違いからわかります。
- API - .NET Coreには、.NET Frameworkと同じ、 しかし少ない のAPIが多く含まれています（アセンブリ名は
違う。型の形状はキーケースによって異なります）。これらの違い
現在、通常はソースを.NET Coreに移植するための変更が必要です。 .NET Coreは.NET Standard Library APIを実装しています。
今後、.NET Framework BCL APIの多くが含まれるようになります。- サブシステム - .NET Coreは.NET Frameworkのサブシステムのサブセットを実装し、より単純な実装と
プログラミングモデルたとえば、コードアクセスセキュリティ（CAS）はそうではありません。
反射はサポートされていますが、サポートされています。
何かを素早く立ち上げる必要がある場合は、Monoを使用してください。現在（2016年6月）より成熟した製品ですが、長期的なWebサイトを構築している場合は、.NET Coreをお勧めします。それはマイクロソフトによって公式にサポートされており、サポートされているAPIの違いはおそらくMicrosoftが.NET Coreの開発に注いでいる努力を考慮すると、すぐに消えるでしょう。
私の目標は、C＃、LINQ、EF7、ビジュアルスタジオを使用して、Linuxで実行/ホストできるWebサイトを作成することです。
LinqとEntity framework .NET Coreに含まれています なので、あなたは安全にショットを撮ることができます。
シンプルに
Monoは、Linux/Android/iOs用の.Netフレームワークのサードパーティによる実装です。
.NET Coreは、Microsoft独自の実装です。
ネットコアは未来です。そしてモノはやがて死にます。 .Net Coreが十分に成熟していないと言ったこと。私はそれをIBM Bluemixで実装するのに苦労していて、後でその考えをやめました。時間が経てば（1〜2年になるかもしれませんが）、それはもっと良いはずです。
手短に：
Mono = C＃用のコンパイラ
Mono Develop =コンパイラ+ IDE
.Net Core = ASPコンパイラ
.Net Coreの現在のケースは、オープンなWinform標準とより広範な言語の採用が採用され次第、Webのみとなり、ついにはMicrosoftのキラー開発大国になる可能性があります。オラクルが最近行ったJavaライセンス交付の動きを考えると、マイクロソフトは輝く大きな時間を過ごしています。