모노가 황금 시간대에 준비되었습니까?

모노가 황금 시간대에 준비되었습니까?

닫혔습니다. 이 질문은.여론에 입각한현재 답변을 수락하고 있지 않습니다.

---

이 질문을 개선하고 싶으십니까?이 게시물을 편집하여 사실과 인용문으로 답변할 수 있도록 질문을 업데이트합니다.

7년 전에 문을 닫았습니다.

이 질문을 개선합니다.

오픈 소스인 모노를 사용한 사람이 있습니까?대규모 또는 중규모 프로젝트에서 NET을 구현하시겠습니까?실제 환경, 생산 환경에 맞게 준비가 되었는지 궁금합니다.안정적이고, 빠르고, 호환 가능하며, 충분히 사용할 수 있습니까?프로젝트를 모노 런타임으로 포팅하는 데 많은 노력이 필요합니까? 아니면 마이크로소프트 런타임에 대해 이미 작성된 코드를 가져와서 실행할 수 있을 정도로 정말 호환됩니까?

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

첫 번째 경우 Mono Migration Analyzer 도구(Moma)를 사용하여 응용 프로그램이 Mono에서 실행되는 것으로부터 얼마나 떨어져 있는지 평가할 수 있습니다.평가 결과가 긍정적으로 나오면 테스트와 QA를 시작하고 선적 준비를 해야 합니다.

모노에서 의미론이 누락되거나 크게 다른 기능을 강조하는 보고서와 함께 평가가 돌아오면 코드를 적용하거나 다시 작성할 수 있는지, 최악의 경우 응용 프로그램이 기능을 축소하여 작동할 수 있는지 여부를 평가해야 합니다.

사용자 제출을 기반으로 한 Moma 통계에 따르면(이것은 메모리에서 나온 것입니다) 애플리케이션의 약 50%가 즉시 작동합니다. 약 25%는 약 1주일간의 작업(리팩터링, 적응)을 필요로 하며, 나머지 15%는 코드 청크를 다시 실행하기 위해 진지한 노력을 필요로 합니다.그리고 나머지는 Win32와 매우 밀접하게 관련되어 있기 때문에 포팅을 방해할 가치가 없습니다.이 시점에서 제로에서 시작하거나 비즈니스 결정으로 인해 코드를 이식할 수 있게 될 것입니다. 하지만 우리는 몇 달 동안의 작업에 대해 이야기하고 있습니다(적어도 우리가 가지고 있는 보고서에서).

처음부터 시작하는 경우 Mono에 있는 API만 사용하기 때문에 상황이 훨씬 간단합니다.지원되는 스택(거의 대부분)을 유지하는 한.NET 2.0과 LINQ 및 시스템을 포함한 3.5의 모든 핵심 업그레이드.코어, 그리고 모노 크로스 플랫폼 API)이면 됩니다.

때때로 모노 또는 제한 사항에서 버그를 만날 수 있으며 버그를 해결해야 할 수도 있지만 다른 시스템과 다르지 않습니다.

휴대성에 관해서는: ASP.NET 애플리케이션은 Win32에 거의 또는 전혀 의존하지 않으며 SQL 서버 또는 기타 일반적인 데이터베이스(Mono와 함께 번들로 제공되는 데이터베이스 프로바이더가 많음)를 사용할 수 있기 때문에 포팅이 더 쉽습니다.

창문들.개발자들이 탈출하기를 좋아하기 때문에 폼 포팅이 더 까다로울 수 있습니다.NET 샌드박스와 P/Invo는 wParam에서 BCD 형태로 인코딩된 두 개의 베지어 포인트로 표현되는 커서 점멸 속도를 변경하는 것만큼 유용한 것을 구성하기 위해 머리를 짜냅니다.아니면 그런 잡동사니들.

