Unavailable

http://msdn.microsoft.com/en-us/library/ms953320.aspx

Introduction

Visual Studio 2005에서 새로 추가된 ClickOnce라고 불리는 새로운 윈도우 폼 배포 방식이 있다. 이 방식은 어플리케이션의 설치와 웹 어플리케이션의 업그레이드를 스마트 클라이언트로 가능케 해주는 좋은 친구다. 이 글은 윈도우 폼의 장점과 ClickOnce라고 불리는 녀석에 대해서 자세하고 세세하게 살펴볼 예정이란다.

왜 윈도우 폼인가?

여기서 말하는 윈도우 폼이라 함은 .NET 을 기반으로 작성된 윈도우 폼 어플리케이션을 말한다. 뭐 대표적인 예로는 C#으로 작성된 윈폼이 있겠네. 웹 어플리케이션이 등장한 후로 사람들이 이 웹 어플리케이션에 지대한 관심을 보이는데 그 이유는 단지 '쿨'하다는 이유 말고도 다음과 같은 장점들이 있다.

• 웹 어플리케이션은 세계 어디서나 언제든지 인터넷 커넥션만 있으면 접근 가능, 또한 실행 가능하다. 심지어는 클라이언트가 윈도우를 운영체제로 사용하지 않아도 상관이 없다. 유비쿼터스 환경을 추구하는 어플리케이션이라면 웹 어플리케이션이 짱!
• 웹 어플리케이션은 배포와 업뎃이 쉽다. 걍 설치 파일을 서버에 업로드만 해놓으면 사용자들이 설치하면 끄읏! DLL 걱정도 없고 레지스트리 걱정도 없고 COM 클래스 등록 걱정조차도 없다. 걍 돌아간다... 이것이야 말로 프로그래머의 퐌타지!

• 우선 유저 인터페이스가 구리다. 웹 어플리케이션은 일반적인 윈도우즈 어플리케이션이 가지는 드래그 드롭이나 우클릭등 이런게 아예 불가능하거나 지원이 매우 매우 힘들다. 
• 비록 위의 단점을 해결하기 위해 쿨해보이는 유저 인터페이스나 각종 기능을 추가한다고 하더라도 해당 스크립트를 작성하는 게 절라게 어렵다. 이유는 설명안했지만, 아마도 다양한 클라이언트의 경우를 고려하려면 수 많은 경우를 고려해야 겠지?
• 아시다시피 서버를 사용하는 중앙 집중형 방식이므로 사용자에게 기다릴 줄아는 참을성을 요구한다. 난 힘들겠는데...
• 화면에 출력하는 프린팅이 오직 화면 출력만으로 제한된다. 
• 플러그 인이나 ActiveX 컨트로 때문에 위에서 나열한 문제들이 종합되어 나타난다. 뭐, 그렇지만 이 문제점은 웹 어플리케이션이 아니더라도 나타는 문제점이래요. 이놈의 액티브엑스는 내논 자식이구만.

<a href="MainProject.exe">Call MainProject</a>

• 닷넷 프레임워크가 반드시 클라이언트 (사용자) 컴퓨터에 설치되어 있어야 한다. 
• 내가 만든 어플리케이션은 클라이언트 입장에서 봤을 때 '부분적으로 신뢰'된다. 이걸 좋게 보려면 참 장점인게 클라이언트의 컴퓨터에 최대한 접근을 적게하려 하므로 클라이언트 입장에서는 더욱 안전하다. 다만, 프로그래머 입장에서 좀더 심층적인 작업, 예를 들자면 파일을 열고 쓰고 닫고 COM 오브젝트를 불러다 쓰고 싶다면 반드시 클라이언트의 보안 규정에 따라야 하므로 좀 귀찮은 과정이 추가된다.
• 기본적으로 어플리케이션은 몇몇 DLL을 필요로 하게 마련이고 이것을 로드해야 하는데 느린 인터넷 속도와 현재의 설계방식 때문에 좀 느릴수 있다는 점. 
• 업데이트 자체가 파일 단위 업뎃이라서 어플리케이션이 반만 업데이트 될수도 있다. 헐퀴... 이거 무서운데?
• 오프라인 모드도 있다는데 이것이 인터넷 익스플로러에만 있고 어플리케이션 자체에는 없다?
• 기본적으로 어플리케이션의 속성을 조절하기 위한 .config 파일이 없다. 하지만 할 수 있는 방법이 있어. 근데 링크가 죽었네? ㅋㅋ 
• 오, 프로그램 시작메뉴나 데스크 탑에 단축 아이콘 생성이 안돼! 헐 이거 대박 단점인데? 

• 이것은 로컬 어플리케이션으로 작동한다. 즉, 퍼포먼스 페널티가 없다. 왜냐면 하드 드라이브에서 실행하는 것과 같으므로.
• 업뎃의 Atomic operation을 보장한다. 즉, 업뎃 하면 100% 업뎃 한다. 중간에 끊기 없기
• 어플리케이션이 manifest 파일을 가진다. (명세서)
• 100% Trusted 모드로 실행된다. 즉, 보안 규약이고 나발이고 걍 내 맘대로 할 수 있다.
• 시작메뉴에 단축 아이콘 생성된다! 

• 이걸 쓰려고 하면 어플리케이션의 대대적인 수정이 불가피하다.
• 옛날 버전 윈도우에서는 안된다. 98, ME에서 작동 안되고 2000이상되어야 한다. 98/ME 아직도 쓰는 사람 있나? 손들어보자...
• 100% 트러스트 모드로 작동하므로 난장판 만들 확률 또한 존재한다.
• 마이크로 소프트에의해 지원 받지 못한다. 헐? 이건 뭔 소리야... 마이크로소프트에서 만들었다면서?

• 업뎃의 Atomic Operation 100% 보장 (중간에 끊기 없음)
• 오프라인모드 지원할 뿐만아니라 어느정도 수준으로 할 건지도 조절가능. 심지어 어플리케이션이 온라인인지 오프라인인지 알아내는 API도 제공됨
• Visual Studio와 연동도 뛰어나 어플리케이션이 요구하는 보안 수준도 설정가능하다
• Bootstraper와 함께 오기때문에 필요한 컴포넌트를 쉽게 다운 받을 수 있다. 심지어는 닷넷 프레이워크 자체를 다운받는 것도 가능하다. 즉, 백지상태의 클라이언트에서도 인터넷만 연결되어 있다면 필요한 모든 것을 다 받아 설치할 수 있다는 말.
• 시작메뉴에 단축 아이콘 생성 가능!

