Search

'CLR'에 해당되는 글 4건

  1. 2010.03.03 8. System.Object (2)
  2. 2010.02.16 7. System.Object
  3. 2010.01.26 5. Assembly - Strongly named assemblies
  4. 2010.01.06 3. MSCorLib & Metadata (4)

8. System.Object (2)

CLR 2010.03.03 09:00 Posted by 52
2. GetHashCode

객체 값에 대한 HashCode를 반환해주는 Method입니다. 근데 이 Method가 반환해 주는 Hashcode는 그닥 쓸모가 없다고 합니다. 각 객체마다 유일한 Hashcode를 보장해 주어야 하지만 그렇지 못하기 때문입니다.

암튼 디자이너는 어떠한 객체라도 HashTable에 담길 수 있다면 여러모로 편리할 것이라고 판단해서 모든 Object를 상속하는 객체는 이 Method를 통해 Int32형태의 hashcode를 얻을 수 있도록 설계했다고 합니다.

하지만 결국 이 Method로 유일한 hashcode를 제대로 반환해 줄 수 있도록 사용하기 위해서는 override를 통해 재작성하여 사용해야 합니다. 그래서 CLR via C# 에서는 Object의 Method로 정의되어 있을 것이 아니라 interface로 정의해 놓는게 맞는게 아닌가 라고 말합니다.

그런데 이 GetHashCode를 재정의해서 사용하기 위해서는 기억해야 할 점이 있습니다. 지난 번에 공부했던 Object의 Method인 Equals()를 재정의 한다면 이 GetHashCode()도 재정의를 해 주어야 한다는 점입니다. 만약 Equals()만 재정의 한다면 컴파일시 warning을 발생합니다.

------ Build started: Project: Test04, Configuration: Debug x86 ------
C:\Documents and Settings\XPMUser\my documents\visual studio 2010\Projects\TestSolution\Test04\Program.cs(8,11): warning CS0659: 'Test04.Animal' overrides Object.Equals(object o) but does not override Object.GetHashCode()

Animal이라는 Class에서 Equals()만 재정의 했더니 위와 같은 경고 메시지를 발생하는 것을 볼 수 있습니다. 이유는 두 객체가 같다면 (Equals()의 값이 true라면) 두 객체의 hashcode도 같을 것이라는 가정을 System.Collections.HashTable 타입과 System.Collections.Generic.Dictionary 타입이 하고 있기 때문입니다.
결국 객체의 동질성을 판단하는 Equals()의 알고리즘에 의해 두 객체가 같다고 판명이 난다면 GetHashCode()를 구하는 알고리즘도 Equals()을 판단하는 알고리즘과 연관되어 같은 값을 반환할 수 있도록 구현해 주어야 합니다.



GetHashCode()는 객체가 속한 AppDomain수준에서 유일할 수 있는 ID를 숫자로 반환하게 되어 있으며 이 값은 객체의 일생동안 바뀌지 않는 것이 보장되지만 이 객체가 가비지 수집기에 의해 수집되면 수집된 객체 hashcode를 의미하는 ID가 다른 새로운 객체에 재활용될 수 있다고 하네요. 그래서 유일한 값을 보장 못한다고 말하는데 그렇다면 AppDomain 수준에서 객체의 유일한 값을 보장해주는 HashCode를 반환해주는 Method가 CLR에 없을까요?

아니 있습니다. System.Runtime.ComplierServices 네임 스페이스에 있는 RuntimeHelpers 클래스의 정적 Method인 GetHashCode 메서드를 제공하고 있습니다. 객체가 Object의 GetHashCode 메서드를 재정의했다고 하더라도 해당 Object를 RuntimeHelpers.GetHashCode() 메소드의 인자로 제공하면 유일한 값을 보장받을 수 있는 ID를 제공해 줍니다.

아 그럼 Object의 GetHashCode()를 쓸게 아니라 저 RuntimeHelpers.GetHashCode()를 쓰면 되겠구나.

하면 되겠죠.


그런데 이 GethashCode()가 VS2010에 포함되어 있는 4.0X 버전의 mscorlib.dll 에서 구현하고 있는 것과 이전 버전에서 구현하고 있는 것이 좀 틀립니다.

우선 기존의 CLR의 mscorlib.dll에서 제공하고 있는 GetHashCode()의 내부를 살펴보도록 하겠습니다.


내부에서 Object.InternalGetHashCode()라는 Method를 호출하고 있네요. 저 함수를 들어가 보면


위와 같은 코드를 볼 수 있습니다. 함수 선언을 보면 internalcall이라는게 붙어 있는데 이것은 unmanaged코드가 불리는 것이라고 생각하면 됩니다. CLR의 관리되는 코드가 아니라 nativecode의 영역에서 구현되어 있다는 말이지요.

