.NET Core与Mono [英] .NET Core vs Mono
问题描述
.NET Core和Mono之间有什么区别?
我在官方网站上发现一条声明:为此编写的代码也可以跨应用程序堆栈(例如Mono)移植."
我的目标是使用C#，LINQ，EF7和Visual Studio创建一个可以在Linux上运行/托管的网站.
有人告诉我他希望它成为单声道"，但我不知道那是什么意思.我知道我想将.NET Core 1.0与上面列出的技术一起使用.他还说他想使用快速CGI".我也不知道那是什么意思.
如果我的期望是现实的，您能帮助我理解所有这些术语吗?
创新.
提供实际答案.
.Net Core和Mono有什么区别?
.NET Core 现在正式是.NET的未来.它的开始大部分是重新编写 ASP.NET MVC 框架和控制台应用程序，其中当然包括服务器应用程序. (由于它是图灵完备的，并且支持与C dll的互操作，因此，如果您绝对愿意，还可以使用它编写自己的桌面应用程序，例如通过诸如 Avalonia ，这在我第一次写这篇文章时是非常基本的，这意味着您几乎只限于Web或服务器. .NET Core已添加了许多API，以至于在3.1版之后，.NET Core将跳至5.0版，即不带"Core"的.NET 5.0，这将是.NET的未来.框架.过去，完整的.NET Framework将在维护模式下像完整的.NET Framework 4.8.x徘徊数十年，直到它消失(也许仍然会有一些升级，但我对此表示怀疑). 换句话说，.NET Core是.NET和完整.NET Framework的未来将按照Dodo/Silverlight/WindowsPhone 的方式进行.
.NET Core的主要观点，除了多平台支持之外，还在于提高性能和启用本机编译"/自包含部署(因此您不需要在.NET Framework上安装.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，，而且永远都没有计划支持它们( NetStandard 混用围绕System.Runtime/mscorelib(以及其他一些)的包装，使您可以同时编写针对.NET Core，Full .NET Framework和Xamarin(iOS/Android)的库.
- .NET Core SDK无法/不能在ARM上运行，至少在我上次检查时不是.
>" Mono 项目" 比.NET年代久远核心.
Mono是西班牙语，意为Monkey，此外，该名称与Mononucleosis无关(提示:您可以在 Miguel de Icaza (以 MonoDevelop (也称为Xamarin Studio)的IDE.或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. .您必须从源代码编译整个框架.
也就是说，如果您有足够的空间(例如，在Chromebook上具有16到32 GB的总高清空间).
它还曾经存在与OpenSSL 1.1和libcurl不兼容的问题.
这些已在最新版本的.NET Core版本2.2中得到纠正.
跨平台就这么多.
我在官方网站上找到一条声明，说:为 它也可以跨应用程序堆栈(例如Mono")移植.
只要该代码不依赖WinAPI调用，Windows-dll-pinvokes，COM-Components，不区分大小写的文件系统，默认系统编码(代码页)并且没有目录分隔符问题，这是正确的.但是，.NET Core代码在.NET Core上运行，而不在Mono上运行.因此，将两者混合是困难的.而且由于Mono非常不稳定且运行缓慢(对于Web应用程序)，因此无论如何我都不会推荐它.尝试在.NET Core上进行图片处理，例如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 App中[基本上共享 托管?])
到目前为止，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文档(很平常)，那么(现在)(我正在为此工作).
此外，用.NET Core编写的代码不能移植到Mono上，因为Mono到目前为止没有.NET Core运行时库.
我的目标是使用C#，LINQ，EF7，Visual Studio创建网站 可以在linux中运行/托管.
到目前为止，我尝试使用的任何版本的EF都是如此之慢(即使在诸如带有一个左联接的一张表之类的简单事情上)，我也不推荐使用它-也不在Windows上.
如果您的数据库具有unique-constrains或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.
否则，文件将在目标位置显示乱码.
另请参见此处和此处.. >
总结:
当前(2016-09-28)的.NET Core并不是真正可移植的，也不是真正的跨平台(尤其是调试工具).
本机编译也不容易，尤其是对于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的博客文章-VS Wiki中有一个方法-github上的代码)，因为它们不提供可执行文件.
Yeoman也失败了. (我想这与您安装的nodejs版本有关-VS Code需要一个版本，而Yeoman需要另一个版本...但是它应该在同一台计算机上运行.pretty lame
没关系，它应该在操作系统上默认提供的节点版本上运行.
没关系，首先应该不依赖NodeJS.
kestell服务器也在进行中.
从我在单一项目中的经验来看，我非常怀疑他们是否曾在FastCGI上测试过.NET Core，或者是否知道FastCGI支持对其框架意味着什么，更不用说他们对其进行了测试以确保一切正常" ".实际上，我只是尝试使用.NET Core创建一个fastcgi应用程序，只是意识到没有针对.NET Core"RTM"的FastCGI库...
因此，当您要在nginx后面运行.NET Core"RTM"时，只能通过将请求代理到kestrell(该半成品的nodeJS派生的Web服务器)上来进行处理-目前，不存在fastcgi支持.NET Core"RTM"，AFAIK.由于没有.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年12月更新: 结论:随着我们进入2017年，.NET Core仍然是预发布质量的软件.移植您的库，但不要将其用于生产用途，直到框架质量稳定为止. 2017更新 您可以运行
但是，与go不同，它不是静态链接的可执行文件，而是自解压的zip文件，因此在部署时，您可能会遇到
问题，尤其是在临时目录已按组锁定的情况下
政策或其他一些问题.可以正常工作
你好，世界计划.而且，如果您不缩小文件大小，则可执行文件的大小大约为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月更新 2018年5月更新 此外，请注意，在Linux上，.NET Core是仅64位 ！ 还有一件事: .NET Core 2.2+的最新版本支持OpenSSL 1.1.所以你可以使用
放在Arch或(k)Ubuntu 19.04+上.您可能必须使用 .NET-Core
不过要安装脚本，因为还没有软件包. 从好的方面来说，性能肯定有所提高:
.NET Core 3: 注意: PS: 如果您在Windows上使用过它，则可能从未见过: .NET Core工具收集使用情况数据以改善您的
经验. 我想提到的是，我认为monodevelop(又名Xamarin Studio，Mono IDE或现在在Mac上称为Visual Studio Mac)已经发展得相当不错，并且-在很大程度上-可以使用.
目前(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的调试支持
本机编译已从.NET Core预览中删除，因为它尚未准备好...
似乎它们在原始文本文件基准方面有了很大的改进，但另一方面，它却出现了很多问题.而且，它在JSON基准测试中进一步恶化.同样令人好奇的是，实体框架的更新速度要比Dapper快-尽管两者都处于创纪录的速度.这不太可能是真的.看起来仍有许多错误需要寻找.
另外，Linux IDE方面似乎也有所缓解.
JetBrains发布了"Project Rider"，这是Linux(以及Mac和Windows)的C#/.NET Core IDE的早期访问预览，可以处理Visual Studio Project文件.
最后，一个可用的C#IDE那并不慢.
并注意Project Rider.
目前已将我(兄弟的)主页迁移到.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
dotnet publish -r win-x64 -c Release /p:PublishSingleFile=true
dotnet publish -r linux-x64 -c Release /p:PublishSingleFile=true
.NET Core 2.0已发布.
小心-伴随着(巨大的)更改身份验证...
从好的方面来说，它带回了DataTable/DataAdaper/DataSet类，还有更多.
已实现的.NET Core仍然缺少对Apache SparkSQL的支持，因为尚未移植 Mobius .不好，因为这意味着我的IoT Cassandra群集不支持SparkSQL，因此没有联接...
实验性的ARM支持(仅运行时，而不是SDK-对我的Chromebook的开发工作来说太糟糕了-期待2.1或3.0).
PdfSharp现在已通过实验移植到.NET Core.
JetBrains Rider 离开了EAP.您现在可以使用它来开发&在Linux上调试.NET Core-尽管到目前为止只有.NET Core 1.1，直到支持.NET Core 2.0的更新发布为止.
.NET Core 2.1即将发布.
也许这可以修复Linux上的NTLM身份验证(NTLM身份验证在具有多个身份验证标头(例如通常通过ms-exchange发送的协商)的.NET-Core 2.0中的Linux {以及可能的Mac}上不起作用.仅在v2.1中进行了修复，没有针对2.0的错误修正发布).
但是我没有在计算机上安装预览版本.等等.
据说v2.1可以大大减少编译时间.那就好.
在Linux上没有，而且也没有x86-32版本的.NET Core a>.
并且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 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进行支持. echo "DOTNET_CLI_TELEMETRY_OPTOUT=1" >> /etc/environment
export DOTNET_CLI_TELEMETRY_OPTOUT=1
数据是匿名的，不包含命令行
论点.
数据由Microsoft收集并与
社区.
您可以通过设置一个
使用以下命令将DOTNET_CLI_TELEMETRY_OPTOUT环境变量设置为1
最喜欢的外壳.
您可以阅读有关.NET Core工具遥测的更多信息@
https://aka.ms/dotnet-cli-telemetry .
但是，JetBrains Rider(此时为2018 EAP)绝对更好，更可靠(并且随附的反编译器是生命安全的)，也就是说，如果您在Linux或Mac上开发.NET-Core.但是，MonoDevelop在.NET Core中的Linux上不支持Debug-StepThrough，因为MS不许可其调试API dll(VisualStudio Mac ...除外).但是，您可以通过
免责声明:
我不使用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-runtime，您将获得与使用(dev)系统的mono-runtime相同的结果.这也并不意味着(在任何地方)嵌入mono-runtime不一定是免费的.
所有这些都不一定意味着mono不适合iOS或Android，或者那里存在相同的问题.我在Android或IOS上不使用Mono，因此我对在这些平台上的稳定性，可用性，成本和性能一无所知.显然，如果在Android上使用.NET，则还需要考虑其他一些成本因素，例如权衡xamarin成本与成本以及将现有代码移植到Java的时间.有人听说过Android和IOS上的单声道会相当不错.撒一粒盐.首先，不要期望android/ios与Windows上的default-system-encoding是相同的，也不要期望android文件系统是不区分大小写的.
What is the difference between .NET Core and Mono?
I found a statement on the official site that said: "Code written for it is also portable across application stacks, such as Mono."
My goal is to use C#, LINQ, EF7 and Visual Studio to create a website that can be ran/hosted on Linux.
Someone told me that he wanted it to be "in Mono", but I don't know what that means. I know I want to use the .NET Core 1.0 with the technologies I listed above. He also said he wanted to use "fast CGI". I don't know what that means either.
Can you help me make sense of all these terms and if my expectations are realistic?
Necromancing.
Providing an actual answer.
What is the difference between .Net Core and Mono?
.NET Core now officially is the future of .NET. It started for most part with a re-write of the ASP.NET MVC framework and console applications, which of course includes server applications. (Since it's Turing-complete and supports interop with C dlls, you could, if you absolutely wanted to, also write your own desktop applications with it, for example through 3rd-party libraries like Avalonia, which were a bit very basic at the time I first wrote this, which meant you were pretty much limited to web or server stuff.) Over time, many APIs have been added to .NET Core, so much so that after version 3.1, .NET Core will jump to version 5.0, be known as .NET 5.0 without the "Core", and that then will be the future of the .NET Framework. What used to be the full .NET Framework will linger around in maintenance mode as Full .NET Framework 4.8.x for a few decades, until it will die (maybe there are still going to be some upgrades, but I doubt it). In other words, .NET Core is the future of .NET, and Full .NET Framework will go the way of the Dodo/Silverlight/WindowsPhone.
The main point of .NET Core, apart from multi-platform support, is to improve performance, and to enable "native compilation"/self-contained-deployment (so you don't need .NET framework/VM installed on the target machine.
On the one hand, this means docker.io support on Linux, and on the other, self-contained deployment is useful in "cloud-computing", since then you can just use whatever version of the dotnet-CORE framework you like, and you don't have to worry about which version(s) of the .NET framework the sysadmin has actually installed.
While the .NET Core runtime supports multiple operating systems and processors, the SDK is a different story. And while the SDK supports multiple OS, ARM support for the SDK is/was still work in progress. .NET Core is supported by Microsoft. Dotnet-Core did not come with WinForms or WPF or anything like that.
- As of version 3.0, WinForms and WPF is also supported by .NET Core, but only on Windows, and only by C#. Not by VB.NET (VB.NET support planned for v5 in 2020). And there is no Forms Designer in .NET Core: it's being shipped with a Visual Studio update later, at an unspecified time.
- WebForms are still not supported by .NET Core, and there are no plans to support them, ever (Blazor is the new kid in town for that).
- .NET Core also comes with System.Runtime, which replaces mscorelib.
- Oftentimes, .NET Core is mixed up with NetStandard, which is a bit of a wrapper around System.Runtime/mscorelib (and some others), that allows you to write libraries that target .NET Core, Full .NET Framework and Xamarin (iOS/Android), all at the same time.
- the .NET Core SDK does not/did not work on ARM, at least not last time I checked.
"The Mono Project" is much older than .NET Core.
Mono is Spanish and means Monkey, and as a side-remark, the name has nothing to do with mononucleosis (hint: you could get a list of staff under http://primates.ximian.com/).
Mono was started in 2005 by Miguel de Icaza (the guy that started GNOME - and a few others) as an implementation of the .NET Framework for Linux (Ximian/SuSe/Novell). Mono includes Web-Forms, Winforms, MVC, Olive, and an IDE called MonoDevelop (also knows as Xamarin Studio or Visual Studio Mac). Basically the equivalent of (OpenJDK) JVM and (OpenJDK) JDK/JRE (as opposed to SUN/Oracle JDK). You can use it to get ASP.NET-WebForms + WinForms + ASP.NET-MVC applications to work on Linux.
Mono is supported by Xamarin (the new company name of what used to be Ximian, when they focused on the Mobile market, instead of the Linux market), and not by Microsoft.
(since Xamarin was bought by Microsoft, that's technically [but not culturally] Microsoft.)
You will usually get your C# stuff to compile on mono, but not the VB.NET stuff.
Mono misses some advanced features, like WSE/WCF and WebParts.
Many of the Mono implementations are incomplete (e.g. throw NotImplementedException in ECDSA encryption), buggy (e.g. ODBC/ADO.NET with Firebird), behave differently than on .NET (for example XML-serialization) or otherwise unstable (ASP.NET MVC) and unacceptably slow (Regex). On the upside, the Mono toolchain also works on ARM.
As far as .NET Core is concerned, when they say cross-platform, don't expect that cross-platform means that you could actually just apt-get install .NET Core on ARM-Linux, like you can with ElasticSearch. You'll have to compile the entire framework from source.
That is, if you have that space (e.g. on a Chromebook, which has a 16 to 32 GB total HD).
It also used to have issues of incompatibility with OpenSSL 1.1 and libcurl.
Those have been rectified in the latest version of .NET Core Version 2.2.
So much for cross-platform.
I found a statement on the official site that said, "Code written for it is also portable across application stacks, such as Mono".
As long as that code doesn't rely on WinAPI-calls, Windows-dll-pinvokes, COM-Components, a case-insensitive file system, the default-system-encoding (codepage) and doesn't have directory separator issues, that's correct. However, .NET Core code runs on .NET Core, and not on Mono. So mixing the two will be difficult. And since Mono is quite unstable and slow (for web applications), I wouldn't recommend it anyway. Try image-processing on .NET core, e.g. WebP or moving GIF or multipage-tiff or writing text on an image, you'll be nastily surprised.
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, but has issues on iOS/Android - if it works at all, there.
Prior to .NET Core 2.0, that is to say sometime mid-February 2017, you could use SkiaSharp for imaging (example) (you still can).
Post .net-core 2.0, you'll notice that SixLabors ImageSharp is the way to go, since System.Drawing is not necessarely secure, and has a lot of potential or real memory leaks, which is why you shouldn't use GDI in web-applications; Note that SkiaSharp is a lot faster than ImageSharp, because it uses native-libraries (which can also be a drawback). Also, note that while GDI+ works on Linux & Mac, that doesn't mean it works on iOS/Android.
Code not written for .NET (non-Core) is not portable to .NET Core.
Meaning, if you want a non-GPL C# library like PDFSharp to create PDF-documents (very commonplace), you're out of luck (at the moment) (not anymore). Never mind ReportViewer control, which uses Windows-pInvokes (to encrypt, create mcdf documents via COM, and to get font, character, kerning, font embedding information, measure strings and do line-breaking, and for actually drawing tiffs of acceptable quality), and doesn't even run on Mono on Linux
(I'm working on that).
Also, code written in .NET Core is not portable to Mono, because Mono lacks the .NET Core runtime libraries (so far).
My goal is to use C#, LINQ, EF7, visual studio to create a website that can be ran/hosted in linux.
EF in any version that I tried so far was so goddamn slow (even on such simple things like one table with one left-join), I wouldn't recommend it ever - not on Windows either.
I would particularly not recommend EF if you have a database with unique-constrains, or varbinary/filestream/hierarchyid columns. (Not for schema-update either.)
And also not in a situation where DB-performance is critical (say 10+ to 100+ concurrent users).
Also, running a website/web-application on Linux will sooner or later mean you'll have to debug it.
There is no debugging support for .NET Core on Linux. (Not anymore, but requires JetBrains Rider.)
MonoDevelop does not (yet) support debugging .NET Core projects.
If you have problems, you're on your own. You'll have to use extensive logging.
Be careful, be advised extensive logging will fill your disk in no time, particularly if your program enters an infinite loop or recursion.
This is especially dangerous if your web-app runs as root, because log-in requires logfile-space - if there's no free space left, you won't be able to login anymore.
(Normally, about 5% of diskspace is reserved for user root [aka administrator on Windows], so at least the administrator can still log in if the disk is almost full. But if your applications run as root, that restriction does not apply for their disk usage, and so their logfiles can use 100% of the remaining free space, so not even the administrator can log in any more.)
It's therefore better not to encrypt that disk, that is, if you value your data/system.
Someone told me that he wanted it to be "in Mono", but I don't know what that means.
It either means he doesn't want to use .NET Core, or he just wants to use C# on Linux/Mac. My guess is he just wants to use C# for a Web-App on Linux. .NET Core is the way to go for that, if you absolutely want to do it in C#. Don't go with "Mono proper"; on the surface, it would seem to work at first - but believe me you will regret it because Mono's ASP.NET MVC isn't stable when your server runs long-term (longer than 1 day) - you have now been warned. See also the "did not complete" references when measuring Mono performance on the techempower benchmarks.
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.
It means he wants to use a high-performance full-featured WebServer like nginx (Engine-X), possibly Apache.
Then he can run mono/dotnetCore with virtual name based hosting (multiple domain names on the same IP) and/or load-balancing. He can also run other websites with other technologies, without requiring a different port-number on the web-server. It means your website runs on a fastcgi-server, and nginx forwards all web-requests for a certain domain via the fastcgi-protocol to that server. It also means your website runs in a fastcgi-pipeline, and you have to be careful what you do, e.g. you can't use HTTP 1.1 when transmitting files.
Otherwise, files will be garbled at the destination.
See also here and here.
To conclude:
.NET Core at present (2016-09-28) is not really portable, nor is is really cross-platform (in particular the debug-tools).
Nor is native-compilation easy, especially for ARM.
And to me, it also does not look like its development is "really finished", yet.
For example, System.Data.DataTable/DataAdaper.Update is missing...
(not anymore with .NET Core 2.0)
Together with the System.Data.Common.IDB* interfaces. (not anymore with .NET Core 1.1)
if there ever was one class that is often used, DataTable/DataAdapter would be it...
Also, the Linux-installer (.deb) fails, at least on my machine, and I'm sure I'm not the only one that has that problem.
Debug, maybe with Visual Studio Code, if you can build it on ARM (I managed to do that - do NOT follow Scott Hanselman's blog-post if you do that - there's a howto in the wiki of VS-Code on github), because they don't offer the executable.
Yeoman also fails. (I guess it has something to do with the nodejs version you installed - VS Code requires one version, Yeoman another... but it should run on the same computer. pretty lame
Never mind that it should run on the node version shipped by default on the OS.
Never mind that there should be no dependency on NodeJS in the first place.
The kestell server is also work in progress.
And judging by my experience with the mono-project, I highly doubt they ever tested .NET Core on FastCGI, or that they have any idea what FastCGI-support means for their framework, let alone that they tested it to make sure "everything works". In fact, I just tried making a fastcgi-application with .NET Core and just realized there is no FastCGI library for .NET Core "RTM"...
So when you're going to run .NET Core "RTM" behind nginx, you can only do it by proxying requests to kestrell (that semi-finished nodeJS-derived web-server) - there's no fastcgi support at present in .NET Core "RTM", AFAIK. Since there is no .net core fastcgi library, and no samples, it's also highly unlikely that anybody did any testing on the framework to make sure fastcgi works as expected.
I also question the performance.
In the (preliminary) techempower-benchmark (round 13), aspnetcore-linux ranks on 25% relative to the best performance, while comparable frameworks like Go (golang) rank at 96.9% of peak performance (and that is when returning plaintext without file-system access only). .NET Core does a little better on JSON-serialization, but it does not look compelling either (go reaches 98.5% of peak, .NET core 65%). That said, it can't possibly be worse than "mono proper".
Also, since it's still relatively new, not all of the major libraries have been ported (yet), and I doubt that some of them will ever be ported.
Imaging support is also questionable at best.
For anything encryption, use BouncyCastle instead.
Can you help me make sense of all these terms and if my expectations are realistic?
I hope i helped you making more sense with all these terms.
As far as your expecations go:
Developing a Linux application without knowing anything about Linux is a really stupid idea in the first place, and it's also bound to fail in some horrible way one way or the other. That said, because Linux comes at no licensing costs, it's a good idea in principle, BUT ONLY IF YOU KNOW WHAT YOU DO.
Developing an application for a platform where you can't debug your application on is another really bad idea.
Developing for fastcgi without knowing what consequences there are is yet another really bad idea.
Doing all these things on a "experimental" platform without any knowledge of that platform's specifics and without debugging support is suicide, if your project is more than just a personal homepage. On the other hand, I guess doing it with your personal homepage for learning purposes would probably be a very good experience - then you get to know what the framework and what the non-framework problems are.
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).
To summarize
At present (2016-09-28), I would stay away from .NET Core (for production usage). Maybe in one to two years, you can take another look, but probably not before.
If you have a new web-project that you develop, start it in .NET Core, not mono.
If you want a framework that works on Linux (x86/AMD64/ARMhf) and Windows and Mac, that has no dependencies, i.e. only static linking and no dependency on .NET, Java or Windows, use Golang instead. It's more mature, and its performance is proven (Baidu uses it with 1 million concurrent users), and golang has a significantly lower memory footprint. Also golang is in the repositories, the .deb installs without problems, the sourcecode compiles - without requiring changes - and golang (in the meantime) has debugging support with delve and JetBrains Gogland on Linux (and Windows and Mac). Golang's build process (and runtime) also doesn't depend on NodeJS, which is yet another plus.
As far as mono goes, stay away from it.
It is nothing short of amazing how far mono has come, but unfortunately that's no substitute for its performance/scalability and stability issues for production applications.
Also, mono-development is quite dead, they largely only develop the parts relevant to Android and iOS anymore, because that's where Xamarin makes their money.
Don't expect Web-Development to be a first-class Xamarin/mono citizen.
.NET Core might be worth it, if you start a new project, but for existing large web-forms projects, porting over is largely out of the question, the changes required are huge. If you have a MVC-project, the amount of changes might be manageable, if your original application design was sane, which is mostly not the case for most existing so-called "historically grown" applications.
December 2016 Update:
Native compilation has been removed from .NET Core preview, as it is not yet ready...
Seems like they have improved pretty heavily on the raw text-file benchmark, but on the other hand, it's gotten pretty buggy. Also, it further deteriorated in the JSON benchmarks. Curious also that entity framework shall be faster for updates than Dapper - although both at record slowness. This is very unlikely to be true. Looks like there still are more than just a few bugs to hunt.
Also, there seems to be relief coming on the Linux IDE front.
JetBrains released "Project Rider", an early access preview of a C#/.NET Core IDE for Linux (and Mac and Windows), that can handle Visual Studio Project files.
Finally a C# IDE that is usable & that isn't slow as hell.
Conclusion: .NET Core still is pre-release quality software as we march into 2017. Port your libraries, but stay away from it for production usage, until framework quality stabilizes.
And keep an eye on Project Rider.
2017 Update
Have migrated my (brother's) homepage to .NET Core for now.
So far, the runtime on Linux seems to be stable enough (at least for small projects) - it survived a load test with ease - mono never did.
Also, it looks like I mixed up .NET-Core-native and .NET-Core-self-contained-deployment. Self-contained deployment works, but it is a bit underdocumented, although it's super easy (the build/publish tools are a bit unstable, yet - if you encounter "Positive number required. - Build FAILED." - run the same command again, and it works).
You can run
dotnet restore -r win81-x64
dotnet build -r win81-x64
dotnet publish -f netcoreapp1.1 -c Release -r win81-x64
Note: As per .NET Core 3, you can publish everything minified as a single file:
dotnet publish -r win-x64 -c Release /p:PublishSingleFile=true
dotnet publish -r linux-x64 -c Release /p:PublishSingleFile=true
However, unlike go, it's not a statically linked executable, but a self-extracting zip file, so when deploying, you might run into problems, especially if the temp directory is locked down by group policy, or some other issues. Works fine for a hello-world program, though. And if you don't minify, the executable size will clock in at something around 100 MB.
And you get a self-contained .exe-file (in the publish directory), which you can move to a Windows 8.1 machine without .NET framework installed and let it run. Nice. It's here that dotNET-Core just starts to get interesting. (mind the gaps, SkiaSharp doesn't work on Windows 8.1 / Windows Server 2012 R2, [yet] - the ecosystem has to catch up first - but interestingly, the Skia-dll-load-fail doesn't crash the entire server/application - so everything else works)
(Note: SkiaSharp on Windows 8.1 is missing the appropriate VC runtime files - msvcp140.dll and vcruntime140.dll. Copy them into the publish-directory, and Skia will work on Windows 8.1.)
August 2017 Update
.NET Core 2.0 released.
Be careful - comes with (huge breaking) changes in authentication...
On the upside, it brought the DataTable/DataAdaper/DataSet classes back, and many more.
Realized .NET Core is still missing support for Apache SparkSQL, because Mobius isn't yet ported. That's bad, because that means no SparkSQL support for my IoT Cassandra Cluster, so no joins...
Experimental ARM support (runtime only, not SDK - too bad for devwork on my Chromebook - looking forward to 2.1 or 3.0).
PdfSharp is now experimentally ported to .NET Core.
JetBrains Rider left EAP. You can now use it to develop & debug .NET Core on Linux - though so far only .NET Core 1.1 until the update for .NET Core 2.0 support goes live.
May 2018 Update
.NET Core 2.1 release imminent.
Maybe this will fix NTLM-authentication on Linux (NTLM authentication doesn't work on Linux {and possibly Mac} in .NET-Core 2.0 with multiple authenticate headers, such as negotiate, commonly sent with ms-exchange, and they're apparently only fixing it in v2.1, no bugfix release for 2.0).
But I'm not installing preview releases on my machine. So waiting.
v2.1 is also said to greatly reduce compile times. That would be good.
Also, note that on Linux, .NET Core is 64-Bit only !
There is no, and there will be no, x86-32 version of .NET Core on Linux.
And the ARM port is ARM-32 only. No ARM-64, yet.
And on ARM, you (at present) only have the runtime, not the dotnet-SDK.
And one more thing:
Because .NET-Core uses OpenSSL 1.0, .NET Core on Linux doesn't run on Arch Linux, and by derivation not on Manjaro (the most popular Linux distro by far at this point in time), because Arch Linux uses OpenSSL 1.1. So if you're using Arch Linux, you're out of luck (with Gentoo, too).
Edit:
Latest version of .NET Core 2.2+ supports OpenSSL 1.1. So you can use it on Arch or (k)Ubuntu 19.04+. You might have to use the .NET-Core install script though, because there are no packages, yet.
On the upside, performance has definitely improved:
.NET Core 3:
.NET-Core v 3.0 is said to bring WinForms and WPF to .NET-Core.
However, while WinForms and WPF will be .NET Core, WinForms and WPF in .NET-Core will run on Windows only, because WinForms/WPF will use the Windows-API.
Note:
.NET Core 3.0 is now out (RTM), and there is WinForms and WPF support, but only for C# (on Windows). There is no WinForms-Core-Designer. The designer will, eventually, come with a Visual Studio update, somewhen. WinForms support for VB.NET is not supported, but is planned for .NET 5.0 somewhen in 2020.
PS:
echo "DOTNET_CLI_TELEMETRY_OPTOUT=1" >> /etc/environment
export DOTNET_CLI_TELEMETRY_OPTOUT=1
If you've used it on windows, you probably never saw this:
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.
I thought I'd mention that I think monodevelop (aka Xamarin Studio, the Mono IDE, or Visual Studio Mac as it is now called on Mac) has evolved quite nicely, and is - in the meantime - largely usable.
However, JetBrains Rider (2018 EAP at this point in time) is definitely a lot nicer and more reliable (and the included decompiler is a life-safer), that is to say, if you develop .NET-Core on Linux or Mac. MonoDevelop does not support Debug-StepThrough on Linux in .NET Core, though, since MS does not license their debugging API dll (except for VisualStudio Mac ... ). However, you can use the Samsung debugger for .NET Core through the .NET Core debugger extension for Samsung Debugger for MonoDevelop
Disclaimer:
I don't use Mac, so I can't say if what I wrote here applies to FreeBSD-Unix based Mac as well. I am refering to the Linux (Debian/Ubuntu/Mint) version of JetBrains Rider, mono, MonoDevelop/VisualStudioMac/XamarinStudio and .NET-Core. Also, Apple is contemplating a move from Intel-processors to self-manufactured ARM(ARM-64?)-based processors, so much of what applies to Mac right now might not apply to Mac in the future (2020+).
Also, when I write "mono is quite unstable and slow", the unstable relates to WinFroms & WebForms applications, specifically executing web-applications via fastcgi or with XSP (on the 4.x version of mono), as well as XML-serialization-handling peculiarities, and the quite-slow relates to WinForms, and regular expressions in particular (ASP.NET-MVC uses regular expressions for routing as well).
When I write about my experience about mono 2.x, 3.x and 4.x, that also does not necessarely mean these issues haven't been resolved by now, or by the time you are reading this, nor that if they are fixed now, that there can't be a regression later that reintroduces any of these bugs/features. Nor does that mean that if you embed the mono-runtime, you'll get the same results as when you use the (dev) system's mono runtime. It also doesn't mean that embedding the mono-runtime (anywhere) is necessarely free.
All that doesn't necessarely mean mono is ill-suited for iOS or Android, or that it has the same issues there. I don't use mono on Android or IOS, so I'm in no positon to say anything about stability, usability, costs and performance on these platforms. Obviously, if you use .NET on Android, you have some other costs considerations to do as well, such as weighting xamarin-costs vs. costs and time for porting existing code to Java. One hears mono on Android and IOS shall be quite good. Take it with a grain of salt. For one, don't expect the default-system-encoding to be the same on android/ios vs. Windows, and don't expect the android filesystem to be case-insensitive.
这篇关于.NET Core与Mono的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