1. Visual Studio 시작 
2. 새 프로젝트 생성
3. 간단한 C# 윈폼 프로젝트 선택
4. 이름 맘대로 정하고 생성
5. 간단한 버튼 추가해 주고
6. 버튼에 간단한 코드 MessageBox.Show() 같은거 넣어주기

어쩌다 보니 Arduino를 사용하게 되었는데 이 조그마한 기판을 사용하는 목적은 입력으로 들어오는 5 V / 60 Hz의 신호를 원하는 시간만큼 딜레이를 줘서 고대로 내보내거나 혹은 주파수를 원하는 형태 즉, 30 Hz, 20 Hz, 15 Hz로 변환 하는 것이었다.

처음 생각은 간단하겠는데 였는데 생각보다 쉽지 않았다. 제일 먼저 시도한 것이 analogRead() 함수 였는데 이것의 문제점은 기본적으로 이 함수는 최대한 빨리 입력으로 들어오는 신호를 읽어 들인다는 것이다. 다시 말해서 모든 입력 트리거를 캐치하지 못할 수도 있다는 것.

왜냐면 입력으로 들어오는 트리거 신호는 60 Hz 이므로 16.6ms 마다 5 V에서 0 V로 떨어졌다 바로 다시 5 V로 바뀌는 구조 인데 여기서 0 V로 유지되는 시간이 무지 무지 짧다는 점. 그렇기 때문에 analogRead() 함수가 아니라 attachInterrupt() 함수를 이용해야 한다. 

http://arduino.cc/en/Reference/attachInterrupt 를 참고하면 어떻게 attachInterrupt() 함수를 사용하는지 알수 있다. 기본적으로 디지털 핀 2번으로 입력을 넣고 코드에서 attachInterrupt() 함수를 해당 핀에 연결시키면 트리거가 들어올때 마다 100% 확률로 연결되어진 콜백함수를 호출한다. 고로 신호를 읽을 걱정은 안해도 된다.

다만 그 다음 스텝인 신호 지연을 어떻게 하느냐는 것이었는데, 이것은 micros() 함수를 사용해서 트리거가 들어오는 시점(0 V로 떨어지는 순간)의 시간을 기억해 둔 다음 지연시키고자 하는 만큼의 시간을 더해서 기억해 둔 다음 현재의 시간이 기억해둔 시점보다 크거나 기억해둔 시점 더하기 1 ms 의 시간보다 적으면 (그 범위에 있다면), 그 시간동안 0 V를 출력 핀으로 전송한다. 그 외의 시간에는 계속해서 5 V를 출력 핀으로 전송한다. 물론 원한다면 1 ms이아니라 더 정교한 시간 조절도 가능하다. 하지만 반드시 어느 정도의 시간동안은 0 V를 유지해야 하는데 왜냐면 너무 짧게 0 V를 유지하면 오실로스코프에도 잡히지 않을 정도로 빠르게 통과해 버린다.

추가적으로 60 Hz 속도의 주파수를 30, 20, 15 Hz로 변경하는 방법은 몫과 나눗셈 그리고 나머지를 이용한 방법이다. attachInterrupt() 함수를 CHANGE 플래그와 함께 사용하면 입력 신호가 상태 변화를 일으키는 모든 경우에 콜백 함수를 호출한다. 즉, 하나의 트리거에 대해서 낮은 볼트에서 높은 볼트, 그리고 높은 볼트에서 낮은 볼트로 두 번 변화를 일으키므로 두 번의 콜백 함수가 호출된다.

고로 나눗셈을 이용한 주파수 변환시에 이것을 고려해서 60 Hz에서는 2로 나누고 30 Hz에서는 4로 20 Hz에서는 6 그리고 15 Hz에서는 8로 나누면 된다. 콜백함수가 매번 호출될 때 마다 카운터를 하나씩 올려서 정해진 몫으로 나누면 남은 나머지가 바로 언제 0 V가 되어야 하는지를 알려준다. 원한다면 쉬프팅도 가능하다.

또 가장 주의 해야 할 점이 Arduino와 같은 계판 기기는 주로 오랜 시간 작동하므로 항상 변수의 범주에 대해서 깊이 생각해봐야 했다. 단순히 int로 선언한 카운터가 시간이 지나 한참 지나 결국 오버플로우가 되면 0으로 초기화 되면서 알수 없는 에러가 터지기 때문에 내가 작성한 코드에서는 적당한 시점에서 카운터를 0으로 초기화 시켜서 오버플로우가 발생하지 않도록 했다.

다만, micros() 함수가 메뉴얼에 보면 56분 정도 후에 리셋된다고(오버플로우로 인한) 해 놨는데 이것이 어떠한 영향을 미칠지에 대해서 검증이 좀 필요한 것 같다. 

추가로 시리얼 포트를 통한 통신으로 C# GUI와 연동하면 사용자의 어여쁜 GUI와 강력크한 Arduino의 능력을 섞어서 쓸수 있다. 아마도 더 좋은 방법이 많이 있겠지만...

// vcmcppv2_impl_dllimp.cpp
// compile with: /clr:pure user32.lib
using namespace System::Runtime::InteropServices;

// Implicit DLLImport specifying calling convention
extern "C" int __stdcall MessageBeep(int);

// explicit DLLImport needed here to use P/Invoke marshalling because
// System::String ^ is not the type of the first parameter to printf
[DllImport("msvcrt.dll", EntryPoint = "printf", CallingConvention = CallingConvention::Cdecl,  CharSet = CharSet::Ansi)]
// or just
// [DllImport("msvcrt.dll")]
int printf(System::String ^, ...); 

int main() {
   // (string literals are System::String by default)
   printf("Begin beep\n");
   MessageBeep(100000);
   printf("Done\n");
}

Begin beep
Done

위의 코드를 보면 PInvoke에 대한 경우들을 잘 설명하고 있는데 우선 첫번째가 Implicit DLLImport이다. Native로 작성된 DLL 어디엔가 __stdcall 호출 규약을 가지는 함수 MessageBeep(int) 가 정의되어 있다고 알려주는 한 줄의 코드로써 상황 종료다. 

다만 이런 암묵적인 PInvoke를 사용하기 위해서는 반드시 호출 함수의 입력 변수가 마샬링이 필요 없어야 한다. MessageBeep() 함수의 경우 int를 받기 때문에 Int32로 마샬링 없이 변환이 가능하므로 암묵적 PInvoke 사용이 가능하다.

두번째를 보게 되면 명시적인 DLLImport인데 이 명시적인 것도 두가지 방법이 있네. 첫번째는 보아하니 msvcrt.dll에서 printf 함수를 어떤 형태의 호출 규약으로 그리고 어떤 형태의 타입 (ANSI냐 Unicode냐)까지 명확하게 정의하는 것과 혹은 걍 간단하게 어떤 DLL을 가져와라라고 말하는 방법이다. 둘다 된다면 당연히 두번째 방법이 더 쉬지 않나? 

