출처: http://sjc333.egloos.com/3131382



c++ dll (/clr) 을 c#에서 dllimport 하고 디버그(debug) 하기

제목이 좀 어렵네요.
그냥 이쪽 전공에서나 필요한 지식이고, 귀찮으니 최대한 요점만 짧게 로그 남기듯이 적습니다.
보통은 이런 뻔한 시나리오는 안적는데 vs2013의 황당한 버그 비슷한 것이 저를 괴롭혀서 2시간 가량 낭비하는 바람에 
저와 같은 피해자(?)가 없도록 글을 남기는 것입니다. ㅎㅎ


1. C++ dll을 만든다. 이때 clr 옵션을 건다. 자세한건 구글링...
  한줄만 더 적자면 CLR은 managed가 아니다.

2. C# 어플리케이션을 만들고 1에서 만든 dll을 .cs 소스코드 안에서 직접 import. 하고 작동되는지 확인한다.
  ex ) [DllImport("../bin/test.dll")]

이 글을 보는 사람이라면 사실 1과 2는 이미 되어있는 상태일 것이라고 가정함.

3. 이제 셋팅 들어간다. 위의 1, 2는 하나의 솔루션에 있어야 한다.
  - 가장 중요한 것!! tools > options >  debugging > general > 마지막줄의 use managed compatibility mode 체크.
  - 솔루션에 속성 설정 > common properties > project dependencies >  여기서 c# 프로젝트는 c++ dll 프로젝트에 의존한다고 체크
  - c#프로젝트에 속성 설정 > debug > Enable Debuggers > Enable native code debugging 체크!!!
  - c#프로젝트를 set as startup project

4. 이제 준비는 끝났으니 c++ 코드에 브레이크 포인트 걸고 F5



3번에 중요하다고 한 부분이 내가 고생한 부분이다. 인터넷에서 c++ dll을 c#에서 로드하는 상황에서 디버깅하는 방법을 검색해봤는데 저 말을 찾을 수 없었다. 어딘가 누군가는 적어놨겠지만...아무튼 저 부분이 매우 중요하다.

만약에 use managed com... 이 것을 체크하지 않은 상태라면 이상한 현상이 발생한다.
 - enable native code... 이 옵션을 체크하면 c++에 브레이크 포인트가 작동하지 않는다.
 - enable native code... 이 옵션을 해제하면 c++에 브레이크 포인트가 작동은 하지만 변수값을 제대로 볼 수 없다.

그런데 인터넷에서 흔히 찾을 수 있는 글들에는 오히려 enable native code... 를 해제하면 브레이크 포인트를 쓸 수 없다는 식으로 설명하기 때문에 굉장히 혼란스럽다.
아마도 vs2013의 사소한 버그인듯...

다행인 것은 c#에서 c++ dll을 로드한 상태로 디버깅을 시도하면 use managed com... 이 옵션을 켜야한다고 메세지가 뜬다.
문제는 이 메세지가 제법 길기 때문에 실수로 확인버튼 눌러서 닫으면 옵션이 어디에 있는지 찾기 힘들다는 것.
나는 대충 읽고 옵션을 찾으려고 했는데 tools에서 안찾고 c#프로젝트에서 찾아 들어가는 바람에 ....그 때 부터 대혼란이 시작되었다 orz





Posted by 세모아
,


출처: http://blog.daum.net/silnoontee/13743552



*** 출처: 마이크로소프트웨어

*** 링크: 효과적인 C#메모리 기법

조명근 narlamy@ndoors.net|엔도어즈 기술 지원팀 팀장으로 근무하고 있으며, MMORPG ‘아틀란티카’를 개발했다. 덴마크에 있는 유니티 개발팀과 긴밀히 협조해 메모리 문제 등 여러 가지 이슈들을 처리하고 있으며 현재 유니티 3D엔진을 사용해 웹과 모바일 플랫폼을 지원하는 MMORPG ‘삼국지를 품다’를 개발하고 있다.

C#은 상당히 좋은 언어다. 가장 많이 알려진 C#의 특징 중 하나는 메모리 관리에 부담이 없다는 점이다.

So Cool~ C# 메모리
C/C++를 사용하면서 포인터 때문에 괴로워 해본 적이 있는가? 그렇다면 C#에 관심을 가져보는 것이 좋다. C#은 다음과 같은 특징들을 제공하기 때문이다.

- 메모리 해제에 신경 쓰지 않아도 된다.
- 이미 삭제된 메모리에 접근하는 실수를 방지해준다.
- 잘못된 캐스팅으로 엉뚱한 메모리에 접근하지 않게 한다.
- 배열 크기보다 큰 메모리에 접근하지 못한다.
- 메모리 단편화에 대해 신경 쓰지 않아도 된다.

편한 C#, 마구잡이로 사용하면 낭패
골치 아픈 메모리 관리를 신경 쓰지 않아도 된다는 점은 사용자들에게 무척 편리하게 다가온다. 하지만 C#에서도 메모리를 다루기 위해서는 세심한 주의가 필요하다. 마음 놓고 개발하다 당황했던 과거 필자의 경험을 살펴보도록 하자. 

개 발 초창기, 게임 플레이 중에 주기적으로 랙이 발생했다. 로직을 확인해 봤지만 특별히 로딩 중이거나 초기화된 부분이 없어 의아했다. 유니티 엔진에서 제공하는 프로파일러로 한 프레임에 걸리는 시간을 측정해봤다. 측정 결과, System.GC.Collect() 호출에 오랜 시간이 걸린다는 점이 발견됐다. 플레이 중에 프레임마다 소모되는 시간을 그래프로 보여주는 <그림 1>을 보면 System.GC.Collect() 호출 시 그래프가 크게 튀어 오른 모습이 확인된다. C#에서 사용하지 않는 메모리를 정리하면서 가비지 컬렉션(Garbage collection) 랙이 발생한 것이다.

 


<그림 1> 프로파일러 이미지

이때는 가비지 컬렉션이 동작하는 횟수를 줄여서 랙 발생을 줄이면 된다. 가비지 발생을 줄이면 가비지 컬렉션이 호출되는 시간을 늦출 수 있어 동작 횟수가 줄어든다. 가비지란 프로그램이 실행되면서 어디에서든 더 이상 참조되지 않는 메모리를 의미하므로 가능한 한 메모리를 할당했다 금방 버려지는 상황을 만들지 않는 것이 좋다. 몇 가지 사례들을 살펴보자.

‘+’ operator를 통한 문자열 조합 
C#은 문자열 조합이 쉽다. <리스트 1>에 보이는 것처럼 ‘+’로 연결하면 간단히 문자열 조합이 이뤄진다. 모든 객체가 ToString()을 지원하기 때문에 문자열끼리만 조합되는 게 아니라 int, float 등의 값도 알아서 문자열로 변환·조합된다.

<리스트 1> ‘+’로 연결한 문자열 조합

class Names
{
    public string[] name = new string[100];
    public void Print()
    {
        for (int index = 0; index < name.Length; index++)
        {
            string output = "[" + index + "]" + name;
            Console.WriteLine(output);
        }
    }
}

문제는 <리스트 1>에서 가비지가 많이 발생한다는 점이다. ‘+’ 연산자로 두 값을 연결할 때마다 새로운 string 인스턴스가 생성된다. 연이어 ‘+’ 연산자가 나오기 때문에 다시금 새로운 string 인스턴스가 생성되고, 이전에 만들어진 string 인스턴스는 가비지가 된다. string 조합을 위해 ‘+’ operator 호출이 많아질수록 많은 가비지가 만들어지는 것이다.

