CLR via C#

UserPreferences

Part1. CLR의 기본 지식

생성된 관리 모듈의 헤더 정보를 확인할 수 있게 해주는 DumpBin?.exe와 CorFlags?.exe 두 개의 명령줄 유틸리티를 제공해 준다.

관리코드가 비관리 코드보다 성능이 우수할 수 있는 몇가지 근거
1. CLR은 어플리케이션의 실행패턴을 프로파일 할 수 있으며 이에 따라서 어플리케이션 실행중에 IL코드를 네이티브 코드로 다시 컴파일할 수 있다.
2. 특정상황의 테스트 값 혹은 논리 연산의 결과를 실행전에 이미 정확하게 알 수 있다. 그에 따라서 어플리케이션의 실행코드를 좀 더 빠른 네이티브 코드를 생성하게 된다.
3. 보통의 비관리 코드는 최저사양에 맞춰서 출시된다. 반면 JIT 컴파일러는 실행환경에 최적화된 네이티브 코드를 생성할 수 있다.

IL사용으로 얻는 장점으로 CPU를 추상화함으로 쉽고 빠르게 알아볼 수 있지만 가장 큰 장점은 안전하게 실행됨을 CLR이 보장해 준다는 것이다.
IL코드가 네이티브 코드로 변환될때 CLR은 검증작업으로 불리는 일련의 작업을 수행한다. 모든 메서드의 호출코드를 대상으로 인자의 타입과 개수가 정확하고 올바른지, 반환값은 적절한 타입으로 사용되는지 메모리 침범등도 검출이 된다.
(관리되는 모듈의 메타데이터가 존재하기 때문에 이런 작업이 가능하다.)

Windows 프로세스 하나를 생성하고 유지하는 데는 많은 운영체제의 자원을 필요로 한다.
따라서 많은 프로세스를 생성한다는 것은 CPU에 많은 부담을 주는 것과 동시에 운영체제에 자원부족을 야기하는 원인이 되기도 한다.
실제 CLR은 하나의 OS프로세스에 여러 개의 관리되는 어플리케이션을 안전하게 실행시킬 수 있다. 각각 관리되는 어플리케이션은 AppDomain?이라고 불리며, 기본적으로 모든 EXE파일들은 실행 시에 하나의 AppDomain?만을 포함한 가상 메모리 공간을 확보한다. 하지만 CLR 프로세스 호스팅을 통하여 하나의 OS프로세스에서 다수의 AppDomain?을 실행하는 것이 가능하다. 이에 대한 자세한 내용은 21장

JIT 컴파일러는 안전하지 않은 메서드를 컴파일할 때 메서드를 포함한 어셈블리가 System.Security.Permissions.SecurityPermission? 권한을 부여 받았는지 그리고 이 권한 객체의 System.Security.Permissions.SecurityPermissionFlag?플래그 값이 SkipVerification?으로 설정되었는지 확인한다. 그리고 이 플래그가 설정된 권한을 가지고 있다면 JIT 컴파일러는 안전하지 않은 코드를 컴파일한 후 실행할 것이다. 만약 플래그가 설정되지 않았다면 System.InvalidProgramException?이나 System.Security.VerificationException?을 발생함으로써 해당 코드의 수행을 중단한다.

PEVerify.exe유틸리티는 안전하지 않은 코드를 포함한 메서드가 어셈블리에 정의되어 있는지 모든 메서드를 검색해 주는 작업을 한다. 검증작업은 모든 종속 어셈블리의 메타데이터도 검사하므로 참조된 어셈블리도 로드 가능한 위치에 있어야 한다.

IL은 소스코드를 보호할 충분한 알고리즘을 제공하지 않는다.
향후 DRM(DIgital Rights Management)솔루션을 개발자에게 제공하여 어셈블리에 포함된 IL코드를 보호할 수 있는 기능을 제공하게 될 것이다.

NGen.exe은 네이티브 코드를 생산해준다.
원하는 성능향상을 위해서는 너무 많은 제약조건이 따른다.

FCL : Framework Class Library

