$ sudo apt-get update
$ sudo apt-get upgrade 
$ sudo apt-get install mono-complete

저작자 표시
신고
by 흥배 2014.05.12 21:39

Mono 2.10 이후의 메이저 업데이트.

C# 5 지원과 .NET 4.5 호환성을 가진다.

 

주요 변경점

n  C# Async 컴파일러.

n  MS의 오픈 소스인 ASP.NET MVC4, ASP.NET WebPages, Entity Framework, Razor, System.Json 포함.

n  SGen 가베지컬렉터가 기본 GC가 되었다. 멀티프로세서를 활용하여 성능과 확장성을 향상.

n  Eval() API에서 식만이 아닌 형 전체를 컴파일 할 수 있게 되었다. Compile as Service도 글로벌 컴파일러가 아니게 되어 복수의 영역에서 인스턴스화가 가능.

n  ThreadLocal<T> List<T>등 몇 개의 형을 런타임 최적화.

n  성능 튜닝 용으로 컴파일러에 대해서 인라인 코드를 강제화 하는 새로운 속성을 추가.

n  MacOS 상에서 64비트 바이너리로서 컴파일 가능.

n  USB 기기 접속 성능 향상을 한 소프트웨어 디버거.

n  OS X Mono에는 F# 3.0 번들.

n  SQLite 구현으로 iOS의 암호 API가 지원되었다. 설정에 의한 스레드 모델 변경도 가능.

 

Release Notes

http://www.mono-project.com/Release_Notes_Mono_3.0

 

OpenSUSE 13.1에서는 기본으로 Mono 3.0.6 지원

 

 

 

저작자 표시
신고
by 흥배 2014.02.27 08:00

mono: ECMA CLI 런타임

mono 런타임은 exe 파일이나 dll 파일을 해석하여 그것의 CIL(MSIL) 코드를 CPU의 네이티브 명령으로 옮겨서 실행하는 실행 엔진이다. 그 내용은 CIL(MSIL) 메타 데이터 로더, JIT 컴파일러 등의 실행 엔진, 메모리 관리(가베지 컬렉션), AppDomain 이나 리모, 스레드 관리,  I/O처리,  P/Invoke 구현, 디버거 지원 등 다방면에 걸친다.

 

어셈블리의 로드와 실행

mono CIL 코드를 실행하는 방식으로서 가장 간단한 것은 exe 형식의 CIL 코드 실행이다. executable(실행 형식)로서의 mono(Windows라면 mono.exe) exe 형식의 MSIL 코드를 실행하기 위한 콘솔 도구이다. 예를 들면 다음 명령은 실제로 executable mono를 콘솔에서 실행하고 있다.

 

<콘솔>

$ mono MyProgram.exe   // MyProgram.exe를 실행한다

 

.NET exe 파일은 Windows 상에서는 네이티브 실행 파일 형식(Coff)에 들어가 있지만 Windows 이외의 OS에서는 그렇지 않다. CIL은 어떻게 발버둥 쳐도 Linux의 표준 실행 파일 형식인 ELF 포맷에는 적합하지 않다. ECMA CLI는 이 점에서는 분명히 Windows에 유리한 사양을 책정하고 있다. "mono에서 인수에 실행 파일을 지정하여 실행할 수 밖에 없는 것은 불편하다"라는 것은 착각이다(Linux에서는 "binfmt_misc" 라는 기능을 사용해 .NET 형식의 바이너리를 mono의 호출로 연결할 수 있다. .exe 형식은 Windows의 기본 실행 파일로 Wine에서 실행하지 않으면 쓸 수 없는 가능성도 있으으므로 Linux 상에서 확장자나 MIME 타입으로 연관시키는 것은 추천할 수 없다).

 

.NET 애플리케이션은 exe 형식의 엔트리 포인트를 가질 수는 없다. 예를 들면 ASP.NET Web 어플리케이션은 dll 형식으로 생성되며, ASP.NET의 실행 엔진(IIS이라면 ISAPI)가 독자적으로 CLR 혹은 mono의 호스팅 API를 사용하여 독립된 응용 프로그램 도메인을 만들어서 거기에 dll을 로드하고, 소정의 엔트리 포인트에서 애플리케이션을 실행한다. Silverlight 이라면 CoreCLR로 불리는 호스트가 xap 애플리케이션 패키지에서 공약에 따라 dll을 찾아내 그것을 로드하고 있다.

 

