모노는 프라임 타임 준비가 되셨습니까?

모노는 프라임 타임 준비가 되셨습니까? [닫은]

---

누구든지 대규모 또는 중간 규모 프로젝트에서 오픈 소스 .NET 구현 인 Mono를 사용 했습니까? 실제 프로덕션 환경에 적합한 지 궁금합니다. 안정적이고 빠르며 호환되며 사용하기에 충분합니까? 프로젝트를 Mono 런타임으로 이식하는 데 많은 노력이 필요합니까, 아니면 Microsoft 런타임을 위해 이미 작성된 코드를 가져와 실행할 수있을 정도로 실제로 호환됩니까?

---

고려해야 할 몇 가지 시나리오가 있습니다. (a) 기존 응용 프로그램을 이식하고 Mono가이 작업에 충분한 지 궁금한 경우; (b) 새 코드를 작성하기 시작했으며 Mono가 충분히 성숙한 지 알고 싶습니다.

첫 번째 경우 Mono Migration Analyzer 도구 (Moma)를 사용하여 응용 프로그램이 Mono에서 얼마나 멀리 실행되는지 평가할 수 있습니다. 평가가 플라잉 색상으로 돌아 오면 테스트 및 QA를 시작하여 배송 준비를해야합니다.

평가에서 Mono의 시맨틱에서 누락되었거나 현저하게 다른 기능을 강조 표시하는 보고서가 다시 표시되면 코드를 적용, 재 작성할 수 있는지 또는 최악의 경우 응용 프로그램이 기능을 축소하여 사용할 수 있는지 평가해야합니다.

사용자 제출 (이것은 메모리에서 온 것임)을 기반으로 한 Moma 통계에 따르면 약 50 %의 응용 프로그램이 기본적으로 작동하며, 약 25 %는 약 일주일 동안의 작업 (리팩토링, 적응)이 필요하고 다른 15 %는 코드를 다시 실행하면 나머지는 Win32에 엄청나게 묶여 있기 때문에 이식을 귀찮게 할 가치가 없습니다. 그 시점에서, 당신은 0에서 시작하거나 사업 결정으로 코드를 이식 가능하게 만들려고 노력하지만, 우리는 적어도 몇 달간 (최소한 우리의 보고서에서) 일할 가치가 있습니다.

처음부터 시작하는 경우 Mono에있는 API 만 사용하므로 상황이 훨씬 간단합니다. 지원되는 스택 (.NET 2.0과 LINQ 및 System.Core를 포함한 3.5의 모든 핵심 업그레이드 및 모든 모노 크로스 플랫폼 API)을 유지하는 한 괜찮습니다.

가끔씩 모노 또는 버그로 버그가 발생할 수 있으며, 그 문제를 해결해야 할 수도 있지만 다른 시스템과 다르지 않습니다.

이식성 : ASP.NET 응용 프로그램은 Win32에 거의 의존하지 않으며 SQL 서버 또는 기타 널리 사용되는 데이터베이스 (Mon과 함께 번들로 제공되는 데이터베이스 공급자가 많음)를 사용하기 때문에 이식하기가 더 쉽습니다.

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 "애드온"

또한 WCF 구현은 Silverlight가 지원하는 것으로 제한됩니다.

특정 프로젝트를 확인하는 가장 쉬운 방법은 MoMA (Mono Migration Analyzer )를 실행하는 것 입니다. 이점은 Mono (있는 경우)를 사용하지 못하게하여 작업의 우선 순위를 지정할 수있는 문제를 Mono 팀에 알릴 수 있다는 것입니다.

최근에 SubSonic에서 MoMA를 실행했으며 Nullable 형식을 이상하게 사용하는 문제가 하나만 발견되었습니다. 그것은 큰 코드베이스이므로 적용 범위가 상당히 인상적입니다.

모노는 여러 상용 및 공개 소스 제품 에서 활발히 사용되고 있습니다 . Wikipedia 및 Mozilla Developer Center와 같은 일부 대규모 응용 프로그램에서 사용되며 Sansa MP3 플레이어와 같은 내장 응용 프로그램에서 사용되었으며 수천 개의 게시 된 게임을 지원합니다.

언어 수준 에서 Mono 컴파일러는 C # 5.0 언어 사양을 완벽하게 준수합니다 .

---

데스크톱 측면에서 GTK # 사용을 약속하면 Mono가 훌륭하게 작동합니다. Windows.Forms 구현은 여전히 ​​약간 버그가 있지만 (예 : TrayIcon이 작동하지 않음) 먼 길을 왔습니다. 게다가 GTK #는 Windows Forms보다 더 나은 툴킷입니다.

웹 측에서 Mono는 대부분의 사이트를 완벽하게 실행할 수 있도록 충분한 ASP.NET을 구현했습니다. 여기서 어려움은 아파치에 mod_mono가 설치된 호스트를 찾거나 호스트에 대한 쉘 액세스 권한이있는 경우 직접 수행하는 것입니다.