그래서 실제 GetHashCode는 다음과 같이 구현이 되어 있다고 합니다.

FCIMPL1(INT32, ObjectNative::GetHashCode, Object* obj) {
    
    CONTRACTL
    {
        THROWS;
        DISABLED(GC_NOTRIGGER);
        INJECT_FAULT(FCThrow(kOutOfMemoryException););
        MODE_COOPERATIVE;
        SO_TOLERANT;
    }
    CONTRACTL_END;

    VALIDATEOBJECTREF(obj);
    
    DWORD idx = 0;
    
    if (obj == 0)
        return 0;
    
    OBJECTREF objRef(obj);

    HELPER_METHOD_FRAME_BEGIN_RET_1(objRef);

        
    idx = GetHashCodeEx(OBJECTREFToObject(objRef));

    
    HELPER_METHOD_FRAME_END();

    return idx;
}
FCIMPLEND

INT32 ObjectNative::GetHashCodeEx(Object *objRef)
{
    CONTRACTL
    {
        MODE_COOPERATIVE;
        THROWS;
        GC_NOTRIGGER;
        SO_TOLERANT;
    }
    CONTRACTL_END

    VALIDATEOBJECTREF(objRef);

    DWORD iter = 0;
    while (true)
    {
        DWORD bits = objRef->GetHeader()->GetBits();

        if (bits & BIT_SBLK_IS_HASH_OR_SYNCBLKINDEX)
        {
            if (bits & BIT_SBLK_IS_HASHCODE)
            {
                return  bits & MASK_HASHCODE;
            }
            else
            {
                SyncBlock *psb = objRef->GetSyncBlock();
                DWORD hashCode = psb->GetHashCode();
                if (hashCode != 0)
                    return  hashCode;

                hashCode = Object::ComputeHashCode();

                return psb->SetHashCode(hashCode);
            }
        }
        else
        {
            if ((bits & (SBLK_MASK_LOCK_THREADID | 
(SBLK_MASK_APPDOMAININDEX << SBLK_APPDOMAIN_SHIFT))) != 0)
            {
                objRef->GetSyncBlock();
            }
            else
            {
                if (bits & BIT_SBLK_SPIN_LOCK)
                {
                    iter++;
                    if ((iter % 1024) != 0 && g_SystemInfo.dwNumberOfProcessors > 1)
                    {
                        YieldProcessor();
                    }
                    else
                    {
                        __SwitchToThread(0);
                    }
                    continue;
                }

                DWORD hashCode = Object::ComputeHashCode();

                DWORD newBits = bits | BIT_SBLK_IS_HASH_OR_SYNCBLKINDEX | 
BIT_SBLK_IS_HASHCODE | hashCode;

                if (objRef->GetHeader()->SetBits(newBits, bits) == bits)
                    return hashCode;
            }
        }
    }
}


Hashcode 소스이지만 이 소스만 읽어서는 어떤 알고리즘으로 hashcode를 생성하는 건지 정확히 파악하기가 어렵군요. :)

암튼 이런식으로 GetHashCode()가 구현되어 있었습니다.

그런데 4.0 버전에서의 구현은 다음과 같습니다.



어라 어디서 많이 보던 함수를 호출 하고 있군요. 아까 앞에서 살펴본 AppDomain상에서 객체마다 유일한 ID를 제공하는 것을 보장해준다고 하는 System.Runtime.CompilerServices.RuntimeHelpers::GetHashCode(object)를 호출하고 있습니다!


System.Runtime.CompilerServices.RuntimeHelpers.GetHashCode()는 역시 unmanaged code를 invoke하게 되어 있는 것 같습니다. 내부 구현 코드를 찾아볼 수 있으면 좋을텐데 찾기가 힘드네요;

결국 내부 코드 구현으로 봤을 때 .NET 4.0기반의 CLR에서는 Object.GethashCode()를 사용하는 것과 System.Runtime.CompilerServices.RuntimeHelpers.GetHashCode()를 사용하는 건 동일합니다.



GetHashCode()를 재정의 할 때 고려해야 할 점을 생각해 볼까요.

1. 무엇보다 잘 분포된 난수를 생성할 수 있는 그러니까 같은 Application 환경에서 유일한 값을 보장할 수 있는 알고리즘을 사용해야 합니다.
2. 정의하는 알고리즘 상에서 상위 클래스의 GetHashCode() 를 호출해서 자신의 Hashcode에 값을 반영하는 경우가 있겠지만 기본적으로 제공하는 Object의 GetHashCode()는 가능하면 사용하지 말아야 합니다. 빠른 성능을 고려해서 만든 알고리즘이 아니기 때문입니다.
3. 알고리즘은 적어도 하나의 인스턴스 필드는 이용해야 합니다. 미리 정의되어 있는 정적 값만을 이용하면 안된다는 말이겠지요.
4. 사용되는 필드는 불변의 속성을 가져야 합니다. 즉 필드값은 한번 생성되면 그 객체가 소멸될 때까지는 절대 값이 바뀌어서는 안됩니다.
5. 객체가 같은 값을 지니고 있다면 HashCode도 같은 값을 반환해야 합니다.

