남정현의 닷넷 블로그

Mono 2.0 릴리즈 노트

Mono 2.0은 오픈 소스 기반의 이식성 높은 닷넷 프레임워크 구현으로, Unix, Windows, Mac OS 등의 운영 체제를 지원합니다.

발표일: 2008년 10월 6일

Microsoft 호환 API

• 데이터베이스 액세스를 위한 ADO.NET 2.0 API
• 웹 기반 응용프로그램 개발을 위한 ASP.NET 2.0 API
• 데스크톱 응용프로그램 개발을 위한 Windows Forms 2.0 API
• XML 문서 활용 및 제어를 위한 System.XML 2.0 API
• 언어 연동 질의 (LINQ) 구현을 위한 System.Core API
• XLINQ 구현을 위한 System.Xml.Linq API
• 이식성 높은 그래픽 렌더링을 제공하는 System.Drawing 2.0 API

Mono API

• Gtk# 2.12: Gtk+ 2.12와 GNOME 라이브러리에 대응되며, Linux, Windows, Mac OS X를 위한 데스크톱 응용프로그램 개발을 지원합니다.
• Mono.Cecil: ECMA CLI 규격에 맞는 바이너리 파일을 생성하기 위한 라이브러리
• Mono.Cairo: 2D 그래픽 렌더링을 위한 Cairo 그래픽 라이브러리 (이미지, GUI, 포스트스크립트, PDF 등의 생성을 지원합니다.)
• Mono의 SQLite 지원: SQLite 기반 데이터베이스를 생성하거나 활용할 수 있습니다.
• Mono.Posix: Linux와 Unix에 한정되는 기능을 관리되는 응용프로그램상에서 활용할 수 있게 하며, 저수준/고수준 API를 모두 제공합니다.

Mono에 번들링된 Thirdparty API

• PostgreSQL, DB2, Oracle, Sybase, Microsoft SQL Server, SQLite, Firebird를 지원합니다.
• C5 제네릭스 라이브러리: 제네릭 기반 컬렉션 클래스 라이브러리인 C5 라이브러리를 번들링하였습니다.

컴파일러

• LINQ의 모든 사양을 지원하는 C# 3.0 컴파일러가 제공됩니다.
• Visual Basic 8.0 컴파일러가 제공됩니다.
• IL 어셈블러, 디스어셈블러와 개발에 필요한 모든 도구가 제공됩니다.

도구

• 디버거: 관리 코드 환경에서 사용 가능한 첫 공식 디버거가 제공됩니다.
• Gendarme: 닷넷 기반 응용프로그램과 라이브러리의 문제점을 진단합니다. 컴파일러가 진단하지 못하는 문제들을 추가 점검할 수 있도록 고안되었습니다.
• Mono Linker: Mono 런타임 전체를 배포하지 않고 필요한 어셈블리군만을 통합하여 배포 런타임의 크기를 줄일 수 있도록 도와줍니다.
• 이 외에도 Mono Tuner, Mono 문서화 도구가 제공됩니다.

라이선스

Mono는 오픈 소스 프로젝트로서, 클래스 라이브러리와 C# 컴파일러는 MIT X11 라이선스, 런타임은 GNU LGPL, SDK 도구들은 GNU GPL과 MIT X11 라이선스로 나뉘어서 제공됩니다.
Mono을 정적으로 링크하는 경우 (예를 들어 Apple iPhone이나 Nintendo Wii 또는 다른 모든 형태의 사유형 운영 체제들을 위하여) 라이선스를 별도로 문의할 수 있습니다.

주요 포커스

• Windows Forms: ToolStrip과 MenuStrip이 완전히 구현되었습니다. 기존 Windows Forms 1.0의 메뉴 및 도구 모음 컨트롤도 유효합니다.
• Windows Forms: VirtualMode 등 몇 가지 고급 기능이 누락되기는 하였지만, 이전보다 더 낳은 DataGridView 컨트롤이 제공됩니다.
• Windows Forms: Mozilla Gecko 렌더링 엔진을 기준으로 WebBrowser 컨트롤이 구현되어있습니다.
• Windows Forms: TableLayoutPanel, FlowLayoutPanel, SplitContainer와 같은 특수 컨테이너 컨트롤이 구현되었습니다.
• Windows Forms: XIM을 통한 다국어 입력이 지원됩니다.
• News: Paint.NET 3.0의 포팅 작업이 일정 수준 이상 진행되었습니다.
• Component: 성능 카운터 구현이 제공됩니다.
• ASP.NET: Virtual Path Provider 기능이 제공되며, Browser 정보 파일을 사용할 수 있습니다.
• Visual C++: Microsoft Visual C++ 7.0 컴파일러 이후부터 제공되는 혼합 모드 어셈블리를 Windows용 모노에서 실행할 수 있습니다.
• BCL: 64비트 인덱스를 사용하는 대규모 배열을 지원합니다. (--enable-big-arrays 옵션이 필요합니다.)
• DTrace 지원: Mac OS X와 Solaris에서 Mono를 사용할 경우 DTrace 추적을 지원합니다. (--enable-dtrace 옵션이 필요합니다.)