어느 쪽이든, 모노는 훌륭하고 안정적입니다.

크로스 플랫폼 프로그램을 작성할 때 기억해야 할 주요 사항 :

• Windows 대신 GTK #을 사용하십시오.
• 파일 이름을 올바르게 입력하십시오
• 사용 Path.Separator하는 대신 하드 코딩으로 "\"도 사용 Environment.NewLine대신에 "\n".
• Win32 API에 대한 P / Invoked 호출을 사용하지 마십시오.
• Windows 레지스트리를 사용하지 마십시오.

---

나는 개인적으로 프라임 타임 환경에서 모노를 사용합니다. 기가 바이트의 udp / tcp 데이터 처리 관련 작업을 처리하는 모노 서버를 실행했는데 더 행복 할 수 없었습니다.

특이점이 있으며 가장 성가신 것은 Mono의 현재 상태로 인해 msbuild 파일을 "빌드"할 수 없다는 것입니다.

• MonoDevelop (IDE)는 부분적인 msbuild를 지원하지만, 기본적으로 단순한 hello-world (사용자 정의 빌드 작업, $ (SolutionDir)와 같은 동적 "속성", 실제 구성은 몇 가지 사망자를 넘어서서 "REAL"빌드 conf에서 시작됩니다. 끝)
• xbuild 되어 있어야 모노 - 공급 - msbuild를-완벽하게 호환 빌드 시스템은 실제로 그렇게 명령 줄에서 구축의 매우 "정통"상태 인 GUI를 사용하는 것보다 더 나쁜 경험을 더욱 끔찍한입니다 리눅스 환경을위한 연합 ...

한 번 / 실제로 물건을 얻는 동안, 다음과 같이 지원되어야하는 코드조차도 광야를 볼 수 있습니다.

• 컴파일러는 특정 구문에서 지루해집니다.
• 그리고 더 진보 된 새로운 .NET 클래스가 예기치 않은 쓰레기를 던집니다 (XLinq 누구입니까?)
• 일부 미성숙 런타임 "기능"(x64에서 3GB 힙 제한 ... WTF!)

그러나 헤빙은 일반적으로 말하기가 매우 빨리 작동하기 시작하며 솔루션 / 해결 방법이 풍부하다고 말했다 .

일단 당신이 그 초기 허들을 극복했다면, 나의 경험은 그 모노 ROCKS이며, 매번 반복 할 때마다 계속 나아지고 있습니다.

나는 모노로 실행하고 매일 300GB의 데이터를 처리하는 서버를 가지고 있었으며, 많은 p / invoke를 사용하고 일반적으로 "최첨단"모노에서도 5-6 개월 동안 일을 계속하고 있습니다.

도움이 되었기를 바랍니다.

---

허용 된 답변에 대한 권장 사항이 약간 오래되었습니다.

• 윈도우 폼 구현은 이제 꽤 좋습니다. ( Windows Forms 응용 프로그램 인 Paint.net 포트는 Paint-Mono 를 참조하십시오 . 필요한 것은 P-Invoke 및 지원되지 않는 일부 시스템 호출에 대한 에뮬레이션 계층이었습니다.)
• Path.Seperator뿐만 아니라 Path.Seperator는 경로와 파일 이름을 결합합니다.
• Windows 레지스트리는 응용 프로그램에서 데이터를 저장하고 검색하는 데만 사용하는 한 괜찮습니다 (예 : 기본적으로 Mono 응용 프로그램의 레지스트리이므로 Windows에 대한 정보를 얻을 수 없음).

---

WPF를 사용하고 싶다면 Mono가 현재 구현할 계획이 없습니다.

http://www.mono-project.com/WPF

---

글쎄, 모노는 훌륭하지만 내가 볼 수있는 한 불안정합니다. 작동하지만 모노 프로세스에 심각한 작업을 줄 때 오류가 발생합니다.

TL; DR-다음과 같은 경우 모노를 사용하지 마십시오.

• 다중 스레드 환경에서 AppDomain (Assembly Load \ Unload) 사용
• 'let-it-fail'모델을 유지할 수 없습니다
• 프로세스 실행 중 가끔 과부하 이벤트 발생

사실.

우리는 RHEL5, Ubuntu에서 mono-2.6.7 (.net v 3.5)을 사용하며, 필자의 견해로는 Novell이 작성한 가장 안정적인 버전입니다. AppDomain 언로드 (segfaults)에 문제가 있지만 매우 드물게 실패하며 이것은 우리가 받아 들일 수 있습니다.

괜찮아. 그러나 .net 4.0의 기능을 사용하려면 버전 2.10.x 또는 3.x로 전환해야하며 여기서 문제가 시작됩니다.