그리고 이 GetHashCode()를 사용할 떄의 주의점도 있습니다. 절대로 이 메소드를 통해 연산한 결과를 저장하여 사용하지 말아야 한다는 점인데 예를 들어 설명하자면 어떤 사이트에서 회원 정보를 받을 때 암호를 GetHashCode()를 이용해서 만들어진 hashcode를 DB에 저장해선 안된다는 것입니다.

지금까지 알아본것 처럼 CLR이 업데이트 되면서 내부 구현이 바뀌게 된다거나, 사용자가 직접 재정의한 GetHashCode()의 알고리즘이 변경된다면 저 DB에 저장된 hashcode는 모두 쓰레기가 되어 버리게 될 테니까요.



신고
크리에이티브 커먼즈 라이선스
Creative Commons License
TAG CLR

7. System.Object

CLR 2010.02.16 09:00 Posted by 52
오늘의 주제는 이겁니다.

CLR의 모든 타입은 System.Object로부터 파생된다.

자. 오늘의 공부 끝!


이라고 말하고 싶지만 그러면 안되겠죠;;

그럼 모든 타입의 기본인 System.Object에 대해서 좀 더 공부를 해 봐야겠습니다. System.Object는 Class입니다. Class니까 Method과 Property 들로 구성이 되어 있겠지요.

Object의 Public Method들에 대해서 알아보기로 하죠. IDE 편집창에서 Object를 하나 선언하고 Public Method들이 무엇이 있는지 살펴봅시다.

네 저렇게 4개의 Method가 존재합니다. 이 Method들은 Object의 public Method인 만큼 CLR의 모든 타입들은 저 4개의 Method를 기본적으로 갖고 있게 됩니다. 저 Method들을 알아보기 위해 우선 좀 말이 안되긴 하지만 다음과 같은 클래스들을 만들어 놓습니다.

    class Animal
    {
        Int32 Age;
        string Name;

        public Animal(string name, Int32 age)
        {
            Age = age;
            Name = name;
        }

        public Int32 GetAge()
        {
            return Age;
        }

        public string GetName()
        {
            return Name;
        }

        public virtual string Say()
        {
            return "Can't say";
        }

        public static Int32 GetLegs(Animal animal)
        {
            Int32 legs = 2;

            if (animal.GetType().ToString().Equals("Test04.Animal"))
                legs = 4;

            return legs;

        }
    }

    class Human : Animal
    {
        public Human(string name, Int32 age) : base(name, age)
        {
        }
        public override string Say()
        {
            return "Oh! Yeah!";
        }
    }


Animal 클래스가 있고 Animal에서 상속받은 Human 클래스가 있습니다. Animal의 class 선언에는 생략되어 있지만-

class Animal 은 class Animal : System.Object 와 같이 쓸 수 있습니다. 둘은 같은 의미입니다.


1. Equals

비교 하려는 객체가 같은 값을 가지고 있으면 true 아니면 false를 return 합니다. 같은 값을 가지고 있다는 말은 무슨 의미일까요? 테스트 해 봅시다. 다음과 같은 코드를 작성해 봅니다.

            Animal dog = new Animal("happy", 3);
Human korean = new Human("Park", 33);

            if (dog.Equals(korean))
                Console.WriteLine("dog == korean");
            else
                Console.WriteLine("dog != korean");

dog라는 Animal class의 객체를 선언하고 korean이라는 Human의 객체를 선언하고 이 둘을 비교합니다. 뭐가 찍힐까요? 당연히 dog != korean 이 찍힙니다.

            Animal cat = new Animal("nero", 1);

            if (dog.Equals(cat))
                Console.WriteLine("dog == cat");
            else
                Console.WriteLine("dog != cat");

자 이번엔 어떨까요? 같은 Animal 객체인 cat을 선언해 봅니다. 둘은 같다고 인정될까요? 아닙니다. 역시 dog != cat이 찍힙니다.

            Animal dog2 = new Animal("happy", 3);
            if (dog.Equals(dog2))
                Console.WriteLine("dog == dog2");
            else
                Console.WriteLine("dog != dog2");

아.. 그러면 이번엔 객체 이름은 다르지만 내부의 property값은 같은 dog2라는 객체를 선언하고 둘을 비교해 봅시다. 같다고 인정해 줄까요? 아.. 역시 다르다고 합니다. dog != dog2 라고 찍힙니다.