같은 일이 mono에 대해서도 들어맞는다. mono의 실행 엔진의 몸체는 "libmono"라고 하는 라이브러리로 독립하고 있으며 이를 사용하면 독자적인 호스트를 작성할 수 있다. libmono API "mono의 임베디드 API" 또는 "embedded mono"로 불린다. 전형적인 이용 사례는 브라우저 플러그 인이다. Unity는 가장 유명한 embedded mono의 사용자라고 말할 수 있지만, 그들은 "Web Player"라는 런타임 플러그 인을 제공하고 있다. Mono팀에서도 과거 "Moonlight" 라는 Silverlight 호환 환경을 공개했었는데 이것도 브라우저 플러그 인 API의 표준적 존재로 NPAPI을 경유하여 mono 런타임을 실행하는 플러그 인이다. 구글은 "NaCL(native client)"라는 브라우저용 네이티브 코드 실행 환경에서 mono를 동작시키기 위한 패치를 mono에 컨트리뷰트 했다. mono를 움직이는 NaCL에서는 Unity를 움직일 수 있다.

 

mono 런타임은 어셈블리의 CIL 메타 데이터를 로드하고, 환경 변수나 구성 파일과 대조, 적절한 mscorlib.dll 파일을 로드하여 .NET 런타임의 프로파일을 선택한다. 로드 되는 mscorlib.dll 버전에 따라 그 런타임의 프로파일(.NET 2.0/.NET 4.0/.NET 4.5/iOS/Android )이 결정된다. .NET 2.0 프로파일은 공식은 이미 지원하지 않으므로 언제 없어져도 이상하지 않는 프로파일이므로 .NET 4.x로 이행하는 것이 좋다.

 

 

네이티브 실행 가능한 코드 생성

프로파일이 정해지면 AppDomain이 생성되고 거기에 어셈블리가 로드되어 실행 엔진에 의해 CPU 명령으로 변환된 CIL의 코드가 실행된다. 현재 실행 엔진은 2종류가 있다. "mini"로 불리는 JIT 컴파일러(실행 시 컴파일) AOT 컴파일러(사전 컴파일)이다(이하 단순히 JIT AOT로 표기). 이전에는 이 밖에 "mint" 라는 인터프리터도 있었지만 이미 역할을 끝내고 조만간 소멸할 예정이다. AOT.NET에서 NGen가 비슷한 일을 하고 있는데, 애플리케이션의 실행을 수반하지 않고 dll을 타겟 CPU의 명령으로 컴파일하여 네이티브 공유 라이브러리를 생성하는 기능이다.

 

mono 런타임에서는 직접 CPU 명령을 생성하는 mono 자신의 코드 생성 엔진에 더해, LLVM에 의한 코드 생성 엔진도 지원하고 있다. LLVM이 더 빠른 코드를 생성하는 부분은 적지 않다.  한편 LLVM을 로드 하기 위해 필요한 메모리가 증가하므로 LLVM은 만인 대상은 아니다.

* LLVM 코드생성: http://www.mono-project.com/Mono_LLVM

 

mono AOT는 실제로는 " AOT" "통상 AOT" 2 종류가 있다. AOT는 모든 CIL 코드를 네이티브 명령으로 변환 할 수 있는 것은 아니다. 실행 시 CPU 명령을 JIT에서 생성하는 것이 불가결한 기능이 있다. 예를 들면 System.Reflection.Emit 이름 공간의 API를 사용하여 동적으로 코드를 생성하고 실행하는 것은 AOT에서는 불가능하다. 통상의 AOT모드의 경우 AOT 변환되지 않는 코드를 만나면 코드는 JIT에 폴 백하여 실행된다. AOT의 경우는 에러가 되면 끝이다.

 

