오늘은 3일차로서 닷넷 어셉블리의 1부를 학습 하도록 합니다. 조금 어렵게 느낄수 있는데 자바를 하신 분들은 자바 프로그램의 배포를 위한 Jar 파일 포맷을 아실 겁니다. 유사하게 생각 하시면 되구요 닷넷 환경의 프로그램이 배포되는 단위라고 정리하시면 됩니다.~
닷넷 어셈블리 (Assembly)란?
닷넷에 대해 공부 하시다 보면 닷넷 어셈블리라는 말을 가끔식 보게 되실 겁니다. Low Level 언어인 Assembly는 절대 아니니 착오 없으시기를 바랍니다.어셈블리는 하나의 단일한 단위로 존재 하는 .NET 의 실행 가능한 프로그램 또는 실행 프로그램의 일부 입니다 . 결국 C# 프로그램의 실행 및 배포의 단위라고 할 수 있습니다 . C# 응용 프로그램 작성의 결과로 생긴 .exe 파일이 바로 하나의 어셈블리 이며 클래스 라이브러리 작성의 결과인 DLL(Dynamic Link Library) 도 하나의 어셈블리 입니다 . 하나의 단일한 어셈블리 안의 모든 코드는 하나의 단일한 단위로 빌드 , 배포되며 버전 번호가 부여되는데 각 어셈블리는 다른 프로그램들이 사용 할 수 있는 public class, 속성 , 메소드등을 노출하게 됩니다 . private 으로 선언된 것은 모두 어셈블리 안에 은폐 되는 것 입니다 .
다음은 구성요소 흔히 컴포넌트라고 하는것에 대해 잠시 정리하겠습니다.
MS 는 최초 DLL 을 도입하였는데 DLL 은 코드의 일부를 개별적인 파일로 분리 한 이며 프로그램이 같은 언어로 작성 되었을 때 기본적인 수준에서 동작하는 것 입니다 . 프로그램의 입장에서 자신이 사용하고자 하는 DLL 에 대해 많은 것을 알아야 하며 또한 프로그래머들이 서로의 데이터를 교환하는 용도로 DLL 을 사용 할 수 없습니다 .
데이터 교환의 문제를 해결 하기 위해 개발 된 것이 DDE(Dynamic Data exchange) 로 이것은 한 프로그램에서 다른 프로그램으로 데이터를 전송 하기 위한 형식과 메커니즘을 정의하는데 그리 유연하지는 않습니다 . 그 뒤로 OLE(Object Linkig and Embedding) 등장 하면서 Word 와 같은 문서가 다른 프로그램 (Excel) 을 자신안에 포함 할 수 있게 되었는데 비록 구성요소와 비슷한 개념을 지닌 기술이지만 OLE 1.0 을 진정한 범용적 구성요소로 보기는 어렵습니다 .
MS 최초의 진정한 구성요소의 표준은 1990 년대 중반에 나타난 COM(Component Object Model) 이라고 할 수 있습니다 . OLE 2.0 과 기타 여러 기술들은 COM 으로 통합 되었으며 COM 들이 네트웍 너머로 통신 할 수 있게 하는 DCOM, 다계층 환경에서 구성 요소 사이의 호출에 대해 높은 성능을 보장하는 서비스가 추가된 COM+ 가 등장 했습니다 .
COM 은 잘 동작하는 반면 배우기가 어렵고 사용하기도 어렵습니다 . COM 에서는 구성요소의 정보를 Windows Registry 에 등록해야 하는데 이는 구성요소의 설치와 삭제를 어렵게 하는 요인이 되었습니다 . COM 은 원래 C/C++ 를 위해 설계된 것이며 그 이후 VB 에서도 사용토록 개선 되었고 (“ 자동화 ” 라고 하는 것 ) 실제로 잘 동작 하고 있습니다 . 그 대신 C/C++ 로 VB 와 호환이 되는 구성요소를 만드는 것은 어려워 졌습니다 .( 예를 들어 다른 언어에서 정의된 클래스를 상속하는 것은 여전히 불가능 합니다 .)
또한 사용자가 MS 나 기타 회사들의 DLL 혹은 COM 구성 요소의 여러 버전을 설치하다 보면 문제가 발생 하는데 이는 버전이 다르더라도 DLL 파일의 이름은 동일 한데서 기인하는 것이 많습니다 . 그래서 이미 다른 프로그램에서 사용하는 DLL 을 덮어 씌워 버리는 경우가 자주 나타났으며 또한 시스템에 설치 된 DLL 정보를 관리하는 부담 때문에 구성요소의 업그레이드와 유지 보수가 갈수록 어려워 지는 것 입니다 . 결국 .NET 에서 이러한 문제들을 해결 할 수 있는 새로운 표준이 사용되는 것 입니다 .
다음은 닷넷어셈블리의 자기 서술적인 특징에 대해 알아 보겠습니다.
결국 어셈블리는 자바에서의 배포 단위인 Jar와 비숫하게 생각해 볼 수도 있습니다. Jar 파일에 Menifest 파일이 있어 그속에 JAr 파일의 구조에 대해 정의하고 있는데 이것을 자기 서술(Self Description) 이라고 합니다. 닷넷도 어셈블리 안에 자기서술적인 특징을 가지고 있습니다. 결국 기존의 DLL들 처럼 배포한 후 레지스터리에 등록하여 컴퓨터를 껐다 켜야 인식이 되는 것이 아니라 배포되는 닷넷 어셈블리안에 Self-Descriptiion을 하니까 그럴 필요가 없이 복사만 되면 발로 실행이 가능하다는것이 특징 입니다. 어셈블리에 어떤 것이 있는지가 .NET 어셈블리안에 있으므로 그것을 사용하는 프로그램이나 시스템은 레지스트리와 같은 외부 정보를 참조 할 필요가 없습니다 . 닷넷 어셈블리는 자신이 가지고 있는 개체와 메소드 뿐 아니라 매개변수의 데이터 형식까지 제공 합니다 . 또한 개체들의 버전 정보 , 보안정보도 제공하며 실제로 어셈블리의 설치는 기본적으로 대상 시스템에서 어센블리 파일을 복사하는 것으로도 충분 합니다 . 참고로 한가지 명심할 것은 네임스페이스와 어셈블리가 항상 일대일 대응을 이루는 것은 아니라는 것 입니다 . 예를들어 System.Data.dll 은 System.Data 와 System.Xml 네임스페이스의 일부를 구현하며 System.Xml 의 다른 루틴은 System.Xml.xll 에 구현되어 있습니다 .
다음은 교차 언어 프로그래밍에 대해 정리 하죠
구성요소는 어떠한 .NET 언어에서도 심지어 구성요소를 작성한 언어가 아닌 다른 언어에서도 호출 될 수 있습니다 . 이것 역시 어셈블리가 주는 장점 입니다 . 닷넷은 교차 언어적 프로그래밍을 가능하게 하는 아래와 같은 특징을 가지고 있습니다 .
• Cmmon language Runtime(CLR) : 모든 .NET 어셈블리의 실행을 관리
• Microsoft Intermediate Language(MSIL) : 모든 .NET 언어 컴파일러는 MSIL 을 생산 하며 이는 컴파일러가 생성하는 이진 코드의 표준으로 CLR 은 이 MSIL 코드에 기반하는 것입니다 . MSIL 은 또한 어셈블리의 메타 데이터를 저장 하는 형식을 정의 하는데 이는 어셈블리가 어떤 언어로 만들어 졌든 간에 공통의 형식으로 자신의 메타 데이터를 저장함을 의미 하는 것입니다 .
• Common Language Specification(CLS) : C#, VB, C++ 등 어떠한 닷넷 언어라도 CLS 를 만족 하기만 하면 언어의 경계를 넘어서 구성 요소들을 공유 할 수 있으며 언어의 경계를 넘어서 완전한 상속이 가능 합니다 .
• Common Type System(CTS) : 모든 .NET 언어들이 사용하는 기본 형식들과 자신의 클래스를 정의하는 규칙을 정의 한다 . 예를들면 어떤 언어가 문자열 형식을 비 호환적 방법으로 구현하는 일을 방지한다 . CLS 사양을 따르면 C# 으로 구성 요소를 작성 했을 때 그것을 담은 어셈블리는 VB.NET 같은 언어에서도 사용 될 수 있으며 마찬가지로 C# 은 VB.NET 이나 C++.NET 으로 작성된 구성요소를 사용 할 수 있습니다 . 또한 .NET Framework 에서는 이전에 만들어진 COM 에 대해서도 사용 할 수 있는 방법을 제공 하는데 이는 이전에 작성된 코드를 감싸는 인터페이스 역할을 하는 wrapper assembly 를 통해서 가능 합니다 . VS .NET 은 COM 구성요소에 대한 참조를 추가하면 자동적으로 래퍼 어셈블리를 만듭니다 .
오늘은 3일차로서 다분히 이론적인 내용 이었습니다. 다음 시간은 그림과 함께 닷넷 어셈블리에 대해 조금 더 깊이 살펴 보도록 하겠습니다.
수고하셨습니다.
질문은 .Net Forum의 C# 코너에 올려 주세요~
댓글 없음:
댓글 쓰기