어쨌든 첫번째 방법은 단순한 함수 선언이고 두번째 방법은 DllImport 속성을 이용한 명시적 DLL 파일 이름을 지정하는 것. 그것이 가장 큰 차이점이고 두번째 방법 내부에서 또 추가적으로 더 명시할 수 있는 방법도 있다는 말. 

http://msdn.microsoft.com/en-us/library/2x8kf7zx.aspx

.NET Framework는 Platform Invoke (줄여서 PInvoke)라고 불리는 Managed Application에서 Unmanaged 함수를 호출할 수 있도록 해주는 기능을 Dllimport 속성을 이용해서 지원한다. 이 PInvoke는 두 가지 형태가 있는데 첫번째는 Explicit (명시적) 호출 방법이고 두 번째는 Implicit (암묵적) 호출 방법이다. 오늘 알아볼 녀석은 Explicit (명시적) 호출 방법이다.

DllImportAttribute를 사용해서 PInvoke를 수행하는데 이 녀석은 각각의 DLL 진입점에서 함수 선언 직전에 위치함으로 여기서 부터는 이 Unmanaged DLL을 사용하겠다고 명시하는 것이다. 

Unmanaged DLL 함수는 Managed 코드로 융합되기 위해서 몇가지 추가 코드와 간단한 데이터 변환을 추가로 가지게 되면 이를 통해서 Managed 코드는 Unmanaged DLL의 함수로 접근이 가능하다. PInvoke는 /clr, /clr:pure, /clr:safe 세 종류의 스위치에 대해서 모두 사용 가능하다. 소 파워풀!

위의 그림을 보면 PInvoke에 대한 설명이 잘 나와 있는 것 같다. Managed코드가 컴파일러를 통과해서 CLR 서포트를 받는 어셈블리로 생성이 되면 메타 데이터와 IL (MSIL) 코드를 가지게 된다. 그리고 이런 Managed 코드 내부에서 만약 PInvoke가 호출되게 되면 Standard Marshalling Service를 통해 중간 과정에 필요한 변환을 거쳐서 Unmanaged DLL 함수를 호출하게 된다. 

이 PInvoke는 사실 CLR (Common Language Runtime)이 제공하는 서비스이다. 이 서비스를 통해서 Managed Code가 Unmanaged DLL 함수를 호출 할 수 있도록 해준다. 이러한 형태의 Marshalling, 마셜링 (컨테이너를 수송하기 위해 부두 내에서 이동, 정렬 하여 잠시 대기한다는 의미의 전문 용어) 서비스는 이미 Runtime과 COM의 호환 작용 및 "It Just Works" (IJW)를 위해서도 이미 사용된 적 있는 메커니즘이다. 

마셜링에 대해서 좀 더 자세히 살펴 보고 싶지만 일단 넘어가고, PInvoke를 실제적으로 어떻게 사용하는지 살펴보자.

다음의 코드는 PInvoke를 사용하는 예를 보여주는데 puts라고 불리는 native function은 msvcrt.dll에 정의되어 있다. 즉, puts가 바로 Unmanaged function이고 우리는 그것을 managed code에서 불러다가 사용하려고 하는 것이다. 

// platform_invocation_services.cpp
// compile with: /clr
using namespace System;
using namespace System::Runtime::InteropServices;

[DllImport("msvcrt", CharSet=CharSet::Ansi)]
extern "C" int puts(String ^);

int main() {
   String ^ pStr = "Hello World!";
   puts(pStr);
}

위의 코드를 보아하니 메인 함수 진입점 직전에 DllImport 속성을 이용해서 msvcrt DLL 파일을 연결하고있다. 그리고 바로 다음 줄에 보니 puts 함수를 외부에 존재하는 함수라고 명시적으로 알려주고 있다. 그리고 내부 코드에서 puts를 사용해서 출력을 하고 있다.

위와 같은 역활을 하는 코드를 IJW로 작성해 보면 다음과 같다.

// platform_invocation_services_2.cpp
// compile with: /clr
using namespace System;
using namespace System::Runtime::InteropServices;

#include <stdio.h>

int main() {
   String ^ pStr = "Hello World!";
   char* pChars = (char*)Marshal::StringToHGlobalAnsi(pStr).ToPointer(); 
   puts(pChars);
   
   Marshal::FreeHGlobal((IntPtr)pChars);
}

IJW를 보아하니 명시적으로 Native DLL을 임포트 하라는 DllImport 속성을 사용하지 않았지만 간단하게 puts() 함수를 선언하고 있는 stdio.h 헤더를 선언하고 메인 함수 내부에서 마샬링 서비스를 직접적으로 호출해서 라이브로 변환한 다음 사용된 힙 메모리를 직접 해제 하는 것 같다. 불행히도 MSDN에서는 자세하게 위 코드에 대해서 설명하지 않는다. 아마도 IJW에 대한 페이지를 살펴봐야 정확한 의미를 알 수 있을 것 같다.

IJW를 사용하는 장점은 몇가지가 있는데 다음과 같다. 일단, DLL을 명시적으로 DllImport 속성을 이용해 연결할 필요 없고 그냥 헤더 파일이랑 라이브러리를 임포트 하면 장땡이다. 뭐, 그닥 장점처럼 안보이긴 하는데... 어쨌든.. 

IJW 방법을 사용하면 아주 약간 더 빠르다. 왜냐면 프로그래머가 명시적으로 어떤 타입의 어떤 포인터로 접근하라고 명시적으로 알려주기 때문이다. 

마찬가지로 같은 맥락에서 퍼포먼스에 대한 그림이 쉽게 그려진다는 것이 IJW의 또 다른 장점이다. 위의 코드를 예로 보자면 Unicode에서 ANSI로 변환이 필요하다는 것과 그 과정에서 추가적인 메모리 할당과 해제가 필요함이 확연히 드러나게 된다. 사실 위 경우에는 _putws와 PtrToStringChars를 사용하는 것이 퍼포먼스 면에서는 더 유리하다. 

마지막으로 같은 데이터에 대해서 매번 마샬링을 호출하기보다는 한번 호출해서 메모리를 복사해두고 복사된 메모리를 사용하면 성능향상에 매우 도움이 된다. DllImport를 사용하면 같은 데이터라도 매번 오버헤드가 발생하는 변환을 해야 한다.

자, 이제 안 좋은 점에 대해서 알아보자. 장점에서 언급한 것들의 정 반대가 단점이다. ㅋㅋ