동적으로 생성된 코드가 동작하지 않는 환경이 있다. 대표적으로 Jailbreak 하지 않은 iOS 환경이다. iOS는 코드를 실행하는 플랫폼 차원에서 동적으로 코드를 생성하기 위해 필요한 코드를 무효화한다. AOT는 이러한 플랫폼에서 코드를 실행할 때 사용한다. Xamarin.iOS는 빌드 툴 체인에서 자동으로 이 AOT를 사용하여 애플리케이션 코드를 빌드한다(시뮬레이션용 빌드를 제외).

 

 

가베지 컬렉션(GC)

mono 런타임은 오랫동안 고전적 GC의 대표적인 존재인 "Boehm GC"에 손을 더한 것을 사용했지만 현재는 세대별 가베지 컬렉션을 구현하고 있다. 이 구현은 "SGen"이라고 불린다(원래는 "Simple Generational GC" 이었는데 지금은 분명히 simple이 아니다). mono 3.2 이후는 기본적으로 SGen이 유효하게 되어 있다. 현재의 Xamarin.iOS는 기본은 SGen이 아니며 선택 가능하다. Xamarin.Android Java GC와 협조 동작인 관계로 당초부터 SGen에서만 실행 가능했다.

 

 

mscorlib의 내부 호출 기능(및 파일 I/O의 특기 사항)

mono 런타임의 또 하나 중요한 기능은 mscorlib.dll에서 MethodImpl 속성에 "MethodImplOptions.InternalCall"를 지정하여 선언하고 있는 extern 메서드의 실체인 InternalCall(mono의 소스 코드에서는 "icall"으로 불린다). mono mscorlib 소스 코드(이하 "소스"로 표기)에는 C#에서는 구현할 수 없기 때문에 C에서 런타임 기능을 호출 하는 부분이 불가피하게 존재한다. 형 시스템에 접속 또는 쓰레드의 조작, I/O 조작 등이 있으므로 이들은 InternalCall을 통해 mono 런타임에서 네이티브로 실행된다.

 

여기서 특별히 언급해 둘 것이 I/O 주변이다. 이 부분은 Windows 이외의 환경에서는 "io-layer"로 불리는 Windows I/O API의 에뮬레이션 구현이 담당하고 있으며 직접 파일 I/O가 이뤄지고 있는 것은 아니다. 일반적으로는 Windows Linux에서는 파일 처리에 큰 차이가 있다. 가장 중요한 것은 Linux에서는 대문자와 소문자를 구분하는 것이다. Windows 상에서는 대문자와 소문자가 구분되지 않으므로 예를 들면 다음과 같은 코드는 문제없이 동작한다.

 

C#

File.WriteAllText ("FILE.txt", "test string");

return File.ReadAllText ("file.txt");

 

이를 Linux 환경에 가져가면 거의 실패하다. Linux 상에서 사용되는 파일 시스템은 "FILE.txt" "file.txt"을 별개로 다루기 때문이다. 이것은 프로그래머가 스스로 주의해야 할 일이지만 .NET 애플리케이션은 대부분 Windows 상에서 개발되고 있기 때문에 Windows에서 움직이면 OK라는 전제 아래 적혀 있는 것이 많다. 이러한 프로그램에도 어느 정도 움직이도록 mono에는 "MONO_IOMAP" 이란 환경 변수에서 Windows I/O 같은 거동을 지정할 수 있는 기능이 있다. "MONO_IOMAP=all"로 지정하고 mono 상에서 애플리케이션을 실행하면 위의 코드도 생각대로에 동작한다(참고로 이를 사용하면 파일 이름의 문제가 모두 해결하려는 게 아니다. 어디까지나 파일 I/O API가 미칠 수 있는 범위에서만이다. 파일 이름의 대 소문자는 항상 일치시켜 두는 것이 바람직하다).

 

참고로 Mac OS X에서 사용하는 HFS+ 파일 시스템에서는(기본 포맷에서는) 대 소문자를 구분하지 않는다. 한편 이는 mono에 한정 하지 않는 이야기지만 HFS+는 파일명을 취급할 때 Unicode NFD 정규화와 유사한 독자적인 변환을 실시하기 때문에 Mac OS X와 그 이외의 환경에서 크로스 개발하고 있는 경우에는 조심하는 것이 좋다(NTFS ext4 등의 파일 시스템은 특히 이러한 변환은 않는다). iOS Mac OS X Android Linux을 바탕으로 구축된 OS 라는 것을 기억해 두면 덫에 걸리지 않는다.

 

 