도대체 그럼 뭐를 어떻게 해야 같은거야? 라고 생각하면서 마지막으로 다음과 같이 테스트 해 봅시다.

            Animal dog3 = dog;

            if (dog.Equals(dog3))
                Console.WriteLine("dog == dog3");
            else
                Console.WriteLine("dog != dog3");

dog 객체를 새로 생성한 dog3에 할당합니다. 여기선 어떤 값이 찍힐까요? 아. 드디어 두 객체가 같다고 인정해 줍니다. dog == dog3 가 찍힙니다!

Object.Equals()의 같다는 의미는 좀 어렵네요. 두 객체가 포함하는 property등의 값이 같다고 equal이 아닙니다. 두 객체가 참조하는 것이(주소값 이라고 해야 할까요? C++적인 의미로 말입니다.) 이 완전히 일치해야지 equal입니다. 

음 개념적으로는 대충 이해가 되는데 좀 더 자세히 알아보고 싶어지는군요.  앞으로 자주 보게 될 ILDASM을 꺼내봐야겠습니다. ILDASM으로 지금까지 작성한 코드들이 어떻게 CLR에 들어가는지 살펴봅시다.


ILDASM을 이용하여 작성한 코드들을 MSIL코드로 볼 수 있습니다. 하나하나씩 따라가보면서 간단하게나마 분석을 해보려고 합니다. 일단 Main 앞 부분입니다. main()함수에서 사용하는 지역변수들을 초기화 하고 알아보기 쉽게 index를 붙여서 태깅해 놓고 시작하네요.

            Animal dog = new Animal("happy", 3);
            Human korean = new Human("Park", 33);

  IL_0001:  ldstr      "happy"
  IL_0006:  ldc.i4.3
  IL_0007:  newobj     instance void Test04.Animal::.ctor(string, int32)
  IL_000c:  stloc.0
  IL_000d:  ldstr      "Park"
  IL_0012:  ldc.i4.s   33
  IL_0014:  newobj     instance void Test04.Human::.ctor(string, int32)
  IL_0019:  stloc.1

1. [IL_0001] ldstr은 스트링 개체를 스택으로 PUSH합니다. "happy"가 스택에 PUSH됩니다. 
2. [IL_0006] ldc.i4.3 은 정수값 3을 역시 스택으로 PUSH합니다. 
3. [IL_0007] newobj는 받아야 할 argument들 갯수만큼 스택에서 POP 한 후 새로운 객체를 생성하고 그 객체를 스택에 PUSH하게 됩니다. 
4. [IL_000c] stloc.0 는 스택에서 값을 POP하여 지역변수 인덱스 0 에 넣습니다. 

IL_0001 부터 IL_000c까지의 내용입니다. 그대로 하면 어떻게 되나요. 위의 C#코드에서 처럼

Animal dog = new Animal("happy", 3); 

을 수행한 결과가 됩니다. 변수 dog는 지역변수 인덱스 0 으로 태깅되어 있지요. IL_000d 부터 IL_0019까지는 korean 객체를 생성하는 과정입니다. IL_0012의 ldc.i4.s 33은 정수값 33을 스택에 PUSH하라는 명령입니다.

            if (dog.Equals(korean))
                Console.WriteLine("dog == korean");
            else
                Console.WriteLine("dog != korean");

  IL_001a:  ldloc.0
  IL_001b:  ldloc.1
  IL_001c:  callvirt   instance bool [mscorlib]System.Object::Equals(object)
  IL_0021:  ldc.i4.0
  IL_0022:  ceq
  IL_0024:  stloc.s    CS$4$0000
  IL_0026:  ldloc.s    CS$4$0000
  IL_0028:  brtrue.s   IL_0037
  IL_002a:  ldstr      "dog == korean"
  IL_002f:  call       void [mscorlib]System.Console::WriteLine(string)
  IL_0034:  nop
  IL_0035:  br.s       IL_0042
  IL_0037:  ldstr      "dog != korean"
  IL_003c:  call       void [mscorlib]System.Console::WriteLine(string)
  IL_0041:  nop

자 다음은 두 객체를 비교하는 부분입니다. 