그래서 문자열을 조합하는 동안 새로운 객체를 생성하지 않는 System.Text.StringBuilder 객체를 소개한다. ‘+’ operator가 아닌 Append() 메소드를 통해 문자열을 추가하며, string 객체를 만들어내는 게 아니라 이미 잡아놓은 메모리 공간에 문자열만 복사해 뒀다가 한번에 ToString()으로 string 객체를 생성해낸다.

<리스트 2> System.Text.StringBuilder 객체 사용

class NewNames
{
    public string[] name = new string[100];
    private StringBuilder sb = new StringBuilder();

    public void Print()
    {
        sb.Clear();     // sb.Length = 0;
        for (int index = 0; index < name.Length; index++)
        {
            sb.Append("[");
            sb.Append(index);
            sb.Append("] ");
            sb.Append(name);
            sb.AppendLine();
        }
        Console.WriteLine(sb.ToString());
    }
}

과다한 Append() 메소드 호출이 필요해 ‘+’ 코드보다 깔끔하지 못하다고 생각된다면 AppendFormat()을 사용하는 것도 좋다.

 <리스트 3> AppendFormat() 활용

class NewNames
{
    public string[] name = new string[100];
    private StringBuilder sb = new StringBuilder();

    public void Print()
    {
        sb.Clear();     // sb.Length = 0;
        for (int index = 0; index < name.Length; index++)
        {
            sb.AppendFormat("[{0}] {1}", index, name.ToString());
        }
        Console.WriteLine(sb.ToString());
    }
}

string처럼 Immutable pattern을 사용한 객체들의 값에 접근할 때는 기존 메모리를 수정하지 않고 새로운 메모리를 만들어 반환하거나 입력받으므로 사용 시 주의가 필요하다.

메소드 안에서 생성한 객체
C#은 C++과 달리 클래스를 인스턴싱하려면 반드시 new를 해줘야 한다. 이때 heap에서 메모리 할당이 일어난다. 

<리스트 4>와 같이 메소드 안에서 new로 생성된 인스턴스는 메소드를 빠져나오면 더 이상 사용하지 않게 돼 가비지로 처리된다. 이런 패턴의 메소드가 자주 호출될수록 가비지도 많이 발생한다.

<리스트 4> new로 생성된 인스턴스

public class MyVector
{
    public float x, y;
    public MyVector(float x, float y) { this.x = x; this.y = y; }
    public double Length() { return System.Math.Sqrt(x * x + y * y); }
}

static class TestMyVector
{
    public static void PrintVectorLength(float x, float y)
    {
        MyVector v = new MyVector(x, y);
        Console.WriteLine("Vector=({0},{1}), lenght={2}", x, y, v.Length());
    }
}

Vector 클래스를 구조체로 바꿔보면, new 연산자로 인스턴스를 만들어도 heap 영역에 메모리가 할당되지 않는다. 구조체 역시 Value type이기 때문에 stack 영역에 메모리가 할당되며, 메소드를 빠져나갈 경우 자동으로 삭제된다. 물론 heap 영역에 생성된 메모리가 아니기 때문에 가비지 컬렉션의 대상이 되지도 않는다. 

<리스트 5> Vector 클래스를 구조체로 변환

public struct MyVector
{
    public float x, y;
    public MyVector(float x, float y) { this.x = x; this.y = y; }
    public double Length() { return System.Math.Sqrt(x * x + y * y); }
}

static class TestMyVector
{
    public static void PrintVectorLength(float x, float y)
    {
        MyVector v = new MyVector(x, y);
        Console.WriteLine("Vector=({0},{1}), lenght={2}", x, y, v.Length());
    }
}

구조체로 바꿀 수 없다면, <리스트 6>처럼 멤버변수 사용을 권장한다.

<리스트 6> 멤버변수 사용

public class MyVector
{
    public float x, y;
    public MyVector() { x = .0f; y = .0f; }
    public MyVector(float x, float y) { this.x = x; this.y = y; }
    public double Length() { return System.Math.Sqrt(x * x + y * y); }
}

static class TestMyVector
{
    private static MyVector m_cachedVector = new MyVector();
    public static void PrintVectorLength(float x, float y)
    {
        m_cachedVector.x = x;
        m_cachedVector.y = y;

        Console.WriteLine("Vector=({0},{1}), lenght={2}",
x, y, m_cachedVector.Length());
    }
}

속도 저하가 큰 Boxing
Boxing이란 Value type 객체를 Reference type 객체로 포장하는 과정을 뜻한다. C#의 모든 객체는 object로부터 상속되는데, 심지어 상속받지 못하는 int, float 등의 Value type 조차도 object로부터 상속된 것처럼 사용할 수 있다. 하지만 가비지 컬렉션에 의한 부하 못지않게 boxing으로 인한 부하도 크다. 무심코 만든 코드에서 boxing 과정이 일어나는 경우가 있으니 잘 이해하고 사용해야 한다.

<리스트 7>을 보면 리스트에 서로 다른 type의 값을 추가했지만, loop 안에서 추가 값을 object type으로 받아 하나의 코드로 처리할 수 있음을 알 수 있다.

<리스트 7> 서로 다른 type 값 추가

class MyClass
{
    public override string ToString() { return "다섯"; }

    static public void Sample()
    {
        ArrayList list = new ArrayList();
        list.Add(1);
        list.Add(1.5f);
        list.Add(‘3’);
        list.Add("four");
        list.Add(new MyClass());

        foreach (object item in list)
            Console.WriteLine(item.ToString());
    }
}

 


<그림 2> <리스트 7>의 실행 결과

매력적인 C#이지만 Value type의 값을 Reference type인 object로 바꿔주는 과정에는 많은 시간이 걸리며 변환 시에는 System.Object 내부에 랩핑하고 관리되는 heap에 저장된다. 즉 새로운 객체가 만들어지는 셈이다. MSDN에서 발췌한 <그림 3>을 참조하길 바란다.




https://msdn.microsoft.com/ko-kr/library/yz2be5wk.aspx

http://www.gamedevforever.com/322


<그림 3> boxing과 unboxing의 비교

따라서 한 번에 다양한 type을 처리하는 경우가 아니라면 collection에 사용된 값의 type을 명시해주는 Generic collection 사용을 권한다. Generic은 C++의 template와 비슷하다. 그래서 Generic collection들은 C++의 STL container들과 비슷하게 생겼다. <리스트 8>을 참고하자.

<리스트 8> Generic collection

class Example
{
    static public void BadCase()
    {
        ArrayList list = new ArrayList();
        int evenSum = 0;
        int oddSum = 0;

        for (int i = 0; i < 1000000; i++)
            list.Add(i);

        foreach (object item in list)
        {
            if (item is int)
            {
                int num = (int)item;
                if(num % 2 ==0) evenSum += num;
                else oddSum += num;
            }
        }
           
        Console.WriteLine("EvenSum={0}, OddSum={1}", evenSum, oddSum);
    }

    static public void GoodCase()
    {
        List<int> list = new List<int>();
        int evenSum = 0;
        int oddSum = 0;

        for (int i = 0; i < 1000000; i++)
            list.Add(i);

        foreach (int num in list)
        {
            if (num % 2 == 0) evenSum += num;
            else oddSum += num;
        }
           
        Console.WriteLine("EvenSum={0}, OddSum={1}", evenSum, oddSum);
    }
}

메모리가 계속 늘어나는 또 다른 문제의 발생!
이 글을 시작하며 C#에서 사용자는 메모리 해제에 신경 쓸 필요가 없다고 했지만 의도하지 않게 메모리가 늘어나기도 한다. C#에는 delete 같은 메모리 해제 명령이 없기에 메모리 릭(memory leak) 현상이 발생하면 당혹스러울 수 있다. 여기서 C# 메모리의 특징을 다시 한 번 떠올려보자.