우선 마샬링이 아주 아주 명시적이므로 코드를 아주 정확하게 적성해야만 작동한다. DllImport를 사용하면 이러한 복잡한 과정을 생략할 수 있다. 위 두 코드를 딱 봐도 DllImport가 훠얼씬 더 간단하다. 

IJW의 마샬링은 죄다 Inline 함수다. 고로 어플리케이션의 흐름에 지장을 줄수도 있다. 

마지막으로 명시적인 마샬링은 IntPtr 타입을 리턴하므로 반드시 ToPointer 함수를 사용해야 한다. 이게 왜 단점일까 라고 잠시 생각했다. 생각해보니 이것은 데이터 타입을 void로 바꾸는 것과 같다. 고로 프로그래머가 정확한 타입을 명시해 주어야 한다. 위 코드에서처럼 (char*)타입으로 명시적으로 캐스팅 하는 과정이 추가로 필요하다는 말. 

고로 위의 이야기를 요약하자면 IJW를 사용한 것이 더 효율적이 효과적인 프로그래밍이 가능하지만 만약 내가 작성하는 코드가 가끔씩 Unmanaged API를 호출하는 정도라면 둘 중 어떤 것을 사용해도 무방하다.

그 다음으로 MSDN에서 설명하고 있는 것이 PInvoke를 Windows API와 사용하는 것인데 일단 코드를 보자.

// platform_invocation_services_4.cpp
// compile with: /clr /c
using namespace System;
using namespace System::Runtime::InteropServices;
typedef void* HWND;
[DllImport("user32", CharSet=CharSet::Ansi)]
extern "C" int MessageBox(HWND hWnd, String ^ pText, String ^ pCaption, unsigned int uType);

int main() {
   String ^ pText = "Hello World! ";
   String ^ pCaption = "PInvoke Test";
   MessageBox(0, pText, pCaption, 0);
}

사실 Managed 코드라면 얼마든지 MessageBox를 잘 불러다 사용할 수 있지만 이건 예를 들기 위해 이렇게 한거다. user32 DLL을 DllImport를 사용해 명시적으로 연결해 주고 메인 함수 내부에서 실제적으로 사용하고 있다. 아하, 두번째 인자에 대한 비밀이 풀렸다. 위의 예제들에서 보면 DllImport 속성자 다음에 오는 첫번째 인자는 DLL 파일의 이름이라는 것은 알았을테고 두번째 인자에 대해서 저건 왜 필요하지에 대해서 생각했었는데 바로 해답은 아래와 같다.

실제로 user32.dll 파일 안에는 MessageBox라는 함수는 없다. 왜냐면 user32.dll에는 MessageBoxA (ANSI 타입)과 MessageBoxW (Unicode 타입) 둘 만 존재한다. 그래서 저 CharSet = CharSet::Ansi 인자를 통해서 MessageBoxA를 사용하라고 알려주는 것이다. 재미 있는 점은 되도록이면 Unicode 버전을 쓰라는 건데 왜 위의 모든 예제 코드에서는 죄다 Ansi를 쓰는지 모르겠네. 된다는 걸 보여주기 위해서 인가? Unicode를 사용하면 오버헤드가 더 줄어든단다. 

중요한 게 한가지 나오는데 언제 PInvoke를 사용하면 안되느냐 하는 것이다.

예를 들어 다음과 같은 함수를 Unmanaged code로 작성해서 Dll로 만들었다고 치자. 

char * MakeSpecial(char * pszString);

그렇다면 이 함수를 불러다 쓰려면 다음과 같은 형태를 취해야 한다.

[DllImport("mylib")]

extern "C" String * MakeSpecial([MarshalAs(UnmanagedType::LPStr)] String ^);

이 함수 호출의 문제점은 MakeSpecial로 호출되어 리턴되어지는 메모리를 해제 할 수가 없다는 점이다. PInvoke를 통해서 리턴된 포인터는 사용자가 해제할수 없는 내부 메모리로 저장이 되기 때문이란다. 고로 이런 경우에는 반드시 IJW를 써야 한다. 

PInvoke의 한계점은 입력으로 들어오는 변수를 출력으로 리턴할 수 없다는 데 있다. 입력으로 들어가는 변수가 PInvoke에 의해서 마샬링을 거치게 되면 이 변수는 리턴될 때 메모리 커럽션 에러가 발생한다. 방금 위에서 말한 것과 거의 같은 이유인것 같다.

__declspec(dllexport)
char* fstringA(char* param) 

{
   return param;
}

또 다른 간단한 예를 보자면 아래 코드와 같은 user32.dll에 있는 CharLower이라는 함수를 호출해서 사용하는 경우인데 이 함수도 입력으로 들어오는 입력 변수의 메모리 공간을 사용해서 다시 출력으로 돌려 보내는 함수이다. 고로 이렇게 하게 되면 입력으로는 제대로 된 변수와 메모리가 들어가지만 출력으로 돌아오는 변수와 메모리는 해제되어 버린 값이 된다. 간단하게 생각하면 PInvoke를 통해서 호출된 함수는 리턴하는 즉시 해제되어 버린다고 보면 되는건가? 변수와 메모리를 유지하는 일반적인 범위에서는 일어날 수 없는 일이지만 PInvoke는 마샬링 서비스를 통과하기 때문에 잠깐 동안 함수의 범위에서 벗어났다가 들어오기 때문인가..

PInvoke를 쓰더라도 같은 형태의 데이터 타입에 대해서는 마샬링이 필요가 없는데 예를 들자면 int 타입과 Int32 타입이다. 하지만 같은 형태의 데이터 타입이 아닌 경우에는 당연히 마샬링이 필요하다. 아래 테이블을 보면 다양항 형태의 타입에 대해서 어떤 마샬링이 맵핑 되는지 보여준다. 젠장 테이블이 안맞아서 걍 링크를 건다. http://msdn.microsoft.com/en-us/library/ms235282.aspx

마샬링을 수행하는 '마샬러' (젠장, 한국어로 바꾸려니 말 참 이상해지네..)는 Unmanaged 함수로 넘어가는 변수의 주소를 자동적으로 런타임 힙 메모리 공간에 Pin (꼳아 놓는다) 시켜 놓는다. 즉, 홀딩 시킨다. 이렇게 해야 가비지 컬렉터가 이 메모리 공간을 비워버리지 않는다. 

위에서 본 예제에서 CharSet이라는 두번째 변수를 이용해서 DllImport 속성자에 명시했던 것을 기억하는가? 이것이 바로 Managed String이 어떻게 마샬링 되어야 하는 가를 알려주는 단서다. 위의 예제에서는 Native 함수가 ANSI로 되어 있다고 알려주었다. 

