Mono는 종종“예, .NET은 크로스 플랫폼입니다”라고 말합니다. 그 주장은 얼마나 유효합니까? [닫은]

에서 당신은 무엇을이 시점에서 .NET 및 Java 사이에 프로젝트를 선택할 것인가? "항상 Windows에 배포 하시겠습니까?" 새로운 웹 프로젝트에서 가장 먼저 결정해야 할 가장 중요한 기술적 결정이며, 대답이 "아니오"이면 .NET 대신 Java를 사용하는 것이 좋습니다.

매우 일반적인 반론은 "리눅스 / OS X / 무엇이든 실행하고 싶다면 Mono 만 실행합니다" ¹ 인데, 이는 표면적으로 매우 설득력있는 주장이지만 몇 가지에 동의하지 않습니다. 원인.

• OpenJDK와 공급 업체가 제공 한 모든 JVM은 공식적인 Sun TCK를 통과하여 제대로 작동합니다. Mono가 Microsoft TCK를 전달하는 것을 알지 못합니다.
• 모노는 .NET 릴리스를 추적합니다. 현재 어떤 .NET 수준이 완전히 지원됩니까?
• 모든 GUI 요소 (WinForms?)가 Mono에서 올바르게 작동합니까?
• 기업은 공식 계획 B로서 오픈 소스 프레임 워크에 의존하기를 원하지 않을 수 있습니다.

Oracle의 새로운 Java 거버넌스로 미래는 안전하지 않다는 것을 알고 있지만 IBM은 Linux를 포함한 많은 플랫폼에 JDK를 제공합니다 . 그들은 단지 오픈 소스가 아닙니다.

그렇다면 어떤 환경에서 Mono가 .NET 응용 프로그램에 유효한 비즈니스 전략입니까?