시스템에서 더 이상 참조가 없는 메모리를 알아서 해제하는 것을 우리는 가비지 컬렉션이라 부른다. 가비지는 더 이상 참조가 없는 메모리다. C# 애플리케이션이 메모리가 해제되지 않고 계속 증가되고 있다면 어디선가 의도하지 않는 참조가 일어나고 있다고 보면 된다. 그렇다면 어디에서 의도하지 않은 참조가 일어나는 것일까? 예를 통해 확인해 보자.

 


<그림 4> #1 - 케릭터 매니저에서 케릭터를 생성한다

 


<그림 5> #2 - 누군가 디버깅을 위해 '캐릭터 위치 표시' 객체를 만들고 캐릭터 매니저에 접근해 등록된 캐릭터를 모두 참조한다

 


<그림 6> #3 - 캐릭터 매니저에서 필요없는 캐릭터를 삭제한다

 


<그림 7> #4 - 캐릭터 매니저에서 삭제됏지만 '캐릭터 위치 표시' 객체에서는 여전히 참조 중이다. 가비지가 아니기 때문에 메모리에 계속 남아있으며, 구현에 따라서는 의도하지 않게 화면에 남을 수도 있다.

WeakReference로 의도하지 않은 참조를 없애보자
System.WeakReference 는 가비지 컬렉션에 의한 객체 회수를 허용하면서 객체를 참조한다. 인스턴스를 참조하려면 Weak Reference.Target으로 접근해야 하는데 원본 인스턴스가 가비지 컬렉터에 의해 회수되면 WeakReference.Target은 null이 반환된다.

<리스트 9> WeakReference.Target

public class Sample
{
    private class Fruit
    {
        public Fruit(string name) { this.Name = name; }
        public string Name { private set; get; }
    }

    public static void TestWeakRef()
    {
        Fruit apple = new Fruit("Apple");
        Fruit orange = new Fruit("Orange");
           
        Fruit fruit1 = apple;   // strong reference
        WeakReference fruit2 = new WeakReference(orange);
        Fruit target;
           
        target = fruit2.Target as Fruit;
        Console.WriteLine(" (1) Fruit1 = \"{0}\", Fruit2 = \"{1}\"",
            fruit1.Name, target == null ? "" : target.Name);

        apple = null;
        orange = null;

        System.GC.Collect(0, GCCollectionMode.Forced);
        System.GC.WaitForFullGCComplete();

        // fruit1과 fruit2의 값을 바꾼 적은 없지만, fruit2의 결과가 달라진다.
        target = fruit2.Target as Fruit;
        Console.WriteLine(" (2) Fruit1 = \"{0}\", Fruit2 = \"{1}\"",
            fruit1==null ? "" : fruit1.Name,
            target == null ? "" : target.Name);
    }
}

<리스트 9>의 실행으로 <그림 8>을 확인할 수 있다. Fruit2가 참조하고 있던 orange 인스턴스는 가비지 컬렉터에 의해 회수돼 null이 됐다.

 


<그림 8> <리스트 9>의 실행 결과

‘캐릭터 매니저’처럼 객체의 생성·삭제를 직접 관여하는 모듈이 아닌 곳에서는 가능한 WeakRefernce를 사용하는 것이 좋다. ‘객체 위치 표시 객체’처럼 인스턴스를 참조하는 모듈에서 WeakReference를 사용하면, 의도하지 않은 참조로 메모리가 해제되지 않는 실수를 방지할 수 있다. 주의할 점은 Weak Reference.Target 값을 보관하면 안 된다는 것이다. 만약 그대로 보관하고 있으면 강한 참조(strong reference)가 일어나 이를 인식한 가비지 컬렉터는 회수를 실행하지 않게 된다.

C/C++처럼 원하는 시점에 객체를 삭제하고 싶다면
C#에서 는 할당된 메모리를 임의로 해제할 수 없다. 컬렉션에 보관된 인스턴스를 제거하거나 인스턴스를 담고 있던 변수에 null을 넣어 더 이상 참조하지 않는 방법이 있지만 실제 인스턴스가 삭제되는 시점은 가비지 컬렉션 동작 이후가 되므로, 언제가 될 지 정확히 알 수 없다. 의도한 시점에 맞춰 정확히 삭제할 수 없다는 점이 그렇게 중요하지는 않다. 하지만 캐릭터 매니저에서 캐릭터를 제거했는데도 여전히 캐릭터 인스턴스가 남아서 화면에 한동안 계속 나타나는 경우가 발생할 수 있다.

Dispose pattern 소개C#에서는 관리되지 않는 메모리(리소스)를 해제하는 용도로 System.IDisposable이라는 인터페이스를 제공한다. IDisposable 인터페이스를 상속받은 클래스라면 용도에 맞게 Dispose()를 구현해줘야 하는데 이는 FileStream 관련 객체들에서 많이 볼 수 있다.

리소스를 강제로 해제시키려면 직접 Release(), Delete(), Destroy(), Close() 등의 메소드를 만들어 사용하면 되는데 굳이 IDisposable을 사용할 필요가 있을까? 서로 다른 type의 객체여도 IDisposable 인터페이스를 상속받고 있다면, 하나의 코드로 다양한 type의 메모리를 정리할 수 있기 때문에 IDisposable을 사용할 필요가 있다. 또한 Dispose() 메소드만 보고도 “아, 이 클래스는 사용이 끝나면 Dispose()를 호출해서 메모리를 정리해야 하는구나” 라고 금방 알 수 있다.

캐릭터 객체에서 IDisposable 인터페이스를 구현해보자. 업데이트 목록에서도 제외시키고 렌더링 정보도 다 지우자. 캐릭터의 Dipsose()를 호출한 이후에 캐릭터는 어떠한 동작도 하지 못하게 된다. 물론 Dispose()를 호출한다고 캐릭터가 가비지 컬렉터에 의해 메모리 해제되는 것은 아니다.

WeakReference과 IDisosalbe의 조합원하는 시점에 메모리를 해제하려면 앞서 설명한 Weak Reference와 IDisposable을 개별적으로 사용하는 것으로는 부족하다. 둘을 함께 사용하는 것이 좋다. <리스트 10>을 보자.

<리스트 10> Disposable 인터페이스를 상속받아 구현된 캐릭터 클래스

namespace MyApp
{
    public class SampleChar : IDisposable
    {
        private IRenderObject m_Render = Renderer.CreateRenderObject();

        public void Dispose()
        {
            SampleCharManager.Remove(this);
            m_Render = null;
        }

        public bool isRemoved { get { return m_Render == null; } }

        public void Render()
        {
            if (m_Render == null) return;
            // 렌더링
        }

        public void Update() { }
    }
}

예제로 만들어 본 캐릭터 클래스는 Disposable 인터페이스를 상속받아 구현된다. Dispose 후에는 더 이상 업데이트가 되지 않도록 SampleCharManager에서 제거되며, 렌더링 객체를 null로 만들어 화면에 그려지지 않도록 했다.

IRenderObject 인터페이스는 <리스트 11>과 같이 구현된다.

<리스트 11> IRenderObject 인터페이스

namespace MyApp
{
    public interface IRenderObject
    {
        void Render();
    }

    public static class Renderer
    {
        public static IRenderObject CreateRenderObject()
{
return new DumyRenderObject(); // IRenderObject를 상속받은 더미 객체
}
    }
}

<리스트 12>의 캐릭터 매니저 클래스는 등록된 캐릭터들을 일괄적으로 업데이트시키고 렌더링한다.

<리스트 12> 등록 캐릭터 일괄 업데이트 및 렌더링

