어셈블리 로드 해결
어셈블리 로드 해결Resolve assembly loads 이 문서의 내용 --> .NET에서는 어셈블리 로드를 보다 효율적으로 제어해야 하는 애플리케이션에 대해 AppDomain.AssemblyResolve 이벤트를 제공합니다..NET provides the AppDomain.AssemblyResolve event for applications that require greater control over assembly loading. 이 이벤트를 처리
docs.microsoft.com
1. 내부적으로 CLR은 System.Reflection.Assembly 내 정적 Load 메서드를 이용해 어셈블리 로드
2. 바인딩 리디렉션 정책 어셈블리 적용 약한 어셈블리 이름을 전달하였으면 정책 적용 X
3. 전역 어셈블리 캐시로부터 어셈블리 탐색
4. 그 후 응용프로그램의 기본 디렉터리, 하위 디렉터리, 코드베이스(codebase)를 차례대로 탐색
5. Load 메서드가 어셈블리를 찾지 못하면 System.IO.FileNotFoundException 발생
보통 어셈블리 구분자를 조합할 수 있는 개별 정보들을 모두 가지고 있는 경우가 빈번해 Load(위와 같은 방식)를 선호
어셈블리 경로명을 이용하여 로드 시 LoadFrom
내부적으로 System.Reflection.AssemblyName의 정적 메서드 GetAssemblyName을 호출
1. 지정한 파일 Open
2. AssemBlyDef 메타데이터 테이블 항목의 어셈블리 구분자 정보 획득
3. System.Reflection.AssemblyName 객체로 반환
4. 내부적으로 Load호출 및 위 단계에서 산출된 객체 인자로 전달
5. 매개변수로 URL전달 가능
리플렉션
리플렉션(C#)
리플렉션(C#)Reflection (C#) 이 문서의 내용 --> 리플렉션은 어셈블리, 모듈 및 형식을 설명하는 개체(Type 형식)를 제공합니다.Reflection provides objects (of type Type) that describe assemblies, modules, and types. 리플렉션을 사용하면 동적으로 형식 인스턴스를 만들거나, 형식을 기존 개체에 바인딩하거나, 기존 개체에서 형식을 가져와 해당 메서드를 호출하거나, 필드 및
docs.microsoft.com
어셈블리와 모듈의 메타데이터를 기반으로 객체 모델을 타입으로 구성하고 이를 한 어셈블리에 모아 두었다. 이러한 객체 모델 타입들을 사용하는 것이 Reflection이다.
단점
l 컴파일 시 타입 안정성을 해친다.
컴파일 시에는 문제가 없을 수 있어도 런타임 시에 해당 객체의 정보가 최신화 되어있다고는 말할 수 없다. (메타 정보가 있어도 타입들이 그 시점에서 그 정보를 가리키고 있다는 것을 보장할 수 없다.)
l 전반적으로 느리다.
런타임 시에 타입과 멤버를 구분할 수 있는 문자열을 이용하는데 검색 속도를 느리게 한다.
l 매개변수를 배열로 포장 한 후 내부적으로 해당 내용을 다시 꺼내어 스레드의 스텍을 옮기는 과정을 거친다.
l 추가적으로 CLR은 매개변수가 올바른 타입을 가지는지 확인해야 하고 호출하려는 멤버에 접근권한까지 확인해야 한다.
대처
l 컴파일 시 타입 구조를 알 수 있는 기본 타입 상속
l 컴파일 시 타입 구조를 알 수 있는 인터페이스 상속
여기서 Type 객체는 그저 타입의 객체를 가리키는 일종의 포인터를 수행하는 가벼운 역할이다.
'C# > CLR via' 카테고리의 다른 글
| 스레드(Thread) (0) | 2020.03.25 |
|---|---|
| 직렬화 serialization (0) | 2020.03.25 |
| 앱도메인 (0) | 2020.03.25 |
| 가비지 컬렉터 (0) | 2020.03.25 |
| 예외와 상태 관리 (0) | 2020.03.25 |