이러한 마샬링에 필요한 정보를 각각의 Native 함수의 입력 변수마다 정의 할 수 있다. String * 입력 변수에 대해서 마샬링 할 수 있는 것들로는: BStr, ANSIBStr, TBStr, LPStr, LPTStr. 이 있고 기본 타입은 LPStr 이다. 

아래의 예제 코드를 보면 string이 2 바이트 유니코드 char string (LPWStr)으로 마샬링 하는 것을 보여주고 있다. 출력으로 나오는 놈은 문장 전체가 아니라 Hello World!의 첫 글자만 나온다. 왜냐면 마샬링된 문자열의 두번째 바이트가 null이므로 문장 종료로 인식되기 때문이다. 고로, 어떤 마샬링을 해야하는지 알려주는 과정이 굉장히 중요하고 또한 프로그래머의 책임이 뒤따른다.

// platform_invocation_services_3.cpp
// compile with: /clr
using namespace System;
using namespace System::Runtime::InteropServices;

[DllImport("msvcrt", EntryPoint="puts")]
extern "C" int puts([MarshalAs(UnmanagedType::LPWStr)] String ^);

int main() {
   String ^ pStr = "Hello World!";
   puts(pStr);
}

PInvoke는 x86 에서 실행시 각 호출마다 약 10 에서 30 의 오버헤드가 발생한다. 그리고 추가로 마샬링을 수행함으로써 또 다른 오버헤드가 발생한다. 다만 같은 형태의 타입에 대해서는 마샬링 오버헤드가 없다. 

고로 보다 나은 퍼포먼스를 위해서는 보다 적은 PInvoke를 사용하고 동시에 많은 데이터를 마샬링 하도록 하는 것이 많은 수의 PInvoke를 사용하며 동시에 적은 데이터를 마샬링 하는 것보다 더 빠르다.

Visual C++은 .NET 프로그래밍 환경에서 세가지 다른 형태의 CLR (Common Language Runtime) 컴파일 옵션을 제공하는데 고놈들이 바로 Mixed, Pure 그리고 Verifiable이다. 

• Mixed (/clr)

이 녀석은 일반적인 기본 옵션이다. 말 그대로 섞여 있다는 말인데 무엇과 무엇이 섞여 있는냐 하면은, Managed 코드와 Unmanaged 코드가 섞여 있다는 의미다. 이 옵션을 켬으로써 Managed 코드와 Unmanaged 코드의 결혼을 성사시킨다는 말이다... 이것을 이른바 C++ Interop이라 부른다. 아마도 Interoperable의 약자가 아닐까?

• Pure (/clr:pure)

Pure 옵션의 경우는 Managed 와 Unmanaged 데이터 타입을 둘 다 가질 수 있지만 함수는 오직 Managed 형태만 소유 할 수 있다. Mixed와 마찬가지로 Pure Assembly는 P/Invoke를 통해서 Native DLL과의 Interop을 허락하지만 C++ Interop Feature는 불가하다. 잠깐만, 그러니까 이미 컴파일된 Managed 코드 DLL은 P/Invoke를 통해 함수를 호출해 사용할 수 있지만 코드 내에서 직접적으로 함수를 선언해서 호출하는 것 (다른 말로 C++ Interop)은 허락되지 않는다는 말인감? 그리고 한가지 더 중요한 점은 Pure Assembly는 Native 함수로 부터 호출가능한 함수를 Export할 수없는데 그 이유는 Pure Assembly는 __clrcall 호출 규약을 사용하기 때문이다. 

• /clr:pure 사용의 장점
• 더 나은 성능: Pure Assembly는 오직 MSIL만 포함하고 있으므로 Native Function을 내포하고 있지 않다. 고로 Managed/Unmanaged Transition이 없다. 왔다리 갔다리 안한다는 말. (다만 P/Invoke를 이용해서 호출되는 경우는 예외다. 여전히 왔다리 갔다리 한다는 말)
  
  
• AppDomain Awareness: Managed 함수들과 CLR 데이터 타입은 전부다 Application Domain에 상주하고 있으므로 이런 함수와 데이터 타입에 대한 접근성이나 안정성이 Mixed assembly 경우보다 훨씬 더 낫다는 점. 그리고 .NET 프레임워크 내에서 다른 언어와의 호환성에서도 더 유리하다는 점.
  
  
• Non-disk loading: Pure Assembly들은 메모리 상에 로딩 될 수도 있고 심지어는 스트리밍이 될 수도 있다. Mixed 경우에는 반드시 디스크 상에 물질적으로 존재해야만 한다는 조건이 따라 붙는다. 
  
  
• Reflection: Mixed 된 실행 파일은 Reflection이 허용되지 않지만 Pure의 경우에는 완전 서포트 해준다.
  
  
• Host Controllability: MSIL만 포함하고 있기 때문에 Mixed보다 예측가능하고 더 유연성 있게 코드를 작성할 수 있단다.
  
  
• /clr:pure 사용의 한계
• Pure Assembly는 Unmanaged Function으로부터 호출 되어 질 수 없다. 고로 Pure Assembly는 COM interface를 구현할 수 없고 또는 Native Callback을 드러낼 수도 없다. Pure Assembly는 __declspec(dllexport)나 .DEF 파일을 통해 함수를 Export할 수 없다. 
  
  
• ATL과 MFC 라이브러리들은 지원되지 않는다. 
  
  
• #import 지원 안됨
  
  
• 익셉션 핸들링과 얼라인먼트를 위한 플로팅 포인트 옵션 조정 불가. 고로 fpieee.h 와 같은 파일은 pure 옵션으로 컴파일 안됨
  
  
• GetLastError 함수는 pure 옵션에서 Undefined Behavior라는 에러로 처리됨. 헐퀴.

• Verifiable (/clr:safe)

Visual Studio 2010의 Setup Project로 만든 이쁜 셋업 파일을 막상 다른 컴퓨터에 설치해 보면 관리자 권한으로 실행하기가 기본 옵션이 아니다.

일반적으로 프로그램은 많은 경우에 관리자 권한을 요구하게 마련이다. 그런데 참 재미 있는 것은 Visual Studio는 이런 권한 설정을 바꾸어 주는 옵션을 제공하지 않는다. 왜? 왜 그랬을까?

아무튼, 생성된 msi 파일을 Orca로 수정해야만 생성되는 단축 아이콘에 관리자 권한이 설정이 된다. 