¹ _{Mark H는 "저는 .NET으로 작성된 Windows 응용 프로그램이 모노로 실행되어야합니다"라는 주장이 있다고 주장하는 경우에는 유효한 클레임이 아니라고 말합니다. 그러나 Mono는 그러한 응용 프로그램을 이식하려고 노력했습니다. 더 간단합니다. "}

Sparkie의 대답에 따라 조금 보완하겠습니다.

".NET is cross platform"은 원래 만들어진 프레임 워크와 세계가 변화하고 진화했기 때문에 너무 모호한 진술입니다.

짧은 대답은 다음과 같습니다.

.NET 및 그 파생물 인 Common Language Infrastructure Standard를 지원하는 기본 엔진은 크로스 플랫폼이며 코드를 여러 플랫폼으로 이동시키려는 경우 올바른 플랫폼에서 올바른 API를 사용하여 제공하도록 계획해야 합니다. 각 플랫폼에서 최고의 경험.

CLI 제품군은 전화기와 메인 프레임의 차이가 너무 커서 "Write Once, Run Anywhere"접근 방식을 시도하지 않았습니다. 대신 플랫폼별로 고유 한 API 및 런타임 기능이 개발자에게 각 플랫폼에서 훌륭한 경험 을 제공 할 수있는 적절한 도구를 제공하기 위해 등장했습니다 .

프로그래머는 더 이상 Windows PC 또는 Unix 서버를 대상으로하지 않습니다. PC, 게임 콘솔, 강력한 전화, 셋톱 박스, 대형 서버 및 분산 시스템 클러스터에 이르기까지 매혹적인 플랫폼이 전 세계에 퍼져 있습니다. 모든 플랫폼에 딱 맞는 크기는 작은 장치에서 부풀어 오르고 큰 시스템에서는 성능이 저하 된 느낌 일뿐 입니다.

Microsoft의 .NET Framework 제품은 크로스 플랫폼이 아니며 Windows에서만 실행됩니다. Windows Phone 7, XBox360 및 Silverlight를 통한 브라우저와 같은 다른 시스템에서 실행되는 Microsoft의 .NET Framework 변형이 있지만 모두 약간 다릅니다.

오늘날 .NET 기반 기술로 모든 주요 주류 OS, 전화, 모바일 장치, 임베디드 시스템 및 서버를 대상으로 할 수 있습니다. 다음은 각 경우에 사용할 CLI 구현을 보여주는 목록입니다 (이 목록은 포괄적이지 않지만 경우의 99 %를 차지해야 함).

• x86 및 x86-64 기반 PC 컴퓨터 :
  • Windows 실행-> 일반적으로 .NET 또는 Silverlight를 실행하지만 여기에서 전체 Mono를 사용할 수도 있습니다.
  • Linux, BSD 또는 Solaris 실행-> 전체 Mono 또는 Silverlight를 실행
  • MacOS X 실행-> 전체 모노 또는 실버 라이트 실행
  • Android 실행-> Mono / Android 하위 세트를 실행합니다.
• ARM 컴퓨터 :
  • Windows Phone 7 실행 : Compact Framework 2010을 실행합니다.
  • Windows 6.5 및 이전 버전 실행 : 이전 Compact Framework를 실행
  • Android 기기 : Mono / Android를 실행합니다
• PowerPC 컴퓨터 :
  • 전체 Linux, BSD 또는 Unix 운영 체제에 대해 전체 Mono를 실행합니다.
  • PS3, Wii 또는 기타 임베디드 시스템 용 내장 모노를 실행합니다.
  • XBox360에서 CompactFramework를 실행합니다.
• S390, S390x, Itanium, SPARC 컴퓨터 :
  • 당신은 전체 모노를 실행
• 다른 임베디드 운영 체제 :
  • 모바일 프로파일로 .NET MicroFramework 또는 Mono를 실행합니다.

귀하의 요구에 따라 위의 내용이 충분하거나 그렇지 않을 수 있습니다. 모든 곳에서 동일한 소스 코드를 실행할 수는 없습니다. 예를 들어 XNA 코드는 모든 데스크톱에서 실행되지 않지만 .NET 데스크톱 소프트웨어는 XNA 또는 전화에서 실행되지 않습니다. 일반적으로 .NET Framework의 다른 프로필에서 실행하려면 코드를 변경해야합니다. 내가 알고있는 프로필은 다음과 같습니다.

• .NET 4.0 프로필
• Silverlight 프로필
• Windows Phone 7 프로필
• XBox360 프로필
• 모노 코어 프로파일-.NET 프로파일을 따르며 Linux, MacOS X, Solaris, Windows 및 BSD에서 사용할 수 있습니다.
• .NET 마이크로 프레임 워크
• iPhone 프로필의 모노
• 안드로이드 프로파일의 모노
• PS3 프로필의 모노
• Wii 프로필의 모노
• 달빛 프로필 (Silverlight와 호환 가능)
• Moonlight 확장 프로파일 (Silverlight + 전체 .NET 4 API 액세스)

따라서 이들 프로파일 각각은 실제로 약간 씩 다르며 이는 나쁘지 않습니다. 각 프로파일은 호스트 플랫폼에 맞도록 설계되었으며 의미가있는 API를 노출하고 의미가없는 API를 제거합니다.

예를 들어 호스트 브라우저를 제어하는 ​​Silverlight의 API는 전화에 적합하지 않습니다. 그리고 XNA의 쉐이더는 PC 하드웨어에서 이에 대한 지원이 부족한 경우에는 의미가 없습니다.

.NET이 하드웨어 및 기본 플랫폼의 기본 기능에서 개발자를 격리하는 솔루션이 아니라는 사실을 빨리 알면 더 나아질 것입니다.

우선 일부 API와 스택은 여러 플랫폼에서 사용할 수 있습니다. 예를 들어 ASP.NET은 Windows, Linux, Solaris, MacOS X에서 사용할 수 있습니다. API는 .NET과 Mono에 모두 존재하기 때문입니다. ASP.NET은 XBox 또는 Windows Phone 7과 같은 일부 Microsoft 지원 플랫폼에서는 사용할 수 없으며 Mono가 Wii 또는 iPhone과 같이 지원하는 다른 플랫폼에서는 지원되지 않습니다.

다음 정보는 11 월 21 일 기준으로 정확하며, 모노 세계의 많은 것들이 변경 될 것입니다.

동일한 스택을 다른 스택에도 적용 할 수 있습니다. 전체 목록에는 적절한 테이블이 필요합니다. 여기에는 어떤 방법을 제시해야할지 모르지만 특정 플랫폼에는 없을 수있는 기술 목록이 있습니다. 여기에 나열되지 않은 내용을 사용할 수 있다고 가정 할 수 있습니다.

[핵심 런타임 엔진]

• Reflection.Emit 지원 [WP7, CF, Xbox, MonoTouch, PS3를 제외한 모든 곳]
• CPU SIMD 지원 [Linux, BSD, Solaris, MacOS X; 곧 PS3, MonoTouch 및 MonoDroid]
• 계속-Mono.Tasklets [Linux, BSD, Solaris, MacOS, PS3, Wii]
• 어셈블리 언로드 [Windows 만 해당]
• VM 인젝션 [Linux, BSD, MacOS X, Solaris]
• DLR [Windows, Linux, MacOS X, Solaris, MonoDroid]
• 일반 사항 [PS3 및 iPhone의 일부 제한 사항].

언어

• C # 4 [모든 곳에서]
• 서비스로서의 C # 컴파일러 (Linux, MacOS, Solaris, BSD, Android)
• IronRuby [모든 곳, WP7, CF, Xbox, MonoTouch, PS3 제외]
• IronPython [모든 곳, WP7, CF, Xbox, MonoTouch, PS3 제외]
• F # [모든 곳, WP7, CF, Xbox, MonoTouch, PS3 제외]

서버 스택

• ASP.NET [Windows, Linux, MacOS, BSD, Solaris]
• ADO.NET [모든 곳]
• LINQ to SQL [모든 곳]
• 엔터티 프레임 워크 [모든 곳]
• [핵심 XML 스택]
  • XML 직렬화 (WP7, CF, Xbox를 제외한 모든 곳)
• LINQ to XML (모든 곳에서)
• System.Json [Silverlight, Linux, MacOS, MonoTouch, MonoDroid]
• System.Messaging [Windows; Linux, MacOS 및 Solaris에서는 RabbitMQ가 필요합니다.]
• .NET 1 엔터프라이즈 서비스 [Windows 만 해당]
• WCF [Windows에서 완료; Silverlight, Solaris, MacOS, Linux, MonoTouch, MonoDroid의 작은 하위 집합]
• Windows 워크 플로 [Windows 만 해당]
• 카드 공간 ID [Windows 만 해당]

GUI 스택

• Silverlight (Windows, Mac, Linux-달빛 포함)
• WPF (Windows 만 해당)
• Gtk # (Windows, Mac, Linux, BSD)
• Windows.Forms (Windows, Mac, Linux, BSD)
• MonoMac-기본 Mac 통합 (Mac 만 해당)
• MonoTouch-기본 iPhone 통합 (iPhone / iPad 만 해당)
• MonoDroid-기본 Android 통합 (Android 만 해당)
• Media Center API-Windows 전용
• 클러 터 (Windows 및 Linux)

그래픽 라이브러리

• GDI + (Windows, Linux, BSD, MacOS)
• 쿼츠 (MacOS X, iPhone, iPad)
• 카이로 (Windows, Linux, BSD, MacOS, iPhone, iPad, MacOS X, PS3, Wii)

모노 라이브러리-크로스 플랫폼, .NET에서 사용할 수 있지만 수동으로 빌드해야 함

• 서비스로서의 C # 4 컴파일러
• Cecil-CIL 조작, 워크 플로우, CIL 계측, 링커
• RelaxNG 라이브러리
• Mono.Data. * 데이터베이스 제공자
• 전체 System.Xaml (.NET이 스택을 제공하지 않는 설정에 사용)

MonoTouch는 iPhone에서 모노를 실행하는 것을 의미합니다. MonoDroid는 Android에서 실행되는 Mono를 의미합니다. PS3 및 Wii 포트는 Sony 및 Nintendo 인증 개발자 만 사용할 수 있습니다.

형식이 결여되어 죄송합니다.

먼저, 공용 언어 인프라 (공개 표준)와 .NET (해당 표준의 Microsoft 구현)을 구분해야합니다. Mono는 CLI의 구현이며 "휴대용 .NET"이라고 주장한 적이 없습니다. 또한 C # 언어는 개방형 표준이며 .NET과 밀접하게 관련되어 있지 않습니다.

Microsoft에 구현이 호환되는지 확인하는 도구가 있는지는 알 수 없지만, 그렇게한다면, 모노 사람들이 그것을 사용하고 있다고 확신합니다.

모노는 .Net 뒤에 있지만 간신히 있습니다. Mono는 C # 4.0 코드 (현재 .NET 버전)를 실행할 수 있습니다. 또한 Microsoft는 최근에 모든 DLR 코드 및 라이브러리 오픈 소스 (Apache 2.0 라이센스에 따라)를 만들었으며,이를 통해 Mono는 IronPython, IronRuby 및 F #과 같은 언어를 사용할 수있게되었으며 지난 주에만 오픈 소스가되었습니다. 또한 Microsoft는 .NET에서 곧 출시 될 기능의 CTP를 정기적으로 발표하여 모노 개발자가 최신 릴리스 버전을 유지할 수 있도록합니다.

.NET에는 코드 계약과 같은 많은 도구와 확장이 있습니다. 이것들이 항상 모노로 완전히 구현 된 것은 아닙니다. (현재는 계약 필요에 대한 부분 계약 유효성 검사기가 있다고 생각합니다). 어쨌든 이들은 .NET 앱에서 일반적으로 사용되지 않지만 인기가 높아지면 모노로 구현되는 속도도 높아집니다.

WinForms는 (전적으로) 이식성이 없습니다. 이들은 .NET 전용이며 CLI의 일부가 아닙니다. CLI는 특정 위젯 세트를 지정하지 않습니다. 그러나 크로스 플랫폼 위젯 세트 (GTK # 및 Silverlight)가 있습니다. 이식성을 염두에두고 처음부터 응용 프로그램을 작성하는 경우 Winforms / WPF 대신이 중 하나를 사용합니다. 또한 mono는 Winforms API를위한 얇은 래퍼 (wrapper)를 제공하여 기존 winforms 앱을 GTK #에보다 쉽게 ​​이식 할 수 있습니다 (전체 재 작성없이).

Mono는 기존 .Net 응용 프로그램을 가져 와서 이식성에 대해 알려줄 수있는 MoMA (Mono Migration Analyzer) 도구를 제공합니다. (예 : 사용되는 이식 불가능한 라이브러리, P / Invokes 등 식별)

오픈 소스에 의존하고 싶지 않은 비즈니스의 경우 모노 라이센스를 다시 사용할 수 있습니다. 모노에 추가 된 코드의 소유권은 소설에 넘겨지며, 일반 LGPL 라이센스 이외의 다른 방법으로 라이센스를받을 수 있습니다 (어쨌든 제한이 거의 없음).

".NET은 이식성이 뛰어나다"라는 주장에 대해서는 처음부터 코드를 작성하고 프레임 워크의 이식성 문제를 알고 있다면 이것이 유효한 주장 일 수 있다고 생각합니다. ".NET으로 작성된 Windows 응용 프로그램이 모노로 실행되어야한다"는 주장은 유효한 주장이 아닙니다. 그러나 Mono는 그러한 응용 프로그램을보다 간단하게 이식하기 위해 노력했습니다.

포인트 별 :

• OpenJDK와 공급 업체가 제공 한 모든 JVM은 공식적인 Sun TCK를 통과하여 제대로 작동합니다. Mono가 Microsoft TCK를 전달하는 것을 알지 못합니다.
  Microsoft CLR이 준수하는 사양이 있습니다. Mono는 Microsoft CLR의 복제본이 아니라 동일한 사양을 구현 한 것입니다. 한편으로, 이것이 더 큰 비 호환성을 초래할 가능성이 있습니다. 실제로 이것은 모노에 매우 효과적이었습니다.
• 모노는 .NET 릴리스를 추적합니다. 현재 어떤 .NET 수준이 완전히 지원됩니까?
  .Net에 대한 문서가 실제 릴리스보다 우선하기 때문에 mono 는 공식 Microsoft 릴리스 이전 에 .Net 4에 대한 .Net 4 지원을 실제로 완료했습니다 (베타 릴리스 아님) . 또한 mono는 지원되지 않는 사항을 문서화하는 데 매우 효과적이며 기존 프로젝트에 대해 실행할 수있는 몇 가지 도구가있어 비 호환 가능성이있는 장소를 파악할 수 있습니다.
• 모든 GUI 요소 (WinForms?)가 Mono에서 올바르게 작동합니까?
  대부분의 winforms는 정상적으로 작동합니다. WPF, 그렇게 많지 않습니다. Java에서도 마찬가지입니다. 많은 고급 위젯 / gui 툴킷이 모든 플랫폼에서 지원되는 것은 아닙니다.
• 기업은 공식 계획 B로서 오픈 소스 프레임 워크에 의존하기를 원하지 않을 수 있습니다.이
  경우 Java와 함께 진행되지 않을 것입니다. 그러면 오픈 소스 프레임 워크가 계획 A보다 훨씬 높아집니다.

요약하자면, 지금 크로스 플랫폼 앱을 만들고 싶다면 get-go에서 mono로 시작하여 프레임 워크로 사용하는 것은 아무 문제가 없습니다. 원하는 경우 Windows에 모노를 배포 할 수도 있습니다.

반면 에, 미래에 알려지지 않은 시점에 플랫폼 간 교차 가 필요할 수 있다고 생각되는 Windows 앱을 구축 하려는 경우 기본 Windows 위젯 및 도구를 사용하고 싶을 것입니다. .Net은 Java보다 훨씬 나은 작업을 수행하며이 시나리오에서 mono는 완벽하게 수용 가능한 폴백입니다.

다시 말해, 그렇습니다. .Net은 귀하의 질문에 중요한 모든 방식으로 크로스 플랫폼입니다. 아니요, mono는 모든 .Net 프로그램을 기본적으로 실행하지는 않지만 새 프로젝트의 맥락에서 질문합니다. 특히 .Net 용으로 개발하는 것이 아니라 모노 용으로 개발하려는 경우 새 프로젝트를 문제없이 유지하고 호환성 문제를 피하기 위해 많은 노력을 기울이지 않습니다.

무엇보다도 이것이 처음에는 잘못된 질문이라고 생각합니다. 처음부터 새로운 개발 팀을 구축하지 않는 한, 한 분야에서 전문 지식을 갖춘 프로그래머부터 시작합니다. 프로그래머가 이미 알고있는 것을 사용하면 최상의 결과를 얻을 수 있습니다. 크로스 플랫폼 앱을 구축하는 것만 큼 중요한 것은 자바 경험이 거의없는 .Net 프로그래머로 가득 찬 팀이 있다면 해고하거나 다음 프로젝트에서 모두 자바를 배우지 않을 것입니다. Java 프로그래머로 가득 찬 팀이 있다면 Windows 전용 프로젝트에 대해 .Net을 배우도록 요청하지 않을 것입니다. 그것들 중 하나는 견과류 일 것입니다.

저는 Mono와 함께 일해 왔으며 Microsoft가 직접 지원하지 않는 오픈 소스 인 대체 플랫폼을 사용하는 것만 큼 좋다고 말할 수 있습니다. Clojure 또는 Scala와 같은 대체 오픈 소스 플랫폼을 사용하는 것이 편하다면 Mono를 사용하는 것이 편할 것입니다.

Mono가 지원하는 .NET 레벨은 항상 Mono Roadmap 페이지 에서 찾을 수 있습니다 .

모든 GUI 요소가 작동합니까? 내가 아는 한, 그들은 모든 요소를 ​​철저히 시도하지는 않았지만 그렇게합니다.

Mono는 .NET과 동일합니까? 아니요. 여기저기서 약간의 (또는 아마도 큰) 조정이 필요할 것으로 생각됩니다. 예를 들어, 현재는 Entity Framework를 실행할 수 없습니다.

대상으로 .NET / mono 유니버스 는 매우 빠르게 이동 합니다.

몇 년마다 Microsoft는 .NET과 관련된 언어, 런타임 및 인프라와 관련하여 몇 가지 강력한 변경 사항과 혁신 사항을 발표했습니다. 예를 들어 : Generics, LINQ, DLR, Entity Framework-Visual Studio의 모든 새로운 개정판에서 일반적으로 대상 프레임 워크의 기능 세트와 유용성이 크게 향상되었습니다.

프레임 워크의 지속적인 개선은 환영하지만, 여러 플랫폼에서 호환성을 원한다면 문제가됩니다. Red Hat Enterprise Linux와 같은 장기 지원 플랫폼은 새로운 기술 채택과 관련하여 빙하 적으로 느리게 움직이며, 어떤 시점에서든 지난 몇 개월 내에 모노 플랫폼이 크게 개선 될 것입니다. 따라서 멋진 아이들이 만드는 것들을 실행하려면 Mono를 처음부터 컴파일하고 자신의 패치와 업데이트를 관리해야합니다. 멋지지 않아요.

반면에 Java는 어린이 수영장만큼 정체되어 있습니다. 특히 특허 소송을 위해 Java를 원했던 회사의 소유이기 때문에 가까운 미래에 언어 나 런타임에 변화가 감지되지 않을 것이라고 확신 할 수 있습니다. Java는 FORTRAN만큼 안정적인 플랫폼입니다. 어떤 종류의 개선을 원한다면 그렇게 좋지는 않지만 엔터프라이즈 응용 프로그램을 배포하려고하면 그렇게 나쁘지 않습니다.

사용자 관점에서 Mono는 Windows .NET 앱을 Linux와 호환되도록 만드는 데 어려움을 겪습니다. 실제로 모노로 작성된 Windows 앱을 실행하려고하면 작동하지 않습니다.

패키저의 관점에서 (휴대용 앱에서 약간의 작업을 했었 음) .NET은 축복이자 저주가 될 수 있습니다. Windows에만 있다면 .NET을 사용하면 라이브러리가 많을수록 시스템 종속적 요소가 적어지기 때문에 배포가 훨씬 쉬워집니다 (대부분 Windows 버전간에 믿습니다). 호환 또는 전달 호환. 프로그램마다 다른 버전의 .NET을 다운로드해야합니다.

즉, Mono는 C # 프로그램을 크로스 플랫폼으로 만드는 좋은 출발점입니다. 프로그램을 최신 WINE으로 패키지하지 말고 완료하십시오. 어디에서 Picasa를 사용했는지 살펴보세요.

두 언어 / 플랫폼의 정치적 안정성과 마찬가지로 RMS는 Mono가 어떻게 Novell을 이끌고 있는지에 대해 논할 것입니다. 두 플랫폼 모두 현재 정치적으로 불안정한 것으로 간주 될 수 있습니다.

쉽게 크로스 플랫폼을 원한다면, 시도되고 진정한 길은 QT이며, 현재로서는 정치적으로 매우 안정적입니다. 정말 인기있는 전화를 판매합니다.

모노는 Microsoft .net의 1 : 1 포트가 아닙니다. Mono는 단순히 구현하지 않거나 그렇게 할 계획이없는 기술 (예 : Workflow Foundation 또는 WPF )이 있지만 Microsoft .NET이 수행하지 않는 자체 기술 (예 : SIMD Extensions)도 있습니다. .

짧은 대답 : Mono와 Microsoft .NET은 동일한 기본 기반 (CIL과 BCL)을 기반으로하지만 별도의 프로젝트입니다.

원래 게시물의 진술에 대한 작은 의견. TCK가 오라클이 Java를 개방형 표준이라고 주장 할 수있는 이론적 인 도구라고 주장합니다. 아시다시피, Apache Harmony는 현재 몇 년 동안 "자바"인증을 받기 위해 노력해 왔습니다. 오라클은 실제로 제휴 관계가 있거나 오픈 컨트롤 (OpenJDK)과 별개로 오픈 소스 구현에 관심이 없다는 것이 분명합니다. Mono와 매우 유사하며, 완료되지 않았으며 (예 : Java Web Start 지원 없음) 비공개 소스 HotSpot 구현에서 사용 가능한 일부 최적화가 누락되었습니다.

2010 년 현재 (대부분의) Java는 공개 소스이지만 공개 표준은 아니지만 .NET의 대부분은 공개 소스가 아니라 공개 표준입니다. 물론 예외는 있지만 DLR, IronPython, IronRuby 및 F #은 실제로 오픈 소스입니다. 모노는 오픈 표준의 오픈 소스 구현 인 두 가지 세계를 모두 제공하기 때문에 흥미 롭습니다.

모든 기술을 제쳐두고 실제로 코드를 작성할 때 매우 중요한 부분이 발생합니다.

크로스 플랫폼 기술 (Java, Python, Ruby 등)과 마찬가지로 이식성을 염두에두고 코드를 작성하지 않으면 코드가 제대로 실행될 가능성이 기본적으로 없다고 가정해야합니다 (이런 기회가 있더라도 이상한 오동작이 매우 중요하기 때문에 실제로는 훨씬 더 높습니다. 읽는다 : 랜덤 어셈블리를 가져 가지 않고 모노에서 실행하라.

그러나 새로운 프로젝트 (또는 쉽게 리팩터링 할 수있는 프로젝트)의 경우 잠재적으로 이식 가능한 런타임으로 .Net / Mono를 선택하는 것이 합리적이지만 프로젝트가 초기에 있었더라도 Mono에서 매우 일찍 코드를 테스트하여 많은 번거 로움을 덜어줍니다. 멀티 플랫폼으로의 약간의 변화. 연속 통합 서버를 사용하는 경우 이는 모노 빌드 노드를 설정하는 것만 큼 간단 할 수 있습니다. 개발 과정에서 많은 문제가 해결 될 수 있습니다 (빌딩 문자열과 같은). 습관을 들이지 않고 약간의 예측만으로도 많은 코드 덩어리를 Mono에서 이식 가능하고 단위 테스트 할 수 있습니다. 나머지 (즉, 실패한 단위 테스트)는 플랫폼에 따라 다르지만 (PInvoke를 사용하는 코드와 같은) 대상 플랫폼마다 대체 구현을 제공 할 수 있도록 충분히 캡슐화되어야합니다.

물론 Mono에서 사용할 수없는 (.Net) 또는 호환 가능한 (타사) 라이브러리를 사용하면이를 배제 할 수는 있지만 내 분야 에서는 아직 보지 못했습니다. 이것이 우리가 실제로 직장에서 사용하는 전략이며, 적용 할 때 .Net + Mono가 크로스 플랫폼이라고 주장 할 염려가 없습니다.

정답입니다. 작은 웹 서버가 IIS에서 Apache로 이동하여 거의 어려움없이 모노로 실행되는 것을 보았습니다. Linux에서 Win Forms를 사용하여 변경되지 않은 Windows .Net 응용 프로그램을 성공적으로 실행했습니다.

그러나 작동 할 수는 있지만 모노로 구현되지 않은 API 호출을 사용하면 작동하지 않으며 유일한 해결책은 응용 프로그램을 다시 작성하거나 창을 사용하거나 추가 항목을 모노로 작성하는 것입니다.