. net Core并不需要mono框架意义上的mono， . net Core是一个可以在包括Linux在内的多个平台上工作的框架。参考https://dotnet.github.io/。

然而。net核心可以使用mono框架。参考https://docs.asp.net/en/1.0.0-rc1/getting-started/choosing-the-right-dotnet.html(注意rc1 documentatiopn没有rc2可用)，但是mono不是微软支持的框架，建议使用受支持的框架

现在实体框架7现在被称为实体框架核心，可以在包括Linux在内的多个平台上使用。参考https://github.com/aspnet/EntityFramework(回顾路线图)

我目前正在使用这两个框架，但你必须明白，它仍然处于发布候选阶段(RC2是当前的版本)，在测试和发布候选阶段，已经有了巨大的变化，通常会让你摸不到头脑。

这是一个关于如何在Linux中安装MVC . net Core的教程。https://docs.asp.net/en/1.0.0-rc1/getting-started/installing-on-linux.html

最后，您可以选择Web服务器(我假设快速cgi引用来自Web服务器)在Linux上托管您的应用程序。下面是安装到Linux环境的参考点。https://docs.asp.net/en/1.0.0-rc1/publishing/linuxproduction.html

我知道这篇文章最后主要是文档的链接，但在这一点上，这些是你最好的信息来源。net core在。net社区中仍然是相对较新的，在它完全发布之前，考虑到发布版本之间的巨大变化，我会犹豫是否要在产品环境中使用它。

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

有两种“完整”的CLR实现，微软原生的。net CLR(用于Windows)和Mono CLR(它本身有用于Windows、linux和unix的实现(Mac OS X和FreeBSD))。一个完整的CLR就是你所需要的一切。因此，“完整的”clr往往尺寸较大。

Core CLRs are on the other hand are cut down, and much smaller. Because they are only a core implementation, they are unlikely to have everything you need in them, so with Core CLRs you add feature sets to the CLR that your specific software product uses, using NuGet. There are Core CLR implementations for Windows, linux (various) and unix (Mac OS X and FreeBSD) in the mix. Microsoft have or are refactoring the .NET framework libraries for Core CLR too, to make them more portable for the core context. Given mono's presence on *nix OSs it would be a surprise if the Core CLRs for *nix did not include some mono code base, but only the Mono community and Microsoft could tell us that for sure.

此外，我同意尼科的观点，核心clr是新的——我想它目前在RC2。我还不会依赖它来编写产品代码。

为了回答你的问题，你可以使用Core CLR或Mono在linux上发布你的网站，这是两种不同的方式。如果你现在想要一个安全的赌注，我会在linux上使用mono，然后如果你以后想移植，就移植到Core。

这个问题尤其实际，因为昨天微软正式宣布了。net Core 1.0的发布。假设Mono实现了大多数标准的。net库，Mono和。net core之间的区别可以通过。net Framework和。net core之间的区别来看出:

APIs — .NET Core contains many of the same, but fewer, APIs as the .NET Framework, and with a different factoring (assembly names are different; type shape differs in key cases). These differences currently typically require changes to port source to .NET Core. .NET Core implements the .NET Standard Library API, which will grow to include more of the .NET Framework BCL APIs over time. Subsystems — .NET Core implements a subset of the subsystems in the .NET Framework, with the goal of a simpler implementation and programming model. For example, Code Access Security (CAS) is not supported, while reflection is supported.

如果你需要快速发布一些东西，选择Mono，因为它是目前(2016年6月)更成熟的产品，但如果你正在构建一个长期的网站，我会建议。net Core。它是由微软官方支持的，考虑到微软在。net Core开发中所付出的努力，所支持的api之间的差异可能很快就会消失。

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

Linq和Entity框架包含在。net Core中，所以你可以放心尝试。

你不仅选择了一条现实的道路，而且可以说是微软强有力支持的最佳生态系统之一(也是x平台)。

Update: Main doc about .Net platform standard is here: https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md Update: Current Mono 4.4.1 cannot run latest Asp.Net core 1.0 RTM Although mono is more feature complete, its future is unclear, because MS owns it for some months now and its a duplicate work for them to support it. But MS is definitely committed to .Net Core and betting big on it. Although .Net core is released, the 3rd party ecosystem is not quite there. For example Nhibernate, Umbraco etc cannot run over .Net core yet. But they have a plan. There are some features missing in .Net Core like System.Drawing, you should look for 3rd party libraries You should use nginx as front server with kestrelserver for asp.net apps, because kestrelserver is not quite ready for production. For example HTTP/2 is not implemented.

我希望这对你们有帮助

Necromancing。 提供一个真实的答案。

.Net Core和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.

虽然. net Core运行时支持多个操作系统和处理器，但SDK是另一回事。虽然SDK支持多种操作系统，但ARM对SDK的支持仍在进行中。net Core由微软支持。Dotnet-Core并没有附带WinForms或WPF之类的东西。

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.

我在官方网站上找到一份声明，上面写着"为 它还可以跨应用程序栈(如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).

此外，用。net Core编写的代码不能移植到Mono，因为Mono缺乏。net Core运行时库(到目前为止)。

我的目标是用c#， LINQ, EF7, visual studio来创建一个网站 可以在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.

有人告诉我，他希望它是“在Mono”，但我不知道 这意味着什么呢?

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.