1. ORCA 설치 - Orca는 Windows Platform SDK에 기본으로 포함되는 옵션 프로그램이다. 아래 그림처럼 찾아가보면 Orca.msi가 있을 것이다. 이 프로그램은 기본적으로 MSI 파일을 수정하는 프로그램이다.

2. Orca 설치가 끝났다면 수정하고자 하는 MSI 파일을 Orca로 열자. 그리고 Property 옵션에가서 새로운 열을 하나 생성한다. 그 새로운 열의 이름은 바로 DISABLEADVTSHORTCUTS. 그리고 값은 1로 주자. 참고로 새로운 열을 생성하는 것은 더블클릭으로 가능하다. 아니면 우클릭! 

3. 이제 왼쪽 Tables 에서 Shortcut으로 이동해 보면 내가 만든 단축키들이 그 모습을 드러낸다. 여기서 오른쪽 화면 중간 쯤 보면 Target 이라는 행이 있는데 여기에 기본 값으로 'DefaultFeature'이라는 것이 들어가 있는데 이 것을 [TARGETDIR]\내실행파일이름.exe로 바꾼다. 그리고 세이브 때리면 이제 이 파일이 설치된 컴퓨터의 데스크탑 화면 단축 아이콘에는 관리자 권한 실행 요구 표시인 방패 문양이 뜰것이다. 

제목이 무척 도발적이다. C++/CLI 10분만에 배우기... 글 읽는데만 10분 넘게 걸리는데 어떻게 10분만에 배운다는 거냐...

참고로 출처는 http://www.codeproject.com/Articles/19354/Quick-C-CLI-Learn-C-CLI-in-less-than-10-minutes (저자: Elias Bachaalany)

기본적으로 이 글의 취지는 C++/CLI를 빠르게 시작하기 위한 글이다. 고로 독자들이 C++이랑 .NET 배경지식이 어느정도 있다고 가정하고 글을 쓴다고 한다. 글을 일기전에 자고있는 당신의 머리 세포들을 깨워줄 좋은 글도 있다고 추천해주는 저자의 센스! 

아래에 포함되는 예제를 실행하려면 다음과 같이 하면 된다.

"C:\Program Files\Microsoft Visual Studio 8\Common7\Tools\vsvars32.bat"

요로코롬 하면 저 명령 이후로는 Visual Studio 2005 x86을 이용하여 컴파일을 하게 된다.

그리고 어떤 파일을 컴파일 하고 싶다면 다음과 같이...

cl your_file.cpp /clr

뒤에 붙은 /clr 스위치가 정겨워 보인다...

So, What is C++/CLI?

이것에 대한 대답은 이미 다른 글에서 많이 했는데 일단 이 글을 쓴 저자의 말을 옮겨 보면, C++은 알다시피 C의 Superset (상위셋)이라고 할 수있다. C++은 C에 OOP (객체 지향성) 및 Template를 추가한 것이다. 그렇다면 CLI는 무엇인가?

CLI은 Common Language Infrastructure의 줄임말로 그 뜻은 다음과 같다.

It is an open specification that describes the executable code and runtime environment that allows multiple high-level languages to be used on different computer platforms without being rewritten for specific architectures.

CLI라 함은 실행 코드와 런타임 환경을 정의하는 오픈된 명세로써 많은 고레벨 언어가 운영체제가 다른 플랫폼에서 코드의 재작성 없이 사용될 수 있도록 해주는 것이란다.

Handles and Pointers

아마도 한번이라도 C++/CLI를 써 본 사람이라면 '^' 요 마크가 친숙 할 것이다. 변수 선언시에 꼭 따라 붙는 놈이다. 알다시피 C++에서는 포인터를 선언할 때 * 마크를 사용한다. C++/CLI에서는 ^를 이용해 핸들을 선언한다. 자, "*" 는 Native Pointer를 말하고 이것은 CRT 힙에 상주한다. 반면 "^"는 핸들을 선언하는 것이고 "Safe Pointer"라 불리며 Managed 힙 공간에 상주한다. 이 핸들이라고 하는 녀석은 단순히 생각해서 C++의 레퍼런스와 같은 개념이긴 하지만 C++과는 다른게 (Native 와는 다른게) 제대로 해제하지 않더라도 메모리 리크 (유출)이 발생하지 않는다. 왜냐면 가비지 컬렉터 (GC)가 알아서 메모리를 수거해주기 때문이다. 오우 나이스!

특정 클래스나 값 타입의 레퍼런스를 만들기 위해서는 gcnew라는 키워드를 사용해서 선언해야 한다. 다음과 같이..

System::Object ^x = gcnew System::Object();

nullptr이 흔히 사용하는 null의 CLI 버전이고 ^ 심볼과 함께 % 심볼도 사용된다. 

N* pn = new N; // allocate on native heap
N& rn = *pn; // bind ordinary reference to native object
R^ hr = gcnew R; // allocate on CLI heap
R% rr = *hr; // bind tracking reference to gc-lvalue

C++에서 *과 &이 한 묶음 이듯이 CLI에서는 ^이랑 %가 한 묶음이다. 

Let us get started: Hello World

자 이제 가장 단순한 프로그램 하나 만들어보자. 

#using <mscorlib.dll>

using namespace System;

int main(array<System::String ^> ^args)
{
  System::Console::WriteLine("Hello world");
  return 0;
}

다른 건 뭐 다 봐줄만 한데 main의 입력 함수로 들어오는 놈이 예사롭지 않아보인다. 하지만 C++ 코드를 떠올려보면 저것이 의미하는 것이 그렇게 복잡한 것만은 아니다. 

Classes and UDTs

Classes

클래스를 어떻게 선언하는지 일단 살펴보자. 해줘야 할 것은 단 한가지 뿐. Protection Modifier (Private / Public) 바로 다음에 ref 키워드만 붙이면 끄읏!

public ref class MyClass
{
private:
public:
  MyClass()
  {

  }
}

헐 이렇게 쉬울 수가? 이렇게 선언된 클래스를 네이티브 클래스로 생성하려면 원래 사용하던 방식 그대로 클래스를 선언하면 그만이다. 자, 이제 궁금한 것은 C++/CLI 도 파괴자를 가지고 있느냐 하는 것인데 정답은 Yes다. 하지만 컴파일러는 파괴자 호출을 IDispose 인터페이스를 투명하게 구현한 다음 Dispose() 함수로 유도하게 된다. 추가적으로 GC에 의해 호출되는 Finalizer라고 불리는 녀석이 있는데 이것은 !MyClass() 와 같이 C++ 파괴자 함수 스타일이다. 이 Finalizer에서 사용자는 파괴자가 호출되었는지 체크해봐야 한다.

#using <mscorlib.dll>