까지 꽤 광범위한 범위를 가지고 있습니다.NET 4.0 및 의 일부 기능도 포함되어 있습니다.NET 4.5 API, 그러나 API가 더 이상 사용되지 않거나 새로운 대안이 만들어지거나 범위가 너무 넓기 때문에 구현하지 않기로 선택한 몇 가지 영역이 있습니다.다음 API는 Mono에서 사용할 수 없습니다.

• 윈도 프레젠테이션 파운데이션
• Windows Workflow Foundation(두 버전 모두)
• 엔티티 프레임워크
• 표준 웹 서비스 스택에 대한 WSE1/WSE2 "추가 기능"

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

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

최근에 SubSonic에서 MoMA를 실행했는데 한 가지 문제만 발견했습니다. 바로 Nullable 유형의 이상한 사용입니다.그것은 큰 코드베이스이기 때문에, 그곳의 보도는 꽤 인상적이었습니다.

Mono는 여러 상용 제품과 오픈 소스 제품에서 사용되고 있습니다.Wikipedia 및 Mozilla Developer Center와 같은 일부 대형 응용 프로그램에서 사용되고 있으며, Sansa MP3 플레이어와 같은 임베디드 응용 프로그램에서 사용되었으며 수천 개의 게시된 게임에 전원을 공급합니다.

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

데스크톱 측면에서 모노는 GTK#를 사용하기로 약속하면 잘 작동합니다.윈도우.양식 구현은 여전히 약간 버그가 있지만(예: TrayIcon이 작동하지 않음), 많은 진전이 있었습니다.게다가 GTK#는 그대로의 Windows Forms보다 더 나은 툴킷입니다.

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

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

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

• Windows 대신 GTK#을 사용합니다.양식
• 파일 이름의 대소문자를 올바르게 구분합니다.
• 사용하다Path.Separator 코딩 "\"또한 사용합니다.Environment.NewLine에 "\n".
• Win32 API에 대한 P/Invocted 호출을 사용하지 마십시오.
• Windows 레지스트리를 사용하지 마십시오.

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

특이한 점이 있는데, 가장 짜증나는 점 중 하나는 Mono의 현재 상태로 인해 msbuild 파일을 "빌드"할 수 없다는 것입니다.

• MonoDevelop(IDE)은 부분적으로 msbuild를 지원하지만 기본적으로 단순한 hello-world(사용자 지정 빌드 작업, $(SolutionDir)와 같은 동적 "속성", 몇 가지 데드엔드를 지정할 수 있는 실제 구성)를 넘어 모든 "REAL" 빌드 conf에서 작동합니다.
• mono-supply-msbuild-ful-compatible-build-system이어야 하는 xbuild는 훨씬 더 끔찍합니다. 따라서 명령줄에서 빌드하는 것은 Linux 환경에 대한 연합의 매우 "비정통적인" 상태인 GUI를 사용하는 것보다 실제로 더 나쁜 경험입니다.

제품을 실제로 제작하는 동안 다음과 같은 코드를 지원해야 하는 경우에도 일부 문제가 발생할 수 있습니다.

• 컴파일러가 특정 구조물에 대한 작업을 중단함
• 그리고 더 발전된/새로운.예상치 못한 헛소리를 하는 NET 수업 (XLINK 누구?)
• 일부 미숙한 런타임 "기능"(x64의 3GB 힙 제한...WTF!)

그러나 Having은 일반적으로 말하는 것은 매우 빠르게 작동하기 시작하고 해결책/해결책이 풍부하다고 말했습니다.

일단 여러분이 이러한 초기 장애물들을 극복하고 나면, 제 경험은 모노락스(mono Rocks)입니다. 그리고 매번 반복할 때마다 계속해서 나아집니다.

서버를 모노로 실행하고, 하루에 300GB의 데이터를 처리하고, 수많은 p/invoke를 실행하며, 일반적으로 말하는 것은 "블리드 에지" 모노로도 5-6개월 동안 많은 작업을 수행하고, 가동 상태를 유지합니다.

이게 도움이 되길 바랍니다.

수락된 답변에 대한 권장 사항은 현재 약간 구식입니다.