我知道我想在这些技术中使用。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 (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"...

所以当你打算在nginx后面运行。net Core“RTM”时，你只能通过代理请求到kestrell(半成品的nodejs派生的web服务器)来做到这一点——目前在。net Core“RTM”中没有fastcgi支持，AFAIK。由于没有。net核心fastcgi库，也没有样本，因此几乎不可能有人在框架上做了任何测试来确保fastcgi按预期工作。

我也质疑它的表现。 在(初步的)技术功率基准测试(第13轮)中，aspnetcore-linux相对于最佳性能排名为25%，而类似的框架如Go (golang)的峰值性能排名为96.9%(这是在只返回纯文本而不访问文件系统的情况下). net Core在json序列化方面表现稍好，但看起来也不太令人满意(Go达到峰值的98.5%，. net Core达到65%)。也就是说，它不可能比“单核细胞增多症”更糟糕。

此外，由于它还相对较新，并不是所有的主要库都被移植了(目前)，我怀疑其中一些库是否会被移植。 成像支持充其量也值得怀疑。 对于任何加密，使用BouncyCastle代替。

你能帮我理解一下这些术语和我的期望吗 是现实的吗?

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.

结论:进入2017年，. net Core仍然是预发布的高质量软件。移植您的库，但在框架质量稳定之前，不要用于生产使用。 留意一下骑士计划。

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

你可以跑

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核心才开始变得有趣起来。(请注意差距，SkiaSharp不能在Windows 8.1 / Windows Server 2012 R2上工作，[目前]-生态系统必须先赶上-但有趣的是，ska -dll-load-fail不会使整个服务器/应用程序崩溃-所以其他一切都可以)

(注意:在Windows 8.1上的SkiaSharp缺少适当的VC运行时文件- msvcp140.dll和vcruntime140.dll。将它们复制到发布目录中，Skia将在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.

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

另外，请注意，在Linux上，.NET Core只支持64位! 现在没有，将来也不会有。net Core的x86-32版本。 而且ARM端口只能是ARM-32。目前还没有ARM-64。 在ARM上，你(目前)只有运行时，没有。net- 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。 然而，虽然。net -Core中的WinForms和WPF将是。net -Core中的WinForms和WPF将只在Windows上运行，因为WinForms/WPF将使用Windows- api。

注意: . net Core 3.0已经发布了(RTM)，并且支持WinForms和WPF，但是只支持c#(在Windows上)。没有WinForms-Core-Designer。设计师最终会在某个时候发布Visual Studio更新。对VB的WinForms支持。NET不受支持，但计划在2020年的某个时候推出。NET 5.0。

PS:

echo "DOTNET_CLI_TELEMETRY_OPTOUT=1" >> /etc/environment
export DOTNET_CLI_TELEMETRY_OPTOUT=1 

如果你在窗户上用过，你可能从来没有见过这个:

.NET核心工具收集使用数据，以提高您的 体验。数据是匿名的，不包括命令行 参数。这些数据由微软收集，并与 社区。您可以选择退出遥测设置 将DOTNET_CLI_TELEMETRY_OPTOUT环境变量设置为1 最喜欢的外壳。你可以阅读更多关于。net Core工具遥测@ 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

免责声明: 我不使用Mac，所以我不能说我在这里写的东西是否适用于基于FreeBSD-Unix的Mac。我指的是Linux (Debian/Ubuntu/Mint)版本的JetBrains Rider, mono, MonoDevelop/VisualStudioMac/XamarinStudio和. net - core。此外，苹果正在考虑从英特尔处理器转向自主制造的基于ARM(ARM-64?)的处理器，所以现在适用于Mac的很多东西在未来(2020+)可能不适用于Mac。

此外，当我写“mono是相当不稳定和缓慢的”时，这种不稳定与WinFroms和WebForms应用程序有关，特别是通过fastcgi或XSP(在4上)执行web应用程序。mono的x版本)，以及xml序列化处理特性，以及相当慢的WinForms，特别是正则表达式(ASP。NET-MVC也使用正则表达式进行路由)。

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, and don't expect any windows fonts to be present.

简单来说，

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

. net Core是未来。Mono最终会死。说到。net Core还不够成熟。我曾努力用IBM Bluemix实现它，后来放弃了这个想法。下来的时间(可能是1-2年)，应该会更好。

这不再是。net Core vs. Mono。这是统一的。

2020年11月更新- .NET 5发布，统一了。net框架和。net核心

.NET和Mono将统一到。net 6下，该版本将于2021年11月发布

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

This is one of my favorite topics and the content here was just amazing. I was thinking if it would be worth while or effective to compare the methods available in Runtime vs. Mono. I hope I got my terms right, but I think you know what I mean. In order to have a somewhat better understanding of what each Runtime supports currently, would it make sense to compare the methods they provide? I realize implementations may vary, and I have not considered the Framework Class libraries or the slew of other libraries available in one environment vs. the other. I also realize someone might have already done this work even more efficiently. I would be most grateful if you would let me know so I can review it. I feel doing a diff between the outcome of such activity would be of value, and wanted to see how more experienced developers feel about it, and would they provide useful guidance. While back I was playing with reflection, and wrote some lines that traverse the .net directory, and list the assemblies.