2.6.7과 비교하여 새 버전은 사용할 수 없습니다. 모노 설치를 테스트하는 간단한 스트레스 테스트 응용 프로그램을 작성했습니다.

사용 지침과 함께 여기 있습니다 : https://github.com/head-thrash/stress_test_mono

스레드 풀 작업자 스레드를 사용합니다. Worker는 dll을 AppDomain에로드하고 수학 작업을 시도합니다. 일부 작업은 스레드가 많고 일부는 단일 작업입니다. 디스크에서 일부 파일 읽기가 있지만 거의 모든 작업이 CPU에 종속됩니다.

결과가 좋지 않습니다. 실제로 버전 3.0.12의 경우 :

• sgen GC segfaults 프로세스가 거의 즉시
• boehm을 가진 모노는 더 오래 (2-5 시간) 살지만 segfaults는 결국

위에서 언급했듯이 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 <unknown> <0xffffffff>
at System.Collections.Generic.Dictionary`2.Init (int,System.Collections.Generic.IEqualityComparer`1<TKey>) [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<string, System.Type>,System.Collections.Generic.IDictionary`2<string, string>) [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<string, System.Type>,System.Collections.Generic.IDictionary`2<string, string>) [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 <unknown> <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<string, System.Type>,System.Collections.Generic.IDictionary`2<string, string>) [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, 테스트 된 프로그램은 MS .NET 4.5 env의 Windows 컴퓨터에서 24 시간 동안 아무런 문제없이 작동했습니다.

결론적으로 모노를 조심스럽게 사용하십시오. 언뜻보기에 작동하지만 언제든지 쉽게 실패 할 수 있습니다. 오픈 소스 프로젝트에서 많은 핵심 덤프와 주요 믿음 상실을 경험하게 될 것입니다.

---

다른 사람이 제안한 것처럼 MoMA는이를위한 훌륭한 도구입니다. 오늘날 비 호환성의 가장 큰 원인은 DllImport (또는 P / Invoke)가 Win32 라이브러리에있는 응용 프로그램입니다. 일부 어셈블리는 구현되지 않았지만 대부분은 Windows 전용이며 Linux에서는 실제로 의미가 없습니다. 대부분의 ASP.NET 응용 프로그램은 제한된 수정으로 Mono에서 실행할 수 있다고 말하는 것이 안전하다고 생각합니다.

(공개 : 저는 Mono 자체와 그 위에 실행되는 앱을 작성했습니다.)

---

많은 경우에, 특히 ASP.NET 응용 프로그램을 포팅하는 경우 기존 코드를 가져와 모노에서 실행할 수 있습니다.

경우에 따라 완전히 새로운 코드 섹션이 필요할 수도 있습니다. 예를 들어 System.Windows.Forms를 사용하면 응용 프로그램이 수정되지 않습니다. Windows 특정 코드 (예 : 레지스트리 액세스 코드)를 사용하는 경우에도 마찬가지입니다. 그러나 최악의 범죄자는 UI 코드라고 생각합니다. Macintosh 시스템에서는 특히 나쁩니다.

---

우리는 Linux에서 실행해야하지만 Managed C ++에서 빌드 한 일부 .NET 라이브러리를 재사용 해야하는 직장에서 프로젝트에 사용했습니다. 나는 그것이 얼마나 잘 작동했는지 매우 놀랐습니다. 우리의 주요 실행 파일은 C #으로 작성되고 있으며 문제없이 Managed C ++ 바이너리를 참조 할 수 있습니다. Windows와 Linux 간의 C # 코드의 유일한 차이점은 RS232 직렬 포트 코드입니다.

내가 생각할 수있는 유일한 큰 문제는 약 한 달 전에 일어났습니다. Linux 빌드에는 Windows 빌드에서 볼 수없는 메모리 누수가 있습니다. 수동 디버깅을 수행 한 후 (Linux에서 Mono의 기본 프로파일 러는별로 도움이되지 않음) 특정 코드 덩어리로 문제를 좁힐 수있었습니다. 우리는 해결 방법을 패치했지만 결국 돌아가서 누출의 근본 원인이 무엇인지 알아낼 시간이 필요합니다.

---

Windows Forms 2.0에 대한 Mono 2.0 Preview의 지원 기능이 얼마나되는지 알고 있습니까?

내가 가지고 노는 약간에서, 그것은 비교적 완전하고 거의 사용 가능한 것처럼 보였다. 그것은 일부 장소에서 제대로 보이지 않았으며 여전히 전반적으로 약간의 타격이나 그리움입니다. 솔직히 말해서 우리 양식 중 일부와 마찬가지로 작동한다는 사실에 놀랐습니다.

---

그렇습니다 (정확한 경우) 우리는 Ra-Ajax ( http://ra-ajax.org에있는 Ajax 라이브러리)의 Mono를 지원 하며 대부분 문제가 없습니다. WSE와 같은 .Net의 "가장 미친 것"에주의를 기울여야하며, 기존 프로젝트 중 일부는 100 % 모노 호환되지 않지만 개발 중에 테스트하면 새 프로젝트는 대부분 모노 문제없이 호환됩니다. 그리고 Mono를 사용하여 Linux 등을 지원함으로써 얻는 이익은 정말 시원합니다.)

모노를 지원하는 비결의 대부분은 ActiveRecord, log4net, ra-ajax 등과 같이 처음부터 올바른 도구를 사용하는 것입니다.

---

우리는 응용 프로그램 유형에 대해 불행하게도 Mono를 제작할 준비가되지 않았습니다. 우리는 전체적으로 감명을 받았으며 Windows와 EC2 시스템 모두에서 그 성능에 깊은 인상을 받았지만, 프로그램은 Windows와 Linux 모두에서 가비지 수집 오류와 함께 충돌했습니다.

오류 메시지는 "GC의 치명적인 오류 : 너무 많은 힙 섹션"입니다. 다음은 약간 다른 방식으로 문제를 겪고있는 다른 사람의 링크입니다.

http://bugzilla.novell.com/show_bug.cgi?id=435906

우리가 Mono에서 실행 한 첫 번째 코드는 우리가 개발 한 간단한 프로그래밍 문제였습니다.이 코드는 약 10mb의 데이터를 일부 데이터 구조 (예 : HashSets)에로드 한 다음 데이터에 대해 10 개의 쿼리를 실행합니다. 시간을 정하고 평균을 얻기 위해 쿼리를 100 회 실행했습니다.

Windows에서 55 번째 쿼리에서 코드가 충돌했습니다. 리눅스에서는 효과가 있었지만 더 큰 데이터 세트로 이동하자마자 충돌이 일어났습니다.

이 코드는 매우 간단합니다. 예를 들어 일부 데이터를 HashSets에 넣은 다음 HashSets 등 모든 네이티브 c #, 안전하지 않은 항목, API 호출을 쿼리하지 않습니다. Microsoft CLR에서는 충돌이 발생하지 않으며 거대한 데이터 세트에서 1000 배만 실행됩니다.

우리 직원 중 한 명이 Miguel에게 이메일을 보내 문제를 일으키는 코드를 포함했지만 아직 응답하지 않았습니다. :(

다른 많은 사람들이 해결책 없이이 문제를 겪은 것처럼 보입니다. 하나의 솔루션은 다른 GC 설정으로 Mono를 다시 컴파일하도록 제안되었지만 충돌하기 전에 임계 값을 증가시키는 것처럼 보입니다.

---

www.plasticscm.com을 확인하십시오. 모든 것 (클라이언트, 서버, GUI, 병합 도구)은 모노로 작성됩니다.

---

.NET 프레임 워크에서 사용하는 네임 스페이스 및 클래스에 따라 다릅니다. Windows 서비스 중 하나를 전자 메일 서버 (Suse)에서 실행하도록 변환하는 데 관심이 있었지만 완전히 구현되지 않은 API를 사용하여 몇 가지 어려운 장애물에 부딪 쳤습니다. 모노 웹 사이트 어딘가에 모든 수업과 수료 레벨을 보여주는 차트가 있습니다. 귀하의 신청서가 적용되는 경우에는 신청하십시오.

물론 다른 응용 프로그램과 마찬가지로 프로토 타입과 테스트를 수행하여 완전히 헌신하십시오.

우리가 마주 친 또 다른 문제는 라이센스가있는 소프트웨어입니다. 다른 사람의 DLL을 참조하는 경우 해당 어셈블리에 묻힌 비 호환성 문제를 해결할 수 없습니다.

---

그런 다음 타사 구성 요소가있는 응용 프로그램이 있으면 채워질 수 있습니다. 많은 업체들이 Mono를 염두에두고 개발할 것으로 의심합니다.

예 : http://community.devexpress.com/forums/p/55085/185853.aspx

---

아니요, 모노는 진지한 작업을 할 준비가되어 있지 않습니다. F #을 사용하여 Windows에서 몇 가지 프로그램을 작성하고 Mono에서 실행했습니다. 이 프로그램은 디스크, 메모리 및 CPU를 매우 집중적으로 사용했습니다. 모노 라이브러리 (관리 코드)에서 충돌이 발생하고 원시 코드에서 충돌이 발생하고 가상 시스템에서 충돌이 발생했습니다. 모노가 작동했을 때 프로그램은 Windows의 .Net보다 두 배 이상 느리고 더 많은 메모리를 사용했습니다. 진지한 작업을 위해 모노를 피하십시오.

참고 URL : https://stackoverflow.com/questions/18450/is-mono-ready-for-prime-time