死灵法师。
提供实际答案。
.Net Core和Mono有什么区别？
.NET Core现在正式是.NET的未来。它在很大程度上是从重写ASP.NET MVC框架和控制台应用程序开始的，其中当然包括服务器应用程序。（因为它是图灵完备和支持互操作使用C的dll，你可以，如果你绝对要，也可以通过类似的第三方库写与它自己的桌面应用程序，例如阿瓦隆尼亚，这在我第一次编写此书时是非常基本的，这意味着您几乎只限于Web或服务器内容。）随着时间的流逝，.NET Core已添加了许多API，以至于在3.1版之后， .NET Core将跳转到5.0版，即不带“ Core”的.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 Framework的哪个版本。
尽管.NET Core运行时支持多种操作系统和处理器，但SDK却是另一回事。尽管SDK支持多种操作系统，但ARM对SDK的支持仍在进行中。Microsoft支持.NET Core。Dotnet-Core没有随附WinForms或WPF或类似的东西。
- 从3.0版开始，.NET Core也支持WinForms和WPF，但仅在Windows上，并且仅由C＃支持。不是通过VB.NET（计划在2020年为v5提供VB.NET支持）。.NET Core中没有Forms Designer：它是随Visual Studio更新一起在未指定的时间提供的。
- .NET Core仍然不支持WebForms，并且从来没有计划支持它们（Blazor是的新手）。
- .NET Core还带有System.Runtime，它取代了mscorelib。
- 通常，.NET Core与NetStandard混合在一起，后者是System.Runtime / mscorelib（以及其他一些文件）的包装，使您可以编写针对.NET Core，Full .NET Framework和Xamarin（iOS / Android）。
- .NET Core SDK在ARM上不起作用，至少在我上次检查时不起作用。
“ Mono项目”比.NET Core古老得多。
Mono是西班牙语，意为猴子，另外，与单核细胞增多症无关（提示：您可以在http://primates.ximian.com/下找到员工列表）。
Mono由Miguel de Icaza（创建GNOME的人 -和其他一些人）于2005年启动，作为Linux的.NET Framework（Ximian / SuSe / Novell）的实现。Mono包括Web窗体，Winforms，MVC，Olive和称为MonoDevelop的IDE。（也称为Xamarin Studio或Visual Studio Mac）。基本上等效于（OpenJDK）JVM和（OpenJDK）JDK / JRE（相对于SUN / Oracle JDK）。您可以使用它来使ASP.NET-WebForms + WinForms + ASP.NET-MVC应用程序在Linux上运行。
Xamarin（以前是Ximian的新公司名称，当时他们专注于移动市场，而不是Linux市场）支持Mono，而不是Microsoft。
（由于Xamarin是由Microsoft收购的，从技术上来说，（但从文化角度而言）
这是Microsoft。）通常，您会得到C＃东西，以便在mono上进行编译，而不是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。您必须从源代码编译整个框架。
也就是说，如果您有足够的空间（例如，在具有16至32 GB总HD的Chromebook上）。
它还曾经有与OpenSSL 1.1和libcurl不兼容的问题。
这些问题已在.NET Core版本2.2的最新版本中得到纠正。
跨平台就这么多。
我在官方网站上找到了一条声明，说：“为此编写的代码也可以跨应用程序堆栈（例如Mono）移植”。
只要该代码不依赖WinAPI调用，Windows-dll-pinvokes，COM-Components，不区分大小写的文件系统，默认系统编码（代码页）并且没有目录分隔符问题，那就是正确。但是，.NET Core代码在.NET Core上运行，而不在Mono上运行。因此，将两者混合是困难的。而且由于Mono非常不稳定且运行缓慢（对于Web应用程序），因此无论如何我都不推荐这样做。尝试在.NET核心上进行图像处理，例如WebP或移动GIF或多页tiff或在图像上书写文本，您会感到非常惊讶。
注意：
从.NET Core 2.0开始，有System.Drawing.Common（NuGet），其中包含System.Drawing的大部分功能。在.NET-Core 2.1中，它应该或多或少地具有功能完善性。然而，System.Drawing.Common使用GDI +，并因此将在Azure上不工作（System.Drawing中库在Azure的云服务[基本上只是一个VM]可用，但不是在Azure的Web应用程序[基本上共享主机？]）
所以到目前为止，System.Drawing.Common在Linux / Mac上运行良好，但在iOS / Android上存在问题-如果可以的话，在那里。
在.NET Core 2.0之前，也就是说，在2017年2月中旬，您可以使用SkiaSharp进行成像（示例）（仍然可以）。
在.net-core 2.0之后，您会注意到SixLabors ImageSharp之所以要这样做，是因为System.Drawing不一定是安全的，并且有很多潜在的或实际的内存泄漏，这就是为什么您不应该在Web应用程序中使用GDI的原因；请注意，SkiaSharp比ImageSharp快得多，因为它使用本机库（这也可能是一个缺点）。另外，请注意，尽管GDI +可在Linux和Mac上运行，但这并不意味着它可在iOS / Android上运行。
未为.NET（非核心）编写的代码无法移植到.NET Core。
意思是，如果您想要像PDFSharp这样的非GPL C＃库来创建PDF文档（非常常见），那您就不走运了。（在这一刻）（不再）。没关系，ReportViewer控件使用Windows-pInvokes（通过COM进行加密，创建mcdf文档，并获取字体，字符，字距，字距嵌入，字体嵌入信息，测量字符串并进行换行，以及实际绘制可接受质量的tiff）。 ，甚至没有在Linux上的Mono上运行
（我正在研究）。
而且，用.NET Core编写的代码不能移植到Mono上，因为Mono到目前为止没有.NET Core运行时库。
我的目标是使用C＃，LINQ，EF7，Visual Studio创建一个可以在Linux中运行/托管的网站。
到目前为止，我尝试使用的任何版本的EF都是如此之慢（即使在诸如带有一个左联接的一张表之类的简单事情上），我也永远不会推荐-也不在Windows上。
如果您的数据库具有唯一约束或varbinary / filestream / hierarchyid列，那么我尤其不建议您使用EF。（或者也不用于模式更新。）
而且在数据库性能至关重要的情况下（例如10+到100+并发用户）也不是。
另外，在Linux上运行网站/网络应用程序迟早将意味着您必须对其进行调试。
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就是这样做的方法。不要选择“单声道专有”；从表面上看，它似乎起初会工作-但相信我，您会后悔的，因为当服务器长期运行（超过1天）时，Mono的ASP.NET MVC不稳定-现在已受到警告。在techempower基准上测量Mono性能时，另请参阅“未完成”参考。
我知道我想将.Net Core 1.0框架与上面列出的技术一起使用。他还说他想使用“快速cgi”。我也不知道那是什么意思。
这意味着他想使用高性能的全功能Web服务器，例如nginx（Engine-X），可能是Apache。
然后，他可以使用基于虚拟名称的托管（同一IP上的多个域名）和/或负载平衡来运行mono / dotnetCore。他还可以使用其他技术来运行其他网站，而无需在Web服务器上使用其他端口号。这意味着您的网站在fastcgi-server上运行，并且nginx通过fastcgi-protocol将特定域的所有Web请求转发到该服务器。这也意味着您的网站运行在fastcgi管道中，并且您必须小心操作，例如，在传输文件时不能使用HTTP 1.1。
否则，文件将在目标位置出现乱码。
另请参阅此处和此处。
结论：
.NET Core当前（2016-09-28）不是真正可移植的，也不是真正的跨平台（尤其是调试工具）。
本地编译也不容易，特别是对于ARM。
对我来说，它的发展似乎还没有“真正完成”。
例如，缺少System.Data.DataTable / DataAdaper.Update ...
（.NET Core 2.0不再支持）
连同System.Data.Common.IDB *接口。（.NET Core 1.1不再使用），
如果曾经有一个经常使用的类，那就是DataTable / DataAdapter了。
此外，至少在我的机器上，Linux安装程序（.deb）失败了，我可以肯定，我不是唯一一个遇到这个问题的人。
如果可以在ARM上构建它，则可以使用Visual Studio Code进行调试（我设法做到这一点- 如果这样做，请不要关注Scott Hanselman的博客文章 -github上的VS-Code Wiki中有一个howto），因为他们不提供可执行文件。
Yeoman也失败了。（我想这与您安装的nodejs版本有关-VS Code需要一个版本，Yeoman需要另一个版本...但是它应该在同一台计算机上运行。很la脚，
不要介意它应该在默认提供的节点版本上运行在操作系统上。
没关系，首先应该不依赖NodeJS。
kestell服务器也在进行中。
从我在单一项目中的经验来看，我非常怀疑他们是否曾在FastCGI上测试过.NET Core，或者他们是否知道FastCGI支持对其框架意味着什么，更不用说他们对其进行了测试以确保“一切正常” ”。实际上，我只是尝试使用.NET Core创建一个fastcgi应用程序，并且才意识到没有用于.NET Core“ RTM”的FastCGI库。
因此，当您要在nginx后面运行.NET Core“ RTM”时，只能通过将请求代理到kestrell（该半成品的nodeJS派生的Web服务器）上来进行操作-.NET Core当前不支持fastcgi AFAIK，“ RTM”。由于没有.net核心fastcgi库，也没有示例，因此极不可能有人在框架上进行任何测试以确保fastcgi能够按预期工作。
我也质疑表现。
在（初步）techempower基准测试（第13轮）中，相对于最佳性能，aspnetcore-linux的排名为25％，而类似的框架（如Go（golang））的峰值性能则为96.9％（也就是说，不带文件返回纯文本时） -仅限系统访问）。.NET Core在JSON序列化方面做得更好，但是看起来也不引人注目（达到峰值的98.5％，. NET core达到65％）。就是说，这不可能比“单调妥当”更糟。
另外，由于它仍然相对较新，因此尚未移植所有主要库（尚未），我怀疑其中某些库是否会被移植。
影像支持最多也是可疑的。
对于任何加密，请改用BouncyCastle。
如果我的期望是现实的，您能帮助我理解所有这些术语吗？
希望我能帮助您在所有这些术语上更有意义。
就您的期望而言：
一开始不了解Linux的情况下开发Linux应用程序确实是一个愚蠢的主意，而且注定会以某种可怕的方式失败。就是说，因为Linux不收取许可费用，所以原则上讲 是个好主意，但前提是您知道自己要做什么。
在无法调试应用程序的平台上开发应用程序是另一个非常糟糕的主意。
在不知道结果的情况下为fastcgi进行开发还有另一个非常糟糕的主意。
如果您的项目不仅仅是一个个人主页，那么在“实验”平台上执行所有这些操作而又不了解该平台的详细信息并且没有调试支持将导致自杀。另一方面，我想使用个人主页进行学习可能会是一个很好的体验-然后您将了解什么是框架以及什么是非框架问题。
例如，您可以（以编程方式）为您的应用程序循环装入不区分大小写的fat32，hfs或JFS，以解决区分大小写的问题（在生产中不建议使用循环装入）。
总结
目前（2016-09-28），我将远离.NET Core（用于生产用途）。也许在一到两年内，您可以再看一遍，但也许不会。
如果您要开发一个新的Web项目，请在.NET Core（而不是mono）中启动它。
如果您想要一个可以在Linux（x86 / AMD64 / ARMhf）和Windows和Mac上运行的框架，并且没有依赖性，即仅静态链接，并且对.NET，Java或Windows没有依赖性，请改用Golang。它更加成熟，并且其性能得到了证明（百度将其用于100万并发用户），并且golang的内存占用量显着降低。此外，golang位于存储库中，.deb安装没有问题，源代码可以编译-无需更改-并且golang（与此同时）具有对delve和JetBrains的调试支持Linux（以及Windows和Mac）上的Gogland。Golang的构建过程（和运行时）也不依赖于NodeJS，这是另一个优点。
就Mono而言，请远离它。
令人惊讶的是，mono已经走了多远，但不幸的是，它不能替代生产应用程序中的性能/可伸缩性和稳定性问题。
而且，单一开发已经死了，他们基本上只开发了与Android和iOS相关的部分，因为这就是Xamarin赚钱的地方。
不要指望Web开发是一流的Xamarin / mono公民。
如果您开始一个新项目，.NET Core可能是值得的，但是对于现有的大型Web窗体项目，移植基本上是不可能的，需要进行的更改很大。如果您有一个MVC项目，并且您的原始应用程序设计合理，那么更改的数量可能是可控的，而对于大多数现有的所谓“历史增长”的应用程序而言，情况并非如此。
2016年12月更新：本
机编译已从.NET Core预览中删除，因为它尚未准备好...
似乎在原始文本文件基准方面，它们已得到了很大的改进，但另一方面，它已经出现了很多问题。而且，它在JSON基准测试中进一步恶化。同样有趣的是，实体框架的更新速度应该比Dapper快-尽管两者都处于创纪录的低速状态。这是不可能的。看起来仍有许多错误需要寻找。
另外，Linux IDE方面似乎也有所缓解。
JetBrains发布了“ Project Rider”，这是Linux（以及Mac和Windows）的C＃/。NET Core IDE的早期访问预览，可以处理Visual Studio Project文件。最后，一个可用的C＃IDE并不会像地狱般缓慢。
结论：.NET Core在进入2017年时仍是预发布质量的软件。移植您的库，但不要将其用于生产用途，直到框架质量稳定为止。
并密切注意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
注意：根据.NET Core 3，您可以将所有缩小的内容发布为单个文件：
dotnet publish -r win-x64 -c Release /p:PublishSingleFile=true
dotnet publish -r linux-x64 -c Release /p:PublishSingleFile=true
但是，与go不同，它不是静态链接的可执行文件，而是自解压缩的zip文件，因此在部署时，您可能会遇到问题，尤其是当temp目录被组策略或其他问题锁定时。不过，对于hello-world程序来说效果很好。而且，如果您不缩小文件大小，可执行文件的大小大约为100 MB。
然后，您将获得一个独立的.exe文件（在发布目录中），您可以将其移至未安装.NET Framework的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类，以及更多其他类。
由于尚未移植Mobius，因此Realized .NET Core仍然缺少对Apache SparkSQL的支持。太糟糕了，因为这意味着我的IoT Cassandra群集不支持SparkSQL，因此也就没有加入...
实验性的ARM支持（仅运行时，而不是SDK-对我的Chromebook的开发工作来说太糟糕了-期待2.1或3.0）。
PdfSharp现在已通过实验移植到.NET Core。
JetBrains骑士离开EAP。现在，您可以使用它在Linux上开发和调试.NET Core-尽管到目前为止只有.NET Core 1.1，直到支持.NET Core 2.0的更新生效。
2018年5月
即将推出.NET Core 2.1 更新。也许这会修复Linux上的NTLM身份验证（NTLM身份验证在具有多个身份验证标头（例如通常通过ms-exchange发送的协商）的.NET-Core 2.0中的Linux {以及可能的Mac}上不起作用。仅在v2.1中进行了修复，没有针对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 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将是.NET Core，但.NET-Core中的WinForms和WPF将仅在Windows上运行，因为WinForms / WPF将使用Windows-API。
注意：
.NET Core 3.0现在已经发布（RTM），并且具有WinForms和WPF支持，但仅适用于C＃（在Windows上）。有没有WinForms的核心-设计。最终，设计器将在某个时候附带Visual Studio更新。WinForms对VB.NET的支持不受支持，但计划在2020年对.NET 5.0进行支持。
PS：
echo "DOTNET_CLI_TELEMETRY_OPTOUT=1" >> /etc/environment
export DOTNET_CLI_TELEMETRY_OPTOUT=1
如果您在Windows上使用过它，则可能从未见过：
.NET Core工具收集使用情况数据以改善您的体验。
数据是匿名的，不包含命令行参数。
数据由Microsoft收集并与社区共享。
您可以通过使用自己喜欢的shell将DOTNET_CLI_TELEMETRY_OPTOUT环境变量设置为1来退出遥测。
您可以在https://aka.ms/dotnet-cli-telemetry中了解有关.NET Core工具遥测的更多信息
。
我想提一提，我认为monodevelop（又名Xamarin Studio，Mono IDE或现在在Mac上称为Visual Studio Mac）已经发展得相当不错，并且在很大程度上是可以使用的。
但是，JetBrains Rider（此时为2018 EAP）绝对更好，更可靠（并且随附的反编译器是生命安全的），也就是说，如果您在Linux或Mac上开发.NET-Core。但是，MonoDevelop在.NET Core中的Linux上不支持Debug-StepThrough，因为MS没有许可其调试API dll（VisualStudio Mac ...除外）。但是，可以通过用于MonoDevelop的Samsung Debugger的.NET Core调试器扩展来使用用于.NET Core的Samsung调试器。
免责声明：
我不使用Mac，所以我不能说我在这里写的内容是否也适用于基于FreeBSD-Unix的Mac。我指的是JetBrains Rider，mono，MonoDevelop / VisualStudioMac / XamarinStudio和.NET-Core的Linux（Debian / Ubuntu / Mint）版本。此外，苹果公司正在考虑从英特尔处理器向基于ARM（ARM-64？）的自行制造处理器的转变，因此目前适用于Mac的大部分内容可能在将来（2020年或以后）不适用于Mac。
另外，当我写“ mono非常不稳定且缓慢”时，不稳定与WinFroms＆WebForms应用程序有关，特别是通过fastcgi或XSP（在mono 4.x版本上）执行Web应用程序，以及XML序列化。 -处理特性，并且相当慢的与WinForms有关，尤其是与正则表达式有关（ASP.NET-MVC也使用正则表达式进行路由）。
当我写有关Mono 2.x，3.x和4.x的经验时，这也不一定意味着这些问题现在或您阅读本文时尚未解决，或者是否已经解决。现在已修复，以后将无法进行回归以重新引入所有这些错误/功能。这也并不意味着如果嵌入Mono运行时，您将获得与使用（dev）系统的Mono运行时相同的结果。这也不意味着嵌入Mono-runtime（在任何地方）都是免费的。
所有这些并不一定意味着mono不适合iOS或Android，或者那里存在相同的问题。我在Android或IOS上不使用Mono，因此我对在这些平台上的稳定性，可用性，成本和性能没有任何意见。显然，如果在Android上使用.NET，则还需要考虑其他一些成本因素，例如权衡xamarin成本与成本以及将现有代码移植到Java的时间。有人听说Android和IOS上的单声道会相当不错。撒一粒盐。首先，不要期望默认系统编码在android / ios与Windows上是相同的，不要期望android文件系统不区分大小写，也不要期望任何Windows字体存在。