Mono 프로젝트 홈페이지: http://www.mono-project.com/
Mono 2.0 다운로드 페이지: http://www.go-mono.com/mono-downloads/download.html

출처: http://www.mono-project.com/Release_Notes_Mono_2.0

Creative Commons License

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

'개발자가 놓치기 쉬운 자바의 기본 원리' 라는 글의 내용을 보고 같은 내용을 닷넷을 기준으로 서술한다면 재미있을 것 같다는 생각에 곧바로 글을 옮겨적어봅니다. 좋은 소스를 제공해주신 다음 커뮤니티본부 커뮤니티개발1팀의 전성호님께 감사드립니다. 이 글이 닷넷에 입문하시는 분들이나 기본적인 원리때문에 고민하셨던 분들께 좋은 역할을 해주기를 바랍니다.

출처: http://dna.daum.net/technote/java/PrincipleOfJavaInternalForDeveloperEasyToLost

요약: 개발자가 놓치기 쉬운 닷넷의 기본 원리에 대하여 기본적이긴 하지만 개발하면서 느끼고 경험한 내용을 정리하였다.

1. 객체 지향의 구멍 static

1.1 닷넷은 객체 지향 환경이다?

"닷넷은 자바와 마찬가지로 객체지향 언어이다" 라는 주장을 자주 접하게 된다. 만일 이것이 사실이라면 닷넷을 사용하는 한 "기존의 절차 지향 프로그래밍을 전혀 할 수 없을게 아닌가?" 라는 생각이 들지만 사실은 그렇지 않다. static을 이용하면 비 객체지향 언어처럼 코딩할 수 있다.

static method, static property, static event는 instance가 아닌 클래스에 속하는 method로, class method, class property, class event라고 부른다. 반대로 static이 아닌 method, property, event은 instance method, instance property, instance event라고 부른다.

static method, static property에는 this가 없다. instance method, property에는 숨겨진 파라미터로 this가 건네진다. (아래 "객체지향에 흔히 있는 오해" 참고) 하지만 static method, static property는 절차 지향의 함수와 동일하므로 숨겨진 파라미터 this는 없다. 그래서 static method, static property에서는 전달한 this가 없으므로 instance method, instance property를 호출하거나 instance field를 참조할 수 없는 것이다.

(참고) 객체지향에 흔히 있는 오해

• 오해 1. "객체 지향에서는 객체 끼리 서로 메시지를 주고 받으며 동작한다."라는 말을 듣고 다음과 같이 생각할 수 있다. "객체 지향에서는 객체가 각각 독립하여 움직인다는 것인가, 그러면 각 객체에 독립된 thread가 할당되어 있단 말인가?" 그렇지 않다. "메세지를 보낸다"라는 것은 단순히 각 객체의 함수 호출에 불과하다.
• 덧. 메세지를 보낸다라는 개념을 같은 컴퓨터 내에서가 아닌 네트워크 상의 관점으로 확장을 하였을 때, 우리가 흔히 알고 있는 XML Web Service, DCOM, CORBA와 같은 Remote Procedure Call 기반 통신 기법으로 발전하게 되는 것이다.
• 오해 2. "객체 지향에서는 method, property, event가 class에 부속되어 있다"는 말을 듣고 다음과 같이 생각할 수 있다. "그러면 instance별로 method의 실행 코드가 복제되고 있는 것이 아닌가?" 물론 이것도 오해다. method의 실행 코드는 종래의 함수와 동일한 어딘가 다른 곳 (CLR의 메모리 영역 내)에 존재하며 그 첫 번째 파라미터로 객체의 포인터 this가 건네질 뿐이다.
• 오해 3. "그렇다면 각 instance가 method의 실행 코드를 통째로 갖고 있지 않는 것은 확실하지만, method의 실행 코드의 포인터는 각 instance별로 보관하고 있는 것이 아닌가?" 이것은 약간 애매한 오해이긴 하다. CLR 스펙에서는 JVM 스펙에서와 마찬가지로 별도의 메모리 영역 내에 실행 코드를 가지고 있는 상황에서 각 메서드 호출 시 Stack Frame이 생성되어 실행되고 실행 완료 시 복귀 주소를 전달한다.

1.2 전역 변수

