.NET Core 与 Mono

死灵术。提供实际答案。

.Net Core 和 Mono 有什么区别？

.NET Core 现在正式成为 .NET 的未来。它的大部分开始于对 ASP.NET MVC 框架和控制台应用程序的重写，其中当然包括服务器应用程序。 （由于它是图灵完备的并且支持与 C dll 的互操作，如果您绝对愿意，您也可以使用它编写自己的桌面应用程序，例如通过像 Avalonia 这样的 3rd-party 库，这在我第一次写这篇文章的时候，这意味着你几乎仅限于 Web 或服务器的东西。）随着时间的推移，许多 API 已添加到 .NET Core 中，以至于在 3.1 版之后，.NET Core 将跳转到 5.0 版，被称为没有“核心”的 .NET 5.0，这将是 .NET Framework 的未来。过去完整的 .NET Framework 将作为完整的 .NET Framework 4.8.x 在维护模式下徘徊数十年，直到它死去（也许还会有一些升级，但我对此表示怀疑）。 In other words, .NET Core is the future of .NET, and Full .NET Framework will go the way of the Dodo/Silverlight/WindowsPhone。

.NET Core 的重点，除了多平台支持之外，是为了提高性能，并启用“本机编译”/自包含部署（因此您不需要在目标机器上安装 .NET 框架/VM . 一方面，这意味着 docker.io 在 Linux 上的支持，另一方面，自包含部署在“云计算”中很有用，因为那时你可以使用任何你喜欢的 dotnet-CORE 框架版本，而且您不必担心系统管理员实际安装了哪个版本的 .NET 框架。

虽然 .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 中没有表单设计器：它稍后会在未指定的时间随 Visual Studio 更新一起发布。

.NET Core 仍然不支持 WebForms，也没有计划支持它们（Blazor 是这方面的新手）。

.NET Core 还附带 System.Runtime，它取代了 mscorelib。

通常，.NET Core 与 NetStandard 混合在一起，后者是 System.Runtime/mscorelib（和其他一些）的一个包装器，允许您编写针对 .NET Core、完整 .NET Framework 和 Xamarin（iOS /Android），同时。

.NET Core SDK 在 ARM 上不起作用/不起作用，至少我上次检查时没有。

"The Mono Project" 比 .NET Core 古老得多。
Mono 是西班牙语，意思是猴子，顺便说一句，这个名称与单核细胞增多症无关（提示：您可以在 http://primates.ximian.com 下获得工作人员列表/)。
Mono 于 2005 年由 Miguel de Icaza（启动 GNOME 的人以及其他一些人）作为 Linux 的 .NET Framework (Ximian/SuSe/Novell) 的实现而创建。 Mono 包括 Web-Forms、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 支持 Mono（以前是 Ximian 的新公司名称，当时他们专注于移动市场，而不是 Linux 市场），而不是被微软收购。
（因为 Xamarin 被微软收购，这在技术上 [但不是文化上] 微软。）
你通常会得到你的 C# 东西在单声道上编译，但不是 VB.NET 的东西。
Mono 遗漏了一些高级功能，例如 WSE/WCF 和 WebParts。
许多 Mono 实现不完整（例如，在 ECDSA 加密中抛出 NotImplementedException），有缺陷（例如，带有 Firebird 的 ODBC/ADO.NET），行为不同于在 .NET 上（例如 XML 序列化）或其他不稳定（ASP.NET MVC）和不可接受的慢（正则表达式）。从好的方面来说，Mono 工具链也适用于 ARM。

就 .NET Core 而言，当他们说跨平台时，不要期望跨平台意味着您实际上可以在 ARM-Linux 上 apt-get 安装 .NET Core，就像使用 ElasticSearch 一样。您必须从源代码编译整个框架。也就是说，如果您有该空间（例如，在 Chromebook 上，总 HD 容量为 16 到 32 GB）。它还曾经存在与 OpenSSL 1.1 和 libcurl 不兼容的问题。这些已在 .NET Core 版本 2.2 的最新版本中得到纠正。跨平台就这么多。

