닷넷 어셈블리는
하나의
단일한
단위로
존재
하는 .NET의
실행
가능한
프로그램
또는
실행
프로그램의
일부이며
실행
및
배포의
단위라고
할
수
있다. C# 응용
프로그램
작성의
결과로
생긴 .exe 파일이
바로
하나의
어셈블리
이며
클래스
라이브러리
작성의
결과인 DLL(Dynamic Link Library)도
하나의
어셈블리
이다.:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office"
/>
하나의
단일한
어셈블리
안의
모든
코드는
하나의
단일한
단위로
빌드, 배포되며
버전
번호가
부여되는데
각
어셈블리는
다른
프로그램들이
사용
할
수
있는 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 코드를
코드를
포함한다. 또한
실행
코드가
없는
리소스
파일
역시
다중
파일
어셈블리의
한
부분이
될
수
있다.
9. 닷넷 어셈블리(.NET Assembly) 개요(구성요소, component, 매니페스트,
MSIL
닷넷 어셈블리는
하나의
단일한
단위로
존재
하는 .NET의
실행
가능한
프로그램
또는
실행
프로그램의
일부이며
실행
및
배포의
단위라고
할
수
있다. C# 응용
프로그램
작성의
결과로
생긴 .exe 파일이
바로
하나의
어셈블리
이며
클래스
라이브러리
작성의
결과인 DLL(Dynamic Link Library)도
하나의
어셈블리
이다.:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office"
/>
하나의
단일한
어셈블리
안의
모든
코드는
하나의
단일한
단위로
빌드, 배포되며
버전
번호가
부여되는데
각
어셈블리는
다른
프로그램들이
사용
할
수
있는 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 코드를
코드를
포함한다. 또한
실행
코드가
없는
리소스
파일
역시
다중
파일
어셈블리의
한
부분이
될
수
있다.
댓글 없음:
댓글 쓰기