1. [IL_001a] ldloc.0 은 0번 지역변수의 값을 스택에 PUSH합니다. 
2. [IL_001b] ldloc.1 은 1번 지역변수의 값을 스택에 PUSH하겠지요.
3. [IL_001c] callvirt 는 런타임에 바인딩된 method를 호출합니다. (call뒤에 virt가 붙은 건 호출 할 method가 virtual로 선언되어 있다는 걸 의미합니다. 실제로 Object.Equals()는 'public virtual bool Equals(object obj);' 로 선언되어 있습니다.) 호출하기 전 method와 관련된 객체와 해당 method의 인수와 관련된 값을 스택에서 POP합니다. 그리고 해당 method의 결과값이 있으면 스택에 PUSH하게 됩니다. 여기서는 equals의 값을 스택에 PUSH하게 되겠네요.
4. [IL_0021] ldc.i4.0 는 정수값 0을 스택에 PUSH하게 됩니다.
5. [IL_0022] ceq 는 비교 명령입니다. 비교에 사용될 값 value0과 value1을 스택에서 POP합니다. 여기서는 4번에서 넣었던 정수값 0과 3번 equals의 결과값이 각각 value0과 value1에 들어가게 되겠지요. 그리고 두 값을 비교해서 같으면 1이 스택으로 PUSH되며 틀리면 0이 스택으로 PUSH됩니다.
6. [IL_0024] stloc.s    CS$4$0000 스택에서 값을 꺼내어 CS$4$0000 이라는 지역변수에 넣습니다. 맨 위에서 보면 알다시피 CS$4$0000은 bool값을 가진 지역변수인데 우리가 직접 선언한 변수는 아니지요. if문에서 비교를 해서 나온 bool값을 저장하기 위해 CLR이 생성한 임시 지역 변수입니다. 결국 ceq로 비교된 값이 CS$40000 이라는 변수에 들어가게 됩니다.
7. [IL_0026] ldloc.s    CS$4$0000 은 지역변수 CS$4$0000의 값을 스택에 PUSH합니다. 아 이거 왜 뺐다가 다시 넣는거야.
8. [IL_0028] brtrue.s  IL_0037 는 스택에서 값을 하나 POP한다음에 이 값이 true거나 null이 아니거나 0이 아닌경우 IL_0037로 점프하게 됩니다. 결국 bool 형식의 CS$4$0000 값이 true면 IL_0037로 점프를 하게 되겠지요. 다시 정리하면 5번에서의 ceq의 값이 같으면 IL_0037로 점프를 하게 되는 것입니다. 또 거슬러가면 ceq의 값이 같기 위해서는 3번의 결과 값이 0이 되어야 하는데 3번의 결과 값이 0이라는 얘기는 equals()의 결과값이 0 그러니까 false라는 이야기죠. 결국 dog != cat 이면 IL_0037로 점프하는겁니다.
9. [IL_002a] ~ [IL_002f] 스택에 스트링값(dog == korean)을 넣고 Console.WriteLine()을 호출합니다.
10. [IL_0034] nop 아무일도 하지 않습니다.
11. [IL_0035] br.s       IL_0042 는 어떠한 조건에 상관없이 IL_0042로 점프하게 됩니다. [IL_0042]는 if문이 모두 끝난 다음의 명령문이 있는 주소입니다.
12. [IL_0037] ~ [IL_003C] 는 dog != korean 을 찍겠지요.

와 길고 복잡합니다. 첨부된 소스를 컴파일 하고 컴파일 된 실행 파일을 ILDASM으로 보면 계속 뒤의 코드를 볼 수 있는데 쭉- false를 리턴했던 dog2까지의 비교는 위와 동일한 패턴의 코드로 진행됩니다. 무엇보다 주시해야 될 부분은 cat이나 dog2의 객체는 쭉- newobj로 새로 생성한다는 점입니다.

            Animal dog3 = dog;

if (dog.Equals(dog3))
                Console.WriteLine("dog == dog3");
            else
                Console.WriteLine("dog != dog3");

  IL_00aa:  ldloc.0
  IL_00ab:  stloc.s    dog3
  IL_00ad:  ldloc.0
  IL_00ae:  ldloc.s    dog3
  IL_00b0:  callvirt   instance bool [mscorlib]System.Object::Equals(object)

이제 true를 반환했던 dog3입니다. IL코드를 읽어보면 알겠지만 dog3의 값은 지역변수 인덱스 0인 dog의 값(주소)를 가져와서 dog3 지역변수에 그대로 넣습니다. 이건 뭘 의미하는건가요?

Animal dog3 = dog;

를 수행한다는 것은 dog3라는 새로운 객체 공간을 생성해서 dog의 값을 복사해 오는 것이 아니라 dog라는 객체가 가리키는 값(주소)를 그대로 dog3와 연결 시킨다는 의미입니다. 결국 dog와 dog3가 가리키는 값(주소)는 같은 값(주소)입니다. equals()는 그래서 같다. 라고 결과를 반환했던 것입니다. equals()가 하는 일은 정말 간단하네요. 내용이고 자시고 간에 그냥 값이 같으면 true입니다. 

간단한 내용을 정말 길게 돌아서 확인했네요.

휴-

Object는 다음에 계속 하기로 하지요. 오늘은 이만!!

참고 소스 : 

신고
크리에이티브 커먼즈 라이선스
Creative Commons License

'CLR' 카테고리의 다른 글