using namespace System;

public ref class MyNamesSplitterClass
{
private:
  System::String ^_FName, ^_LName;
public:
  MyNamesSplitterClass(System::String ^FullName)
  {
    int pos = FullName->IndexOf(" ");
    if (pos < 0)
      throw gcnew System::Exception("Invalid full name!");
    _FName = FullName->Substring(0, pos);
    _LName = FullName->Substring(pos+1, FullName->Length - pos -1);
  }

  void Print()
  {
    Console::WriteLine("First name: {0}\nLastName: {1}", _FName, _LName);
  }
};

int main(array<System::String ^> ^args)
{
  // local copy

  MyNamesSplitterClass s("John Doe");
  s.Print();

  // managed heap

  MyNamesSplitterClass ^ms = gcnew MyNamesSplitterClass("Managed C++");
  ms->Print();

  return 0;
}

Value types

Value type이라 함은 기본으로 제공되는 타입말고 추가로 만들어내는 타입들을 말한다. 모든 value type들은 System::ValueType으로 부터 파생된다. 이 value type들은 스택에 저장될 수 있고 = 연산자를 통해서 할당 가능하다.

public value struct MyPoint
{
  int x, y, z, time;
  MyPoint(int x, int y, int z, int t)
  {
    this->x = x;
    this->y = y;
    this->z = z;
    this->time = t;
  }
};

Enums

마찬가지로 열거형도 다음과 같이 정의 가능하다.

public enum class SomeColors { Red, Yellow, Blue};

혹은 엘리먼트의 타입을 정의할 수도 있다.

public enum class SomeColors: char { Red, Yellow, Blue};

Arrays

배열의 선언은 사실 복잡해 보이지만 다음과 같이 쉽다.

cli::array<int> ^a = gcnew cli::array<int> {1, 2, 3};

기존 C++과의 차이라면 array<> 키워드가 쓰이고 있고 ^ 심볼로 핸들 지정을 하며 new 대신 gcnew를 사용한다는 점.

또 다른 형태의 배열 선언 방식은 다음과 같다.

array<int> ^a = gcnew array<int>(100) {1, 2, 3};

처음 방식보다 단순화 되었는데 cli 네임스페이스 명시를 빼고 100개의 배열을 선언한 다음 처음 3개만 값 1,2,3으로 초기화 했다. 각각의 배열 요소에 접근하려면 foreach를 다음과 같이 사용할 수 있다.

for each (int v in a)
{
  Console::WriteLine("value={0}", v);
}

자, 이제 4x5x2 형태의 3차원 배열을 선언해보자... 초기값은 모두 0.

array<int, 3> ^threed = gcnew array<int, 3>(4,5,2);

Console::WriteLine(threed[0,0,0]);

오오오... 생각보다 쉽다. 

이제 스트링 클래스를 배열로 선언해보자..

array<String ^> ^strs = gcnew array<String ^> {"Hello", "World"}

이런 형태를 초기화 하기 위해서는 다음과 같이 하면 된다.

array<String ^> ^strs = gcnew array<String ^>(5);
int cnt = 0;

// We use the tracking reference to access the references inside the array
// since normally strings are passed by value

for each (String ^%s in strs)
{
    s = gcnew String( (cnt++).ToString() );
}

나와 있는 설명처럼 % 심볼이 사용되었는데 그 이유는 일반적으로 스트링의 경우 값으로 전달되기 때문에 레퍼런스를 이용해야 메모리로 직접적인 접근이 가능하기 때문이다. 

Parameter Arrays

헛, 이것도 가능했단 말인가? C에서 printf() 함수와 같이 파라미터가 들어가는 함수의 사용도 가능하다. 단, 사용할 수 있는 조건은 C와 동일하다. 

using namespace System;

void avg(String ^msg, ... array<int> ^values)
{
  int tot = 0;
  for each (int v in values)
    tot += v;
  Console::WriteLine("{0} {1}", msg, tot / values->Length);
}

int main(array<String ^> ^args)
{
  avg("The avg is:", 1,2,3,4,5);
  return 0;
}

Properties

C#에서 사용되는 형태의 프로퍼티

public ref class Xyz
{
private:
  int _x, _y;
    String ^_name;
public:
  property int X
    {
      int get()
        {
          return _x;
        }
        void set(int x)
        {
          _x = x;
        }
    }
  property String ^Name
  {
    void set(String ^N)
    {
      _name = N;
    }
    String ^get()
    {
      return _name;
    }
  }
};

Wrapping Around a Native C++ Class

자, 이제 C++ class를 어떻게 CLI에서 감싸는지 보자

// native class

class Student
{
private:
  char *_fullname;
  double _gpa;
public:
  Student(char *name, double gpa)
  {
    _fullname = new char [ strlen(name+1) ];
    strcpy(_fullname, name);
    _gpa = gpa;
  }
  ~Student()
  {
    delete [] _fullname;
  }
  double getGpa()
  {
    return _gpa;
  }
  char *getName()
  {
    return _fullname;
  }
};

위 코드는 Native class의 한 예다. 이것을 C++/CLI 클래스로 바꾸려면 다음의 가이드를 따르면 된다.

• Managed Class를 만들고 그것의 멤버 변수가 Native Class를 가리키도록 해라
• 생성자 혹은 다른 적절한 위치에서 Native Class를 Native Heap (new 키워드를 사용하여) 에 생성해라
• 생성자를 호출할 때 필요한 변수와 입력 인자를 전달하라. 이때 몇몇 입력 값은 Unmanaged 에서 Manged Type으로 Marshal (변환)이 필요할 것
• Managed Class로 부터 드러내고 싶은 함수의 Stub를 생성하라
• Managed Class의 파괴자에 Native Pointer 를 지우는 것을 잊지 마라 (메모리 누수)

자, 이제 위 Native Class의 C++/CLI 버젼을 보자.

// Managed class

ref class StudentWrapper
{
private:
  Student *_stu;
public:
  StudentWrapper(String ^fullname, double gpa)
  {
    _stu = new Student((char *) 
           System::Runtime::InteropServices::Marshal::StringToHGlobalAnsi(
           fullname).ToPointer(), 
      gpa);
  }
  ~StudentWrapper()
  {
    delete _stu;
    _stu = 0;
  }

  property String ^Name
  {
    String ^get()
    {
      return gcnew String(_stu->getName());
    }
  }
  property double Gpa
  {
    double get()
    {
      return _stu->getGpa();
    }
  }
};

중간에 좀 후덜덜한 부분이 있긴 하지만 그래도 생각보다 어렵진 않다.

Wrapping Around C Callbacks