• 윈도우 폼 구현은 이제 상당히 좋습니다. (Paint.net 의 포트는 그림판-모노를 참조하십시오. 이것은 윈도우 폼 애플리케이션과 상당히 관련이 있습니다.필요한 것은 일부 P-Invoke 및 지원되지 않는 시스템 호출에 대한 에뮬레이션 계층뿐이었습니다.
• 경로. 결합 및 경로.경로 및 파일 이름을 조인할 구분자입니다.
• Windows 레지스트리는 응용 프로그램에서 데이터를 저장하고 검색하는 데만 사용하는 경우(기본적으로 Mono 응용 프로그램용 레지스트리이므로 Windows 레지스트리에서 Windows에 대한 정보를 가져올 수 없음)에는 문제가 없습니다.

만약 당신이 WPF를 사용하고 싶다면, 당신은 운이 없습니다. 모노는 현재 그것을 구현할 계획이 없습니다.

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

모노도 좋지만, 제가 보기엔 불안정해요.효과는 있지만 단일 프로세스에 심각한 작업을 부여하면 오류가 발생합니다.

TL;DR - 다음과 같은 경우 모노를 사용하지 않습니다.

• AppDomain 사용(어셈블리 로드)\멀티스레드 환경에서 언로드)
• 'Let-it-fail' 모델을 유지할 수 없음
• 프로세스 실행 중에 때때로 부하가 큰 이벤트 발생

그래서 사실은.

우리는 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 세그먼트 결함은 거의 즉시 처리됩니다.
• bhem이 포함된 모노는 수명이 더 길지만(2~5시간) 결국 segfaults가 발생합니다.

위에서 언급한 바와 같이, sgengg는 단지 작동하지 않습니다(소스에서 빌드된 모노).

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

