有没有人使用过大型或中型项目的开源.NET实现Mono?我想知道它是否适合现实世界的生产环境.它是否稳定,快速,兼容,......足以使用?是否需要花费大量精力将项目移植到Mono运行时,或者它是否真的非常兼容,只需要为Microsoft的运行时获取并运行已编写的代码?
有几种情况需要考虑:(a)如果您正在移植现有的应用程序并想知道Mono是否足够完成此任务; (b)你开始写一些新的代码了,你想知道Mono是否足够成熟.
对于第一种情况,您可以使用Mono Migration Analyzer工具(Moma)来评估应用程序在Mono上运行的程度.如果评估结果显示颜色鲜艳,您应该开始测试和QA并准备发货.
如果您的评估结果是报告突出显示Mono中缺少或显着不同的功能,则必须评估代码是否可以调整,重写或在最坏的情况下,您的应用程序是否可以使用减少的功能.
根据我们根据用户提交的Moma统计数据(这是来自内存),大约50%的应用程序开箱即用,大约25%需要大约一周的工作量(重构,调整)另外15%需要认真承诺重做代码的重做,剩下的就是不值得打扰移植,因为它们与Win32紧密相关.在这一点上,要么你从零开始,要么商业决策将推动你的代码可移植,但我们正在谈论几个月的工作(至少从我们的报告中).
如果您从头开始,情况要简单得多,因为您只会使用Mono中的API.只要你留在支持堆栈(这是相当多的.NET 2.0,加上3.5的所有核心功能升级,包括LINQ和System.Core程序,加上所有的单跨平台API),你会被罚款.
每隔一段时间你就会遇到Mono中的错误或限制,你可能不得不解决它们,但这与其他任何系统都没有什么不同.
至于可移植性:ASP.NET应用程序更容易移植,因为它们几乎没有依赖Win32,你甚至可以使用SQL服务器或其他流行的数据库(Mono有很多捆绑的数据库提供程序).
Windows.Forms移植有时比较棘手,因为开发人员喜欢逃离.NET沙箱和P/Invoke他们的大脑配置的东西就像改变光标闪烁率一样有用,表示为在wParam中以BCD格式编码的两个贝塞尔点.或者像这样的一些垃圾.
它具有相当广泛的覆盖范围,直到.NET 4.0,甚至包括.NET 4.5 API的一些功能,但由于不推荐使用API,创建了新的替代方案或范围太大,我们选择了一些不实现的领域.大.Mono中不提供以下API:
Windows Presentation Foundation
Windows Workflow Foundation(两个版本都不是)
实体框架
WSE1/WSE2"附加组件"到标准Web服务堆栈
此外,我们的WCF实现仅限于Silverlight支持的内容.
检查特定项目的最简单方法是运行Mono Migration Analyzer(MoMA).好处是它会通知Mono团队一些问题会阻止你使用Mono(如果有的话),这会让他们优先考虑他们的工作.
我最近在SubSonic上运行MoMA,发现只有一个问题 - Nullable类型的奇怪使用.这是一个很大的代码库,所以那里的报道非常令人印象深刻.
Mono正在积极使用几种商业和开源产品.它在一些大型应用程序中使用,例如维基百科和Mozilla开发人员中心,并已用于嵌入式应用程序,如Sansa MP3播放器,并为数千种已发布的游戏提供支持.
在语言层面,Mono编译器完全符合C#5.0语言规范.
在桌面方面,如果您承诺使用GTK#,Mono可以很好地工作.Windows.Forms实现仍然是一个小错误(例如,TrayIcon不起作用)但它已经走了很长的路.此外,GTK#是比Windows Forms更好的工具包.
在网络方面,Mono已经实现了足够的ASP.NET来完美地运行大多数网站.这里遇到的困难是找到一个在apache上安装mod_mono的主机,或者如果你有shell访问主机的话就自己动手.
无论哪种方式,Mono都很棒,而且很稳定.
创建跨平台程序时要记住的关键事项:
使用GTK#而不是Windows.Forms
确保正确填写文件名
使用Path.Separator
而不是硬编码"\"
,也使用Environment.NewLine
而不是"\n"
.
不要对Win32 API使用任何P/Invoked调用.
不要使用Windows注册表.
我个人在黄金时段使用Mono.我运行单处理服务器处理与gd字节的udp/tcp数据处理相关的任务,并且不能更快乐.
有一些特点,最烦人的事情之一就是你不能仅仅因为Mono的当前状态而"构建"你的msbuild文件:
MonoDevelop(IDE)有一些部分的msbuild支持,但基本上会在任何"REAL"构建版本上超出简单的hello-world(自定义构建任务,动态"属性",如$(SolutionDir),真正的配置,以命名一些死-ends)
xbuild 应该是单声道提供的msbuild完全兼容的构建系统甚至更加可怕,因此从命令行构建实际上是比使用GUI更糟糕的体验,这是一种非常"非正统"的状态. Linux环境联盟......
一旦/在获得你的东西实际上是BUILT,你可能会看到一些荒野,即使对于应该支持的代码,如:
编译器在某些构造上被搞砸了
某些更高级的/新的.NET类会给你带来意想不到的废话(XLinq有人吗?)
一些不成熟的运行时"功能"(3GB堆限制ON x64 ... WTF!)
但是说,一般来说,事情开始很快就会开始,解决方案/解决方案很多.
一旦你完成了那些最初的障碍,我的经验就是单声道ROCKS,并且每次迭代都会越来越好.
我有服务器运行单声道,每天处理300GB的数据,有大量的p/invokes,一般来说做很多工作并保持5-6个月的UP,即使是"前沿"单声道.
希望这可以帮助.
接受答案的建议现在有点过时了.
Windows窗体的实现现在非常好.(请参阅Paint-Mono获取Paint.net的一个端口,它是一个非常复杂的Windows窗体应用程序.所需要的只是一些P-Invoke和不支持的系统调用的仿真层).
Path.Combine以及Path.Seperator用于连接路径和文件名.
Windows注册表是可以的,只要您只使用它来存储和检索应用程序中的数据(即您无法从中获取有关Windows的任何信息,因为它基本上是Mono应用程序的注册表).
如果你想使用WPF你运气不好Mono目前没有计划实现它.
http://www.mono-project.com/WPF
嗯,单声道是伟大的,但据我所知,它是不稳定的.它可以工作,但是当你给单声道处理做一个认真的工作时会出现故障.
TL; DR - 如果您:不使用单声道:
在多线程环境中使用AppDomains(程序集加载\卸载)
无法维持"让它失败"的模式
在流程运行期间偶尔会遇到重载事件
所以,事实.
我们在RHEL5,Ubuntu上使用mono-2.6.7(.net v 3.5),并且在我看来,它是由Novell构建的最稳定的版本.它有一个卸载AppDomains(segfaults)的问题,然而,它失败非常罕见,到目前为止,这是可以接受的(由我们).
好的.但是如果你想使用.net 4.0的功能,你必须切换到版本2.10.x或3.x,这就是问题的开始.
与2.6.7相比,新版本使用起来是不可接受的.我写了一个简单的压力测试应用程序来测试单声道安装
它在这里,使用说明:https://github.com/head-thrash/stress_test_mono
它使用线程池工作线程.工作者将DLL加载到AppDomain并尝试进行一些数学工作.有些工作是多线程的,有些是单一的.尽管从磁盘中读取了一些文件,但几乎所有工作都受CPU限制.
结果不是很好.实际上,对于3.0.12版:
sgen GC段错误过程几乎立即进行
单声道与boehm寿命更长(从2到5小时),但最终会出现段错误
如上所述,sgen gc只是不起作用(从源代码构建单声道):
* Assertion: should not be reached at sgen-scan-object.h:111 Stacktrace: Native stacktrace: mono() [0x4ab0ad] /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0) [0x2b61ea830cb0] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35) [0x2b61eaa74425] /lib/x86_64-linux-gnu/libc.so.6(abort+0x17b) [0x2b61eaa77b8b] mono() [0x62b49d] mono() [0x62b5d6] mono() [0x5d4f84] mono() [0x5cb0af] mono() [0x5cb2cc] mono() [0x5cccfd] mono() [0x5cd944] mono() [0x5d12b6] mono(mono_gc_collect+0x28) [0x5d16f8] mono(mono_domain_finalize+0x7c) [0x59fb1c] mono() [0x596ef0] mono() [0x616f13] mono() [0x626ee0] /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a) [0x2b61ea828e9a] /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x2b61eab31ccd]
至于boehm segfauls - 例如(Ubuntu 13.04,从源代码构建的单声道):
mono: mini-amd64.c:492: amd64_patch: Assertion `0' failed. Stacktrace: at<0xffffffff> at System.Collections.Generic.Dictionary`2.Init (int,System.Collections.Generic.IEqualityComparer`1 ) [0x00012] in /home/bkmz/my/mono/mcs/class/corlib/System.Collections.Generic/Dictionary.cs:264 at System.Collections.Generic.Dictionary`2..ctor () [0x00006] in /home/bkmz/my/mono/mcs/class/corlib/System.Collections.Generic/Dictionary.cs:222 at System.Security.Cryptography.CryptoConfig/CryptoHandler..ctor (System.Collections.Generic.IDictionary`2 ,System.Collections.Generic.IDictionary`2 ) [0x00014] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/Crypto Config.cs:582 at System.Security.Cryptography.CryptoConfig.LoadConfig (string,System.Collections.Generic.IDictionary`2 ,System.Collections.Generic.IDictionary`2 ) [0x00013] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/CryptoCo nfig.cs:473 at System.Security.Cryptography.CryptoConfig.Initialize () [0x00697] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:457 at System.Security.Cryptography.CryptoConfig.CreateFromName (string,object[]) [0x00027] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:495 at System.Security.Cryptography.CryptoConfig.CreateFromName (string) [0x00000] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:484 at System.Security.Cryptography.RandomNumberGenerator.Create (string) [0x00000] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/RandomNumberGenerator.cs:59 at System.Security.Cryptography.RandomNumberGenerator.Create () [0x00000] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/RandomNumberGenerator.cs:53 at System.Guid.NewGuid () [0x0001e] in /home/bkmz/my/mono/mcs/class/corlib/System/Guid.cs:492
或者(RHEL5,单声道取自rpm这里ftp://ftp.pbone.net/mirror/ftp5.gwdg.de/pub/opensuse/repositories/home%3A/vmas%3A/mono-centos5)
Assertion at mini.c:3783, condition `code' not met Stacktrace: at<0xffffffff> at System.IO.StreamReader.ReadBuffer () [0x00012] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.IO/StreamReader.cs:394 at System.IO.StreamReader.Peek () [0x00006] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.IO/StreamReader.cs:429 at Mono.Xml.SmallXmlParser.Peek () [0x00000] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/Mono.Xml/SmallXmlParser.cs:271 at Mono.Xml.SmallXmlParser.Parse (System.IO.TextReader,Mono.Xml.SmallXmlParser/IContentHandler) [0x00020] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/Mono.Xml/SmallXmlParser.cs:346 at System.Security.Cryptography.CryptoConfig.LoadConfig (string,System.Collections.Generic.IDictionary`2 ,System.Collections.Generic.IDictionary`2 ) [0x00021] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptog raphy/CryptoConfig.cs:475 at System.Security.Cryptography.CryptoConfig.Initialize () [0x00697] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:457 at System.Security.Cryptography.CryptoConfig.CreateFromName (string,object[]) [0x00027] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:495 at System.Security.Cryptography.CryptoConfig.CreateFromName (string) [0x00000] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:484 at System.Security.Cryptography.RandomNumberGenerator.Create (string) [0x00000] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptography/RandomNumberGenerator.cs:59 at System.Security.Cryptography.RandomNumberGenerator.Create () [0x00000] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptography/RandomNumberGenerator.cs:53 at System.Guid.NewGuid () [0x0001e] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System/Guid.cs:483 at System.Runtime.Remoting.RemotingServices.NewUri () [0x00020] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Runtime.Remoting/RemotingServices.cs:356 at System.Runtime.Remoting.RemotingServices.Marshal (System.MarshalByRefObject,string,System.Type) [0x000ba] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Runtime.Remoting/RemotingServices.cs:329 at System.AppDomain.GetMarshalledDomainObjRef () [0x00000] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System/AppDomain.cs:1363
这两个故障都以某种方式连接到AppDomains逻辑,因此,您应该单声道地远离它们.
BTW,测试程序在Windows机器上运行24小时,在MS .NET 4.5 env中没有任何失败.
所以,最后,我想说 - 谨慎使用mono.它从第一眼开始工作,但随时都很容易失败.你会在开源项目中留下一堆核心转储和主要信念损失.
正如其他人所建议的那样,现代艺术博物馆是一个很好的工具.目前最大的不兼容性来源是DllImport(或P/Invoke)到Win32库中的应用程序.有些程序集没有实现,但大多数只是Windows,在Linux上真的没用.我认为大多数ASP.NET应用程序可以在Mono上运行并且修改有限,这是相当安全的.
(披露:我为Mono本身以及在其上运行的书面应用程序做出了贡献.)