.NET Core与Mono

Question

.NET Core和Mono有什么区别？

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

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

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

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

Answer 1

Necromancing.
提供实际答案.

.Net Core和Mono有什么区别？

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

__CODE__

重点是启用"本机编译"/自包含部署(因此您不需要在目标计算机上安装.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).
这么多跨平台.

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

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

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

注意:
从.NET Core 2.0开始,有System.Drawing.Common(nuget),它包含System.Drawing的大部分功能.它应该在.NET-Core 2.1中或多或少地具有功能.但是,System.Drawing.Common使用GDI +,因此无法在Azure上工作(System.Drawing库在Azure Cloud Service中可用[基本上只是一个VM],但在Azure Web App中没有[基本上是共享主机？])
所以远,System.Drawing.Common在Linux/Mac上运行良好.

不是为.NET(非核心)编写的代码不能移植到.NET核心.
这意味着如果你想要像PDFSharp这样的非GPL C#库来创建PDF文档(非常普通),那你就不走运了(在这一刻) (not anymore). Never mind ReportViewer control, which uses Windows-pInvokes (for whatever reason), 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 (yet).

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

到目前为止我尝试过的任何版本的EF都是如此的死得很慢(即使是一个简单的东西,比如一张桌子上有一个左连接),我也不会推荐它 - 也不会在Windows上推荐它.
如果您有一个包含unique-constrains或varbinary/filestream/hierarchyid列的数据库,我特别不建议使用EF.(也不适用于架构更新)
并且也不是在DB性能至关重要的情况下(例如10+到100+并发用户).
此外,在Linux上运行网站/网络应用程序迟早意味着你必须调试它.
Linux上没有针对.NET Core的调试支持. (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 infine 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.
(通常,大约5%的磁盘空间是为用户root [也就是Windows上的管理员]保留的,所以至少管理员仍然可以登录,如果磁盘几乎已满.但是如果您的应用程序以root用户身份运行,则该限制不适用于他们的磁盘使用,因此他们的日志文件可以使用100%的剩余可用空间,因此管理员甚至不能再登录.)
因此,最好不加密该磁盘,即,如果您重视数据/系统.

有人告诉我,他希望它是"单声道",但我不知道这意味着什么.

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

我知道我想将.Net Core 1.0框架与上面列出的技术结合使用.他还说他想用"快速cgi".我也不知道这意味着什么.

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 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 for you - 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, 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.
IntelliJ 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

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).

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.

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) 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.

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 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

Answer 2

在.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.

Answer 3

您不仅选择了一条现实的路径,而且可以说是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.

我希望它有所帮助

Answer 4

.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当前版本),并且在测试和发布候选版本中已经发生了大量更改,通常最终会让你摸不着头脑.

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

Answer 5

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

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

.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

Answer 6

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

• 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和Entity框架包含在.NET Core中,因此您可以放心使用.

Answer 7

简单来说，

Mono 是 Linux/Android/iOs 的 .Net 框架的第三方实现

.Net Core 是微软自己的实现。

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