클래스 라이브러리

mono에 어느 클래스 라이브러리의 어셈블리가 있을지는 GitHub 저장소를 보는 것이 가장 빠르지만 각각 설명하는 것만으로도 너무 많으므로 개요만 정리한다. 기본적으로 Xamarin이 지원하고 있는 분야는 상용 지원으로서 비교적 두터운 개선을 받고 있다. 반대로 현재의 Xamarin이 모바일 플랫폼에서 사용하지 않는 클래스 라이브러리는 거의 관리되지 않는 상태이다.

 

.NET 3.0에서 추가된 API는 대부분 존재하지 않는다. WPF(Windows Presentation Foundation) WF(Windows Workflow Foundation)이 없고 일부 코드가 "olive"라는 다른 저장소에 형태만 존재하고 있다. WCF도 모바일에서 사용 되는 부분 이외는 거의 미완성으로 그치고 있다. 모바일 프로파일의 WCF Silverlight 2.0과 거의 같다.

 

Windows 고유 API를 전제로 하는 라이브러리(System.Management.dll, System.Core.dll System.IO.Pipes 이름 공간 등)도 구현은 없다. COM Windows의 고유 기능이라서 mono에서 동작하는 것은 기대할 수 없다(사실 Windows 한정으로 mono 런타임에 COM 기능을 구현하고 있는 커뮤니티 해커는 존재했지만 아무튼 의존하는 라이브러리 측이 Windows 전용이므로 mono로 지원하는 의의는 거의 없다).

 

.NET 클래스 라이브러리는 너무 방대하여 이것을 구현하는 Mono 클래스 라이브러리에는 미 구현이 많다. 구체적으로는 틀이나 멤버가 존재하지 않는 것과 존재하고 있지만 호출해 보면 NotImplementedException 예외를 던진다(원래 어떤 형태가 얼마나 구현되고 있는가 하는 정보는 Mono "class status" web 페이지에서 확인할 수 있도록 되어 있는데 본고 집필 시점에서 갱신이 멈춘 상태다).

 

