.NET Core与Mono
.NET Core和Mono有什么区别？
我在官方网站上发现了一个声明：“为它编写的代码也可以跨应用程序堆栈移植，如Mono。”
我的目标是使用C＃，LINQ，EF7和Visual Studio创建一个可以在Linux上运行/托管的网站。
有人告诉我他想让它成为“单声道”，但我不知道这意味着什么。 我知道我想用我上面列出的技术来使用.NET Core 1.0。 他还表示他想使用“快速CGI”。 我不知道这是什么意思。
你能帮我理解这些条款吗？如果我的期望是现实的？
Necromancing。
提供实际答案。
.Net Core和Mono有什么区别？
.NET Core在很大程度上是重写ASP.NET MVC框架（和控制台应用程序）以减少依赖关系，使其更加模块化并提高性能。
<edit>Console Applications: this includes server applications IMHO</edit>
重点是启用“本地编译”/自包含部署（因此您不需要在目标机器上安装.NET框架/ VM。
这在“云计算”中很有用，因为您可以只使用您喜欢的任何版本的dotnet-CORE框架，并且不必担心系统管理员实际使用.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＃东西在mono上编译，而不是VB.NET的东西。
某些高级功能（如WSE / WCF和WebParts）缺失。
许多实现是不完整的（例如，在ECDSA加密中抛出NotImplementedException），错误（例如带有Firebird的ODBC / ADO.NET），行为与.NET（例如XML序列化）或其他不稳定（ASP.NET MVC）令人无法接受的缓慢（正则表达式）。
但是，不要指望跨平台意味着您实际上可以在ARM-Linux上安装.NET Core，就像使用elasticsearch一样。 你将不得不从源代码编译整个框架。
也就是说，如果你有空间的话（例如在Chromebook上，总共有16到32 GB的高清）。
跨平台非常多。
我在官方网站上发现了一个声明，说：“为它编写的代码也可以跨应用程序堆栈移植，如Mono”。
只要代码不依赖于WinAPI调用，Windows-dll-pinvokes，COM-Components，不区分大小写的文件系统，并且不存在目录分隔符问题，那就是正确的。 但是，.NET核心代码在.NET核心上运行，而不是在单声道上运行。 所以混合这两个将是困难的。 由于单声道是相当不稳定和缓慢，我不会推荐它。 尝试使用.NET核心进行图像处理，例如WebP或移动GIF或multipage-tiff或在图像上编写文本，您会感到惊讶。
<edit>作为每中期2017年2月：可以使用用于SkiaSharp现在（例如） </edit>
不为.NET编写的代码（非核心）不能移植到.NET核心。
这意味着如果您希望像PDFSharp这样的非GPL C＃库创建PDF文档（非常普遍），那么您运气不佳（目前）。 不要介意ReportViewer控件，该控件使用Windows-pInvokes（无论出于何种原因），甚至不在Linux上以单声道运行。
此外，使用.NET核心编写的代码不能移植到单声道，因为mono缺少.NET核心运行时库（还）。
我的目标是使用C＃，LINQ，EF7，Visual Studio创建一个可以在Linux中运行/托管的网站。
在目前为止我尝试过的任何版本中，EF都非常慢（甚至在一个表格中只有一个左连接这样简单的事情），我不会推荐它，也不会在Windows上。
如果您有一个具有唯一约束的数据库，或者varbinary / filestream / hierarchyid列，我尤其不会推荐EF。 （不适用于模式更新）
而且在数据库性能非常关键的情况下（比如说10+到100+以上的并发用户）。
另外，在Linux上运行网站/网络应用程序迟早意味着您将不得不进行调试。
Linux上没有.NET Core的调试支持。 （不再了，但需要JetBrains骑士）
MonoDevelop不支持调试.NET核心项目。
如果你有问题，你是自己的。 你将不得不使用广泛的日志记录。
请小心，建议广泛的日志记录将立即填满您的磁盘，特别是如果您的程序进入了循环或递归循环。
如果您的web-app以root身份运行，这是特别危险的，因为登录需要日志文件空间 - 如果没有剩余空间，您将无法再登录。
（通常，大约5％的磁盘空间是为root用户保留的[在Windows上也称为管理员]，所以如果磁盘快满了，至少管理员仍然可以登录，但是如果你的应用程序以root身份运行，那么这个限制不适用于他们磁盘使用率，因此他们的日志文件可以使用剩余空间的100％，因此即使管理员也不能再登录。）
因此，最好不要加密该磁盘，也就是说，如果你重视你的数据/系统。
有人告诉我他想让它成为“单声道”，但我不知道这意味着什么。
这意味着他不想使用.NET Core，或者他只想在Linux / Mac上使用C＃。 我的猜测是他只想在Linux上使用C＃作为Web-App。 如果你绝对想用C＃来完成这项工作，那么.NET Core就是其中的选择。 不要与“单音适当”去; 表面上看，它似乎起初工作 - 但相信我，你会后悔，因为单声道的ASP.NET MVC是不稳定的，当你的服务器长期运行（超过1天） - 你现在已被警告。 在techmpower基准测量单声道性能时，请参见“未完成”参考。
我知道我想用我上面列出的技术来使用.Net Core 1.0框架。 他还表示他想使用“快速CGI”。 我不知道这是什么意思。
这意味着他想使用像nginx（Engine-X）这样的高性能全功能WebServer，可能是Apache。
然后他可以使用基于虚拟名称的托管（同一IP上的多个域名）和/或负载平衡运行mono / dotnetCore。 他还可以使用其他技术运行其他网站，而无需在Web服务器上使用不同的端口号。 这意味着您的网站在fastcgi服务器上运行，并且nginx将通过fastcgi协议将某个域的所有web请求转发到该服务器。 这也意味着您的网站在fastcgi-pipeline中运行，并且您必须小心处理您的操作，例如在传输文件时不能使用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另一个版本......但它应该在同一台计算机上运行。
不要介意它应该在操作系统默认发布的节点版本上运行。
不要介意，首先不应该依赖NodeJS。
kestell服务器也在工作中。
根据我对mono-project的经验，我非常怀疑他们曾经在FastCGI上测试过.NET Core，或者他们知道FastCGI支持对于他们的框架意味着什么，更别说他们测试了它，以确保“一切正常”。 实际上，我刚刚尝试使用.NET Core制作fastcgi应用程序，并且刚刚意识到没有用于.NET Core“RTM”的FastCGI库...
因此，当您要在nginx后面运行.NET Core“RTM”时，您只能通过代理请求到kestrell（半成品nodeJS派生的web服务器）来执行此操作 - 目前在.NET Core中没有对fastcgi的支持“RTM”，AFAIK。 由于没有.net core fastcgi库，也没有样例，所以任何人都不太可能在框架上进行任何测试，以确保fastcgi按预期工作。
我也质疑表演。
在（预备）techempower基准测试（第13轮）中，aspnetcore-linux相对于最佳性能排名25％，而类似Go（golang）的框架排名在最高性能的96.9％（即没有文件返回纯文本仅限系统访问）。 .NET Core在JSON序列化上做得稍微好一点，但它看起来并不令人满意（达到峰值的98.5％，.NET核心的65％）。 这就是说，它不可能比“单身”更糟糕。
另外，由于它还比较新，所以并不是所有的主要图书馆都已经被移植，我怀疑它们中的一些将会被移植。
成像支持最多也是有问题的。
对于任何加密，请改用BouncyCastle。
你能帮我理解这些条款吗？ 如果我的期望是现实的 ？
我希望我帮助你更好地理解这些条款。
就你的期望而言：
在不了解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，这是另一个优点。
就mono而言，远离它。
单声道到底有多远并不奇怪，但不幸的是，这无法替代其生产应用的性能/可扩展性和稳定性问题。
此外，单发展已经完全失效，他们主要只是开发与Android和iOS相关的部分，因为这就是Xamarin赚钱的地方。
不要指望Web开发成为一流的Xamarin / mono公民。
.NET Core可能是值得的，如果你开始一个新的项目，但是对于现有的大型Web表单项目，移植很大程度上是不可能的，所需的改变是巨大的。 如果你有一个MVC项目，如果你的原始应用程序设计很健全，大多数现存的所谓的“历史增长”应用程序都不是这种情况，那么更改的数量可能是可管理的。
2016年12月更新：
本地编译已从.NET Core预览中删除，因为它尚未准备就绪...
看起来他们已经在原始文本文件基准测试中得到了很大的改进，但另一方面，它变得非常麻烦。 此外，它在JSON基准测试中进一步恶化。 还好奇的是，实体框架的更新速度要快于Dapper--尽管这两者的记录速度都很慢。 这是不太可能的。 看起来还有不止是寻找一些错误。
此外，Linux IDE前端似乎也有所缓解。
IntelliJ发布了“Project Rider”，这是一个可以处理Visual Studio项目文件的Linux（和Mac和Windows）的C＃/ .NET Core IDE的早期访问预览。 最后是一个可用的C＃IDE，这个IDE并不慢。
结论：随着我们进入2017年，.NET Core仍然是预发布质量软件。将您的库移植到其他库中，但在生产过程中远离它，直到框架质量稳定为止。
并留意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目录中，Skia将在Windows 8.1上运行。）
2017年8月更新
.NET Core 2.0发布。
小心 - 伴随着（巨大的中断）更改认证...
好处是，它带回了DataTable / DataAdaper / DataSet类，等等。
已实现的.NET Core仍然缺少对Apache SparkSQL的支持，因为Mobius尚未移植。 这很糟糕，因为这意味着我的IoT Cassandra集群不支持SparkSQL，所以没有连接...
实验性ARM支持（仅适用于运行时，不适用于SDK - 对于我的Chromebook上的devwork太糟糕了 - 期待2.1或3.0）。
PdfSharp现在通过实验移植到.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，没有bug修正版本2.0）。
但是我没有在我的机器上安装预览版本。 等等。
据说2.1版也大大减少了编译时间。 那会很好。
另外请注意，在Linux上，.NET Core仅为64位 ！
Linux上没有，也没有，x86-32版本的.NET Core。
而ARM端口仅限于ARM-32。 没有ARM-64，但。
PS：
export DOTNET_CLI_TELEMETRY_OPTOUT=1
如果你已经在Windows上使用过它，你可能从来没有见过这样的事情：
.NET Core工具收集使用数据以改善您的体验。
数据是匿名的，不包括命令行参数。
数据由微软收集并与社区分享。
您可以通过使用您喜欢的shell将DOTNET_CLI_TELEMETRY_OPTOUT环境变量设置为1来退出遥测。
您可以阅读更多关于.NET Core工具telemetry @ https://aka.ms/dotnet-cli-telemetry。
在.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的核心CLR实现，linux（各种）和unix（Mac OS X和FreeBSD）的组合。 微软已经或正在重构Core CLR的.NET框架库，以使它们更加便于核心上下文。 鉴于mono在* nix操作系统上的存在，如果用于* nix的核心CLR不包含某些单声道代码库，那将是一个惊喜，但只有Mono社区和微软可以肯定地告诉我们。
另外，我同意Nico的看法：核心CLR是新的 - 我认为这是在RC2。 我不会依赖它来生产代码。
要回答您的问题，您可以使用Core CLR或Mono在Linux上交付您的站点，而这些是两种不同的方式。 如果你现在想要一个安全的赌注，我会在Linux上使用单声道，然后如果你想稍后再使用端口到Core。
你不仅选择了一条现实的道路，而且可以说是MS最有力的支持（也是X平台）的生态系统之一。 你还应该考虑以下几点：
我希望它有帮助
链接地址: http://www.djcxy.com/p/90123.html上一篇: .NET Core vs Mono