5. Assembly - Strongly named assemblies

CLR 2010. 1. 26. 09:00 Posted by 알 수 없는 사용자
CLR에서는 Assembly를 크게 두 종류로 나눌 수 있습니다. Strongly named assemblies(강력한 이름의 어셈블리 - 뭔가 말이 좀 이상하지요?) 그렇지 않은 Assembly 입니다. 

Strongly named assemblies는 해당 assembly의 제공자를 확인할 수 있는 유일한 공개/개인키 쌍으로 서명되어 있고 이 키들은 assembly는 고유한 ID의 일부분으로 인식되어 안전하게 버전이 관리되며 이 키를 통해서 서명된 assembly는 어느곳에서라도 유일한 이름으로 인식되며 배포가 가능하게 됩니다. 

assembly는 크게 전용(Private)으로 배포하는 방식과 전역(Global)으로 배포하는 방법으로 배포 방법을 나눌 수 있습니다. 

전용 배포라는 것은 매우 일반적인 방법의 배포방식으로 배포할 프로그램의 기본 디렉토리와 그 디렉토리의 하위 디렉토리에 관련 assembly들이 설치되어 배포된 형태이며 전역 배포라는 것은 Global Assembly Cache - GAC(전역 어셈블리 캐시) 같은 잘 알려진 특정 디렉토리에 배포되는 방식을 말합니다.

Strongly named assemblies는 전용, 전역 배포가 가능하지만 그렇지 않은 assembly는 전용 배포는 가능하나 전역 배포는 안됩니다. 위에서 알았다시피 Strongly named assemblies가 아닌 경우 유일하게 해당 assembly를 인식할 수 있는 방법이 없으니 당연히 전역적인 배포가 불가능합니다.


자 그럼 Strongly named assemblies를 어떻게 만들 수 있는지 살펴보도록 하지요. 그 전에 잠깐 왜 Strongly named assemblies가 필요한지 잠깐 생각해 봅시다.

다양한 프로그램들이 자신들이 사용하는 assembly를 사용하려고 하는 상황입니다. 일반적으로 그렇듯이 여러 프로그램에서 자주 사용하는 assembly는 잘 알려진 디렉터리에 위치해 있어야 다양한 프로그램들이 사용하기 용이할 것입니다. 

CLR 프로그램 이전의 배포 방식을 되새겨 볼까요.

Visual Studio 6, 7 버전의 Visual C++ 프로그램을 살펴보면 Visual C++ 컴파일러로 생성된 프로그램들은 공통적으로 msvcp71.dll이라던가 msvcp60.dll 등의 공용 모듈을 사용하게 됩니다. 그래서 일반적으로 프로그램 설치시 위의 모듈들을 설치되는 프로그램과 같은 경로에 넣기도 하지만 windows 폴더의 system32 디렉터리에 넣어놓곤 하지요. 일반적으로 MS관련 프로그램을 설치하게 되면 위의 ms..로 시작하는 dll들은 system32 디렉터리에 설치가 되기 때문에 응당 위의 모듈이 모든 PC의 system32 폴더에 있겠거니 착각하고 배포본에 넣어놓지 않았다가 낭패를 보는 경우도 적지 않게 있었지요. 

MS관련의 공통모듈 뿐만이 아니라 다양한 프로그램에서 자주 사용하는 모듈들은 Windows가 설치된 PC라면 설치된 프로그램이 어느 디렉터리에 설치가 되던지 참조가 가능한 system32 폴더에 설치해 놓는 경우가 많습니다. 이러면서 문제가 발생하게 되었는데 다른 회사에서 같은 파일 이름을 가진 모듈을 system32 폴더에 설치를 하게 되었다던가, 같은 이름을 가지지만 버전이 틀린 파일을 설치하게 되어 특정 프로그램은 정확히 자신이 참조해야 하는 모듈을 찾을 수 없어 프로그램이 정상적으로 실행되지 않는 이른바 DLL Hell과 관련된 문제가 생기가 된 것입니다. 무엇보다 별 생각없이 system32같은 중요한 디렉터리에 자신들이 배포하는 프로그램과 관련한 모듈들을 무작정 설치하는 것도 DLL Hell을 만들게 된 중요한 원인 중 하나였지요.

최근에도 그런 문제가 있었습니다. 인터넷 익스플로러 8과 아래아 한글과의 충돌 문제였지요,

