.NET 기반의 프로젝트를 담당하고 있다. 얼마전에 누군가 "NTD 배포( 예를 들어 LoadFrom 메소드 사용)로 다운로드되는 어셈블리가 서명이 된 경우( strong named assembly, signed assembly)라면 클라이언트 머신의 GAC( Global Assembly Cache)에 등록된다"는 얘기를 했다. 깜딱 놀랬다. 해서 .NET 캐시 특히 스마트클라이언트 어플리케이션과 관련된 캐시에 대한 정리를 해야 겠다고 생각하게 됐다.
.NET 어플리케이션중에서도 스마트클라이언트와 관련된 캐시는 4개가 있다.
Global Assembly Cache
Download Cache
Web Browser Cache
ClickOnce Application cache
예의 "그"가 오해했던 것은 "Gloabal Assembly Cache", "Dowonload Cache"를 구분하지 못했던 것 같다.
■ 스마트클라이언트 관련 캐시
위 캐시를 정리해보면 다음과 같다.
캐시 구분 | 개념 | 관련 명령어 | 물리적 경로 |
Global Assembly Cache |
머신 차원의 어셈블리 공유를 위한 캐시 |
gacutil.exe |
.NET2.0 : C:\Windows\Assembly\GAC (*) ( 참조 : “GAC은-어떻게-생겼을까” ) .NET4.0 : C:\Windows\Microsoft.NET\assembly |
Download Cache |
LoadFrom, CodeBase처럼 URL을 이용해서 다운로드된 어셈블리가 캐싱된다. ( 다운로드 기준 : datetime stamp, not version numbers ) ( 참고 : http://www.code-magazine.com/article.aspx?quickid=0307061&page=6 ) 주의)-2014.01.22 테스트결과, 사인이 된 어셈블리가 Download Cache에 있는 경우는 서버측으로 다운로드 요청이 가지 않는다. 캐싱된 어셈블리가 사용됨. 물론 서버측으로 다운로드 요청이 가면 datetime stamp가 다운로드 기준이 된다. |
gacutil.exe /cdl | C:\Users\<사용자>\AppData\Local\assembly\dl3(*) |
IE 브라우저 캐시 |
웹 브라우저 캐시 (다운로드 기준 : datetime stamp, expire 설정 ) URL를 통해서 어셈블리를 다운로드하는 경우 다른 파일들처럼 일단 IE 브라우저 캐시에 먼저 저장된다. 즉 파일 다운로드시 브라우저 인프라를 사용한다는 의미이다. 해당 파일이 어셈블리 인 경우 다시 download cache로 “인스톨”된다. |
C:\Users\<사용자>\AppData\Local\Microsoft\Windows\Temporary Internet Files | |
ClickOnce Application Cache |
ClickOnce 어플리케이션(Launcher)를 통해서 다운로되는 파일 캐시 ( 업데이트 기준 : 어플리케이션 게시 버전 및 파일별 해시값 ) |
merge.exe | C:\Users\<사용자>\AppData\Local\Apps |
(*) 물리적 경로와 뷰어(윈도우 탐색기)의 경로와 다른 경우
■ Global Assembly Cache 뷰어
Global Assembly Cache는 어셈블리 버전 등에 따라서 어셈블리별로 폴더가 구성된다. 따라서 물리적인 폴더 구조 그대로 보기에는 복잡하다고 느껴졌다.
그래서 .NET 2.0에서는 그림처럼 GAC에 저장된 어셈블리를 간략히 볼 수 있는 뷰어를 윈도우 탐색기를 통해서 제공한다.
그림) .NET 2.0 GAC 뷰어
뷰어 경로 :
- c:\windows\assembly
물리적 경로 :
- C:\Windows\Assembly\GAC
물리적인 구조를 탐색해 볼 수 있는 방법은 아래 포스트에서 설명하고 있다.
2009/04/23 - [01. 기술-APP] - GAC은 어떻게 생겼을까
그러나 .NET4.0에서는 물리적인 디렉토리 구조 그대로를 보여주고 있다.
그림) .NET 4.0 GAC
■ Download cache 뷰어
download cache도 어셈블리 버전, codebase 등에 따라서 어셈블리별로 폴더가 구성된다.
그림처럼 download에 저장된 어셈블리를 간략히 볼 수 있는 뷰어를 윈도우 탐색기를 통해서 제공하고 있다.
그림) download cache 뷰어
download cache 의 물리적인 경로 : “C:\Users\<사용자>\AppData\Local\assembly\dl3” 이하
뷰어상의 경로 : “c:\windows\assembly\download”
■ download cache , GAC 비교
download cache를 GAC이라고 오해하는 이유를 생각해보면 몇 가지 있는 듯하다.
우선 뷰어상에서 “download” 폴더가 .NET2.0의 GAC에 등록된 어셈블리를 보여주는 “c:\windows\assembly” 폴더 하위에 위치하고 있다는 것,
그리고 download cache에 캐싱된 어셈블리를 제거하는 명령어가 “GACUTIL.exe /cdl” 이라는 것.
download cache도 어셈블리의 버전과 다운로드 위치(codebase)에 따라서 어셈블리별로 폴더가 구성되다 보니
.NET 2.0 GAC을 보여주는 뷰어를 download cache에 있는 어셈블리들을 보여주는 목적으로도 쉽게 적용할 수 있지 않았을까 하는 개인적인 상상을 해 본다.
그러나 분명 두 캐시는 다르다는 것이다. 상식적으로 생각해봐도 !
LoadFrom이나 codebase로 서명된 어셈블리를 다운로드했는데, 그 어셈블리가 자동으로 GAC에 등록된다는 것은 말이 안 된다.
그렇다면 수정된 어셈블리를 다시 배포하기 위해서는 GAC에 등록된 어셈블리를 명시적으로 다시 제거해야 한다는 말이 된다.
download cache에는 URL로 다운로드된 어셈블리라면 서명이 되었든 되지 않았든 저장되는 곳인 반면,
GAC에 어셈블리 등록하는 작업은 서명이 된 어셈블리를 대상으로 해서 프로그램적으로 “gacutil.exe”를 사용해서 수행하든, 사용자가 직접 명령문을 실행해서 수행하든 “명시적”으로 이뤄져야 한다.
'IT 살이 > 04. 기술 - 프로그래밍' 카테고리의 다른 글
Adobe, Java 환경 설정 (0) | 2015.08.19 |
---|---|
어셈블리 바인딩3-정리 (0) | 2013.05.11 |
back to the basic : .NET Interoperablility (1) | 2013.02.11 |