mono의 클래스 라이브러리는 mono의 소스 트리 상 mcs/class 디렉토리 아래에 대량으로 작성되고 있다(역사적으로는 C#로 쓰여진 코드는 모두 "mcs"라는 모듈에 포함되었다. GitHub에 이행했을 때 mono의 소스 트리에 통합되었다). 디렉터리 구성 규칙은 기본적으로 다음과 같다.

 

mcs/class/[Assembly]/[Namespaces]/[Type]. cs

 

, 클래스 라이브러리의 테스트에는 NUnit(2013년 시점에서는 다소 오래된 2.4.8)이 이용되고 있으며, 각 라이브러리의 테스트의 소스 디렉터리 구성은 대체로 다음과 같다.

 

mcs/class/[Assembly]/Test/[Namespaces]/[Type]Test.cs

 

디렉토리 구조의 주요 예외로서 mscorlib 어셈블리(mscorlib.dll 파일) "corlib", System.Windows.Forms 어셈블리(System.Windows.Forms.dll 파일) "Managed.Windows.Forms" 라는 디렉토리 이름이 되어 있다(외에도 몇 가지 예외는 있다). 클래스 라이브러리는 물론 모두 C#으로 적혀 있다. 다만 빌드에 IDE는 사용하지 않고, make 명령이 사용되고 있다. 소스에 대해서는 aspnetwebstack, entityframeworkrx, cecil 등 외부 프로젝트를 git submodule 로 주입한 것도 있지만 어셈블리의 디렉토리 구성은 변하지 않는다(소스의 목록은 서브 모듈 속을 참조하고 있다).

 

소스 코딩 규칙은 mono적이다. Linux kernel 문화에 친화적이고 불필요하게 줄 수를 늘리지 않는 설계가 되어 있다. 이 코딩 규칙이 마음에 들지 않지만 소스를 읽을 필요가 있는 경우는 monodevelop의 코딩 스타일 설정을 Visual Studio로 한 후에 자동 포맷을 설정하면 낫다.

 

만약 클래스 라이브러리의 미 구현 부분을 구현하거나, 버그 등을 발견하고 수정을 시도 하고 싶은 경우는 한번 mono의 트리 전체를 빌드 한 뒤 그 어셈블리의 디렉토리로 이동하여 make run-test를 실행하면, NUnit 테스트가 실행되므로 편리하다. 참고로 빌드된 dll 파일 등은 mcs/class/lib/net_4_5 와 같은 디렉토리에 생성된다.

 

mono의 클래스 라이브러리에는 사실 복수의 프로파일이 있다. .NET 2.0, .NET 4.0, .NET 4.5로 각각 .NET의 프로파일에 상당한다. 클래스 라이브러리 디렉터리에서 make를 실행했을 때 빌드되는 것은 최신의 프로파일 뿐이다(현재는 .NET 4.5). 낡은 프로파일의 어셈블리를 빌드 하려면 make PROFILE=net_2_0 라는 빌드를 실행할 필요가 있다. 사실 더해서 모바일 프로파일도 있지만 그것에 대해서는 다음에 이야기 하겠다.

 

 

 

 

출처: http://www.buildinsider.net/mobile/insidexamarin/03

 

저작자 표시
신고
by 흥배 2014.02.26 08:00

Mono의 시작

Mono 프로젝트 리더인 Miguel de Icaza는 본래 Linux에 자유로운 데스크탑 환경을 구현하는 것을 목적으로 설립한 GNOME 프로젝트의 초기 리더이며, Mono는 처음에는 Linux 데스크탑 환경용 애플리케이션 개발을 쉽게 하기 위해 시작된 프로젝트이다.

당시 Miguel GNU 프로젝트에서 소프트웨어 대상을 받을 정도로 UNIX 해커이면서 마이크로소프트에 인턴 응모를 한 일이 있을 정도로 마이크로소프트 기술 열광자이고, COM 기술을 사랑하여 비슷한 기술인 CORBA를 응용한 'Bonobo'라는 소프트웨어를 개발하였고, GNOME 개발 촉진을 그렸던 역사도 있다.

그는 .NET Framework가 등장하자 바로 흥미를 여기로 옮겨서 GNOME 개발을 이것으로 하려고 당시 그가 설립한 Ximian사에서 Mono 프로젝트를 시작하였다.

 

Mono는 주로 다양한 ADO.NET 프로바이더나 ASP.NET 등 서버 사이드 기술을 구현하는 것을 시작하여(이것이 1.0) 다음은 Windows Forms을 구현하였다. 이것이 버전 2.0으로 .NET 2.0까지 구현했을 때 .NET 3.5가 나왔다. 이것을 사용하여 Paint.NET Mono로 구현한 것이 Paint-mono 이다.

 

.NET 기술은 광범위 하여 Mono 팀은 구현 대상을 조정할 필요가 있었다. 주로 런타임과 C# 컴파일러 개선, ASP.NET, WCF 등의 서버 사이드 기술 구현 등이 집중적으로 개발 되었다. 또 이것과는 별개로 Gtk#이나 MonoDevelop 개발도 병행하였다.

 

'애플리케이션을 자연스럽게 Linux에서도 동작시키자' 라는 레벨의 목적으로도 .NET Framework에 캐치업 하는 것은 쉽지 않다고 생각되지만 Mono 팀이 코어 부분을 착실하게 진행 시키는 중 하나의 전환점을 맞이하였다. MS ASP.NET MVC를 오픈소스로 공개하는 등 .NET Framework의 일부를 오픈 소스로 하는 흐름이었다. ASP.NET MVC, DLR은 오픈 소스로 공개되어서 그대로 Mono에 들어왔다.

이후 MS Entity Framework, Reactive Extensions 라는 .NET의 대규모 라이브러리를 차차 오픈 소스화 하였다. 이것들은 Mono에 그대로 들어와서 바이너리 배포 되고 있다.

 

일단 코어 부분에 집중할 수 있게 된 Mono팀은 완성도를 더욱 높이면서 대상 플랫폼을 확대할 수 있었다. C# 컴파일러는 재 빠르게 C# 5.0 기능을 구현하였다. iOS Android Xamarin 제품의 양 축이 되고 있지만 이것들을 타겟으로 하기 위해 런타임이 개선 되고 있는 측면도 크다. Mono는 현재로서는 주로 Xamarin이 제품으로 사용하는 범위의 기능을 높이는 방향을 향하고 있다.

 

 

Mono 소프트웨어 구성 요소

mono 소스 코드 저장소에는 런타임, C# 컴파일러, mono 클래스 라이브러리가 포함된다.

mono 공식 저장소: https://github.com/mono/mono

mono 소스 상에서 앞의 3개의 요소(런타임, C# 컴파일러, 클래스 라이브러리)는 각각 다음의 디렉토리에 존재한다.

mono/   최상위 디렉토리

|- mono   런타임

|- mcs/

    |- mcs  컴파일러

    |- class  클래스 라이브러리

 

 

 

mcs: C# 컴파일러

mcs C#으로 구현 되어 있고 초기는 csc로 빌드 되었다(msc 빌드에는 mcs가 필요하므로 현재도 부트스트랩용의 빌드된 mcs.exe가 먼저 사용된다).

 

최신 mcs async/await키워드, caller info 등을 포함한 C# 5.0까지의 기능을 모두 구현하고 있다. csc와 비슷한 명령 라인 옵션을 갖추어서 기존의 C# 코드를 문제 없이 빌드 할 수 있다. 문법 에러 체크도 .NET Framework csc와 같이 엄격하게 해준다(배경에는 C# 언어 사양이 규정하는 C#코드의 흐름 분석과 mcs의 충실한 구현이 있다). csc의 에러와 경고는 Visual Studio와 친화적으로 동작하기 위해 일정한 형식으로 출력되지만 mcs에서도 그것은 답습되어 MonoDevelop에서도 마찬가지로 메시지가 목록으로 표시된다. Windows 상에서 동작하는 MonoDevelop csc를 사용하고 있으나 그 컴파일 오류는 MonoDevelop에서 올바르게 목록으로 표시될 것이다.

 

ECMA 334 ECMA 335라는 사양은 C#의 소스 수준의 호환성과 CIL(바이너리 중간 코드) 모두에 대해 호환성을 갖기 위한 것이며, mcs가 생성하는 exe파일 및 dll 파일은 csc이 생성하는 것과 호환성이 있다. 대상 플랫폼에서 읽어지는 어셈블리이면 mcs가 생성한 것을 .NET Framework에서 읽어도 csc가 생성한 것을 mono에서 읽어도 각각 실행할 수 있을 것이다(물론 대응하는 프로파일의 유무 및 대상 프로파일에서의 참조 어셈블리의 유무는 여기에서는 다른 문제이다).

 

다만 mcs-debug 옵션으로 생성하는 디버그 기호 파일은 ".mdb" 라는 자체 포맷이 되어 있다. 이것은 ECMA CLI에 디버그 기호의 규정이 없고, pdb 파일의 사양이 비공개였기 때문이다(현재는 cildb라는 pdb mdb도 아닌 포맷이 규정되고 있다). 현재의 mono에는 이들을 상호 변환하기 위한 툴 pdb2mdb mdb2pdb가 존재한다. 참고로 이들은 포맷의 차이 밖에 없으며 정보의 성질 차이는 없을 것이다.

 

mcs에 의한 LINQ, dynamic 형의 지원 조건은 csc의 경우와 별로 바뀌지 않았다. 즉 확장 방법을 쓰려면 System.Core.dll을 참고로 한 후 "using System.Linq;" 라고 기술해야 하고, dynamic 형을 쓰려면 Microsoft.CSharp.dll을 참조에 더해야 한다(이는 간접적으로 Mono.CSharp.dll 라고 하는 라이브러리도 이용한다). 이들 라이브러리만 있으면 mcs dynamic 형을 충분히 지원할 수 있다(필자는 실제로 PlayStation Mobile이 아직 "PSSuite"로 불리던 시절에 이 환경에서 이들 어셈블리를 적절한 프로파일로 빌드 후 추가하여 지원되고 있지 않을 dynamic형을 기술하고 있는 코드를 동작 시킨 적이 있다).

 

그리고 mcs csc과 달리 다수의 라이브러리를 기본적으로 참조하지 않는다. csc.rsp가 없는 것 같은 상태라고 생각하면 좋다. 이것은. NET개발자에게는 다소 혼란의 원인이지만, 사용되지 않는 어셈블리를 헛되게 해석하면 그만큼 컴파일 시간이 희생된다. 그것을 싫어한 것이다.

 

 

mcs의 설계

mcs는 소스의 해석(파서), 시맨틱 분석, 코드 생성 등 일반적인 순서에 근거하는 언어 컴파일러 구현이므로 주목 할 것은 많지 않다. 소스의 해석이 jay 이라는 LALR(1)문법 파서 생성기를 사용하고 있다(원래는 Java의 소스를 생성하는 도구이지만 C# 생성 기능을 추가했다).

* jay: https://github.com/mono/mono/tree/master/mcs/jay

 

코드 생성은 과거 .NET mscorlib에 포함된 System.Reflection.Emit를 사용하고 있었지만 이것은 "크로스 프로파일" 형태로 어셈블리를 빌드 하는 것을 막는 것으로(예를 들면 NET 4.0 호환 어셈블리를 생성하려면 .NET 4.0 프로파일의 mscorlib.dll에서 동작하는 mcs가 필요했다), 현재는 "IKVM.Reflection.Emit"라고 하는 라이브러리를 사용하고 있다. IKVM Java 바이트 코드를 .NET/Mono 상에서 실행하게 하는 프로젝트이다. 만약 당신이 언어 처리 쪽으로 작성하고 있다면 System.Reflection.Emit 대신 IKVM.Reflection.Emit 사용을 검토하는 것이 뒤에 편하게 될지도 모른다. System.Reflection.Emit을 쓰고 있었을 때는 mono에는 타깃 프로필에 맞춰 mcs, gmcs, dmcs, smcs 같은 컴파일러 툴이 난립하고 있다. 지금은 mcs의 옵션 -sdk로 모두 대응하고 있다.

 

세만틱 분석은 mcs의 가장 복잡한 부분이지만 yield 키워드와 익명형, var에 의한 형 추론, dynamic형 사용, async/await 키워드의 Task 처리 등이 어떤 논리로 생성되고 있는지 만일 흥미가 있다면 mcs의 소스를 따라가면서 확인 가능하다.

 

 

mcs의 응용 사례

mcs는 오랫동안 단일 도구로 존재해 왔지만 최근에는 Mono.CSharp.dll 이라는 독립한 라이브러리로서 재이용 할 수 있도록 되어 있다. MonoDevelop SharpDevelop 두 프로젝트 간에 C# "서비스로서의 컴파일러"(Compiler as a Service 또는 Language Service)로 개발되고 있는"NRefactory"에서도 사용되고 있다. 마이크로 소프트 기술로 말하면 "Roslyn"에 상당하는 것이다.

 

마지막으로 mcs의 흥미로운 응용으로 mono C# shell을 소개한다. 이것은 csharp.exe라는 툴로 안에서는 Mono.CSharp.dll을 사용하여 C#로 인터랙티브 셸을 실현하는 것이다. Gtk#의 도구가 콘솔에서 실행할 수 있는 환경(Linux )이라면 gsharp이라는 GUI 셸도 이용할 수 있다.

* gsharp: https://github.com/mono/mono-tools/tree/master/gsharp

 

C#의 코드를 그 자리에서 쓰고 Gtk# Widget을 만들어 표시하는 것도 가능하다(Miguel은 일찍이 이 위에 Gtk.Canvas에서 도형을 그리는 데모를 하였다). MonoDevelop 사용자 커뮤니티에서는 이 mono C# shell MonoDevelop의 패드로 쓰도록 한 add-in도 공개되고 있다. 인터랙티브 셸은 이미 F#(fsi)의 독무대가 아니다.

 

 

 

출처: http://www.buildinsider.net/mobile/insidexamarin/02

저작자 표시
신고
by 흥배 2014.02.24 08:00

Mono

Mono는 .NET Framework 호환 환경을 크로스 플랫폼으로 구현한 Xamarin(회사)의 핵심 제품이다. 공통 언어 런타임(CLR), C# 컴파일러, 그리고 장대한 .NET 클래스 라이브러리로 이루어져 있다.

 

런타임 'mono' CLI(공통 중간 언어) 메타 데이터 파서, JIT 엔진, 가베지 컬렉션 등 .NET 프로그램 실행에 필요한 기능 대부분을 구현하고 있다. 또한 IronPython, IronRuby 등의 동적 언어도 동작한다.

mono  C 언어로 작성되어 있고 라이브러리로서 애플리케이션이 이용할 수 있는 내장 API도 공개하고 있다.

 

C# 컴파일러 'mcs' 2013년 말 기준으로 async/await 키워드나 caller info C# 5.0 기능을 모두 구현하고 있다. mcs C# 언어로 작성되고 코드는 다른 프로젝트에서도 재 이용되고 있다.

 

클래스 라이브러리는 ECMA 335에서 표준화 되어 있는 부분을 중심으로 주로 Windows 고유가 아닌 부분을 대부분 구현하고 있다. 또한 Windows Forms 등도 구현하고 있어서 Linux X11 환경이나 MacOS X 환경에서도 동작한다.

 

Mono Windows 에서도 동작한다(.NET Framework에 의존 없이 동작한다). 구현 아키텍처는 java에 비슷하다고 할 수 있다. 단 표준적인 환경에서는 .NET Framework와 같이 .exe 파일을 자연스럽게 실행하는 것을 불가능하다.

 

 

 

Gtk#

Mono 프로젝트는 역사적으로 Linux GNOME 데스크탑 상에서 .NET 애플리케이션 개발을 쉽게 하기 위해 시작되어 GNOME GUI 툴킷인 'Gtk+'와 밀접하게 연결되어 있다. Mono를 사용하여 개발된 애플리케이션의 대부분은 Gtk+ .NET 바인딩인 'Gtk#'을 사용하여 개발되고 있다.

 

Gtk# 아키텍처는 .NET에 있어서 Windows Form 아키텍처와 크게 다르지 않다. Mono에서는 네이티브 코드와의 상호 운용을 구현하는 P/Invoke가 지원 되며 Gtk#은 이 P/Invoke를 사용하여 Gtk+ API를 호출하고 있다. Windows Form Windows API P/Invoke 하고 있다.

 

 

 

출처

http://www.buildinsider.net/mobile/insidexamarin/01

 

저작자 표시
신고
by 흥배 2014.02.21 08:00

* (2013-10-02) 업데이트 MonoDevelop의 최신 안정 버전은 4.0.12. 아래에서 다운로드 받아서 설치하면 된다

http://rpm.pbone.net/index.php3/stat/4/idpl/23208049/dir/opensuse/com/monodevelop-4.0.12-92.11.noarch.rpm.html



Virtual Box로 OpenSuse 12.3 64Bit 버전을 설치할 때 분명 Mono 설치를 선택했는데 설치 후에 보니 mono 실행 파일은 있지만 Monodevelop가 설치 되어 있지 않더군요.


보통 우분투의 경우는 apt-get을 사용하여 설치할 수도 있는데 OpenSUSE에서는 사용할 수 없었습니다.


그래서 구글링을 해보니 RPM 파일을 찾아주는 곳이 있어서 그곳을 통해서 Monodevelop의 RPM 파일을 받아서 설치 했습니다.


http://pkgs.org/download/monodevelop




http://pkgs.org/opensuse-12.2/opensuse-oss-i586/monodevelop-2.8.5-2.1.3.noarch.rpm.html


저작자 표시
신고
by 흥배 2013.07.25 08:00

Unity3D과 Mono를 사용하고 있는데 Unity3D 4.0은 Mono 버전을 어디까지 지원하고, 그럼 그 Mono 버전은 .NET Framework 버전을 얼마까지 지원하는지 아주 간단하게 정리합니다



 Mono

.NET Framework 

 

 2.6

 3.5

 Unity3D 4 버전

 2.10

Xamarin 2.0 

3.0 

 4.5

 



저작자 표시
신고
by 흥배 2013.06.20 08:00
| 1 |

티스토리 툴바