.NET核心与单声道
.NET Core和Mono有什么区别？
我在官方网站上发现了一个声明：“为它编写的代码也可以跨应用程序堆栈移植，如Mono。”
我的目标是使用C＃，LINQ，EF7和Visual Studio创build一个可以在Linux上运行/托pipe的网站。
有人告诉我，他希望它是“单声道”，但我不知道这是什么意思。 我知道我想用我上面列出的技术来使用.NET Core 1.0。 他还表示，他想用“快速CGI”。 我也不知道这是什么意思。
你能帮我理解一下这些条款吗？如果我的期望是现实的话？
Necromancing。
提供一个实际的答案。
.Net Core和Mono有什么区别？
.NET Core在很大程度上是重写ASP.NET MVC框架（和控制台应用程序）以减less依赖关系，使其更加模块化并提高性能。
<edit>Console Applications: this includes server applications IMHO</edit>
重点是启用“本地编译”/自包含部署（所以你不需要在目标机器上安装.NET框架/虚拟机。
这在“云计算”中很有用，因为你可以使用你喜欢的任何版本的dotnet-CORE框架，而且不必担心系统pipe理员实际使用.NET框架的哪个版本安装。
.NET Core还支持多种操作系统作为侧边显示。
它受到Microsoft的支持。
Dotnet Core不会与Winforms或WPF或类似的东西。
Mono是用于Linux的.NET Framework（包括Web-Forms，Winforms，MVC）的一个实现。 基本上相当于（OpenJDK）JVM和（OpenJDK）JDK / JRE（而不是SUN / Oracle JDK）。 您可以使用它来获取ASP.NET-WebForms + WinForms + ASP.NET-MVC应用程序在Linux上的工作。
它由Xamarin支持，而不是由Microsoft支持。
（因为Xamarin被微软收购，这在技术上，但不是微软。）
你通常会得到你的C＃东西编译单声道，而不是VB.NET的东西。
某些高级function（如WSE / WCF和WebParts）缺失。
许多实现是不完整的（例如在ECDSAencryption中抛出NotImplementedException），错误（例如ODBC / ADO.NET与Firebird），行为不同于.NET（例如XML序列化）或其他不稳定（ASP.NET MVC）令人难以接受的慢（正则expression式）。
但是，不要指望跨平台意味着实际上你可以在ARM-Linux上安装.NET Core，就像使用elasticsearch一样。 你将不得不从源代码编译整个框架。
也就是说，如果您有空间的话（例如在Chromebook上，总共有16到32 GB的高清）。
这么多来跨平台。
我在官方网站上发现了一个声明：“为它编写的代码也可以跨应用程序堆栈移植，比如Mono”。
只要该代码不依赖于WinAPI调用，Windows-dll-pinvokes，COM-Components，不区分大小写的文件系统，并且没有目录分隔符问题，那就是正确的。 但是，.NET核心代码运行在.NET核心上，而不是单声道。 所以混合这两个将是困难的。 由于单声道是相当不稳定和缓慢，我不会推荐它。 尝试在.NET核心上进行image processing，例如WebP，移动GIF或multipage-tiff或在图像上写文字，你会感到惊讶。
根据2017年2月中旬：您现在可以使用SkiaSharp （示例） </edit>
不为.NET编写的代码（非核心）不能移植到.NET核心。
这意味着如果您希望像PDFSharp这样的非GPL C＃库创buildPDF文档（非常普遍），那么您现在运气不佳。 不要介意使用Windows-pInvokes（无论什么原因）的ReportViewer控件，甚至不能在Linux上以单声道运行。
此外，使用.NET核心编写的代码不能移植到单声道，因为mono缺less.NET核心运行时库（还）。
我的目标是使用C＃，LINQ，EF7，Visual Studio创build一个可以在Linux中运行/托pipe的网站。
在我尝试的任何版本中，EF都非常慢（甚至在一个左连接的表上这样简单的事情），我不会推荐它，也不会在Windows上。
如果你有一个具有唯一约束的数据库，或varbinary / filestream / hierarchyid列，我会特别不推荐EF。 （不适用于模式更新）
而且在DB性能非常关键的情况下（比如10+到100+以上的并发用户）也是如此。
另外，在Linux上运行一个网站/networking应用程序迟早意味着你将不得不进行debugging。 Linux上没有.NET Core的debugging支持。 （不再是，但需要JetBrains骑士）
MonoDevelop不支持debugging.NET核心项目。
如果你有问题，你自己。 你将不得不使用广泛的日志logging。
要小心，build议广泛的日志logging将立即填满您的磁盘，特别是如果您的程序进入一个infine循环或recursion。
如果您的web-app以root身份运行，这是特别危险的，因为login需要日志文件空间 – 如果没有可用空间，您将无法再login。
（通常情况下，大约5％的磁盘空间是为root用户保留的[也就是windows上的pipe理员]，所以如果磁盘快满了，至lesspipe理员仍然可以login，但是如果你的应用程序以root身份运行，那么这个限制就不适用磁盘使用情况，所以他们的日志文件可以使用剩余空间的100％，所以即使pipe理员也不能login）。
因此，最好不要encryption该磁盘，也就是说，如果你重视你的数据/系统。
有人告诉我，他希望它是“单声道”，但我不知道这是什么意思。
这意味着他不想使用.NET Core，或者他只想在Linux / Mac上使用C＃。 我的猜测是他只想在Linux上使用C＃作为Web应用程序。 如果你绝对想用C＃来做，.NET Core就是这么做的。 不要与“单音适当”去; 表面上看，它似乎起初工作 – 但相信我，你会后悔，因为单声道的ASP.NET MVC是不稳定的，当你的服务器运行长期（超过1天） – 你现在已经被警告。 在techmpower基准测量单声道性能时，请参见“未完成”参考。
我知道我想用上面列出的技术来使用.Net Core 1.0框架。 他还表示，他想用“快速CGI”。 我也不知道这是什么意思。
这意味着他想要使用像nginx（Engine-X）这样的高性能全functionWebServer，可能是Apache。
然后，他可以使用基于虚拟名称的主机（同一IP上的多个域名）和/或负载平衡运行mono / dotnetCore。 他还可以使用其他技术运行其他网站，而不需要Web服务器上的不同端口号。 这意味着您的网站运行在fastcgi服务器上，而nginx则通过fastcgi协议将某个域的所有web请求转发给该服务器。 这也意味着你的网站运行在一个fastcgi-pipeline，你必须小心你做什么，例如，当传输文件时不能使用HTTP 1.1。
否则，文件将在目标处乱码。
另见这里和这里 。
总结：
.NET Core目前不是真正的可移植性，也不是真正跨平台的（特别是debugging工具）。
本地编译也不容易，尤其是对于ARM。
而对我来说，它的发展也不像是“真的完成了”。 例如，System.Data.DataTable / DataAdaper.Update缺less… （不再与.NET核心2.0） 与System.Data.Common.IDB *接口一起使用。 （不再与.NET Core 1.1）
如果有一个经常使用的类，DataTable / DataAdapter会是…
另外，Linux安装程序（.deb）至less在我的机器上出现故障，我相信我不是唯一有这个问题的人。
debugging，也许与Visual Studio代码，如果你可以在ARM上构build它（我设法做到这一点 – 不要按照斯科特·汉塞尔曼的博客文章，如果你这样做 – 有一个在Github上的VS-Code维基howto），因为他们不提供可执行文件。
Yeoman也失败了。 （我猜这跟你安装的nodejs版本有关系 – VS Code需要一个版本，Yeoman另一个版本…但它应该运行在同一台计算机上。
不要紧，它应该运行在操作系统默认的节点版本上。
没关系，首先应该不要依赖NodeJS。
kestell服务器也在工作中。
根据我对mono-project的经验，我非常怀疑他们曾经在FastCGI上testing过.NET Core，或者他们对FastCGI支持的框架有什么了解，更别说他们testing了，确保“一切正常”。 事实上，我刚刚尝试使用.NET Core创build一个fastcgi应用程序，刚刚意识到没有.NET Core“RTM”的FastCGI库…
所以，当你要在nginx后面运行.NET Core“RTM”时，你只能通过代理请求到kestrell（这个半完成的nodeJS派生的web服务器）来实现 – 目前在.NET Core中没有对fastcgi的支持“RTM”，AFAIK。 由于没有.net核心fastcgi库，也没有样本，所以任何人都不太可能在框架上做任何testing，以确保fastcgi按预期工作。
我也质疑performance。
在（预备）techempower-benchmark（第13轮）中 ，aspnetcore-linux相对于最佳性能排名25％，而类似go（golang）的框架则排在最高性能的96.9％（也就是没有文件的情况下返回纯文本 – 仅限系统访问）。 .NET Core在JSON序列化上做得稍好一点，但它也看起来不令人信服（达到峰值的98.5％，.NET核心的65％）。 也就是说，它不可能比“单身”更糟糕。
而且，由于还比较新，所以并不是所有的主要图书馆都已经被移植了，我怀疑它们中的一些将会被移植。
成像支持充其量也是有问题的。
对于任何encryption，请改用BouncyCastle。
你能帮我理解这些条款吗？ 如果我的期望是现实的话 ？
我希望我能帮助你更好地理解这些条款。
就你的期望而言：
在不了解Linux的情况下开发一个Linux应用程序，首先是一个非常愚蠢的想法，它也必然以某种可怕的方式失败。 也就是说，因为Linux没有许可成本，原则上这是一个好主意， 但是只要你知道你做了什么。
开发一个平台的应用程序，你不能debugging你的应用程序是另一个非常糟糕的主意。
开发fastcgi不知道会有什么后果是另一个非常糟糕的主意。
如果您的项目不仅仅是一个个人主页，而在没有任何该平台具体知识和没有debugging支持的情况下，在“实验性”平台上做所有这些事情是自杀的。 另一方面，我想用你的个人主页作为学习目的对你来说可能是一个很好的经验 – 那么你就会知道框架和非框架问题是什么。
例如，你可以（编程方式）为应用程序循环挂载不区分大小写的fat32，hfs或JFS，以避开大小写敏感的问题（不推荐在生产环境中使用循环挂载）。
总结
目前，我将远离.NET Core（用于生产用途）。 也许在一两年之后，你可以再看看，但可能不会。
如果您开发了一个新的Web项目，请使用.NET Core启动它，而不是单声道。
如果你想要一个在Linux（x86 / AMD64 / ARMhf）和Windows和Mac上工作的框架，它没有依赖关系，也就是只有静态链接，并且不依赖于.NET，Java或Windows，而是使用Golang。 它更成熟了，它的性能已经得到证实（百度和100万并发用户一起使用它），golang的内存占用率显着降低。 golang也在仓库中，.deb安装没有问题，源代码编译 – 无需修改 – 而golang（同时）在Linux（以及Windows和Mac）上使用delve和JetBrains Gogland进行debugging支持。 Golang的构build过程（和运行时）也不依赖于NodeJS，而NodeJS又是另外一个优点。
就mono而言，远离它。
单声道到底有多远并不奇怪，但不幸的是，它不能替代生产应用中的性能/可扩展性和稳定性问题。
另外，单发展已经相当死亡，他们在很大程度上只是开发与Android和iOS相关的部分，因为这是Xamarin赚钱的地方。
不要指望Web开发成为一stream的Xamarin / mono公民。
.NET Core可能是值得的，如果你开始一个新的项目，但是对于现有的大型Web表单项目，移植在很大程度上是不可能的，所需要的变化是巨大的。 如果你有一个MVC项目，如果你原来的应用程序devise是健全的，大多数现存的所谓的“历史增长”应用程序并不是这种情况，那么更改的数量是可以pipe理的。
2016年12月更新：
本地编译已从.NET Core预览中删除，因为尚未准备就绪…
看起来他们在原始文本文件基准testing中有了相当大的改进，但另一方面，它却变得非常麻烦。 而且，它在JSON基准testing中进一步恶化。 还好奇的是，entity framework的更新速度要比Dapper更快 – 尽pipe两者的logging速度都很慢。 这是不太可能的。 看起来还有更多的狩猎游戏。
而且，Linux IDE前端似乎也有所缓解。
IntelliJ发布了“Project Rider”，这是一个可以处理Visual Studio项目文件的Linux（和Mac和Windows）C＃/ .NET Core IDE的早期访问预览。 最后一个可用的C＃IDE并不慢。
结论：当我们进入2017年时，.NET Core仍然是预发布的高质量软件。将您的图书馆移植到生产环境，但是远离它，直到框架质量稳定。
并留意Project Rider。
2017更新
现在已经将我的（兄弟）主页迁移到.NET Core。
到目前为止，Linux上的运行时似乎是足够稳定的（至less对于小型项目） – 它轻松地经受了负载testing – 单声道从来没有。
另外，它看起来像是混合了.NET-Core-native和.NET-Core-self-contained-deployment。 自包含的部署工作，但它是有点没有logging，虽然它是超级简单的（build设/发布工具有点不稳定，但 – 如果你遇到“正数需要。 – build立失败。” – 再次运行相同的命令，它的工作原理）。
你可以跑
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缺less相应的VC运行时文件 – msvcp140.dll和vcruntime140.dll。将它们复制到publish目录中，Skia将在Windows 8.1上运行。）
2017年8月更新
.NET Core 2.0发布。
小心 – 伴随（巨大的中断）更改身份validation…
另一方面，它带来了DataTable / DataAdaper / DataSet类，还有更多。
实现的.NET Core仍然缺less对Apache SparkSQL的支持，因为Mobius尚未移植。 这是不好的，因为这意味着没有SparkSQL支持我的物联网卡桑德拉群集，所以没有join…
实验性的ARM支持（仅适用于运行时，不适用于SDK – 对我的Chromebook而言太糟糕了 – 期待2.1或3.0）。
现在PdfSharp被实验移植到.NET Core。
JetBrains骑士离开了EAP。 现在，您可以使用它来开发和debuggingLinux上的.NET Core – 尽pipe目前为止只有.NET Core 1.1才支持.NET Core 2.0的更新。
另外请注意，在Linux上，.NET Core 仅为64位 ！
在Linux上没有，也没有x86 Core的x86-32版本 。
而ARM端口只有ARM-32。 没有ARM-64，但是。
PS：
export DOTNET_CLI_TELEMETRY_OPTOUT=1
如果你已经在Windows上使用它，你可能没有看到这个：
.NET Core工具收集使用数据以改善您的体验。
数据是匿名的，不包括命令行参数。
数据由微软收集并与社区共享。
您可以通过使用您最喜欢的shell将DOTNET_CLI_TELEMETRY_OPTOUT环境variables设置为1来退出遥测。
您可以阅读更多关于.NET Core工具telemetry @ https://aka.ms/dotnet-cli-telemetry 。
在.NET世界中有两种types的CLR，“完整的”CLR和核心的CLR，而这些是完全不同的东西。
有两个“完整的”CLR实现，Microsoft本机.NET CLR（用于Windows）和Mono CLR（本身具有用于Windows，linux和unix（Mac OS X和FreeBSD）的实现）。 一个完整的CLR就是这样 – 几乎所有你需要的东西。 因此，“完整的”CLR往往很大。
另一方面，核心CLR被削减，而且小得多。 因为它们只是一个核心实现，所以它们不太可能拥有你需要的所有东西，所以使用核心CLR，可以使用NuGet将特性集添加到特定软件产品使用的CLR中。 有Windows的核心CLR实现，linux（各种）和unix（Mac OS X和FreeBSD）混合使用。 微软已经或正在重构Core CLR的.NET框架库，以使它们更加便于核心上下文。 鉴于mono在* nix操作系统上的存在，如果用于* nix的核心CLR不包含一些单声道代码库，那将是一个惊喜，但只有Mono社区和微软可以肯定地告诉我们。
另外，我同意Nico的看法：核心CLR是新的，现在是RC2。 我不会依赖于它的生产代码呢。
要回答你的问题，你可以使用核心CLR或单声道在Linux上交付你的网站，这是两种不同的方式。 如果你现在想要一个安全的赌注，我会在Linux上单声道，然后如果你想以后端口，去核心。
你不仅select了一条现实的道路，而且还可以说是MS强有力的支持（也是X平台）的最好的生态系统之一。 还是应该考虑以下几点：
- 更新：.Net平台标准的主要文档在这里： https ： //github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md
- 更新：目前的单声道4.4.1不能运行最新的Asp.Net核心1.0 RTM
- 虽然单声道function更完整，但是它的未来还不清楚，因为MS已经拥有了几个月的时间，而且它是一个重复的工作来支持它。 但是MS肯定会致力于.Net Core，并且投入巨资。
- 虽然.Net核心发布了，但是第三方生态系统并不在那里。 例如Nhibernate，Umbraco等无法运行.Net核心。 但他们有一个计划。
- .Net核心像System.Drawing中缺less一些function，你应该寻找第三方库
- 您应该使用nginx作为前端服务器与kestrelserver为asp.net应用程序，因为kestrelserver尚未完全准备好生产。 例如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 available），但是mono不是Microsoft支持的框架，会推荐使用支持的框架
现在entity framework7现在被称为Entity Framework Core ，并且可以在包括Linux在内的多个平台上使用。 参考https://github.com/aspnet/EntityFramework （查看路线图）
我目前正在使用这两种框架，但是您必须了解它仍然处于候选版本阶段（ RC2是当前版本），而在testing版和发行版候选版本中，出现了很大的变化，通常最终会让您挠头。
这里是一个关于如何在Linux中安装MVC .Net Core的教程。 https://docs.asp.net/en/1.0.0-rc1/getting-started/installing-on-linux.html
最后，您可以selectWeb服务器（我假设fast cgi参考文件来自fast cgi ），以便在Linux上托pipe您的应用程序。 这里是安装到Linux环境的参考点。 https://docs.asp.net/en/1.0.0-rc1/publishing/linuxproduction.html
我意识到这篇文章最终是链接到文档，但在这一点上，这些是你最好的信息来源。 .Net核心在.Net社区还是比较新的，直到完全发布之后，由于发布版本之间的突然变化，我会犹豫在产品环境中使用它。
这个问题是特别实际的，因为昨天微软正式发布了.NET Core 1.0版本 。 假设Mono实现了大部分标准.NET库，Mono和.NET核心之间的区别可以通过.NET Framework和.NET Core的区别来看出：
- API – .NET Core包含许多与.NET Framework相同但较less的 API，并且具有不同的因式分解（程序集名称是
不同; types形状在关键情况下不同）。 这些差异
目前通常需要将端口源更改为.NET Core。 .NET核心实现了.NET标准库API，该API将成长为
随着时间的推移包含更多的.NET Framework BCL API。- 子系统 – .NET Core实现了.NET Framework中子系统的一个子集，其目标是实现更简单，
编程模型。 例如，代码访问安全性（CAS）不是
支持，而支持reflection。
如果您需要快速启动某些function，请与Mono联系，因为它目前（2016年6月）更成熟的产品，但是如果您正在build立一个长期的网站，我会推荐.NET Core。 微软正式支持它，支持的API的差异很快就会消失，同时考虑到微软在开发.NET Core方面的努力。
我的目标是使用C＃，LINQ，EF7，Visual Studio创build一个可以在Linux中运行/托pipe的网站。
Linq和Entity框架都包含在.NET Core中 ，因此您可以安心地拍摄。
简单来说，
Mono是Linux / Android / iOs的.Net框架的第三方实现
.Net Core是微软自己的实现。
.Net核心是未来。 Mono最终会死的。 话虽如此.Net Core还不够成熟。 我正在努力用IBM Bluemix来实现它，后来又放弃了这个想法。 下来的时间（可能是1 – 2年），应该会更好。