네임스페이스	네임스페이스에 포함된 타입
System	모든 종류의 어플리케이션에서 사용할 수 있는 여러 기본 타입
System.Data	데이터베이스와 프로세싱 데이터의 통신을 위한 타입
System.Drawing	2D 그래픽을 다루기 위한 타입. 윈폼, 웹폼에서 보통 사용
System.IO	I/O스트림과 디렉터리, 그리고 파일 작업에 사용되는 타입
System.Net	하위수준의 네트워크 통신과 일부 공통 인터넷 프로토콜 작업을 위한 타입
System.Runtime.InteropServices?	관리코드가 OS의 관리되지 않은 기능, 예를 들어 COM, Win32함수, 사용자DLL등의 기능을 액세스 가능하게 해주는 타입
System.Security	데이터와 리소스를 보호하기 위한 타입
System.Text	다양한 인코딩에서 텍스트를 지원 (아스키, 유니코드 등)
System.Threading	비동기 작업을 지원하기 위한 타입
System.Xml	XML스키마와 데이터를 처리하기 위한 타입

CTS : Common Type System
필드, 메서드, 속성, 이벤트
한정자(Private, Family, Assembly, Public, Family or assembly, Family and assembly)
모든 타입은 이미 정의되어 있는 System.Object를 무조건 상속 받는다.
System.Object타입은 다음과 같은 기능을 제공한다.

- 두 객체의 인스턴스 동질성 비교
- 인스턴스의 해시 코드 값 얻기
- 인스턴스의 실제 타입 구하기
- 인스턴스의 복사본 만들기
- 인스턴스의 현재 상태를 표현하는 문자열 구하기

using System; 
 
// 컴파일러에게 CLS 호환성 확인을 요구한다. 
[assembly : CLSCompliant(true)] 
 
namespace SomeLibrary 
{ 
 public sealed class someLibraryType // 경고 : 클래스가 public이므로 
 { 
  public UInt32 Abc { return 0; } // 경고 : 반환형식 UInt32는 CLS규격이 아님 
  public void abc() {} // 경고 : 대소문자만 다른 함수명은 CLS규격이 아님 
  private UInt32 ABC() { return 0; } // 에러 없음 
 } 
} 

CLR에서는 타입의 모든 멤버가 필드이거나 메서드 이다. 하지만 언어차원에서 열거형, 배열, 속성, 인덱서, 델리게이트, 이벤트, 생성자, 소멸자, 연산자 오버로드, 형 변환 연산자등을 제공해주는 것이다.

using System; 
 
internal sealed class Test 
{ 
 // 생성자 
 public Test() {} 
 
 // 소멸자 
 ~Test() {} 
 
 // 연산자 오버로드 
 public static Boolean operator == (Test t1, Test t2) { return true; } 
 public static Boolean operator != (Test t1, Test t2) { return false; } 
 
 public static Test operator + (Test t1, Test t2) { return null; } 
 
 // 속성 
 public String AProperty 
 { 
  get { return null; } 
  set {} 
 } 
   
 // 인덱서 
 public String this [Int32 x] 
 { 
  get { return null; } 
  set {} 
 } 
 
 // 이벤트 
 event EventHandler AnEvent;   
} 

비관리코드와의 상호연동 가능한 부분이 있다.
1. 관리코드에서 DLL에 포함된 관리되지 않은 함수 호출 : P/Invoke를 이용해서 쉽게 호출 가능
2. 관리코드에서 COM 컴포넌트(서버)의 사용 : 타입 라이브러리를 통해 어셈블리의 자동 생성 가능
3. 비관리코드에서 관리되는 타입 사용(서버) : 결론은 COM 컴포넌트 유사형태로 만들어낸다는 건데 자세한 것은 TlbExp?.exe, RegAsm?.exe 툴을 참고
4. C++코드를 IL코드로 생성(제약이 있음, 인라인어셈, 가변인자, setjump, __disable, _AddressOfReturnAddress?, _ReturnAddress?, __enable 과 같은 루틴이 사용된다면 IL코드를 생성할 수 없다.)

Chapter 2. 빌드, 패키지, 배포 그리고 어플리케이션과 타입 관리

Chapter 3. 공유 어셈블리와 강력한 이름의 어셈블리

Part 2. 타입(Type)