닷넷 어셈블리(.NET Assembly) 개요
어셈블리는 하나의 단일한 단위로 존재 하는 .NET의 실행 가능한 프로그램 또는 실행 프로그램의 일부이며 실행 및 배포의 단위라고 할
수 있다. C# 응용 프로그램 작성의 결과로 생긴 .exe 파일이 바로 하나의 어셈블리 이며 클래스 라이브러리 작성의 결과인
DLL(Dynamic Link Library)도 하나의 어셈블리 이다.
하나의 단일한 어셈블리 안의 모든 코드는 하나의 단일한 단위로 빌드, 배포되며 버전 번호가 부여되는데 각 어셈블리는 다른 프로그램들이
사용 할 수 있는 public class, 속성, 메소드 등을 노출하게 되고 private으로 선언된 것은 모두 어셈블리 안에 은폐 되는 것
이다.
* 구성요소(Component)의 역사
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에서 이러한 문제들을 해결 할 수 있는 새로운 표준이 사용되는 것 입니다.
자기 서술적 특징(Self-Describing)
어셈블리에 어떤 것이 있는지 호가인하는 정보가 .NET 어셈블리 안에 있으므로 그것을 사용하는 프로그램이나 시스템은 레지스트리와 같은
외부 정보를 참조 할 필요가 없다. 닷넷 어셈블리는 자신이 가지고 있는 개체와 메소드 뿐 아니라 매개변수의 데이터 형식까지 제공한다. 또한
개체들의 버전 정보, 보안정보도 제공하며 실제로 어셈블리의 설치는 기본적으로 대상 시스템에서 어센블리 파일을 복사하는 것으로도
충분하다.
참고로 한가지 명심할 것은 네임스페이스와 어셈블리가 항상 일대일 대응을 이루는 것은 아니라는 것이다. 예를 들어
System.Data.dll은 System.Data와 System.Xml 네임스페이스의 일부를 구현하며 System.Xml의 다른 루틴은
System.Xml.dll에 구현되어 있다.
교차 언어 프로그래밍
구성요소는 어떠한 .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 구성요소에 대한 참조를
추가하면 자동적으로 래퍼 어셈블리를 만듭니다.
어셈블리의 구조
각 어셈블리는 어셈블리에 들어 있는 것들을 서술하는 매니페스트(Manifest – 일종의 탑승자 명단 같은 것)를 포함하는데
매니페스트가 바로 어셈블리 메타 데이터인 것이다. 이 메타데이터에는 자신이 담고 있는 모듈과 참조하는 다른 어셈블리에 대한 정보가
포함된다.
.NET 런타임은 프로그램을 실행 할 때 프로그램의 어셈블리에 있는 매니페스트를 이용하여 시스템의 다른 어셈블리(예를 들면 “Hello
World”를 출력하는 WriteLine() 메소드를 담은 System.Console 등)에 대한 참조를 알아 내는 것이다.
매니페스트 다음은 어셈블리 안에 담긴 클래스, 속성, 메소드 들과 그것들의 매개변수 및 반환 값의 데이터 형식에 대한 정보를 가지고
있는 형식 메타 데이터 이다.
다음으로 실제 이진코드인 컴퓨터 독립적인 MSIL 코드가 있으며 마지막으로 어셈블리가 사용하는 리소스가 있다. 리소스는 이미지,
아이콘, 메시지 파일 같은 프로그램의 비 실행 부분( .Resource 파일 안)에 저장 된다.
하나의 어셈블리는 보통 단 하나의 파일로 이루어 지지만 아래처럼 여러 개의 파일들이 하나의 어셈블리를 구성 하는 경우도
존재한다.
.NET 런타임의 입장에서 보면 다중 파일 어셈블리는 그냥 여러 개의 파일들로 이루어진 하나의 단일한 논리적 DLL 또는 EXE 이며
이때 오직 한 파일만 매니페스트를 담는데 그 매니페스트는 다중 파일 어셈블리를 구성하는 다른 파일들을 가리 키는 것 이다. 실행 코드를 담은
파일은 모듈이라 부르며 형식 메타 데이터와 MSIL 코드를 코드를 포함한다. 또한 실행 코드가 없는 리소스 파일 역시 다중 파일 어셈블리의 한
부분이 될 수 있다.
댓글 없음:
댓글 쓰기