namespace MyApp 
{
    static class SampleCharManager
    {
        private static List<SampleChar> m_list = new List<SampleChar>();

        public static void Update()
        {
            foreach (SampleChar obj in m_list) 
                obj.Update();
        }

        public static void Render()
        {
            foreach (SampleChar obj in m_list)
                obj.Render();
        }

        public static void Add(SampleChar obj)
        {
            m_list.Add(obj); 
        }

        public static void Remove(SampleChar obj)
        {
            m_list.Remove(obj);
        }
    }
}

<리스트 13>의 디버깅을 위한 ‘캐릭터 위치 표시 객체’는 WeakReference를 통해 SampleChar 객체를 참조하도록 구현돼 있고, SampleCharManager에서 캐릭터를 삭제하더라도 안전하게 가비지가 회수된다. 업데이트 시 DisplayCharInfo는 삭제된 캐릭터를 스스로 판단해 목록에서 제거한다.

<리스트 13> 디버깅을 위한 캐릭터 위치 표시 객체

namespace MyDebug
{
    static class DisplayCharInfo
    {
        private static List<WeakReference> m_list = new List<WeakReference>();
        private static Queue<WeakReference> m_removeQueue =
new Queue<WeakReference>();

        public static void Update()
        {
            foreach (WeakReference item in m_list)
            {
                MyApp.SampleChar obj = (item.Target != null) ?
 item.Target as MyApp.SampleChar : null;

                if (obj == null || obj.isRemoved)
                {
                    m_removeQueue.Enqueue(item);
                }
                else 
                { 
                    /* 캐릭터 정보 표시 */ 
                }
            }

            while(m_removeQueue.Count > 0)
            {
                WeakReference item = m_removeQueue.Dequeue();
                m_list.Remove(item);
            }
        }

        public static void Add(MyApp.SampleChar obj)
        {
            m_list.Add(new WeakReference(obj));
        }
    }
}

C#에서 메모리를 관리하는 데 도움되길 바라며, 지금까지 설명한 내용을 요약하면 다음과 같다.

- string 조합이 많다면, StringBuilder 활용
- Immutable 객체의 값 접근 시 매번 메모리가 생성될 수 있으므로 주의
- 매번 호출되는 메소드 안에서 반복해서 일회성 인스턴스가 생성되지 않도록 주의
- Boxing / unboxing이 가능한 일어나지 않도록 주의
- WeakReference를 사용해서 의도하지 않은 참조 줄이기
- IDisposable 인터페이스를 사용해 사용자가 원하는 시점에 객체 삭제하기

Value type과 Reference type 비교

Value type은 stack 영역에 할당되며 값이 통째로 복사된다.

 

유니티 3D엔진에서의 메모리 관리
유니티 3D엔진으로 개발하면서 주의할 내용을 알아보자. 유니티 3D엔진은 크게 모노 메모리와 엔진에서 관리하는 메모리로 나뉜다. 둘 다 메모리가 부족하면 내부에 관리하는 heap 영역을 늘려 메모리를 할당한다. 이렇게 한 번 늘어난 heap은 줄어들지 않는 특징을 가진다. 물론 늘어난 heap 안에서 메모리가 재사용되므로, 무턱대고 늘어나진 않는다. 하지만 가비지를 너무 많이 생성시키면 GC.Collect()로 인한 성능저하와 더불어 최대 메모리가 늘어날 수도 있으니 주의해야 한다. 가능한 가비지가 덜 생성되도록 코드를 구현하는 게 좋다. 메모리는 한 번에 잡는 것이 좋고, caching이나 memory pool을 사용하는 것도 도움이 된다.

<리스트 14> Value typepublic static class Sample
{
    public static void TestValueType()
    {
        int a = 100;
        int b = a;
       
        a = 200;
        Console.WriteLine(" a={0}, b={1}", a, b);
    }
}

<리스트 14>를 실행하면 <그림 9>와 같은 결과를 확인할 수 있다. a와 b는 서로 다른 메모리 공간을 가지고 있다.

 


<그림 9> <리스트 14>의 실행 결과

Reference Type은 heap 영역에 할당되며, C/C++의 포인터나 레퍼런스처럼 new로 생성한 인스턴스를 참조한다.

<리스트 15> Reference type

public class MyInt
{
    public int Value { get; set; }
    public MyInt(int val) { this.Value = val; }

    public static void TestReferenceType()
    {
        MyInt a = new MyInt(100);
        MyInt b = a;

        a.Value = 200;
        Console.WriteLine(" a={0}, b={1}", a.Value, b.Value);
    }
}

<리스트 15>의 실행 결과로 <그림 10>을 확인할 수 있다. a와 b는 같은 메모리를 참조한다.

 


<그림 10> <리스트 15>의 실행 결과



Posted by 세모아
,

Win7 64bit에서 Windows Service를 대상으로 아래처럼 C# 코드를 사용하면,(일반 WinForm은 아래코드가 먹힘)

string fullpathFile = System.IO.Directory.GetCurrentDirectory() + "\\" + "Log\\";

결과는 C:\Windows\SysWOW64\Log  이다.

------------------------------------

Windows Service를 대상으로 아래처럼 C# 코드를 사용해야, Service의 exe파일이 있는 폴더가 제대로 나옴.

string fullpathFile = AppDomain.CurrentDomain.BaseDirectory + "\\" + "Log\\"; 

 


 

출처: http://mvcp.tistory.com/entry/C에서-실행되는-폴더-알아-내기-윈도우-서비스-테스트-프로젝트

 

 

C#에서 실행되는 폴더 알아 내기(윈도우 서비스, 테스트 프로젝트, ...)

 

참조 URL
  1. http://stackoverflow.com/questions/1658518/getting-the-absolute-path-of-the-executable-using-c

 

 

 

 

 

윈도우 서비스나 테스트 프로젝트에서 실행을 하면 내가 코딩한 DLL이 위치하는 폴더와 실제 실행되는 프로세스의 위치가 상이한 경우가 발생할 수 있다. 이럴경우 기대한 경과와 다르게 에러가 발생할 수 있다. 예로 파일을 읽어 오는 부분이나 환경설정을 읽어 오는 부분에서 경로가 맞지 않아 에러가 발생할 수 있다. 아래 코드와 같이 실행되는 프로세스나 어셈블리의 위치를 알아 내는 방법이 몇가지로 제공을 하고 있다.

 

 

var path1 = Environment.CurrentDirectory; var path2 = Directory.GetCurrentDirectory();
var path3 = new FileInfo(Assembly.GetExecutingAssembly().Location).DirectoryName; var path4 = Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().Location); var path5 = Thread.GetDomain().BaseDirectory; var path6 = AppDomain.CurrentDomain.BaseDirectory;

[코드1] 폴더 위치 가져오기


위 "코드1"에서와 같이 폴더를 알아 낼 수 있지만 path1과 path2는 실행되는 프로세스를 중심으로 폴더를 알아내고 path3 ~ path6은 어셈블리를 기준으로 폴더를 알아내는 구조로 되어 있다.

 

 

위와 같은 코드를 윈도우 서비스에서 실행하면 아래와 같은 폴더의 위치가 달라지게 된다.

 

path1 : C:\Windows\System32

path2 : C:\Windows\System32

path3 : C:\User\xxxx\Visual Studio\Project\xxxx

path4 : C:\User\xxxx\Visual Studio\Project\xxxx

path5 : C:\User\xxxx\Visual Studio\Project\xxxx

path6 : C:\User\xxxx\Visual Studio\Project\xxxx

 

 

위와 같이 값을 확인 할 수 있을 것이다.

 

필요에 따라 값을 가져오는 방법을 달리 하여 가져오면 될 것이다.

 

 

 

 

 