닷넷4.0에서 네이티브코드와 매나지드코드의 동거 part 1.  (2) 2010.08.02
8. System.Object (2)  (0) 2010.03.03
7. System.Object  (0) 2010.02.16
6. Assembly - GAC(Global Assembly Cache)  (2) 2010.02.02
5. Assembly - Strongly named assemblies  (0) 2010.01.26
4. Assembly  (2) 2010.01.15
TAG CLR

5. Assembly - Strongly named assemblies

CLR 2010.01.26 09:00 Posted by 52
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.
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

'CLR' 카테고리의 다른 글

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

3. MSCorLib & Metadata

CLR 2010.01.06 09:00 Posted by 52
어서 빨리 System.Object로 시작해서 CLR을 배우고 싶지만 .NET Framework 환경의 CLR의 기반에 대해 좀 더 자세히 짚고 넘어가야 할 것 같습니다. 그래서 이번엔 이 부분에 대해서 정리를 하면서 공부를 해보려고 합니다.

MSCorLib.dll

public sealed class Program
{
  public static void Main()
  {
    System.Console.WriteLine("Hi");
   }
}

이런 코드를 하나 만들어 봅시다. C# 코드입니다. 우리는 CLR을 공부하려고 하는 것이지 C#을 공부하려는 건 아니지만 앞으로 C#을 이용하여 많은 코드를 작성할 예정입니다. 암튼 빌드 해봐야겠죠. 워워- VS 2010 IDE 아직 띄우지 마세요. 훌륭한 개발툴 깔아놓고서도 쓰지 않는게 억울하긴 하지만 지난번과 같이 Visual Studio Command Prompt를 실행해서 빌드를 해 봅시다.

csc.exe /out:hi.exe /t:exe /r:MSCorLib.dll hi.cs


.exe의 실행파일이 생성되고 실행 해 보면 Hi 라고 문자열을 출력합니다.

csc는 C#컴파일러 입니다. 인자를 살펴보면 /out 은 생성될 실행파일명을 지정하는 것이고 /t는 Target의 약자로 exe로 지정되었다는 것은 Win32 어플리케이션을 생성하겠다는 의미입니다. 그리고 /r은 Reference의 약자인데 코드에서 사용된 외부에서 정의된 타입의 참조를 어떤 모듈을 이용하여 해결하겠다는 의미입니다. 마지막으로 hi.cs는 컴파일할 소스 파일이지요.

여기서 우리가 자세히 살펴봐야 할 부분은 /r의 인자인 MSCorLib.dll 입니다.

우선 소스를 다시 한번 살펴 봅시다. 소스에서는 System.Console.WriteLine이라는 메서드를 사용하고 있습니다. 여기서 System.Console 이라는 타입은 C# 컴파일러에서는 정의되어 있는 타입이 아니기 때문에 위에서 보면 MSCorLib.dll이라는 어셈블리 모듈을 참조하여 컴파일을 하고 있습니다.

MSCorLib.dll은 특별한 파일로서 모든 기본 타입을 제공하고 있습니다. Byte, Char등의 타입부터 그 외에 기본적으로 사용하는 많은 타입들을 포함한 어셈블리입니다. 그야말로 핵심 모듈이지요. 그렇기 때문에 C#등의 컴파일러에서는 /r의 인자로 MSCorLib.dll 만큼은 생략해도 기본적으로 이 모듈은 참조하여 컴파일을 하게 됩니다.
결국

csc.exe /out:hi.exe /t:exe hi.cs

라고 해도 정상적으로 컴파일은 된다는 말이지요. /out 옵션과 /t옵션의 기본값도 원래는 소스파일명(확장자 제외한).exe 이고 /t도 기본이 exe이므로 본래는

csc.exe hi.cs

라고 해도 컴파일은 문제없이 잘 됩니다. csc 컴파일러의 인자 중에서는 기본 라이브러리 모듈은 MSCorLib.dll을 참조하지 말라고 지시하는 인자가 있는데 바로 /nostdlib 입니다.

만약에 hi.cs 를 /nostdlib 인자를 주어서 컴파일을 하면 어떻게 될까요.


당연히 컴파일이 실패합니다. 'System.Object' 타입을 찾을 수 없다고 하면서 말이지요. System.Object는 모든 타입의 기본입니다. 모든 타입은 System.Object로부터 파생이 됩니다. 기본 라이브러리 모듈을 참조하지 않았으니 모든 타입의 기본이 되는 System.Object 타입을 찾지 못하는 건 당연한 결과지요. 다시 말하지만 MSCorLib.dll 은 .NET Framework의 핵심 모듈입니다.

Metadata

자 우리는 hi.exe 라는 작은 프로그램을 생성하였습니다. 이제 이 생성된 파일을 좀 까봐야겠습니다. 지난번에 실행파일은 IL코드와 메타데이터가 포함되어 있다고 배웠습니다. 좀 더 정확히 말하자면 PE32(또는 PE32+)헤더와 CLR헤더 IL코드 그리고 메타데이터가 포함되어 있습니다. 한번 살펴봐야죠.