여기서는 예제용으로 EnumWindows() API 함수를 Wrap 할 건데 다음이 코드의 핵샘이다.

• Manged class를 하나 만드는데 Delegates와 함께 만들거나 Native Callback에 도달하면 호출되는 함수랑 만들거나.
• 방금 만든 Managed Class로 향하는 레퍼런스를 가지는 Native Class 만든다. 이것은 vcclr.h 헤더에 있는 gcroot_atuo를 이용하면 가능하다
• 이제 Native C Callback 함수를 만들고 넘길때 Context Parameter (우리 예제에서는 lParam) 로 넘긴다. (Native Class로의 포인터)
• 이제 Native Callback 내부에서 Native Class 인 Context를 가지고 있으므로 이제 Managed Class로 향하는 레퍼런스를 얻어올수 있고 필요한 함수를 호출 할 수 있다.

using namespace System;

#include <vcclr.h>


// Managed class with the desired delegate

public ref class MyClass
{
public:
  delegate bool delOnEnum(int h);
  event delOnEnum ^OnEnum;

  bool handler(int h)
  {
    System::Console::WriteLine("Found a new window {0}", h);
    return true;
  }

  MyClass()
  {
    OnEnum = gcnew delOnEnum(this, &MyClass::handler);
  }
};

이제 Native Class를 만들어보자. 이 클래스 내부에는 Managed Class 레퍼런스 (m_clr)이 존재하고 직접적인 Callback 프로시져가 있다.

class EnumWindowsProcThunk
{
private:
  // hold reference to the managed class

  msclr::auto_gcroot<MyClass^> m_clr;
public:

  // the native callback

    static BOOL CALLBACK fwd(
    HWND hwnd,
    LPARAM lParam)
  {
      // cast the lParam into the Thunk (native) class,
      // then get is managed class reference,
      // finally call the managed delegate

      return static_cast<EnumWindowsProcThunk *>(
            (void *)lParam)->m_clr->OnEnum((int)hwnd) ? TRUE : FALSE;
  }

    // Constructor of native class that takes a reference to the managed class

  EnumWindowsProcThunk(MyClass ^clr)
  {
    m_clr = clr;
  }
};

마지막으로 실질적으로 사용하는 코드는,

int main(array<System::String ^> ^args)
{
  // our native class

  MyClass ^mc = gcnew MyClass();

    // create a thunk and link it to the managed class

  EnumWindowsProcThunk t(mc);

    // Call Window's EnumWindows() C API with the pointer
    // to the callback and our thunk as context parameter

  ::EnumWindows(&EnumWindowsProcThunk::fwd, (LPARAM)&t);

  return 0;
}

The Other Way Round: From Manged to C Callbacks

이 것은 더 쉽다. 왜냐면 이미 Managed Class 내부에 Native Class로 향하는 포인터를 가지고 있기 때문이다. 다음과 같이 하면 된다.

• Native Callback를 트리거 (발생)시킬 적절한 Delegates를 가지는 Managed Class를 만든다
• Native Class (Callback 을 포함하는)와 이전의 Managed Class (이벤트 발생시키는 놈)을 연결해줄 Managed Class를 만든다
• Callback을 핸들링 할 Native Class를 만든다

Tick Generator Delegate는 다음과 같다

public delegate void delOnTick(int tickCount);

그리고 Managed tick generator class는 다음과 같다.

ref class TickGenerator
{
private:
  System::Threading::Thread ^_tickThread;
  int _tickCounts;
  int _tickFrequency;
  bool _bStop;

  void ThreadProc()
  {
    while (!_bStop)
    {
      _tickCounts++;
      OnTick(_tickCounts);
      System::Threading::Thread::Sleep(_tickFrequency);
    }
  }

public:
  event delOnTick ^OnTick;

  TickGenerator()
  {
    _tickThread = nullptr;
  }

  void Start(int tickFrequency)
  {
    // already started

    if (_tickThread != nullptr)
      return;

    // p.s: no need to check if the event was set,
    // an unset event does nothing when raised!

    _tickCounts = 0;
    _bStop = false;
    _tickFrequency = tickFrequency;

    System::Threading::ThreadStart ^ts = 
      gcnew System::Threading::ThreadStart(this, &TickGenerator::ThreadProc);
    _tickThread = gcnew System::Threading::Thread(ts);
    _tickThread->Start();
  }
  
  ~TickGenerator()
  {
    Stop();
  }

  void Stop()
  {
    // not started?

    if (_tickThread == nullptr)
      return;
    _bStop = true;

    _tickThread->Join();
    _tickThread = nullptr;
  }
};

#pragma unmanaged
// Create a simple native interface for handling ticks

// Native classes implement this class to add custom OnTick handlers

class INativeOnTickHandler
{
public:
  virtual void OnTick(int tickCount) = 0;
};

class MyNativeHandler: public INativeOnTickHandler
{
public:
  virtual void OnTick(int tickCount)
  {
    printf("MyNativeHandler: called with %d\n", tickCount);
  }
};

#pragma managed
// Create the managed thunk for binding between the native
// tick handler and the tick generator managed class

ref class TickGeneratorThunk
{
private:
  INativeOnTickHandler *_handler;
public:
  TickGeneratorThunk(INativeOnTickHandler *handler)
  {
    _handler = handler;
  }

  void OnTick(int tickCount)
  {
    _handler->OnTick(tickCount);
  }
};

int main(array<System::String ^> ^args)
{
  // Initiate the native handler

  MyNativeHandler NativeHandler;

  // Create the tick generator class

  TickGenerator ^tg = gcnew TickGenerator();

  // Create the thunk and bind it with our native handler

  TickGeneratorThunk ^thunk = gcnew TickGeneratorThunk(&NativeHandler);

  // Bind the ontick event with the thunk's onclick event

  tg->OnTick += gcnew delOnTick(thunk, &TickGeneratorThunk::OnTick);

  // Start the tick generator

  tg->Start(1000);

  // Wait for user input

  Console::ReadLine();

  // Stop the generator

  tg->Stop();

  return 0;
}

글을 다 쓰고 보니 좀 글의 내용과 제목이 어울리지 않는다는 생각이 든다. 애초에 C++/CLI를 빠르게 습득하는 것을 타이틀로 했다면 특정 언어간의 호출에 치중하기 보다는 기본적인 타입의 사용과 다양한 예제를 통해 보다 일반적이고 기본적인 개념 설명을 하는 것이 더 좋았을듯 하다... 아무튼, 일단 글을 퍼오기는 했으니 저장은 하지만 썩 마음에 들지는 않는다. 물론 초반에 간단간단하고 명료한 설명은 참 좋았다...