Creative Commons License

Microsoft .NET

닷넷!시작하기
닷넷! Ver 2.0~
닷넷!스킬업
웹개발
윈폼개발
실용모듈개발
Tip & Tech
하루 한 문법

Microsoft .NET 개발자들을 위한 공간입니다. 기초강의에서 부터 고급 기술 정보 및 팁등을 다루도록 하겠습니다.

.

닷넷!시작하기

Microsoft. NET 을 시작하는 분들을 위한 강좌입니다. 주로 기초적인 내용과 때론 기본적인 내용을 다룹니다

닷넷 어셈블리 버전 관리

작성자 : 박종명
최초 작성일 : 2008-05-30 (금요일)
최종 수정일 : 2008-05-30 (금요일)
조회 수 : 5081

* 어셈블리
하나의 단일한 단위로 존재하는 닷넷의 실행 가능한 프로그램(또는 실행프로그램의 일부)를 어셈블리라 하며 실행 및 배포 단위라 할 수 있다. 확장자로는 실행가능한 exe와 클래스 라이브러리의 결과물인 dll 모두 어셈블리이다.
 
* 버전 관리 목적
버전 관리를 하지 않는다고 해서 프로그램을 작성할 수 없는것은 아니다. 그러나 상용화 프로그램, 또는 업무용, 배포용 등의 결과물을 작성한다면, 버전관리를 하는것이 여러모로 이로울 것이다. 아래와 같은 이점을 들 수 있겠다

1) 프로그램을 제작하고 실제 서비스를 하고 난뒤 유지/보수, 확장 등 기존 프로그램의 기능을 계속해서 개선해
    나갈때 각 단계별로 버전을 높여 나감으로써 버전정보와 기능 추가/개선 정보를 매핑하여 관리할 수 있다.
2) 빌드 버전별로 어셈블리들을 따로 관리하면서 이전의 빌드 버전으로 되돌릴 수있다.
3) 버전 정보로 프로그램 이력관리를 할 수 있다.
4) 동일한 이름의 어셈블리를 같은 컴퓨터에 버전별로 설치 할 수 있다.
5) 기타.. 소프트웨어 관리에 거의 필수적인 요소이다
 
 
* 닷넷 버전 체계
닷넷에서 어셈블리의 버전은 아래의 형태로 구성된다.

 주 버전

 부 버전

 빌드 번호

리비전 


현재 웹 스크립트 언어로 많이 사용되는 ASP 는 ASP 3.0 이다
즉 주버전과 부버전을 명시하고 있다. 그리고 닷넷 1.1 은 정식 버전 번호가 1.1.4322 이다.
보통 버전 몇점 몇이다 라고 예기 할때에는 주버전과 부버전을 일컫는다.
 
4가지 버전을 특징을 살펴보자.

1) 주 버전 
일반적으로 프로그램을 처음 릴리스 하는 시점에 버전은 1.0 이 된다. 즉, 개발되고 첫 공개되는 소프트웨어라
하겠다. 주 버전 번호가 1이 되는 것이다. 
이후 기존 프로그램에 중대한 변화가 생겨서 다시 릴리즈 할 때에는 주 버전 번호를 하나 올린다. 버전  2.0

2) 부 버전
중대한 변화 까지는 아니라도 부차적인 변화가 일어 났다면 부버전 번호를 증가 시킨다

3) 빌드 번호
일반적으로 어셈블리를 다시 빌드 할 때마다 증가 시킨다

4) 리비전
사소한 버그를 잡는 것(버그 패치)과 같이 기능 개선이 아닌 변화가 생길 경우 증가 시킨다
 
보통 주 버전과 부 버전의 관리를 철저히 한다.
빌드 버전과 리비전은 상황에 따라 자동으로 증가하도록 설정 하기도 한다.
 

* 버전 샘플
닷넷이 제공하는 내장 어셈블리들의 버전 번호를 살펴 보자