static에서 public field는 전역 변수 (global variable, 글로벌 변수)이다. 여기서 "글로벌 변수는 왜 안되는가"에 대해 잠깐 생각해 본다. 우리는 흔히 "글로벌 변수는 될수있는한 사용하지 않는 것이 좋다"라고 한다. 그 이유는 글로벌 변수는 어디서든 참조할 수 있고 값을 변경할 수 있기 때문이다.

또한 파라미터나 리턴값으로 교환해야할 정보를 글로벌 변수를 경유(사용)하여 건네주면 함수의 역할이 불분명해지고 흐름도 애매해진다. 마지막 이유로는 "글로벌 변수는 하나밖에 없다"는 것이다. 이는 어디서 이 값을 변경했는지 알 수 없게 하는 지름길이고 실무에서도 간혹 발생하긴 하지만, 이 하나밖에 없는 변수가 버전업으로 두개가 필요하게 되었을 때 확장도 대형 프로젝트에서는 힘들어진다.

따라서 static에서 public은 readonly나 const를 붙여 상수나 읽기 전용 변수로 사용해야지 그 외의 용도는 자제하는 것이 좋을 것이다.

(참고) readonly 초기화에서의 주의점. 예를 들어 다음과 같은 코드를 보았을 때 우려되는 점은 무엇인가?

readonly 변수는 인라인 문장과 생성자 권역 내에서 한 번 초기화되면 변경이 불가능한데 object로 초기화할 경우 WHITE라는 필드가 변경될 수 없는 것이지 그것이 가리키는 객체는 아니라는 점이다.

과거 신규 서비스 개발시 readonly 변수 필드에 설정파일을 읽어 cache하는 singleton class의 특정 member를 이용하여 초기화할 경우 이 멤버값이 변경되면 readonly 변수의 값이 변경되었는데 프로그램에서는 이상한 짓을 하는 원인을 찾기가 상당히 어려웠던 경험을 하고난 후 부터 이런 코드는 냄새나는 코드로 여겨지게 되었다.

static은 글로벌 변수와 동일하므로 남발해서는 안된다. static을 사용할 경우 다음 두 가지는 최소한 기억한다.

1. static field는 readonly의 경우와 달리 정말 "하나여도 되는지" 여부를 잘 생각해야 한다.
2. static method는 주저하지 말고 쓰되 다음 두 가지의 경우 매우 활용적이다.
3. 다른 많은 클래스에서 사용하는 Utility Method 군을 만드는 경우. (주로 Utility Class의 method)
4. 클래스 안에서만 사용하는 "하청 메서드 (private method)". 이유를 예를 들어 설명하면, 아래와 같은 조금은 과장된 클래스가 있다고 하자.

위의 클래스 T의 경우 내부에서는 Calc라는 instance 함수를 사용하게 되면 c의 값이 매번 변하게 된다. 이는 무심코 하는 실수로 클래스 내에서 private method는 모든 멤버 instance 변수에 접근 가능하게 되면서 발생하게 된다. c의 값이 변하지 않기를 바랄 수 있다. 이 때 안전한 방법은 다음과 같이 Calc 하청 메서드를 static method로 수정하면 안전하다.

여기서 a와 b는 멤버 변수를 접근할 수 없어 전달해야 한다. (static에는 this가 없어 instance field를 참조할 수 없다는 것은 이미 위에서 설명했다.) 또한 c도 같은 이유로 사용할 수 없어 로컬 변수로 선언하여 사용하고 있다. 이럴 경우 메서드가 약간 커질 수 있지만 instance member 변수를 안전하게 사용할 수 있다는 장점이 있다. 이것은 static을 다시한번 생각하게 하는 좋은 예가 되었을 것이다.

Creative Commons License

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Mono 1.0이 나온지 무려 4년여만에 2.0이 새롭게 모습을 드러내고 있습니다. 정식 버전은 올해 가을에 발표될 예정이며 이제 슬슬 그 윤곽을 드러내고 있습니다.

http://mono.ximian.com/monobuild/preview/archive/2.0/windows-installer/0/mono-2.0-gtksharp-2.10.4-win32-0.exe

Mono 2.0은 Microsoft .NET Framework 2.0과의 호환성을 상당부분 개선하였으며, C# 3.0 스펙과, Visual Basic 컴파일러를 내장하고 있고, IronPython과 Microsoft DLR 환경을 지원하는, 멀티 플랫폼 기반 CLI 프레임워크입니다. Microsoft .NET이 Windows에 최적화된 것이 특징이라면 Mono는 이와는 반대로 다양한 플랫폼에 걸쳐서 다재다능한 역할을 수행해내는 것이 다른 점이며, 최근에는 임베디드 장비로도의 이식이 진행 중입니다.