我在官方网站上找到了一条声明，上面写着“为它编写的代码也可以跨应用程序堆栈移植，例如 Mono”。

只要该代码不依赖于 WinAPI 调用、Windows-dll-pinvokes、COM 组件、不区分大小写的文件系统、默认系统编码（代码页）并且没有目录分隔符问题，那就是正确的。但是，.NET Core 代码在 .NET Core 上运行，而不是在 Mono 上运行。所以将两者混合起来会很困难。而且由于 Mono 非常不稳定且速度很慢（对于 Web 应用程序），我无论如何也不推荐它。尝试在 .NET 核心上进行图像处理，例如 WebP 或移动 GIF 或 multipage-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 不一定安全，并且有很多潜在或真实的内存泄漏，这就是为什么您不应该在网络应用程序；请注意，SkiaSharp 比 ImageSharp 快得多，因为它使用本机库（这也可能是一个缺点）。另外请注意，虽然 GDI+ 可以在 Linux 和 Mac 上运行，但这并不意味着它可以在 iOS/Android 上运行。

不是为 .NET（非核心）编写的代码不能移植到 .NET Core。
意思是，如果您想要一个非 GPL C# 库（如 PDFSharp）来创建 PDF 文档（非常普遍），那么您就完了运气（目前）（not anymore）。不用介意 ReportViewer 控件，它使用 Windows-pInvokes（加密、通过 COM 创建 mcdf 文档，并获取字体、字符、字距调整、字体嵌入信息、测量字符串和进行换行，以及实际绘制质量可接受的 tiff） ，甚至不能在 Linux 上的 Mono 上运行
(I'm working on that)。

此外，用 .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 上将 C# 用于 Web-App。如果您绝对想在 C# 中执行此操作，那么 .NET Core 就是您的理想之选。不要选择“单声道”；从表面上看，它一开始似乎可以工作——但相信我你会后悔的，因为当你的服务器长期运行（超过 1 天）时 Mono 的 ASP.NET MVC 不稳定——你现在已经被警告了。在 techempower 基准测试中测量 Mono 性能时，另请参阅“未完成”参考。

https://i.stack.imgur.com/YuCUc.png

我知道我想将 .Net Core 1.0 框架与上面列出的技术一起使用。他还说他想使用“快速cgi”。我也不知道那是什么意思。

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

总结一下：.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）失败了，至少在我的机器上，我'我确定我不是唯一一个有这个问题的人。调试，也许使用 Visual Studio Code，如果你可以在 ARM 上构建它（我设法做到了 - 如果你这样做，请不要遵循 Scott Hanselman 的博客文章 - 在 github 上的 VS-Code wiki 中有一个操作方法），因为他们不提供可执行文件。约曼也失败了。 （我想这与您安装的 nodejs 版本有关 - VS Code 需要一个版本，Yeoman 另一个......但它应该在同一台计算机上运行。很蹩脚没关系，它应该在默认提供的节点版本上运行在操作系统上。没关系，首先不应该依赖 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 按预期工作。

我也质疑表现。
在 (preliminary) techempower-benchmark (round 13) 中，aspnetcore-linux 相对于最佳性能排名 25%，而像 Go (golang) 等可比框架的峰值性能排名为 96.9%（这是仅在没有文件系统访问的情况下返回纯文本时） ）。 .NET Core 在 JSON 序列化方面做得更好一些，但看起来也不是很吸引人（go 达到峰值的 98.5%，.NET core 为 65%）。也就是说，它不可能比“单声道”更糟糕。

此外，由于它仍然相对较新，并非所有主要库都已被移植（尚未），我怀疑其中一些会被移植。成像支持充其量也是值得怀疑的。对于任何加密，请改用 BouncyCastle。

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

我希望我能帮助你理解所有这些术语。就您的期望而言：首先，在不了解 Linux 的情况下开发 Linux 应用程序是一个非常愚蠢的想法，而且它也必然会以某种可怕的方式失败。就是说，因为 Linux 不收取任何许可费用，所以原则上这是一个好主意，但前提是您知道自己在做什么。为无法调试应用程序的平台开发应用程序是另一个非常糟糕的主意。在不知道后果的情况下为 fastcgi 进行开发是另一个非常糟糕的主意。

如果您的项目不仅仅是个人主页，那么在不了解该平台的细节且没有调试支持的情况下在“实验性”平台上做所有这些事情就是自杀。另一方面，我想用你的个人主页来学习可能是一个很好的体验——然后你就会知道框架是什么，非框架问题是什么。
You can for example (programmatically) loop-mount a case-insensitive fat32, hfs or JFS for your application, to get around the case-sensitivity issues (loop-mount not recommended in production).

总结
目前（2016-09-28），我会远离 .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-Development 成为一流的 Xamarin/mono 公民。如果您开始一个新项目，.NET Core 可能是值得的，但对于现有的大型 Web 表单项目，移植在很大程度上是不可能的，所需的更改是巨大的。如果您有一个 MVC 项目，那么如果您的原始应用程序设计是合理的，那么更改的数量可能是可控的，对于大多数现有的所谓的“历史发展”应用程序来说，情况大多不是这样。

2016 年 12 月更新：本机编译已从 .NET Core 预览版中删除，因为它还没有准备好......似乎他们在原始文本文件基准测试方面已经有了很大的改进，但另一方面，它变得相当有问题。此外，它在 JSON 基准测试中进一步恶化。还奇怪的是，实体框架的更新速度应该比 Dapper 快——尽管两者都处于创纪录的缓慢状态。这不太可能是真的。看起来还有不止一些 bug 需要寻找。此外，Linux IDE 方面似乎也有所缓解。 JetBrains 发布了“Project Rider”，这是适用于 Linux（以及 Mac 和 Windows）的 C#/.NET Core IDE 的早期访问预览版，可以处理 Visual Studio 项目文件。最后是一个可用的 C# IDE，而且速度并不慢。

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

https://i.stack.imgur.com/Yg7vZ.png

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

注意：根据 .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 文件，因此在部署时，您可能会遇到问题，尤其是临时目录被组策略锁定或其他一些问题时。不过，它适用于 hello-world 程序。如果你不缩小，可执行文件大小将在 100 MB 左右。

你会得到一个独立的 .exe 文件（在发布目录中），你可以将它移动到没有安装 .NET 框架的 Windows 8.1 机器上并让它运行。好的。正是在这里，dotNET-Core 才开始变得有趣。 （注意差距，SkiaSharp doesn't work on 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 尚未移植。这很糟糕，因为这意味着我的 IoT Cassandra 集群不支持 SparkSQL，因此不支持连接...
实验性 ARM 支持（仅限运行时，不支持 SDK - 对我的 Chromebook 上的开发工作来说太糟糕了 - 期待 2.1 或 3.0）。
PdfSharp is now experimentally ported to .NET Core.
JetBrains Rider 离开了 EAP。您现在可以使用它来开发 &在 Linux 上调试 .NET Core - 虽然到目前为止只有 .NET Core 1.1，直到 .NET Core 2.0 支持更新上线。

2018 年 5 月更新即将发布的 .NET Core 2.1。也许这将修复 Linux 上的 NTLM 身份验证（NTLM 身份验证在具有多个身份验证标头的 .NET-Core 2.0 中的 Linux {和可能的 Mac} 上不起作用，例如协商，通常与 ms-exchange 一起发送，它们显然是仅在 v2.1 中修复它，2.0 没有错误修复版本）。但我没有在我的机器上安装预览版。所以等待。据说 v2.1 也大大减少了编译时间。那会很好。

另外，请注意，在 Linux 上，.NET Core 是 64-Bit only ！
There is no, and there will be no, x86-32 version of .NET Core on Linux.
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。 So if you're using Arch Linux, you're out of luck (with Gentoo, too).

编辑：

最新版本的 .NET Core 2.2+ 支持 OpenSSL 1.1。所以你可以在 Arch 或 (k)Ubuntu 19.04+ 上使用它。不过，您可能必须使用 .NET-Core 安装脚本，因为还没有包。

https://i.stack.imgur.com/8f5kL.png

https://i.stack.imgur.com/2rWKn.png

.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-Core-Designer。设计师最终会在某个时候提供 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 来选择退出遥测。您可以阅读更多关于 .NET Core 工具遥测 @ https://aka.ms/dotnet-cli-telemetry。

我想我会提到我认为 monodevelop（又名 Xamarin Studio、Mono IDE 或 Visual Studio Mac，因为它现在在 Mac 上被称为）已经发展得非常好，并且在此期间 - 在很大程度上是可用的。
但是，JetBrains Rider（此时为 2018 EAP）肯定更好更可靠（并且包含的反编译器更安全），也就是说，如果你在 Linux 上开发 .NET-Core或麦克。但是，MonoDevelop 不支持 .NET Core 中的 Linux 上的 Debug-StepThrough，因为 MS 没有许可他们的调试 API dll（VisualStudio Mac 除外）。但是，您可以通过 .NET Core debugger extension for Samsung Debugger for MonoDevelop 使用 Samsung debugger for .NET Core

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

此外，当我写“mono 非常不稳定和缓慢”时，不稳定与 WinFroms 和 WebForms 应用程序有关，特别是通过 fastcgi 或 XSP（在 mono 的 4.x 版本上）执行 Web 应用程序，以及 XML 序列化-处理特性，并且非常慢涉及 WinForms，特别是正则表达式（ASP.NET-MVC 也使用正则表达式进行路由）。

当我写下我对单声道 2.x、3.x 和 4.x 的体验时，这也不一定意味着这些问题到现在还没有解决，或者在您阅读本文时，如果它们是现在已修复，以后不会有回归来重新引入这些错误/功能中的任何一个。这也不意味着如果您嵌入单声道运行时，您将获得与使用（开发）系统的单声道运行时相同的结果。这也不意味着嵌入单运行时（任何地方）一定是免费的。

这并不一定意味着单声道不适合 iOS 或 Android，或者它在那里有同样的问题。我不在 Android 或 IOS 上使用 mono，所以我无权谈论这些平台上的稳定性、可用性、成本和性能。显然，如果您在 Android 上使用 .NET，您还需要考虑其他一些成本问题，例如权衡 xamarin 成本与将现有代码移植到 Java 的成本和时间。在 Android 和 IOS 上听单声道应该是相当不错的。带上一粒盐。一方面，不要期望默认系统编码在 android/ios 与 Windows 上相同，不要期望 android 文件系统不区分大小写，也不要期望任何 windows 字体存在.

---

在 .NET 世界中，有两种类型的 CLR，“完整”CLR 和核心 CLR，它们是完全不同的东西。

有两个“完整”的 CLR 实现，Microsoft 本机 .NET CLR（适用于 Windows）和 Mono CLR（它本身具有适用于 Windows、linux 和 unix（Mac OS X 和 FreeBSD）的实现）。一个完整的 CLR 正是你需要的一切。因此，“完整”CLR 的大小往往很大。

另一方面，核心 CLR 被削减了，而且要小得多。因为它们只是一个核心实现，它们不太可能包含您需要的一切，因此使用核心 CLR，您可以使用 NuGet 将功能集添加到您的特定软件产品使用的 CLR。有适用于 Windows、linux（各种）和 unix（Mac OS X 和 FreeBSD）的 Core CLR 实现。 Microsoft 已经或正在重构 Core CLR 的 .NET 框架库，以使它们对于核心上下文更具可移植性。鉴于 mono 在 *nix 操作系统上的存在，如果 *nix 的核心 CLR 不包含一些 mono 代码库，那将是一个惊喜，但只有 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 core 1.0 RTM

虽然 mono 功能更完整，但它的未来尚不清楚，因为 MS 拥有它几个月了，而且它是他们支持它的重复工作。但 MS 绝对致力于 .Net Core 并在其上投入巨大。

虽然 .Net core 发布了，但 3rd 方生态系统还不够完善。例如 Nhibernate、Umbraco 等还不能在 .Net 内核上运行。但他们有一个计划。

.Net Core 中缺少一些功能，例如 System.Drawing，您应该寻找 3rd 方库

对于 asp.net 应用程序，您应该使用 nginx 作为前端服务器和 kestrelserver，因为 kestrelserver 还没有为生产做好准备。例如 HTTP/2 没有实现。

我希望它有帮助

---

这不再是 .NET Core 与 Mono 的对比。是统一的。

截至 2020 年 11 月的更新 - 发布了统一 .NET Framework 和 .NET Core 的 .NET 5

.NET 和 Mono 将在 2021 年 11 月发布的 .NET 6 下统一

.NET 6.0 将添加 net6.0-ios 和 net6.0-android。

特定于操作系统的名称可以包括操作系统版本号，例如 net6.0-ios14。

检查以下文章：

https://devblogs.microsoft.com/dotnet/introducing-net-multi-platform-app-ui/

https://github.com/dotnet/maui

---

.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 文档没有 rc2 可用），但是 mono 不是 Microsoft 支持的框架，建议使用支持的框架

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

我目前正在使用这两个框架，但是您必须了解它仍处于发布候选阶段（RC2 是当前版本）并且超过了 beta 和发布候选版本已经发生了巨大的变化，通常最终会让你摸不着头脑。

这是有关如何将 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 社区中仍然相对较新，在它完全发布之前，鉴于发布版本之间的重大变化，我会犹豫在产品环境中使用它。

---

这个问题特别实际，因为昨天微软正式announced .NET Core 1.0 release。假设 Mono 实现了大部分标准的 .NET 库，那么通过 .NET Framework 和 .NET Core 的区别可以看出 Mono 和 .NET Core 的区别：

API — .NET Core 包含许多与 .NET Framework 相同但更少的 API，并且具有不同的因式分解（程序集名称不同；关键情况下的类型形状不同）。这些差异目前通常需要将源端口更改为 .NET Core。 .NET Core 实现了 .NET 标准库 API，随着时间的推移，它将包含更多的 .NET Framework BCL API。子系统 - .NET Core 实现了 .NET Framework 中的子系统子集，目标是更简单的实现和编程模型。例如，不支持代码访问安全 (CAS)，但支持反射。

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

我的目标是使用 C#、LINQ、EF7、visual studio 创建一个可以在 linux 中运行/托管的网站。

Linq 和实体框架 are included in .NET Core，因此您可以放心尝试。

---

简单来说，

Mono 是 Linux/Android/iOs .Net 框架的第三方实现。Net Core 是微软自己的实现。

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

---

这是我最喜欢的主题之一，这里的内容真是太棒了。我在考虑比较 Runtime 与 Mono 中可用的方法是否值得或有效。我希望我的条件是正确的，但我想你知道我的意思。为了更好地了解每个运行时当前支持的内容，比较它们提供的方法是否有意义？我意识到实现可能会有所不同，并且我没有考虑过框架类库或在一个环境与另一个环境中可用的大量其他库。我也意识到有人可能已经更有效地完成了这项工作。如果您能告诉我，我将不胜感激，以便我对其进行审查。我觉得在此类活动的结果之间进行比较是有价值的，并且想看看更有经验的开发人员对此有何感受，他们是否会提供有用的指导。回来时我在玩反射，并编写了一些遍历 .net 目录的 lines 并列出程序集。

---