1.0.5000.0 <-- 개발 하고 릴리즈 후 5000번의 리빌드가 일어 났나 보다 ^^; (꼭 그렇지는 않을지도 모른다 -.-;)
 
 

* 어셈블리의 종류

1. Private Assembly

사설 어셈블리 또는 전용 어셈블리라 한다.
특정한 하나의 어플리케이션을 위한 어셈블리를 말한다. 전용 어셈블리는 반드시 어플리케이션과 동일한 디렉터리에 존재 해야 한다. 보통 우리가 작성하는 어셈블리는 모두 전용 어셈블리 이다. 특정한 어셈블리를 어플리케이션에서 사용할려면 명시적(물리적)으로 참조 추가 해야한다. 이때 그 어셈블리의 전용 복사본이 만들어져 해당 어플리케이션 디렉터리에 넣는다.
 
2. Shared Assembly
공유 어셈블리라 한다.
시스템 안의 모든 프로그램이 공유하는 어셈블리이다.
많은 어플리케이션에서 참조되는 어셈블리는 공유 어셈블리로 만드는 것이 좋다. 물론 모든 어플리케이션에서 명시적(물리적)으로 참조추가 해서 전용 어셈블리로 사용하여도 되겠지만 용도에 적합치 않다. 닷넷이 제공하는 System.Data.dll 과 같은 것이 바로 공유 어셈블리 이다. 우리가 ADO 관련 프로그램을 할 경우 이 System.Data 를 논리적 참조만 하면 되는 이유가 바로 공유 어셈블리로 이미 시스템에 설치되어 있기 때문이다.
그리고 특별한 설정(로컬복사)을 하지 않는다면, 공유 어셈블리는 해당 어플리케이션의 디렉터리에 포함되지 않는다
(Visual Stuiod 와 같은 IDE 툴은 조금 다르다. 컴파일타임에 공유어셈블리에 대한 명시적 참조 추가를 해 줘야 한다)
C:\WINDOWS\assembly 폴더에 내 컴퓨터에 설치된 공유 어셈블리를 확인 할 수 있다
 
 
* 공유 어셈블리와 버전 호환성
사설 어셈블리라면 버전 호환성을 고려하지 않아도 된다. 특정한 단일 어플리케이션에서만 참조하기 때문에 다른 어플리케이션에서 사용하는 어셈블리와의 충돌이 일어날 일이 없기 때문이다.
 
그러나 공유 어셈블리의 경우는 버전 호환성이 확보 되어야 한다.
시스템에 있는 모든 프로그램에서 사용하기 위해 작성된 공유 어셈블리는 GAC라는 닷넷의 특별한 시스템 디렉터리에 저장이 되는데, 한 컴퓨터에 동일한 이름의 서로 다른 어셈블리의 경우 이름만으로 유일성을 보장할 수 없다.
(내가 제작해서 배포한 어셈블리와 다른 사람이 제작해서 배포한 어셈블리의 이름이 항상 같지 않다고 보장할 수 없다) 또한 내가 작성한 어셈블리라 하더라도 기능개선으로 인해 버전 업이 되어 다시 공유 어셈블리로 사용하고자 할 때 이전 버전의 어셈블리 역시 같이 사용하고자 한다면 버전 호환성이 확보 되어야 한다.
 

* 닷넷에서의 공유 어셈블리 버전 호환성 방법

닷넷은 동일한 이름의 서로 다른 어셈블리들에 대한 버전 호환성을 위해 보안과 강력한 이름, 버전 번호를 사용한다.
공유 어셈블리가 되려면 아래의 조건을 만족해야 한다

 1) Shared Name
   : SN.EXE 로 Public/Private Key 쌍 생성

 2) 전자 서명 필수
   : [assembly:AssemblyKeyFile("")] 로 어셈블리를 보호하고 동일한 이름, 동일한 버전을 가진 서로 다른 어셈블리의
     구분으로도 사용된다

 3) 버전 정보
   : [assembly:AssemblyVersion("1.0.*")] 로 어셈블리 버전번호를 관리한다

 4) GAC 에 등록
   : GACUTIL.EXE 라는 명령줄 유틸리티로 GAC에 등록한다
 