'Programming > C#' 카테고리의 다른 글

[펌] 효과적인 C# 메모리 관리 기법  (0) 2016.03.10
C# delegate & event 작성순서- 20150604  (0) 2015.10.21
[펌] [STAThread]  (0) 2015.09.02
Posted by 세모아
,




Posted by 세모아
,

[펌] [STAThread]

Programming/C# 2015. 9. 2. 10:43

출처: http://grandmaster.tistory.com/9



자주 보이지만 무슨일을 하는지 모르고 항상 궁금하다고 생각됬던 [STAThread]

오늘은 찾아보았다..이놈의 귀차니즘..

네이버 지식in의 답변부터 듣도록 해보자

[System.STAThread]
[STAThread]

최초 어플리케이션 스레드 모델을 단일 스레드 어파트먼트로 지정하는 것을 의미한다.



아직까지는 먼소린지 모르겠다...

그래서 데브피아에 물어봤다.

Q. 

 [STAThread]

 

라는걸 찾아보다 보니

 

C# 코드에서 [STAThread] 가 의미하는 바는 : 
기본적으로, VS .NET에 의해 만들어진 응용 프로그램의 Main()메소드에는 [STAThread] 어트리뷰트가 첨가되어 있다. 
이 어트리뷰트는 해당 응용 프로그램이 COM형식을 이용하는 경우에 (단지 이 경우에만 해당하는 것인데) 해당 응용 프로그램이 
단일 스레드 아파트(single threaded apartment, STA) 모델로 설정되어야 한다는 것을 런타임에게 알려주는 역할을 한다. 
해당 응용 프로그램에서 COM 형식을 이용하지 않는다면, [STAThread] 어트리뷰트는 무시되기 때문에 삭제해도 무방하다

