어셈블리(Assembly) 어셈블리는 하나의 단일한 단위로 존재 하는 .NET의 실행 가능한 프로그램 또는 실행 프로그램의 일부 입니다. 결국 C# 프로그램의 실행 및 배포의 단위라고 할 수 있습니다. C# 응용 프로그램 작성의 결과로 생긴 .exe 파일이 바로 하나의 어셈블리 이며 클래스 라이브러리 작성의 결과인 DLL(Dynamic Link Library)도 하나의 어셈블리 입니다.

어셈블리(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에서 이러한 문제들을 해결 할 수 있는 새로운 표준이 사용되는 것 입니다.

자기 서술적 특징(Self-Describing)

어셈블리에 어떤 것이 있는지가 .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 구성요소에 대한 참조를 추가하면 자동적으로 래퍼 어셈블리를 만듭니다.