Major Highlights (주요 변경 사항)

Mono 2.0 is a major milestone in the Mono project, and it supports the following features:
Mono 2.0은 Mono 프로젝트에 있어서 중요한 전환점이며, 다음의 기능들을 지원합니다:

Microsoft Compatible API (Microsoft 호환 API):

• ADO.NET 2.0 API for accessing databases.
  데이터베이스 접근을 위한 ADO.NET 2.0 API를 지원합니다.
• ASP.NET 2.0 API for developing Web-based applications.
  웹 기반 응용프로그램 개발을 위한 ASP.NET 2.0 API를 지원합니다.
• Windows.Forms 2.0 API to create desktop applications.
  데스크톱 응용프로그램 개발을 위한 Windows Forms 2.0 API를 지원합니다.
• System.XML 2.0: An API to manipulate XML documents.
  XML 문서를 다루기 위한 API인 System.Xml의 2.0 API를 지원합니다.
• System.Core: Provides support for the Language Integrated Query (LINQ).
  언어 통합 질의문 (LINQ)를 위한 System.Core API를 지원합니다. (닷넷 3.5)
• System.Xml.Linq: Provides a LINQ provider for XML.
  Linq를 통한 XML 접근을 위한 XLinq를 지원합니다.
• System.Drawing 2.0 API: A portable graphics rendering API.
  이식 가능한 그래픽 API인 System.Drawing의 2.0 API를 지원합니다.

Mono APIs (Mono 고유의 API, Microsoft .NET에는 없는 사항들입니다):

• Gtk# 2.12: A binding to the Gtk+ 2.12 and GNOME libraries for creating desktop applications on Linux, Windows and MacOS X.
  Gtk+ 2.12와 GNOME 라이브러리에 바인딩되는 GTK# 2.12를 제공하여 리눅스, 윈도, 맥 OS X를 위한 데스크톱 응용프로그램을 제작할 수 있습니다.
• Mono.Cecil: A library to manipulate ECMA CLI files (the native format used for executables and libraries).
  ECMA CLI 파일을 낮은 수준에서 재생산할 수 있는 Mono.Cecil 라이브러리를 제공합니다. (System.Reflection.Emit보다 한단계 더 낮은 수준의 기능을 뜻합니다. Mono.Cecil을 이용하면, 프레임워크의 버전이나 환경을 초월하는 특수 어셈블리 생산이 가능합니다.)
• Mono.Cairo: A binding to the Cairo Graphics library to produce 2D graphics and render them into a variety of forms (images, windows, postscript and PDF).
  Cairo 그래픽 라이브러리에 바인딩되는 Mono.Cairo 라이브러리를 제공하며, 이미지, GUI, 포스트스크립트, PDF 제작을 지원합니다.
• Mono's SQLite support: a library to create and consume databases created with SQLite.
  SQLite 데이터베이스에 관한 API가 제공됩니다.
• Mono.Posix: a library to access Linux and Unix specific functionality from your managed application. With both a low-level interface as well as higher level interfaces.
  리눅스와 유닉스 시스템의 낮은 수준 API들과 함께 이를 응용하는 고급 API들을 공개적으로 지원하는 Mono.Posix 라이브러리를 제공합니다. Microsoft .NET의 Microsoft.Win32 네임스페이스의 위치와 유사한 것입니다.

Third Party APIs bundled with Mono (Mono에 번들링된 써드파티 API들, 역시 Microsoft .NET에는 없는 사항들입니다):

• Extensive support for databases: PostgresSQL, DB2, Oracle, Sybase, SQL server, SQLite and Firebird.
  PGSQL, DB2, Oracle, 사이베이스, SQL 서버, SQLite, 파이어버드 DB와의 연동을 제공합니다.
• C5 Generics Library: we are bundling the C5 generics collection class library as part of Mono.
  C5 제네릭 라이브러리를 번들링합니다. (제네릭을 이용한 다양한 컨셉 컬렉션을 제공합니다. C++ STL과 비슷한 개념으로 생각하시면 됩니다.)

Compilers (컴파일러):

• C# 3.0 compiler implementation, with full support for LINQ.
  C# 3.0 컴파일러와 함께 LINQ가 지원됩니다. (C# 1.0과 2.0은 이미 지원되고 있습니다.)
• Visual Basic 8 compiler.
  Visual Basic 8.0 컴파일러가 지원됩니다.
• IL assembler and disassembler and the development toolchain required to create libraries and applications.
  IL 어셈블러와 디스어셈블러가 지원됩니다.

좀 더 자세한 정보는 http://www.mono-project.com/ 을 참고하세요. :-)

Creative Commons License

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.