지금까지 CLR을 로딩하고 AppDomin을 생성하는 것에 대해 필요에 따라 여기 저기서 산발적으로 다뤘다.
윈도우 프로세스와 AppDomain의 관계
2009/04/23 - [01. 기술-APP] - 애플리케이션 도메인과 속성들(베이스 디렉토리)
IE와 AppDomain 그리고 MIME 타입 및 MIME 필터
2009/04/23 - [01. 기술-APP] - IE 임베딩 방식 스마트클라이언트 애플리케이션의 도메인 중복 생성??
2009/04/23 - [01. 기술-APP] - NTD 배포 및 어셈블리 로딩 그리고 IIS 설정
2009/04/23 - [01. 기술-APP] - IE에서 어셈블리가 로딩되는 과정
이제 이곳에서 호스트 애플리케이션별 CLR 인스턴스가 생성되는 차이점 및 호스트가 어떻게 AppDomain을 관리하는지에 대한 깔끔한 정리를 시도해 볼 생각이다. 다룰 호스트 애플리케이션 타입으로는 다음과 같다.
- 컨솔 및 윈도우 폼 애플리케이션
- Internet Explorer
- MS ASP.NET , XML 웹 서비스 애플리케이션
- MS SQL 서버 2005
■ 컨솔 및 윈도우 폼 애플리케이션
관리형 실행 파일(컨솔, 윈도우 폼 애플리케이션)이 구동되면, shim(MSCorEE.dll)이 가동된다는 것에 대해서 이전 포스트에서 설명했다.
2009/04/23 - [01. 기술-APP] - 로딩되는 CLR 버전 결정하기
shim은 일단 애플리케이션의 시작 어셈블리에 포함된 헤더 정보를 조사해서 그 애플리케이션이 어떤 버전의 CLR로 빌드가 되었는지를 확인한다. 그래서 그 버전의 CLR을 애플리케이션 프로세스로 로딩한다. CLR은 기본 AppDomain을 생성한 다음, 애플리케이션의 시작 어셈블리를 AppDomain으로 로딩한 다음 시작 포인트가 되는 메소드(Main())를 호출해서 애플리케이션을 그때부터 실행시키게 된다.
코드가 실행되면서, 다른 타입을 접근하게 되면, CLR(정확히 말하면 Fusion)은 참조되는 타입을 포함하고 있는 어셈블리의 위치를 결정하고 같은 AppDomain으로 어셈블리를 로딩한다.
애플리케이션의 Main() 메소드가 리턴되면, 애플리케이션을 위한 윈도우 프로세스는 종료된다. 이때 기본 AppDomain 및 추가된 모든 AppDomain들도 제거된다.
애플리케이션은 CLR에게 같은 애플리케이션 프로세스내에서 추가적인 AppDomain을 생성하도록 지시할 수도 있다.
■ Internet Explorer
머신에 .NET 프레임워크를 인스톨시키게 되면, MIME 필터(MSCorIE.dll)도 같이 인스톨된다. 인스톨된 이 MIME 필터는 IE 5.01 이후의 버전부터 작동하게 된다.
이 MIME 필터가 하는 일은 이렇다. IE를 통해서 다운되는 컨텐트에는 MIME 타입이 마킹되어 내려오게 되는데, 여러 MIME 타입 중에서 "application/octet-stream"이나 "application/x-msdownload" 타입의 컨텐트는 이 MIME 필터가 처리하게 된다.
이런 MIME 타입의 컨텐트를 확인하게 되면 MIME 필터는 먼저 CLR을 로딩하게 된다. 이렇게 해서, IE가 CLR를 호스팅하는 프로세스가 되는 것이다.
MIME 필터는 "동일한 웹 사이트"에서 다운된 어셈블리는 동일한 AppDomain으로 로딩되도록 한다. "동일한 웹 사이트"란 정확히 말하면 애플리케이션 베이스 디렉토리가 같은 웹 사이트를 말한다. 지난 포스트(IE 임베딩 방식 스마트클라이언트 애플리케이션의 도메인 중복 생성??)를 참조한다.
기본 AppDomain은 그것의 호스팅 프로세스 여기서는 IE 프로세스가 끝나지 않고서는 언로딩될 수 없다. 따라서 어떤 웹 사이트에서 다운되어 실행되는 코드가 사용자가 다른 웹 사이트로 서핑을 떠난다 해도 언로딩되지 않는다. 이것은 어셈블리가 이미 클라이언트측에 로딩되어 있다면, 사용자가 F5(새로고침)을 한다고 해서 서버에서 수정된 새로운 버전의 어셈블리를 다운받을 수 없는 이유이기도 하다. 수정된 새로운 어셈블리를 다운받으려면 IE 프로세스를 종료해야 한다.
■ MS ASP.NET , XML 웹 서비스 애플리케이션
ASP.NET은 ISAPI DLL로서 ASPNET_ISAPI.dll에 구현되어 있다. 클라이언트에서 처음으로 ASP.NET ISAPI DLL로 요청을 보낼때 ASP.NET은 CLR을 로딩하게 된다.
그런 다음 클라이언트에서 어떤 웹 애플리케이션에 대한 요청이 올라올때 마다, ASP.NET은 그것이 해당 웹 애플리케이션에 대한 첫번째 요청인지를 체크하고 만약 그렇다면 ASP.NET은 CLR에게 그 웹 애플리케이션을 위한 AppDomain을 생성하도록 한다.
각각의 웹 애플리케이션은 그것의 가상 루트 디렉토리(virtual root directory)로 아이덴터티가 구분되어 진다. ASP.NET은 CLR에게 웹 애플리케이션이 노출시킨 타입(.aspx 페이지)이 있는 어셈블리를 AppDomain으로 로딩시켜 이 타입의 인스턴스를 생성하고 클라이언트의 웹 요청을 처리하도록 지시한다. 만약 그 코드가 다른 타입을 참조하고 있다면 CLR은 필요한 어셈블리를 그 웹 애플리케이션의 AppDomain으로 로딩시킬 것이다.
만약 클라이언트에서 다른 웹 애플리케이션에 있는 페이지를 요청하게 되면, ASP.NET은 CLR에게 새로운 AppDomain을 생성하도록 한다. 이 새로운 AppDomain은 이미 다른 AppDomain들이 생성되어 있는 동일한 worker 프로세스내에 생성된다. 즉 많은 웹 애플리케이션이 하나의 윈도우 프로세스내에 생성되고 이것은 시스템의 성능을 향상시켜준다.
■ MS SQL 서버 2005
MS SQL 서버 2005 자체는 비관리형 C++코드로 작성되어 있는 비관리형 애플리케이션이다. 그러나 SQL 서버 2005에서는 관리형 코드를 사용해서 저장 프로시져(stored procedures)를 작성할 수 있다.
관리형 저장 프로시져 실행에 대한 요청이 처음으로 데이터베이스에 들어오면 그때 SQL 서버는 CLR을 로딩한다. 저장 프로시져는 자기만의 AppDomain에서 실행된다. 이 AppDomain은 sandboxing되어 있어서 그 프로시져가 데이터베이스 서버에 해를 입히는 일을 수행하는 것을 막을 수 있다.
이상 CLR의 호스트가 될 수 있는 애플리케이션 타입별로 어떻게 CLR이 로딩되고 어떻게 AppDomain이 생성되는지에 대해서 알아봤다. 이런 과정을 이해하는 것은 .NET 애플리케이션의 내면을 이해함에 있어서 안개를 한층 더 걷어 주는 역할을 할 것이다.
'IT 살이 > 04. 기술 - 프로그래밍' 카테고리의 다른 글
| 로딩되는 CLR 버전 결정하기 (0) | 2009.04.23 |
|---|---|
| .NET 3.0 으로 갈아타기 (0) | 2009.04.23 |
| [연재 03] .NET3.0관련 MIME 타입 (0) | 2009.04.23 |
