.NET Core和Mono有什么区别？

我在官方网站上发现了一条声明："为它编写的代码也可以跨应用程序堆栈移植，例如Mono。"

我的目标是使用C＃，LINQ，EF7和Visual Studio创建一个可以在Linux上运行/托管的网站。

有人告诉我，他希望它是"单声道"，但我不知道这意味着什么。 我知道我想使用上面列出的技术使用.NET Core 1.0。 他还说他想使用"快速CGI"。 我也不知道这意味着什么。

你能帮我理解所有这些术语吗？如果我的期望是现实的吗？

---

Necromancing。
提供实际答案。

What is the difference between .Net Core and Mono?

Ok.

.NET Core在很大程度上是对ASP.NET MVC框架(和控制台应用程序)的重写，以减少依赖性，使其更加模块化，并提高性能。

Console Applications: this includes server applications IMHO

重点是启用"本机编译"/自包含部署(因此您不需要在目标计算机上安装.NET框架/ VM。
这在"云计算"中很有用，从那以后你可以使用你喜欢的任何版本的dotnet-CORE框架，而你不必担心sysadmin实际上有哪些.NET框架版本已安装。
.NET Core还支持多个操作系统作为副作用。
它得到了微软的支持。
Dotnet Core没有Winforms或WPF或类似的东西。

Mono是.NET Framework for Linux(包括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的东西。
缺少一些高级功能，如WSE / WCF和WebParts。
许多实现都是不完整的(例如，在ECDSA加密中抛出NotImplementedException)，buggy(例如ODBC / ADO.NET with Firebird)，行为与.NET(例如XML序列化)或其他不稳定(ASP.NET MVC)和令人无法接受的缓慢(正则表达式)。

但是，不要指望跨平台意味着您实际上只能在ARM-Linux上安装.NET Core，就像使用elasticsearch一样。你必须从源代码编译整个框架。
也就是说，如果你有这个空间(例如在Chromebook上，总HD为16到32 GB)。
这么多跨平台。

I found a statement on the official site that said,"Code written for
it is also portable across application stacks, such as Mono".

Ok.

只要该代码不依赖于WinAPI调用，Windows-dll-pinvokes，COM-Components，不区分大小写的文件系统，并且没有目录分隔符问题，这是正确的。但是，.NET Core代码在.NET核心上运行，而不是在单声道上运行。因此混合这两者将是困难的。由于单声道非常不稳定和慢，我不建议它。尝试在.NET核心上进行图像处理，例如WebP或移动GIF??或multipage-tiff或在图像上书写文字，你会感到非常惊讶。

截至2017年2月中旬：您现在可以使用SkiaSharp(示例)

Note:
As of .NET Core 2.0, there is System.Drawing.Common (nuget), which
contains most of the functionality of System.Drawing. It should be
more or less feature-complete in .NET-Core 2.1. However,
System.Drawing.Common uses GDI+, and therefore won't work on Azure
(System.Drawing libraries are available in Azure Cloud Service
[basically just a VM], but not in Azure Web App [basically shared
hosting?])
So far, System.Drawing.Common works fine on Linux/Mac.

Ok.

不是为.NET(非核心)编写的代码不能移植到.NET核心。
这意味着如果你想要像PDFSharp这样的非GPL C＃库来创建PDF文档(非常普通)，那么你运气不好(目前)(不再是)了。不要介意使用Windows-pInvokes的ReportViewer控件(无论出于何种原因)，甚至不能在Linux上运行单声道
(我正在努力)。

此外，用.NET内核编写的代码不能移植到单声道，因为mono缺少.NET核心运行时库(尚未)。

My goal is to use C#, LINQ, EF7, visual studio to create a website
that can be ran/hosted in linux.

Ok.

到目前为止我尝试过的任何版本的EF都是如此的死得很慢(即使是一个简单的东西，比如一张桌子上有一个左连接)，我也不会推荐它 - 也不会在Windows上推荐它。
如果您有一个包含unique-constrains或varbinary / filestream / hierarchyid列的数据库，我特别不建议使用EF。 (也不用于架构更新)
而且，在数据库性能至关重要的情况下(例如10+到100多个并发用户)也不会这样。
此外，在Linux上运行网站/网络应用程序迟早意味着你必须调试它。
Linux上没有针对.NET Core的调试支持。(不再是，但需要JetBrains Rider)
MonoDevelop(尚未)支持调试.NET-Core项目。
如果你有问题，你可以自己做。您将不得不使用广泛的日志记录。
请注意，建议广泛的日志记录将立即填满您的磁盘，特别是如果您的程序进入一个infine循环或递归。
如果您的网络应用程序以root身份运行，这尤其危险，因为登录需要logfile空间 - 如果没有剩余可用空间，您将无法再登录。
(通常，大约5％的磁盘空间是为用户root [也就是Windows上的管理员]保留的，所以至少管理员仍然可以登录，如果磁盘几乎已满。但是如果您的应用程序以root身份运行，则该限制不适用于他们的磁盘使用情况，因此他们的日志文件可以使用100％的剩余可用空间，因此管理员甚至不能再登录了。)
因此，最好不要加密该磁盘，也就是说，如果您重视数据/系统。

Someone told me that he wanted it to be"in Mono", but I don't know
what that means.

Ok.

这或者意味着他不想使用.NET Core，或者他只是想在Linux / Mac上使用C＃。我的猜测是他只想在Linux上使用C＃作为Web应用程序。如果您绝对想在C＃中使用.NET Core，那么.NET Core就是您的最佳选择。不要选择"Mono proper";从表面上看，它似乎最初起作用 - 但相信我会后悔，因为当您的服务器长期运行(超过1天)时，单声道的ASP.NET MVC不稳定 - 您现在已经收到警告。在测量techempower基准测试中的单声道性能时，另请参阅"未完成"参考。

I know I want to use the .Net Core 1.0 framework with the technologies
I listed above. He also said he wanted to use"fast cgi". I don't know
what that means either.

Ok.

这意味着他想使用像nginx(Engine-X)这样的高性能全功能WebServer，可能是Apache。
然后，他可以运行带有基于虚拟名称的托管(同一IP上的多个域名)和/或负载平衡的mono / dotnetCore。他还可以使用其他技术运行其他网站，而无需在Web服务器上使用不同的端口号。这意味着您的网站在fastcgi服务器上运行，nginx通过fastcgi-protocol将特定域的所有Web请求转发到该服务器。这也意味着您的网站运行在fastcgi管道中，您必须小心您的工作，例如传输文件时不能使用HTTP 1.1。
否则，文件将在目的地出现乱码。
另见这里和这里。

总结：
.NET Core目前不是真正可移植的，也不是真正的跨平台(特别是调试工具)。
本机编译也不容易，特别是对于ARM。
对我而言，它的发展看起来并不像"真正完成"。
例如，缺少System.Data.DataTable / DataAdaper.Update ...
(不再使用.NET Core 2.0)
与System.Data.Common.IDB *接口一起使用。(不再使用.NET Core 1.1)
如果有一个经常使用的类，那么DataTable / DataAdapter就是它......
此外，Linux安装程序(.deb)失败了，至少在我的机器上，我确信我不是唯一有这个问题的人。
调试，也许使用Visual Studio Code，如果你可以在ARM上构建它(我设法做到了 - 如果你这样做，不要跟随Scott Hanselman的博客文章 - 在github上的VS-Code wiki中有一个howto)，因为他们不提供可执行文件。
Yeoman也失败了。 (我想这与你安装的nodejs版本有关 - VS Code需要一个版本，Yeoman另一个版本......但它应该在同一台计算机上运行。非常蹩脚
不要紧，它应该在OS上默认发布的节点版本上运行。
没关系，首先应该不依赖于NodeJS。
kestell服务器也正在进行中。
根据我对单项目的经验判断，我非常怀疑他们曾经在FastCGI上测试.NET Core，或者他们知道FastCGI支持对他们的框架意味着什么，更不用说他们测试它以确保"一切正常""。事实上，我刚刚尝试使用.NET Core制作fastcgi应用程序，并且意识到没有用于.NET Core"RTM"的FastCGI库...

因此，当您要在nginx后面运行.NET Core"RTM"时，您只能通过将请求代理到kestrell(该半成品nodeJS派生的Web服务器)来实现 - 目前.NET Core中没有fastcgi支持"RTM"，AFAIK。由于没有.net核心fastcgi库，也没有样本，所以任何人都不太可能对框架进行任何测试以确保fastcgi按预期工作。

我也质疑表现。
在(初步)techempower-benchmark(第13轮)中，aspnetcore-linux相对于最佳性能排名为25％，而像Go(golang)这样的可比框架在峰值性能上排名为96.9％(这是在没有文件的情况下返回明文) - 仅限系统访问)。 .NET Core在JSON序列化方面做得更好，但它看起来并不引人注目(达到98.5％的峰值，.NET核心达到65％)。也就是说，它不可能比"单身适当"更糟糕。

此外，由于它仍然相对较新，并非所有主要的图书馆都已移植(但)，我怀疑它们中的一些将被移植。
成像支持充其量也值得怀疑。
对于任何加密，请改用BouncyCastle。

Can you help me make sense of all these terms and if my expectations
are realistic?

Ok.

我希望我帮助你用所有这些术语更有意义。
就你的期望而言：
在不知道任何关于Linux的情况下开发Linux应用程序首先是一个非常愚蠢的想法，并且它也必然会以某种可怕的方式以某种方式失败。也就是说，因为Linux没有许可成本，原则上这是一个好主意，但是只要你知道你做什么。
为无法调试应用程序的平台开发应用程序是另一个非常糟糕的主意。
为fastcgi开发而不知道有什么后果是另一个非常糟糕的主意。

如果您的项目不仅仅是个人主页，那么在没有任何平台特定知识且没有调试支持的情况下在"实验"平台上完成所有这些事情就是自杀。另一方面，我想用你的个人主页进行学习可能对你来说非常好 - 然后你就会知道框架和非框架问题是什么。
例如，您可以(以编程方式)为您的应用程序循环安装不区分大小写的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进行调试支持。 Golang的构建过程(和运行时)也不依赖于NodeJS，这又是另一个优点。

就单声道而言，远离它。
毫无疑问，单声道已经达到了多远，但不幸的是，它无法替代其生产应用的性能/可扩展性和稳定性问题。
此外，单一开发已经相当不复存在，他们在很大程度上只开发了与Android和iOS相关的部分，因为这是Xamarin赚钱的地方。
不要指望Web开发成为一流的Xamarin /单身公民。
.NET Core可能是值得的，如果你开始一个新项目，但对于现有的大型Web表单项目，移植很大程度上是不可能的，所需的更改是巨大的。如果您有一个MVC项目，如果您的原始应用程序设计是理智的，那么更改量可能是可管理的，而大多数现有的所谓"历史增长"应用程序大多不是这种情况。

2016年12月更新：
本机编译已从.NET Core预览中删除，因为它还没有准备好......

看起来他们在原始文本文件基准测试中已经有了相当大的改进，但另一方面，它变得非常错误。此外，它在JSON基准测试中进一步恶化。好奇的是，实体框架的更新速度应该比Dapper更快 - 尽管两者都处于创纪录的缓慢状态。这不太可能是真的。看起来还有不止一些虫子需要捕杀。

此外，Linux IDE前端似乎有所缓解。
JetBrains发布了"Project Rider"，这是一个可以处理Visual Studio Project文件的C＃/ .NET Core IDE for Linux(以及Mac和Windows)的早期访问预览版。
最后一个可用的C＃IDE＆amp;那不是那么慢的地狱。

结论：.NET Core仍然是我们迈向2017年的预发布质量软件。移植您的库，但远离它以用于生产用途，直到框架质量稳定。
并密切关注Project Rider。

2017年更新
现在已将我(兄弟)的主页迁移到.NET Core。
到目前为止，Linux上的运行时似乎足够稳定(至少对于小型项目而言) - 它很容易在负载测试中幸存下来 - 单声道从未这样做过。
此外，我看起来像混合了.NET-Core-native和.NET-Core-self-contained-deployment。自包含部署有效，但它有点未被记录，虽然它非常简单(构建/发布工具有点不稳定，但是 - 如果遇到"需要正数。 - 构建失败。" - 再次运行相同的命令，它的工作原理)。

你可以跑

并且您获得了一个自包含的.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。将它们复制到发布目录中，Skia将在Windows 8.1上运行。)

2017年8月更新
.NET Core 2.0发布。
小心 - 认证中发生(巨大的破坏)变化......
从好的方面来说，它带回了DataTable / DataAdaper / DataSet类等等。
已实现的.NET Core仍然缺少对Apache SparkSQL的支持，因为Mobius尚未移植。这很糟糕，因为这意味着没有SparkSQL支持我的IoT Cassandra集群，所以没有加入......
实验性ARM支持(仅限运行时，而非SDK - 对于我的Chromebook上的devwork来说太糟糕了 - 期待2.1或3.0)。
PdfSharp现在通过实验移植到.NET Core。
JetBrains Rider离开了EAP。你现在可以用它来开发＆amp;在Linux上调试.NET Core - 尽管到目前为止只有.NET Core 1.1，直到.NET Core 2.0支持的更新才能生效。

2018年5月更新
.NET Core 2.1即将推出。
也许这将修复Linux上的NTLM身份验证(NTLM身份验证在.NET-Core 2.0中不适用于具有多个身份验证标头的.NET-Core 2.0，例如协商，通常与ms-exchange一起发送，并且它们显然是只修复它在v2.1中，没有bug修正版2.0)。
但我不是在我的机器上安装预览版本。等等。
据说v2.1大大减少了编译时间。那会很好。

另请注意，在Linux上，.NET Core仅为64位！
在Linux上没有，也没有x86-32版本的.NET Core。
ARM端口仅适用于ARM-32。还没有ARM-64。
在ARM上，您(目前)只有运行时，而不是dotnet-SDK。

还有一件事：
因为.NET-Core使用的是OpenSSL 1.0，所以Linux上的.NET Core不能在Arch Linux上运行，也不能在Manjaro(迄今为止最流行的Linux发行版)上运行，因为Arch Linux使用的是OpenSSL 1.1。所以，如果你使用的是Arch Linux，那你就不走运了(也有Gentoo)。

从好的方面来看，性能肯定有所改善：

.NET Core 3：
据说.NET-Core v 3.0将WinForms和WPF引入.NET-Core。
但是，虽然WinForms和WPF将是.NET Core，但.NET-Core中的WinForms和WPF只能在Windows上运行，因为WinForms / WPF将使用Windows-API。

PS：

如果你在Windows上使用它，你可能从未见过这个：

The .NET Core tools collect usage data in order to improve your
experience.
The data is anonymous and does not include command-line
arguments.
The data is collected by Microsoft and shared with the
community.
You can opt out of telemetry by setting a
DOTNET_CLI_TELEMETRY_OPTOUT environment variable to 1 using your
favorite shell.
You can read more about .NET Core tools telemetry @
https://aka.ms/dotnet-cli-telemetry.

Ok.

我想我会提到我认为monodevelop(又名Xamarin Studio，单声道IDE)已经发展得非常好，并且在此期间 - 很大程度上可用。
然而，JetBrains Rider(2018 EAP在这个时间点)肯定是更好，更可靠(并且包含的??反编译器更安全)，也就是说，如果你在Linux或Mac上开发.NET-Core。

免责声明：
我不使用Mac，所以我不能说我在这里写的内容是否适用于基于FreeBSD-Unix的Mac。我指的是JetBrains Rider，mono，MonoDevelop / VisualStudioMac / XamarinStudio和.NET-Core的Linux(Debian / Ubuntu / Mint)版本。此外，Apple正在考虑从英特尔处理器转向自制ARM(基于ARM-64？)的处理器，目前适用于Mac的大部分内容可能不适用于未来的Mac(2020+)。

此外，当我写"单声道非常不稳定和慢"时，不稳定与WinFroms＆amp; WebForms应用程序，特别是通过fastcgi或XSP(在单声道的4.x版本上)执行web应用程序，以及XML序列化处理的特性，而且相当慢的WinForms，特别是正则表达式(ASP) .NET-MVC也使用正则表达式进行路由。

当我写下关于单声道4.x的经验时，这也没有必要意味着这些问题现在还没有得到解决，或者当你正在阅读时，也没有解决，如果它们现在被修复，那就不能稍后回归，重新引入任何这些错误/功能。这也不意味着如果嵌入单声道运行时，您将获得与使用(dev)系统的单声道运行时相同的结果。它也并不意味着嵌入单一运行时(任何地方)是必要的免费。

所有这些并不一定意味着单声道不适合IOS或Android，或者它在那里有相同的问题。 我没有在Android或IOS上使用mono，所以我对这些平台上的稳定性，可用性，成本和性能一无所知。 显然，如果您在Android上使用.NET，您还需要考虑其他一些成本因素，例如加权xamarin-cost与成本以及将现有代码移植到Java的时间。 一个在Android上听到单声道和IOS应该是相当不错的。 拿一粒盐。 首先，不要指望默认系统编码在android / ios与Windows上相同，并且不要指望android文件系统不区分大小写。

好。

---

在.NET世界中，有两种类型的CLR，"完整"CLR和核心CLR，这些是完全不同的东西。

有两个"完整"的CLR实现，Microsoft本机.NET CLR(适用于Windows)和Mono CLR(它本身具有Windows，Linux和unix(Mac OS X和FreeBSD)的实现)。一个完整的CLR就是这样 - 你需要的一切。因此，"完整"CLR的尺寸往往很大。

另一方面，核心CLR被削减，而且更小。因为它们只是一个核心实现，所以它们不太可能拥有您需要的所有内容，因此使用Core CLR，您可以使用NuGet为特定软件产品使用的CLR添加功能集。有适用于Windows，Linux(各种)和unix(Mac OS X和FreeBSD)的Core CLR实现。 Microsoft也已经或正在为Core CLR重构.NET框架库，以使它们在核心上下文中更具可移植性。鉴于mono在* nix OS上的存在，如果* nix的Core CLR不包含某些单声道代码库，那将是一个惊喜，但只有Mono社区和Microsoft可以肯定地告诉我们。

此外，我同意Nico的说法，核心CLR是新的 - 我认为它现在在RC2。我不会依赖它来生成代码。

要回答您的问题，您可以使用Core CLR或Mono在Linux上交付您的站点，这是两种不同的方式。如果你现在想要一个安全的赌注我会在linux上使用mono，然后在你想要的时候移植到Core。

---

您不仅选择了一条现实的路径，而且可以说是MS强有力支持的最佳生态系统之一(也是X平台)。你还应该考虑以下几点：

• 更新：关于.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核心。但他们有一个计划。
• .Net Core中缺少一些功能，如System.Drawing，你应该寻找第三方库
• 对于asp.net应用程序，你应该使用nginx作为前端服务器和kestrelserver，因为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支持的框架，会建议使用支持的框架

现在，实体框架7现在称为Entity Framework Core，可在包括Linux在内的多个平台上使用。参考https://github.com/aspnet/EntityFramework(查看路线图)

我目前正在使用这两个框架，但是你必须明白它仍然处于发布候选阶段(RC2是当前版本)以及beta＆amp;释放候选人已经发生了巨大的变化，通常最终会让你挠头。

这是一个如何将MVC .Net Core安装到Linux中的教程。 https://docs.asp.net/en/1.0.0-rc1/getting-started/installing-on-linux.html

最后，您可以选择Web服务器(我假设fast cgi参考来自)，以便在Linux上托管您的应用程序。这是安装到Linux环境的参考点。 https://docs.asp.net/en/1.0.0-rc1/publishing/linuxproduction.html

我意识到这篇文章最终主要是文档的链接，但在这一点上，这些是你最好的信息来源。 .Net核心在.Net社区中仍然相对较新。在完全发布之前，鉴于发布版本之间的重大变化，我会犹豫是否在产品环境中使用它。

---

这个问题特别实际，因为昨天微软正式宣布发布.NET Core 1.0。假设Mono实现了大多数标准.NET库，可以通过.NET Framework和.NET Core之间的区别来看待Mono和.NET核心之间的区别：

• APIs — .NET Core contains many of the same, but fewer, APIs as the .NET Framework, and with a different factoring (assembly names are
  different; type shape differs in key cases). These differences
  currently typically require changes to port source to .NET Core. .NET
  Core implements the .NET Standard Library API, which will grow to
  include more of the .NET Framework BCL APIs over time.
• Subsystems — .NET Core implements a subset of the subsystems in the .NET Framework, with the goal of a simpler implementation and
  programming model. For example, Code Access Security (CAS) is not
  supported, while reflection is supported.

如果您需要快速启动，请使用Mono，因为它目前(2016年6月)是更成熟的产品，但如果您要构建一个长期网站，我建议使用.NET Core。它得到了微软的正式支持，考虑到微软在开发.NET Core方面的努力，支持的API的差异很快就会消失。

My goal is to use C#, LINQ, EF7, visual studio to create a website
that can be ran/hosted in linux.

Linq和Entity框架包含在.NET Core中，因此您可以放心使用。

---

简单来说，

Mono is third party implementation of .Net framework for
Linux/Android/iOs

.Net Core is microsoft's own implementation for same.

.Net Core是未来。和Mono最终会死。话虽如此.Net Core还不够成熟。我正在努力用IBM Bluemix实现它，后来放弃了这个想法。降低时间(可能是1 - 2年)，应该会更好。

---

简而言之：

Mono = C＃编译器

Mono Develop =编译器+ IDE

.Net Core = ASP编译器

目前.Net Core的案例只有在采用一些开放的winform标准和更广泛的语言采用时才会成为网络，它最终可能成为微软的杀手级开发者。考虑到甲骨文最近的Java许可转移，微软有充足的时间来发挥作用。

---