보엠 세그먼트폴의 경우 - 예를 들어 (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, mono는 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는 다른 사람이 제안한 것처럼 이를 위한 훌륭한 도구입니다.요즘 비호환성의 가장 큰 원인은 Dll을 Win32 라이브러리로 가져오는(또는 P/Invoke) 애플리케이션입니다.일부 어셈블리는 구현되지 않지만 대부분이 Windows 전용이므로 Linux에서는 의미가 없습니다.저는 대부분의 ASP라고 말하는 것이 상당히 안전하다고 생각합니다.NET 응용 프로그램은 Mono에서 제한된 수정 사항으로 실행할 수 있습니다.

(공개:모노 자체와 그 위에서 실행되는 필기 앱에 기여했습니다.)

대부분의 경우 기존 코드를 가져와 Mono에서 실행할 수 있습니다. 특히 ASP를 포팅하는 경우에는 더욱 그렇습니다.NET 응용 프로그램.

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

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

제가 생각할 수 있는 유일한 큰 문제는 약 한 달 전에 일어났습니다.Linux 빌드에서 Windows 빌드에서는 볼 수 없는 메모리 누수가 발생했습니다.몇 가지 수동 디버깅을 수행한 후(리눅스에서 Mono의 기본 프로파일러는 큰 도움이 되지 않았습니다), 문제를 특정 코드 덩어리로 좁힐 수 있었습니다.결국 해결책을 찾아냈지만, 저는 여전히 시간을 내서 누수의 근본 원인이 무엇인지 알아내야 합니다.

Windows Forms 2.0에 대한 Mono 2.0 미리보기의 지원이 얼마나 좋은지 아십니까?

제가 그것을 가지고 놀았던 약간의 시간으로부터, 그것은 비교적 완전하고 거의 사용할 수 있을 것처럼 보였습니다.그것은 일부 장소에서 제대로 보이지 않았고 여전히 전체적으로 약간 히트하거나 빗나갔습니다.솔직히 말해서, 그것이 우리의 몇몇 양식들에서 그랬던 것처럼 잘 작동한다는 것이 저를 놀라게 했습니다.

네, 확실히 그렇습니다(하지만 조심한다면). 우리는 모노 인 라-아작스(http://ra-ajax.org 에서 찾을 수 있는 아작스 라이브러리)를 지원하며, 대부분 전혀 문제가 없습니다.당신은 의 "가장 미친 것들"에 대해 조심할 필요가 있습니다.WSE 등과 마찬가지로 기존 프로젝트 중 일부는 100% 모노 호환이 되지 않을 수도 있지만, 개발 중에 테스트한 새로운 프로젝트는 대부분 모노와 문제 없이 호환이 가능할 것입니다.그리고 모노를 사용하여 리눅스 등을 지원함으로써 얻는 이득은 정말 멋집니다 ;)

모노를 지원하는 비결의 상당 부분은 처음부터 올바른 도구를 사용하는 것이라고 생각합니다. 예를 들어 ActiveRecord, log4net, ra-ajax 등입니다.

우리가 구축하고 있는 애플리케이션 유형의 경우 유감스럽게도 Mono는 생산 준비가 되어 있지 않은 것 같습니다.우리는 전체적으로 그것에 감명을 받았고, 윈도우와 EC2 머신 모두에서 그것의 성능에 감명을 받았지만, 우리의 프로그램은 윈도우와 리눅스 모두에서 가비지 수집 오류로 일관되게 충돌했습니다.

오류 메시지는 "GC의 치명적 오류: 너무 많은 힙 섹션"입니다. 여기 약간 다른 방식으로 문제를 겪고 있는 다른 사용자에 대한 링크가 있습니다.

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

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

코드가 Windows에서 55번째 쿼리를 실행할 때 충돌했습니다.리눅스에서는 작동했지만, 우리가 더 큰 데이터 세트로 이동하자마자, 그것도 충돌할 것입니다.

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

우리 직원 중 한 명이 미겔에게 이메일을 보내 문제를 일으킨 코드를 포함했는데, 아직 응답이 없습니다. :(

또한 다른 많은 사람들이 해결책 없이 이 문제에 직면한 것 같습니다. 한 가지 해결책은 다른 GC 설정으로 Mono를 다시 컴파일하는 것으로 제안되었지만 충돌하기 전에 임계값을 증가시키는 것으로 보입니다.

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

사용하는 네임스페이스와 클래스에 따라 달라집니다.NET 프레임워크.저는 이메일 서버에서 실행할 Windows 서비스 중 하나인 Suse를 변환하는 데 관심이 있었지만, API가 완전히 구현되지 않은 몇 가지 장애물에 부딪혔습니다.Mono 웹사이트 어딘가에 모든 클래스와 완료 수준을 나열한 차트가 있습니다.지원서가 적용되는 경우, 적용해 보십시오.

물론 다른 애플리케이션과 마찬가지로 완전히 약속하기 전에 프로토타이핑 및 테스트를 수행해야 합니다.

또 다른 문제는 라이센스가 부여된 소프트웨어입니다. 다른 사람의 DLL을 참조하는 경우 해당 어셈블리에 포함된 비호환성을 코드화할 수 없습니다.

제 생각에 만약 당신이 일부 타사 구성 요소가 있는 애플리케이션을 가지고 있다면 당신은 속이 꽉 찼을 것입니다.많은 공급업체가 Mono를 염두에 두고 개발할 것 같지는 않습니다.

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

아니요, 모노는 진지한 일을 할 준비가 되지 않았습니다.저는 F#을 사용하여 Windows에서 몇 개의 프로그램을 작성하고 Mono에서 실행했습니다.그 프로그램들은 디스크, 메모리, CPU를 상당히 집중적으로 사용했습니다.모노 라이브러리(관리 코드)의 충돌, 네이티브 코드의 충돌, 가상 시스템의 충돌을 보았습니다.모노가 작동했을 때 프로그램은 에 비해 최소 2배 이상 느렸습니다.Windows에서 인터넷을 사용하고 훨씬 더 많은 메모리를 사용했습니다.진지한 일을 할 때는 모노를 멀리하세요.

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