.NET에서 생성하는 PE32 포맷의 실행파일은 기존의 PE32 형식의 실행 파일과 거의 동일합니다. 거기에 .NET Metadata 관련 섹션 정보가 추가되어 있는 형식입니다.

PE Format


생성된 파일의 Metadata 정보를 확인하기 전에 Metadata의 구조는 어떤식으로 되어 있는지 확인해 봐야겠습니다. Metadata의 구조는 Microsoft SDK에 포함되어 있는 CorHdr.h 라는 헤더 파일에 IMAGE_COR20_HEADER 라는 구조체로 정의가 되어 있습니다.

typedef struct IMAGE_COR20_HEADER
{
    // Header versioning
    DWORD                   cb;             
    WORD                    MajorRuntimeVersion;
    WORD                    MinorRuntimeVersion;
   
    // Symbol table and startup information
    IMAGE_DATA_DIRECTORY    MetaData;       
    DWORD                   Flags;          
 
 // The main program if it is an EXE (not used if a DLL?)
    // If COMIMAGE_FLAGS_NATIVE_ENTRYPOINT is not set, EntryPointToken represents a managed entrypoint.
 // If COMIMAGE_FLAGS_NATIVE_ENTRYPOINT is set, EntryPointRVA represents an RVA to a native entrypoint
 // (depricated for DLLs, use modules constructors intead).
    union {
        DWORD               EntryPointToken;
        DWORD               EntryPointRVA;
    };
   
    // This is the blob of managed resources. Fetched using code:AssemblyNative.GetResource and
    // code:PEFile.GetResource and accessible from managed code from
 // System.Assembly.GetManifestResourceStream.  The meta data has a table that maps names to offsets into
 // this blob, so logically the blob is a set of resources.
    IMAGE_DATA_DIRECTORY    Resources;
 // IL assemblies can be signed with a public-private key to validate who created it.  The signature goes
 // here if this feature is used.
    IMAGE_DATA_DIRECTORY    StrongNameSignature;
    IMAGE_DATA_DIRECTORY    CodeManagerTable;   // Depricated, not used
 // Used for manged codee that has unmaanaged code inside it (or exports methods as unmanaged entry points)
    IMAGE_DATA_DIRECTORY    VTableFixups;
    IMAGE_DATA_DIRECTORY    ExportAddressTableJumps;
 // null for ordinary IL images.  NGEN images it points at a code:CORCOMPILE_HEADER structure
    IMAGE_DATA_DIRECTORY    ManagedNativeHeader;
   
} IMAGE_COR20_HEADER, *PIMAGE_COR20_HEADER;


좀 보기 힘들긴 하지만 위에서부터 하나하나 확인해보죠. 우리가 위에서 생성한 hi.exe 파일을 대상으로 확인하려고 합니다. 직접 헤더를 분석하는 툴을 만들어도 좋겠지만(^-^;;) CFF Explorer 라는 툴을 이용하여 헤더를 확인해 보기로 합니다.


CFF Explorer로 확인해 보면 .NET Directory 섹션부터 위의 헤더 정보와 동일한 이름의 정보들이 순차적으로 기록되어 있는 것을 확인할 수 있습니다. 굉장히 많은 정보 중에서 우리가 짚고 넘어가야 할 정보들은 메타데이터 정의 테이블과 메타데이터 참조 테이블입니다.

Corhdr.h 파일에서 메타 데이터 정의 테이블과 참조 테이블 리스트들의 이름들을 확인해 볼 수 있습니다.   

// Token  definitions

typedef mdToken mdModule;               // Module token (roughly, a scope)
typedef mdToken mdTypeRef;              // TypeRef reference (this or other scope)
typedef mdToken mdTypeDef;              // TypeDef in this scope
typedef mdToken mdFieldDef;             // Field in this scope
typedef mdToken mdMethodDef;            // Method in this scope
typedef mdToken mdParamDef;             // param token
typedef mdToken mdInterfaceImpl;        // interface implementation token

typedef mdToken mdMemberRef;            // MemberRef (this or other scope)
typedef mdToken mdCustomAttribute;      // attribute token
typedef mdToken mdPermission;           // DeclSecurity

typedef mdToken mdSignature;            // Signature object
typedef mdToken mdEvent;                // event token
typedef mdToken mdProperty;             // property token

typedef mdToken mdModuleRef;            // Module reference (for the imported modules)

여기서 확인해 봐야 할 테이블들은 다음과 같습니다.