GAC에 등록된 공유 어셈블리의 식별은 어셈블리명 , 버전번호,공캐 키 의 조합으로 이루어 진다.
이 조합은 사스템에서 유니크 하며 이러한 조합을 강력한 이름(Strong Name) 라 한다.

 

* GAC에 등록된 강력한 이름을 가진 공유 어셈블리 샘플


위 그림에서 처럼 공유 어셈블리는 이름,버전,공캐키 토큰을 가지고 있다.
 

* 공개 어셈블리 만들기.
내가 만든 프로그램이 공개 어셈블리가 되려면 아래의 작업단계를 따라야 한다.

1) sn -k MyApp.snk
     내가 만든 어플리케이션을 위한 키파일을 만든다.

2) [assembly: AssemblyKeyFile("MyApp.snk ")] 
     프로젝트의 Assembly.info 파일의 이전에 만든 키파일 이름을 명시한다(위치를 명확히 지정해야 한다)
     이렇게 해서 프로젝트를 빌드 하면 명시한 키 파일을 기반으로 전자서명된 어셈블리가 생성된다

3) [assembly:AssemblyVersion("1.0.*")]
    하위 버전 호환성을 위해 버전 번호를 명시한다.

4) gacutil /i MyApp.dll (제거는 /u 옵션)
   닷넷의 공유 어셈블리 저장소인 GAC 에 등록한다.
   또는 등록하고자 하는 어셈블리를 드래그앤 드랍으로 C:Windos\assembly 폴더로 이동 시킨다.
 

* 시나리오
1. A 제작자가 만든 공유 어셈블리가 App.dll 라는 이름으로 시스템 GAC 에 등록되었다.
    B 제작자도 공유 어셈블리를 만들고 이름을 App.dll 이라고 했다.
    그리고 불행하게도 이 두 어셈블리는 둘 다 첫 릴리즈 버전이라 1.0.0.0 으로 버전번호 역시 완전 동일하다.
    이미 A제작자가 만든 App.dll 이 설치되어 있는 상태에서 B 제작자가 만든 어셈블리를 시스템에 설치하면
    우째 되겠노?
    답) 두 어셈블리가 공유 어셈블리가 되기 위해서 sn.exe 로 키를 생성하였을 것이다.
         즉, 두 어셈블리는 이름과 버전이 같지만 공개키가 다르다.
         따라서 완전히 다른 어셈블리로 취급된다. 충돌 없다.
 
2. A 제작자가 App.dll 이라는 공유 어셈블리를 만들고 시스템에 등록했다. 얼마 후 A제작자는 기능 개선을 위해 Ap
    p.dll 을 업그레이드 하고 리빌드 했다. 그런데 기능 개선 이전에 App.dll 역시 현재 많은 어플리케이션에서 잘 사용
    되고 있다. 따라서 기능 개선 이전 버전과 기능 개선 이후 버전을 하나의 시스템에 동시에 설치하여 같이 쓰고 싶
    어 졌다. 즉, 필요한 어플리케이션만 기능개선 버전을 쓰고 그렇지 않은 어플리케이션은 여전히 이전버전을 사용
   
하도록 해야 한다. 충돌없이 해결 할려면?
    답) 이 경우에는 이미 공유 어셈블리로 만들어진 동일한 어셈블리의 기능개선 이기에 공개키도 동일하다.
         즉, 어셈블리명과 공개키 가 동일한 것이다.
         이 경우에는 어셈블리의 버전 번호를 달리 하여 충돌없이(덮어쓰지 않고) 사용할 수 있다

이름
비밀번호
홈페이지
KV <- 왼쪽의 문자를 오른쪽 박스에 똑같이 입력해 주세요