인터넷 익스플로러 8이 설치된 PC에 아래아 한글이 설치되면 인터넷 익스플로러 8이 시작하자마자 다운되는 문제가 발생했는데 그 원인은 이미 인터넷 익스플로러 8 이 사용하는 system32폴더에 설치된 최신 버전의 jscript.dll 모듈을 아래아 한글이 사용자 PC에 설치되면서 구 버전의 jscript.dll모듈로 교체 설치를 함으로써(같은 파일명이니 덮어씌워지는 형태로 설치가 되어버린 겁니다.) 인터넷 익스플로러 8은 자신이 사용하는 jscript.dll 파일을 찾지 못해 뻗어버리게 된 것이지요.

단순히 파일 이름만으로 프로그램 자신이 참조해야 하는 모듈 또는 assembly를 찾는 건 좋은 방법이 아니라는 것이 증명된 것입니다. 그래서 CLR의 경우 정확히 자신이 참조해야 하는 assembly를 식별하기 위해서 다음과 같은 4가지 요소를 이용하여 assembly를 식별하게 됩니다.

1. 파일 이름 (확장자를 제외한)
2. 버전 번호
3. 컬쳐 (로케일)
4. 공개키 (또는 공개키를 이용하여 생성한 작은 해시값)

어떤 프로그램이 자신이 원하는 assembly를 찾을 때 저 4가지 요소가 정확히 맞아야지 해당 assembly를 자신이 찾는 assembly라고 확신하고 사용하게 된다는 말이지요. Strongly named assemblies에 해당하는 이야기입니다.

저 4가지 요소중 1, 2, 3번 요소는 굉장히 드물기는 하겠지만 다른 회사와 동일 할수도 있습니다. 하지만 4번 공개키는 공개/개인키 쌍을 만들어서 사용하는 것이니만큼 해당 assembly의 제작자가 틀리다면 같을 수가 없을 것입니다.

Strongly named assemblies가 아닌 경우는 공개키를 제외한 요소들을 manifest metadata로 가질 수 있지만 assembly를 찾을 때는 단순히 파일 이름만을 이용하여 찾게 됩니다.

자 그럼 이젠 Strongly named assemblies를 만드는 방법을 살펴보도록 합시다.

우선은 키를 생성해야 합니다. 키를 생성하기 위해 .NET Framework에서는 SN.exe 라는 툴을 제공합니다. Visual Studio Command Prompt 2010을 실행하여 다음과 같이 실행해 보면-

SN -k VSTSTeam.keys

VSTSTeam.keys 라는 파일명의 공개/개인키의 쌍을 생성하게 됩니다. 이 파일은 바이너리의 형태로 공개/개인키의 쌍을 갖고 있습니다. 우리는 공개키를 사용해야 합니다. 공개키를 확인하기 위해서는 만들어진 키 파일을 이용하여 다음과 같이 SN.exe 를 한번더 실행해야 합니다.

SN -p VSTSTeam.keys VSTSTeam.publickey

결과로 VSTSTeam.publickey 라는 파일이 생성됩니다. 이 파일은 공개키를 포함하고 있는 바이너리 파일입니다. 이 파일의 공개키를 한번 확인해 봅시다.

SN -tp VSTSTeam.publickey

그럼 다음과 같이 굉장히 긴- 공개키 값을 확인할 수 있습니다.


이렇게 공개키는 확인할 수 있지만 개인키를 확인할 수 있는 방법은 제공하지 않고 있습니다.

이렇게 생성한 키를 이용하여 assembly를 컴파일 할 때 다음과 같은 Argument를 이용하여 assembly에 공개키를 포함시키게 됩니다.

csc /keyfile:VSTSTeam.keys hello.cs

당연히 Visual Studio IDE에서도 이런 작업이 가능합니다.



Sign the assembly 라는 체크박스에 체크를 한 후 새로 key를 생성해도 되고 이미 생성된 key 파일이 있다면 해당 key파일을 이용하여 사용하면 됩니다.



참고 자료
CLR Via C# 2nd. Ed.

'CLR' 카테고리의 다른 글

7. System.Object  (0) 2010.02.16
6. Assembly - GAC(Global Assembly Cache)  (2) 2010.02.02
4. Assembly  (2) 2010.01.15
3. MSCorLib & Metadata  (4) 2010.01.06
2. CLR! CLR! CLR!  (3) 2009.12.30