메타 데이터 정의 테이블 리스트
 메타 데이터 정의 테이블 이름 설명 
 ModuleDef 모듈을 식별하기 위한 항목
 TypeDef 모듈 내의 정의된 각 타입을 위한 항목
 ModuleDef 모듈 내에 정의된 각 메서드를 위한 항목
 FieldDef 모듈 내에 정의된 모든 필드를 위한 항목
 ParamDef 모듈 내에 정의된 각 파라미터를 위한 항목  
 PropertyDef 모듈 내에 정의된 각 속성을 위한 항목 
 EventDef 모듈 내에 정의된 각 이벤트를 위한 항목 

메타 데이터 참조 테이블 리스트
 메타 데이터 참조 테이블 이름 설명
 AssemblyRef 모듈이 참조하는 각 어셈블리를 위한 항목 
 ModuleRef 모듈이 참조하는 타입을 구현하는 각 PE 모듈을 위한 항목 
 TypeRef 모듈이 참조하는 각 타입을 위한 항목 
 MemberRef 모듈이 참조하는 각 멤버(필드 메서드 속성 이벤트 등)를 위한 항목 

위의 두 테이블을 참조하여 파일의 메타 데이터 항목들을 살펴 봅니다.

ModuleDef
모듈의 이름 버전 ID (GUID의 형태로 생성됩니다.) 등이 기록되어 있는 것을 확인 할 수 있습니다.

TypeRef
4개의 타입 참조가 보입니다. 그 중 Console Type에 대한 정보를 살펴봅시다. 타입의 이름(Name)과 이 타입이 어디에 있는지(Namespace)에 대한 정보를 포함하고 있네요.

TypeDef
모듈 내에 정의된 각 타입을 위한 항목을 포함한다고 했습니다. 각 엔트리는 타입의 이름(Name), 상위 타입(Namespace), 플래그(TypeDef Flags)등을 갖고 있습니다. Extends에 TypeRef Table Index 1이라고 되어 있네요. TypeRef의 1번째 인덱스는 위의 화면에서 보면 알겠지만 Object입니다. Object 클래스로부터 상속되어 확장되었다는 걸 알 수 있겠네요.

Method
위의 테이블에선 없던 항목이지만 Method라는 항목도 보이네요. 보시면 알겠지만 hi.exe 내의 메서드 정보를 포함하고 있습니다.  .ctor은 뭔가요? 생성자입니다. .ctor이 호출되어야지 해당 객체가 메모리에서 생성된 위치를 가리키는 포인터 this라는 값을 갖게 됩니다.

MemberRef
모듈이 참조하는 각 멤버들의 참조 정보를 갖고 있네요. 3번째는 WriteLine입니다. Class정보를 보면 TypeRef Table Index 4 라고 되어 있네요. 위에서 확인해 보면 System.Console을 가리키는 것임을 알 수 있습니다. 다른 멤버들 역시 TypeRef의 다른 멤버들을 가리키고 있습니다.

그리고 밑에 보이는 CustomAttribute는 나중에 Attribute를 공부할 때 다시 한번 언급해 보기로 하구요. Assembly는 다음에 공부해야 할 Assembly에서 다시 한번 보면 될 것 같네요.

대략이나마 Metadata 정보를 확인해 보니까 정말 다양한 정보들이 체계적으로 기록되어 있다는 것을 확인해 볼 수 있었습니다.

생각보다 진도가 늦어지고 있네요. 그래도 이왕 공부하는 것 아주 완벽히는 아니더라도 이렇게 하나하나씩 살펴봐야지 공부하면 공부할수록 좀 더 깊이있는 이해가 필요한 부분에서 도움이 될 것이라고 생각합니다.

이 글을 보시는 분들 시간을 내서 직접 맨 위의 코드를 컴파일 해보시고 이런저런 메타데이터 정보를 한번 확인해 보세요~ CFF Explorer 라는 툴도 있지만 기본적로 지원하는 IL 역어셈블러 툴인 ILDasm.exe를 이용하셔도 위에서 언급한 메타데이터 정보들을 확인할 수 있습니다.



메타데이터 정보가 보이지요?


함수의 IL코드도 확인할 수 있습니다.

위에서 언급한 .ctor 코드도 볼 수 있습니다. System.Object의 생성자를 부르고 있네요. 이외에도 다양한 정보들을 확인해 볼 수 있으니까 꼭 한번씩 살펴보세요. :)


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



신고
크리에이티브 커먼즈 라이선스
Creative Commons License

'CLR' 카테고리의 다른 글

6. Assembly - GAC(Global Assembly Cache)  (2) 2010.02.02
5. Assembly - Strongly named assemblies  (0) 2010.01.26
4. Assembly  (2) 2010.01.15
3. MSCorLib & Metadata  (4) 2010.01.06
2. CLR! CLR! CLR!  (3) 2009.12.30
1. Hello 世界  (0) 2009.12.23
TAG CLR


 

티스토리 툴바