<출처 : 서비의 다락방 ( http://www.yunsobi.com )>

 
라고하는데요 com형식이 무엇인지 잘모르겠네요 검색해도 너무많은 결과가 나와서 어떤건지 잘모르겠구요.

 

도대체 com형식이 무엇인지  [STAThread] 가 왜필요한지 조금 쉽게 설명해주실분 계신가요?


A.


우선 com 형식이란 com 객체를 말합니다. 그리고 .net은 기본적으로 MTA(멀티쓰레드아파트먼트)로 동작됩니다. 그런데 전통적으로 com 객체는STAThread 기반이어서 이를 명시해줘야 합니다. 만약 명시하지 않고 단일쓰레드아파트먼트 기반인 com 객체를 사용시엔 런타임때 오류가 발생합니다. 이를 직접 눈으로 확인해보시려면 간단하게 form위에 웹브라우져 컨트롤을 올리고 [STAThread] 애트리뷰트를 주석처리하고 실행해보세요.




글쎄..........com객체라는걸 알아야 알수 있을꺼 같다...

그래서 com객체를 조사해보았다.

com 은요 Component Object Model 의 약자이지만 일반적으로 컴포넌트라고 발음합니다. 정확한 해석은 아니지만 줄여서 부르는 셈이지요. 

기존의 프로그램을 살펴보면 여러가지 문제점이 있었지요. 그 많은 문제점중 하나가 예를 들어 dll 의 이름 문제점을 들수 있는데요. 많이 보셨을 겁니다. ****.dll 이라고 하는 파일을요. 이는 메인 프로그램에서 다 처리하지 못하거나 특정한 모듈을 따로 처리하기 위해 만든 일종의 메인에 딸린 하부적인 실행파일이라고 볼수 있는데(일단은 dll 도 실행파일입니다. 자체 실행파일은 아닙니다만...) 이는 dll 의 이름을 가지고 접근하고 있습니다. 하지만 소프트 웨어를 만드는 회사가 많은만큼 같은 dll의 이름을 가진 실행파일들이 많아지고, 또 그것을 인스톨 하면서 윈도우 폴더에 복사하면 문제가 생기지요. 전혀 다른 회사에서 개발한 dll 이 이름만 같고 전혀 다른 기능을 하는데도 이를 모르고 덮어 쓰기 해버리면... 

이를 해소하기 위한 하나의 방법이 컴포넌트 입니다. 사용해 보셨는지는 모르지만 컴포넌트는 GUID 라는 128비트의 일종의 아이디 비슷한게 있습니다. 이걸로 접근하므로 이름의 문제로 인한 충돌이 일어나지 않는 것입니다.

여기까지는 com 을 사용하는 목적중의 하나만 예를 든것이고 com 을 한마디로 정의하자면 객체 지향적 모듈개발이라고 정의하고 싶네요. 아니 이건 제가 개인적으로 내린 정의입니다. 제가 느낀 바로는요...^^ 다른 분들은 어떻게 생각하실지 모르겠습니다. 

어떤 프로그램을 짤때, 예를 들어 메신져를 생각해 보겠습니다. 메신져를 짜려면 접속자 파악, 파일전송, 메시지 보내기 등의 작업들이 있습니다. 그런데 이경우 com 을 사용하지 않고 짜려면 한사람이 설계한 프로그램에 다른 사람들이 달라붙어서 거기에 맞춰가면서 프로그래밍 할 수 밖에 없습니다. 상당히 비효율적이고 또 그렇게 프로그래밍한 소스는 그 메신져에서 밖에 쓸수가 없죠. 하지만 컴포넌트화 해버리면... 쉽게 말해서 모듈별로 따로 만들어 버리면, 넌 메시지 보내는 루틴을 만들어, 난 파일 전송하는 루틴을 만들게 그리고 만들때는 com 으로 만들자. 라고 하면 쉽게 끝나는 거죠. 조립만 하면 되기 때문이죠. 

여기까지 말씀을 드리면 그렇다면 com 은 일정한 형식을 가지고 있어야 한다. 왜냐하면 조립을 하려면 표준형식이 있어야 하기 때문이다. 라고 생각하시는 분이 계실지 모릅니다. 네 맞습니다. 일정한 형식을 맞춰서 프로그램을 짜야 합니다. 그래서 com 을 하시는분들 보면 머리붙잡고 쥐어 뜯습니다.(으아..미쵸미쵸 하면서요...^^ 저도 그런 기억이 있죠) com 의 표준형식을 공부하는게 쉬운게 아니거든요. 그리고 객체지향적 설계가 필요합니다. 그래서 com 에 관해서는 바이블도 따로 나와 있습니다. 공부하시려면 com 은 바이블을 꼭 사셔야 합니다. 아니 꼭은 아니더라도 사시는게 좋습니다. 인터넷으로 공부하려고 하시면... 한계가 보일겁니다.

이외에 책에 적어진 com 의 장점을 적어보겠습니다. 이하는 책에 적혀있는 내용입니다.

1. 이식성이 강하다 : 새로운 프로그램에 대한 강력한 이식성은 개발기간을 단축시킨다.
2. 유연성이 있다 : 컴으로 작업한 소프트웨어를 업그레이드 하고자 할 경우 단순히 업그레이드된 컴포턴트만 복사하면 되고 업그레이드 되지 않은 컴포넌트를 사용하지 않은 경우에도 잘 수행된다.
3. 재 컴파일할 필요가 없다. 
4. 객체지향 개발 방법론(com) 은 프로그램의 구현방법을 획기적으로 바꾸었다. 
5. com 의 경우 플랫폼에 독립적이다. 

출처 : 네이버



어느정도 이해는 됬지만 깊숙하게 알기위해서는 좀더 내공을 길러야 할듯하다.



결론 : 지우면 혼난다.


Posted by 세모아
,

출처: http://agebreak.blog.me/60059787064



관리 코드와 네이티브 코드의 상호 운용성을 위한 최상의 방법
Jesse Kaplan
어떻게 보면 2009년 초반에 이런 칼럼이 MSDN Magazine에 등장하는 것이 이상하게 느껴질 수도 있습니다. 관리 코드와 네이티브 코드의 상호 운용성은 그 정도의 차이는 있을지 모르지만 2002년 버전 1.0부터 Microsoft .NET Framework에서 꾸준히 지원되어 왔기 때문입니다. 또한 API 및 도구 수준의 자세한 지원 문서도 수천 페이지는 찾을 수 있습니다. 그럼에도 불구하고 어떠한 경우에 interop을 사용하고 아키텍처와 관련하여 어떤 점을 고려하고 어떤 interop 기술을 사용해야 하는지를 설명하는 전반적이고 포괄적인 아키텍처 지침은 찾기 어렵습니다. 이 칼럼은 이러한 틈을 메우기 위한 것입니다.


관리되는 네이티브 Interop의 적합한 용도
관리되는 네이티브 interop을 어떤 경우에 사용해야 하는지에 대해서는 자료가 별로 없고 그나마 있는 자료들도 서로 내용이 상이합니다. 게다가 실제 검증 없이 지침을 작성된 지침도 있습니다. 본론을 시작하기 전에 이 칼럼의 모든 내용은 interop 팀이 다양한 규모의 내부 및 외부 고객을 지원하는 과정에서 실제 경험을 바탕으로 작성되었음을 밝힙니다.
이러한 경험을 취합하면서 interop의 성공적인 사용 사례이자 interop의 사용 유형을 잘 보여주는 세 가지 제품을 예로 들었습니다. Visual Studio Tools for Office는 Office용 관리되는 확장 가능 도구 집합으로, interop하면 가장 먼저 떠오르는 응용 프로그램입니다. 이 응용 프로그램은 관리되는 확장 또는 추가 기능 구현이 가능한 대규모 네이티브 응용 프로그램이라는 interop의 일반적인 사용 방식을 보여 줍니다. 다음으로 관리되는 응용 프로그램과 네이티브 응용 프로그램의 혼합형으로 완전히 새롭게 개발된 Windows Media Center를 들 수 있습니다. Windows Media Center는 주로 관리되는 코드를 사용하여 개발되었고 일부분(TV 튜너 및 기타 하드웨어 드라이버와 직접 작동하는 부분)만 네이티브 코드를 기반으로 합니다. 마지막으로 기존 네이티브 코드 기반에서 새로운 관리되는 기술을 활용하여 차세대 사용자 환경을 제공하려 하는 응용 프로그램의 예로서 Expression Design이 있습니다. 여기서 새로운 관리되는 기술이란 WPF(Windows Presentation Foundation)을 말합니다.
이 세 응용 프로그램은 interop을 사용하는 가장 중요한 이유 세 가지를 보여 줍니다. 첫째는 기존 네이티브 응용 프로그램에 관리되는 확장성을 제공하는 것이고, 둘째는 대부분의 응용 프로그램이 가장 기본적인 수준의 코드는 네이티브 코드로 작성하면서 관리 코드의 이점을 활용하도록 하는 것이고, 셋째는 기존 네이티브 응용 프로그램에 차별화된 차세대 사용자 환경을 추가하는 것입니다.
예전에 제공된 지침에서는 이러한 경우에 단순히 전체 응용 프로그램을 관리 코드로 작성할 것을 권장하고 있습니다. 많은 사람들이 이러한 지침을 따르려고 했지만 그러지 못한 것만 봐도 대부분의 기존 응용 프로그램의 경우 전체 응용 프로그램을 관리 코드로 작성하는 것이 불가능함을 입증한다고 하겠습니다. interop은 개발자가 네이티브 코드에 대해 기존에 투자한 자산을 유지하면서 새로운 관리되는 환경의 이점을 활용하는 데 없어서는 안 될 기술입니다. 다른 이유로 응용 프로그램을 다시 작성할 계획이라면 관리 코드로 작성할 수도 있겠지만 일반적으로 단지 새로운 관리되는 기술을 사용하고 interop을 사용하지 않기 위해 응용 프로그램을 다시 작성하는 것은 바람직하지 않습니다.


Interop 기술: 세 가지 선택
.NET Framework에서 사용 가능한 주요 interop 기술에는 세 가지가 있으며 interop에 사용하는 API의 형식과 경계 제어의 요구 사항과 필요성에 따라 세 가지 기술 중 하나를 선택하게 됩니다. 플랫폼 호출 또는 P/Invoke는 주로 관리되는 코드에서 네이티브 코드로의 interop 기술로서 관리 코드에서 C 스타일 네이티브 API를 호출할 수 있도록 합니다. COM interop은 관리 코드에서 네이티브 COM 인터페이스를 사용하거나 관리되는 API에서 네이티브 COM 인터페이스를 내보낼 수 있도록 합니다. 마지막으로 C++/CLI(이전의 관리되는 C++)는 관리되는 C++ 컴파일 코드와 네이티브 C++ 컴파일 코드가 혼합되어 있는 어셈블리를 만들 수 있도록 해주며, 관리 코드와 네이티브 코드를 연결하는 다리 역할을 합니다.


Interop 기술: P/Invoke
P/Invoke는 세 가지 기술 중 가장 간단하며 주로 C 스타일 API에 관리 코드에 대한 액세스를 제공할 목적으로 설계되었습니다. P/Invoke를 사용하는 경우 각 API를 개별적으로 래핑해야 합니다. 따라서 래핑할 API 수가 적고 서명이 그다지 복잡하지 않은 경우에 적합합니다. 그러나 관리되지 않는 API에 동등한 관리되는 항목이 없는 인수(변수-길이 구조, void *s, 중첩되는 공용 구조체 등)가 많으면 P/Invoke를 사용하기가 어려워집니다.
.NET Framework BCL(기본 클래스 라이브러리)에 포함된 여러 가지 API 예제는 수많은 P/Invoke 선언 주위의 두꺼운 래퍼일 뿐입니다. .NET Framework의 기능 중 관리되지 않는 Windows API를 래핑하는 기능 대부분은 P/Invoke를 사용하여 작성됩니다. 사실 Windows Forms도 거의 전체가 P/Invoke를 사용하는 ComCtl32.dll을 기반으로 합니다.
P/Invoke를 훨씬 쉽게 사용할 수 있도록 하는 유용한 리소스가 몇 가지 있습니다. 첫째로, 웹 사이트 pinvoke.net에는 CLR interop 팀의 Adam Nathan이 처음 설정한 Wiki가 있는데, 이 Wiki에는 많이 사용되는 다양한 Windows API에 대해 사용자가 만든 서명이 많이 포함되어 있습니다.
Visual Studio에서 pinvoke.net을 쉽게 참조할 수 있도록 해주는 유용한 Visual Studio 추가 기능도 있습니다. 개발자의 자체 라이브러리에 있는 API든, 다른 사람이 만든 API든, pinvoke.net에서 다루지 않는 API를 위해 interop 팀에서는 P/Invoke Interop Assistant라는 P/Invoke 서명 생성 도구를 발표했습니다. 이 도구는 헤더 파일을 기준으로 네이티브 API에 대한 서명을 자동으로 생성합니다. 다음 스크린샷은 이 도구의 작동 모습을 보여 줍니다.
P/Invoke Interop Assistant에서 서명 만들기


Interop 기술: COM Interop
COM interop은 관리 코드에서 COM 인터페이스를 사용하거나 관리되는 API를 COM 인터페이스로 제공할 수 있도록 해줍니다. TlbImp 도구를 사용하면 특정 COM tlb와 통신하기 위한 관리되는 인터페이스를 제공하는 관리되는 라이브러리를 생성할 수 있습니다. TlbExp는 반대의 작업을 수행하며 관리되는 어셈블리의 ComVisible 형식에 해당하는 인터페이스를 제공하는 COM tlb를 생성합니다.
응용 프로그램 내부적으로 또는 확장 모델로서 이미 COM을 사용하는 경우에 COM interop이 적합한 솔루션이 될 수 있습니다. 또한 관리되는 코드와 네이티브 코드 간에 COM 의미 체계를 정확히 일치하도록 유지하는 가장 손쉬운 방법이기도 합니다. CLR은 기본적으로 Visual Basic 6.0과 동일한 COM 규칙을 따르기 때문에 특히 Visual Basic 6.0 기반 구성 요소와 상호 작용하는 경우에 COM interop이 적합합니다.
반면 응용 프로그램에서 내부적으로 COM을 사용하고 있지 않거나, COM 의미 체계를 완전히 동일하게 유지할 필요가 없고 성능이 응용 프로그램에 적합하지 않은 경우에는 COM interop이 적합하지 않습니다.
COM interop을 관리되는 코드와 네이티브 코드를 잇는 교량으로 사용하는 응용 프로그램의 대표적인 예로 Microsoft Office를 꼽을 수 있습니다. Office에는 확장 메커니즘으로서 COM이 오래 전부터 사용되어왔고 VBA(Visual Basic for Applications) 또는 Visual Basic 6.0에서 많이 사용되었기 때문에 COM interop을 활용하기에 더할 나위 없이 좋습니다.
원래 Office는 관리되는 개체 모델로 TlbImp와 얇은 interop 어셈블리를 전적으로 사용합니다. 그러나 시간이 지나면서 VSTO(Visual Studio Tools for Office) 제품이 Visual Studio를 기반으로 하게 되고 이 칼럼에서 설명하는 여러 가지 원칙을 통합하여 보다 기능이 풍부한 개발 모델을 제공하게 되었습니다. 현재는 BCL의 많은 부분이 P/Invoke를 기반으로 한다는 사실을 잊기 쉬운 것처럼 VSTO 제품을 사용할 때 COM interop이 VSTO의 기반이 된다는 사실을 잊는 경우가 많습니다.


Interop 기술: C++/CLI
네이티브 환경과 관리되는 환경 사이의 교량 역할을 하도록 설계된 C++/CLI는 관리 C++ 코드와 네이티브 C++ 코드를 같은 어셈블리는 물론 같은 클래스에도 컴파일할 수 있도록 하고 어셈블리의 두 부분 간에 표준 C++ 호출을 만듭니다. C++/CLI을 사용하는 경우 어셈블리에서 관리되는 환경으로 구현할 부분과 네이티브 환경으로 구현할 부분을 선택하게 됩니다. 그 결과로 MSIL(모든 관리되는 어셈블리에 포함된 Microsoft Intermediate Language)과 네이티브 어셈블리 코드가 혼합된 어셈블리가 생성됩니다. C++/CLI는 interop 경계를 거의 완벽하게 제어할 수 있는 매우 강력한 interop 기술이지만 경계에 대해 개발자의 제어권을 지나치게 강요한다는 단점이 있습니다.
C++/CLI는 정적 형식 검사가 필요하고 성능이 엄격하게 요구되고 종료를 예측할 수 있어야 하는 경우에 교량 역할로서 적합합니다. 요구 사항에만 맞다면 일반적으로 P/Invoke 또는 COM interop을 사용하는 편이 간단합니다. 특히 C++에 익숙하지 않은 개발자에게는 더욱 편리합니다.
C++/CLI를 고려할 때는 몇 가지에 유의해야 합니다. 먼저 C++/CLI를 사용하여 처리 속도가 빠른 버전의 COM interop을 제공하려는 경우 COM interop은 자동으로 처리하는 작업이 많기 때문에 C++/CLI보다 느리다는 점을 알아야 합니다. 따라서 응용 프로그램에서 COM을 한정적으로만 사용하고 충실도 높은 COM interop이 필요하지 않다면 문제가 되지 않습니다.
그러나 COM 사양의 많은 부분을 사용하는 경우 필요한 COM 의미 체계를 C++/CLI 솔루션에 다시 추가하려면 작업량이 많을 뿐만 아니라 COM interop이 제공하는 성능보다 향상되지도 않습니다. 몇몇 Microsoft 팀에서 이런 전철을 밟았다가 문제를 깨닫고 다시 COM interop을 사용한 사례가 있습니다.
C++/CLI 사용과 관련하여 두 번째로 중요하게 고려해야 할 사항은 C++/CLI가 관리되는 환경과 네이티브 환경을 잇는 교량의 역할만 할 뿐이며 응용 프로그램의 대부분을 작성하기 위한 기술이 아니라는 점입니다. 물론 C++/CLI로 응용 프로그램의 대부분을 작성할 수도 있지만 순수하게 C++ 또는 C#/Visual Basic 환경에서 작성할 때보다 개발자 생산성이 훨씬 떨어지고 부팅 시에 응용 프로그램 실행 속도가 현저하게 느려집니다. 따라서 C++/CLI를 사용할 때는 필요한 파일만 /clr 스위치를 사용하여 컴파일하고 순수한 관리되는 어셈블리 또는 순수한 네이티브 어셈블리의 조합을 사용하여 응용 프로그램의 핵심 기능을 작성해야 합니다.


Interop 아키텍처 고려 사항
응용 프로그램에 interop을 사용하기로 결정하고 사용할 기술도 선택했다면 솔루션을 설계할 때 API 디자인이나 interop 경계에 대한 코드를 작성하는 개발자 환경 등 상위 수준에서 고려해야 할 사항이 있습니다. 또한 네이티브-관리 코드 전환과 이러한 전환이 응용 프로그램에 미치는 영향도 고려해야 합니다. 마지막으로 수명 관리를 고려하고 관리되는 환경의 가비지 수집 환경과 네이티브 환경의 수동/결정적 수명 관리 사이의 격차를 메울 수단이 필요한지를 결정해야 합니다.


API 디자인 및 개발자 환경
API 디자인과 관련해서는 스스로 몇 가지 질문에 대한 답을 구해야 합니다. 어떤 개발자들이 interop 계층에 대해 코드를 작성하게 되며 그러한 개발자의 환경을 개선하거나 경계 구축 비용을 최소화하기 위해 최적화해야 하는가? 이 경계에 대해 코드를 작성하는 개발자와 네이티브 코드를 작성하는 개발자가 동일한가? 아니면 회사의 다른 개발자들인가? 아니면 응용 프로그램을 확장하거나 서비스로 사용하는 타사 개발자들인가? 개발자의 숙련도는 어떤 수준인가? 네이티브 패러다임에 익숙한가 아니면 관리되는 코드를 작성하는 데만 익숙한가?
이러한 질문에 대한 답을 구하면 네이티브 코드의 매우 얇은 래퍼와 내부적으로 네이티브 코드를 사용하는 기능이 풍부한 관리되는 개체 모델 사이에서 적절한 지점을 결정하는 데 도움이 됩니다. 얇은 래퍼의 경우 모든 네이티브 패러다임이 명확히 드러나고 개발자가 네이티브 API에 대해 코드를 작성하고 있다는 사실과 경계를 확실하게 인식하게 됩니다. 반면 두꺼운 래퍼를 사용하는 경우 네이티브 코드가 기반이 된다는 사실이 드러나지 않습니다. BCL의 파일 시스템 API는 중요한 관리되는 개체 모델을 제공하는 매우 두꺼운 interop 계층의 좋은 예입니다.


성능과 Interop 경계의 위치
공연히 응용 프로그램을 최적화하느라 시간을 허비하지 않으려면 interop 성능이 문제가 되는지 여부를 확인하는 것이 중요합니다. 응용 프로그램에서 성능이 중요한 부분에 interop이 사용되기 때문에 주의를 기울여야 하는 경우가 많습니다. 그러나 사용자의 마우스 클릭 동작에 대한 응답으로 interop을 사용하고 interop 전환이 수십, 수백, 수천 번 발생하더라도 사용자에게 지연을 유발하지 않는 응용 프로그램도 많습니다. 따라서 interop 솔루션의 성능을 높이려면 interop 전환 횟수와 각 전환 시에 전달되는 데이터 양을 줄여야 합니다.
관리되는 환경과 네이티브 환경 간에 일정한 데이터 양으로 발생하는 일정 횟수의 interop 전환은 기본적으로 그에 해당하는 고정 비용을 발생시킵니다. 이 고정 비용은 선택하는 interop 기술에 따라 다르지만 해당 기술이 필요해서 선택했다면 변경할 수 없을 것입니다. 즉, 경계의 빈번한 전환을 줄이고 경계를 넘어 전달되는 데이터의 양을 줄이는 데 초점을 맞추어야 합니다.
이러한 목표를 달성하는 방법은 응용 프로그램에 크게 좌우됩니다. 그러나 많은 개발자가 성공적으로 활용한 일반적인 전략으로서 경계의 한쪽에 자주 사용되고 데이터 양이 많은 인터페이스를 정의하는 코드를 작성하여 격리된 경계를 이동하는 방법이 있습니다. 여기서 핵심은 매우 자주 사용되는 인터페이스에 대한 호출을 일괄 처리하는 추상 계층을 작성하거나 응용 프로그램 논리에서 경계를 넘어 이 API와 상호 작용해야 하는 부분을 이동하고 입력 및 결과만 경계를 넘어 전달하는 것입니다.


수명 관리
수명 관리에 있어서 관리되는 환경과 네이티브 환경의 차이점은 interop 고객에게 가장 큰 걸림돌이 되곤 합니다. .NET Framework의 가비지 수집 기반 시스템과 네이티브 환경의 수동 및 결정적 시스템 간의 근본적인 차이점은 진단하기 어려운 형태로 나타나는 경우가 많습니다.
interop 솔루션에서 가장 먼저 나타나는 문제는 관리되는 개체가 관리되는 환경에서 사용이 끝난 후에도 네이티브 리소스를 오랫동안 보유하게 되는 문제입니다. 이는 네이티브 리소스가 매우 부족하여 호출자가 사용이 끝나는 즉시 해제해야 하는 경우에 문제가 됩니다. 대표적인 예로 데이터베이스 연결을 들 수 있습니다.
이러한 리소스가 부족하지 않다면 가비지 수집기가 개체의 종료자를 호출하여 종료자가 암시적으로 또는 명시적으로 네이티브 리소스를 해제하도록 하면 됩니다. 반면 리소스가 부족한 경우에는 관리되는 dispose 패턴이 매우 유용할 수 있습니다. 네이티브 개체를 관리되는 코드에 직접적으로 노출하는 대신 네이티브 개체 주위에 최소한 얇은 래퍼라도 만들어 IDisposable을 구현하고 표준 dispose 패턴을 따르도록 해야 합니다. 이렇게 하면 리소스 고갈이 문제가 될 경우에 관리되는 코드에서 이러한 개체를 명시적으로 정리하고 사용이 끝나는 즉시 리소스를 해제할 수 있습니다.
응용 프로그램에 많이 영향을 미치는 두 번째 수명 관리 문제는 개발자가 까다로운 가비지 수집 문제로 오해하는 경우가 많습니다. 즉, 메모리 사용량이 계속 증가하지만 어떤 이유에서인지 가비지 수집기의 실행 빈도가 낮고 개체가 활성화된 상태로 유지되는 것입니다. GC.Collect에 대한 호출이 계속 추가되어 문제가 더욱 심각해지기도 합니다.
일반적으로 이러한 문제의 근본 원인은 크기가 매우 작은 관리되는 개체가 매우 큰 네이티브 데이터 구조를 계속 사용하면서 활성화된 상태로 유지되기 때문입니다. 그 결과로 가비지 수집기가 불필요하거나 효과가 없는 수집 작업에 시간을 낭비하지 않기 위해 자체 튜닝됩니다. 또한 가비지 수집을 추가로 실행할지 여부를 결정할 때 프로세스의 현재 메모리 사용량은 물론 각각의 가비지 수집으로 확보되는 메모리 양까지 확인합니다.
하지만 이러한 상황에서 가비지 수집기가 실행되면 확보되는 관리되는 메모리 양만 인식하므로 각각의 수집으로 확보되는 메모리 양이 적다고 판단하고 그러한 작은 개체를 정리함으로써 전반적인 메모리 부족 상황을 크게 개선할 수 있다는 사실은 인식하지 못합니다. 때문에 메모리 사용량은 계속 증가하지만 가비지 수집 실행 빈도는 점점 더 낮아지는 현상이 나타납니다.
이 문제는 이러한 작은 관리되는 래퍼에 따른 실질적인 네이티브 리소스 비용에 대한 힌트를 가비지 수집기에 제공함으로써 해결할 수 있습니다. .NET Framework 2.0에는 이러한 용도로 사용되는 API가 한쌍 추가되었습니다. 명시적으로 리소스를 해제하는 대신 dispose 패턴을 추가하는 데 사용하는 것과 동일한 형식의 래퍼를 부족한 리소스에 사용하여 가비지 수집기에 힌트를 제공하는 데 재활용할 수 있습니다.
이 개체의 생성자에서 GC.AddMemoryPressure 메서드를 호출하여 네이티브 개체의 네이티브 메모리에서 소모되는 대략적인 비용을 전달합니다. 그런 다음 개체의 종료자 메서드에서 GC.RemoveMemoryPressure를 호출하면 됩니다. 이 두 호출은 가비지 수집기가 이러한 개체의 실제 비용과 해당 개체를 해제했을 때 확보되는 실제 메모리를 인식하는 데 도움을 줍니다. 이 경우 Add/RemoveMemoryPressure에 대한 호출의 균형을 완벽하게 유지하는 것이 중요합니다.
관리되는 환경과 네이티브 환경의 수명 관리에 있어서 나타나는 세 번째 차이점은 개별 리소스나 개체의 관리보다 전체 어셈블리 또는 라이브러리와 관련이 있습니다. 네이티브 라이브러리는 응용 프로그램에서 사용을 마쳤을 때 쉽게 언로드할 수 있지만 관리되는 라이브러리는 자동으로 언로드되지 않습니다. 대신 CLR에는 개별적으로 언로드할 수 있고 언로드 시에 실행 중인 모든 어셈블리, 개체 및 스레드를 정리하는 AppDomains라는 격리 단위가 있습니다. 네이티브 응용 프로그램을 작성하는 개발자가 사용이 끝난 추가 기능을 언로드하는 데 익숙한 경우 관리되는 추가 기능마다 AppDomains를 사용하면 개별 네이티브 라이브러리를 언로드할 때와 동일한 유연성을 얻을 수 있습니다.


질문이나 의견이 있으면 clrinout@microsoft.com으로 보내시기 바랍니다.


Jesse Kaplan은 현재 Microsoft CLR 팀에서 프로그램 관리자로서 관리되는 환경/네이티브 환경의 상호 운용성을 담당하고 있으며 이전에는 호환성과 확장성을 담당하기도 했습니다.


Posted by 세모아
,


Posted by 세모아
,