시작하면서

 현재 스마트폰 모바일 환경은 굉장히 다양하고, 다이나믹 하다고 해야할까요? 현재 인기도로 봤을 때 크게 3개의 플랫폼이 시장에 존재하고 있습니다.

iPhone, Android, Windows Mobile 이 그 세 종류입니다.

 이, 세 플랫폼을 모두 개발해본 경험으로 말하자면, 현재 위의 3종류 플랫폼중에서는 Windows Mobile 이 가장 떨어집니다. 단순하게 비교하면 다음과 같습니다.

생산성 : iPhone > Android > Windows Mobile

디버깅 : Windows Mobile > iPhone > Android

단, 디버깅의 경우는 Windows Mobile 이 가장 높지만, 개발의 생산성 면에서 다른 두 플랫폼 보다 많이 떨어지기 때문에, 합쳐서 본다면 가장 떨어진다고 볼 수 있습니다.

 그렇다면, Windows Mobile을 왜 배워? 라는 질문이 나올 듯 합니다. 먼저, 위에서 비교한 Windows Mobile은 6.5 까지 입니다. 즉, Windows Mobile 7에서는 위의 결과는 다를 수 있다는 것입니다.

 또한, 제가 보는 Windows Mobile 7의 최대 장점은, 하나만 개발하면 적은 노력으로, Windows, Windows Mobile 7, XBox 360 에 서로 돌아갈 수 있기 때문입니다.

Windows Mobile 7 입문

결론부터 말하자면, 7.0 전에 Native로 WindowsMobile을 개발하던 개발자가, WindowsMobile 7.0 개발을 할려고한다면, 한마디로 “헉” 하는 소리가 나오게 됩니다.

무엇보다. 사용하던 언어자체가, C/C++ 에서 WPF 기반의 C#으로 바뀌게 되면서, xaml 을 알아야만, 개발을 할 수 있게 됩니다. 그래서, 초반에는 꽤 많은 삽질과, 적응이 필요하게 됩니다.

그렇다면, 개발 자체는 더 불편하게 된 것일까요?, 여기에 대해서는 도리어 WindowsMobile 7.0 개발환경이 더 발전되었다고 말할 수 있습니다. 새로운 학습이라는 큰 문제가 생기기는 했지만, WindowsMobile 6.5까지 Native로 개발하시던 분들에게는 UI 등, 각각의 기능 개발에 들어가던 많은 잡일들이, xml 환경으로 간단하게 수정이 가능하게 되었습니다.

개인적으로 WindowsMobile 개발에서 가장 불만이 많았던 부분도, UI 개발에의 불편함이었습니다. 그런 부분이 해결이 되었다고 할까요?

그러나, WindowsMobile 7.0 이상부터 만나게 되는 xaml 역시도 처음에는 꽤 많은 학습이 필요합니다.

앞으로, 저와 함께, WindowsMobile 7.0 개발로 뛰어들어가 보실까요?

제일 먼저 만나게 되는 것은 xaml을 이용해서 UI를 만드는 부분입니다.(6.5까지 Native 로 개발하시 던 분들에게는 거의 노가다와 다름없었던 UI 개발부분이 xml을 통해서 쉽게 구현되도록 바뀌었습니다.)

xaml을 수정하면 바로 변경된 UI를 보실 수 있습니다. 다음은 단순히 xaml의 일부 코드를 붙여넣기로 추가한 형태입니다. 바로 UI가 바뀐 모습을 보실 수 있습니다.

그리고 오류가 있다면, 바로 오류 부분을 알 수 있습니다.

 Native 개발자가 보기에 일단, 최고의 변화중에 하나는 이 UI 개발 부분이 아닐까 하는 생각이 듭니다.

결론

 간단하게 정리하자면, Windows Mobile 7 는 공부 해 볼만한 이유가 상당히 많은 플랫폼이라는 것입니다. 앞으로는 차근 차근 Windwos Mobile 7을 함께 공부해보도록 하겠습니다. ^^ 

- 인덱스는 왜 나오는 고냐...?

인덱스는 방대한 정보를 특정한 기준으로 잘 분류해 놔서 정보를 금방 찾을 수 있도록 해주는 고마운 장치이죠. 아무리 두꺼운 사전이 있다고 해도, 그 사전이 가나다 순이나 알파벳순으로 잘 인덱싱이 되어있지 않으면 쓸모없겠죠. C#도 그래서, 대화하기 여러운 COM과 잘 지내기 위해서 인덱스 가능한 프로퍼티를 사용하기 시작했쬬!


- 인덱스 가능한 프로퍼티가 몬데?

이름 그대로입니다. 그냥 이름 그대로 프로퍼티인데, 프로퍼티의 값을 가져올 때 인덱스로 특정 요소에 접근가능한 프로퍼티죠. 아래와 같은 모양이 인덱스로 접근하는 프로퍼티의 모습입니다.

C++/CLI에 대한 기술 아티클이 별로 없는 편입니다. 좀 오래 되었지만 MSDN 매거진 2005년 1월에 연재된 'Visual C++ 의 프로그래밍 모델과 컴파일러 최적화를 사용한 어플리케이션의 강화'( http://msdn.microsoft.com/ko-kr/magazine/cc163855%28en-us%29.aspx )라는 글을 통해서 간단하게 정리해 보겠습니다.

이 글을 통해서 C++/CLI의 특징이나 .NET 언어 중에서 어떤 특징을 가지고 있는지 알 수 있습니다.

유연한 프로그래밍 모델

C++는 C#에 비해 언어적 표현력이나 라이브러리가 부족하다는 단점이 있지만 C#에 비해서 프로그래머가 가질 수 있는 자유도가 무척 높습니다(때로는 이것 때문에 많은 문제를 일으키지만).

C#으로 프로그래밍을 할 때는 무조건 객체 지향 프로그래밍 모델만 사용해야 합니다. 그러나 C++는 절차형 프로그래밍, 객체 지향 프로그래밍, 제너릭 프로그래밍, 메타 프로그래밍 등 프로그래머가 원하는 모델을 선택하여 프로그래밍 할 수 있습니다.

.NET에서 C++/CLI를 사용하면 이런 C++의 장점을 바로 얻을 수 있습니다.

어떤 .NET 언어보다도 뛰어난 성능

보통 .NET에서 프로그래밍 할 때 어떤 언어를 사용하나 동일한 성능을 낸다고 생각하지만(즉 언어는 달라도 컴파일 결과로 나오는 MSIL은 동일하다고) 이것은 잘 못된 생각입니다.

C++ 컴파일러 팀은 수년에 걸쳐 네이티브 코드의 최적화로부터 얻었던 지식을 C++/CLI의 최적화에 적용할 수 있도록 많은 노력을 했습니다. 그 결과 다른 .NET 언어보다 최적화된 MSIL를 만들어냅니다.

VC++은 어느 컴파일러보다 최상의 최적화를 제공하고 이것은 네이티브 뿐만이 아닌 매니지드 코드에 대해서도 같습니다. VC++ 컴파일러는 네이티브 코드의 모든 최적화 방법을 MSIL에도 적용하여 다른 .NET 언어보다 더 뛰어난 최적화를 할 수 있습니다.

.NET에서 가장 최적화된 .NET 코드를 만들어 내는 것은 C++/CLI 입니다.

네이티브 코드와 상호 운용 가능

사실 C++/CLI가 .NET에서 가장 큰 의미를 갖는 것이 바로 이 부분이라고 생각합니다.

.NET의 다른 언어에서 네이티브 코드를 사용하려면 네이티브 코드를 DLL로 만들어서 P/Invoke로 호출해야 합니다. 그러나 C++/CLI는 네이티브 코드와 매니지드 코드를 혼합하여 사용할 수 있습니다. 네이티브 함수로부터 매니지드 함수를 호출하는 경우 특별한 구문을 기술할 필요가 없습니다.

네이티브에서 매니지드 호출 또는 매니지드에서 네이티브를 호출하는 경우 서로간의 경계를 넘어가야 하므로 비용이 발생하는데 이런 호출을 최대한 줄여야 성능에 좋습니다. C#의 경우에는 서로간의 호출을 줄여야 하는 경우 인터페이스 변경 등이 필요하나 C++/CLI는 /clr 스위치를 사용하는 것으로 쉽게 변경할 수 있습니다. 이러한 결과로 네이티브와 매니지드 간의 호출에 발생하는 비용을 최소화 할 수 잇습니다.

매니지드 코드와 네이티브 코드의 상호 운용에서 가장 비싼 비용은 마샬링입니다. C#의 경우 P/Invoke를 호출할 때 CLR에 의해서 암묵적으로 마샬링이 실행됩니다. 그러나 C++/CLI는 프로그래머가 필요에 따라서 명시적으로 마샬링을 할 수 있어서 한번 마샬링한 데이터를 복수로 사용할 수 있어서 마샬링에 의한 비용을 줄일 수 있습니다.

.NET 프로그램의 처음 실행 시의 딜레이

.NET으로 만든 프로그램과 네이티브로 만든 프로그램의 차이 중의 하나가 .NET으로 만든 프로그램은 처음 실행 시에 CLR을 읽기 위해 딜레이가 발생하는 것입니다. 그러나 C++/CLI는 이런 문제를 회피할 수 있습니다.

VC++에는 DLL 딜레이 로딩 이라는 기능이 있습니다. 링커 옵션에서 /DELAYLOAD:dll에 딜레이 로딩을 할 .NET 어셈블리를 지정하면 네이티브 프로그램과 동일한 정도의 속도록 실행 시킬 수 있습니다.

좀 더 C++/CLI가 다른 .NET 언어보다 좋은 점이 있지만 이것으로 줄이겠습니다.

C++/CLI를 아시는 분들은 언어적 위치의 애매함에 의해서 좋지 않은 인상을 가진 분들이 많으리라 생각하는데 제가 소개한 장점을 통해서 조금이나마 좋은 인상을 얻으셨는지 모르겠네요^^.

C++/CLI가 다른 .NET 언어보다 어떤 특징을 가지고 있는지 좀 더 자세하게 알고 싶다면 위에 소개한 MSDN 매거진의 원문(영어)을 보시던가 또는 제가 발 번역한 글을 보시기 바랍니다.

Visual C++ 의 프로그래밍 모델과 컴파일러 최적화를 사용한 어플리케이션의 강화

http://jacking75.cafe24.com/MSDN_MagaZine/C++Rule_200501.htm

그리고 아래의 글도 참고하시기 바랍니다.

C++/CLI: .NET 프레임워크 프로그래밍을 위한 가장 강력한 언어

http://anyflow.net/entry/CCLI-NET-%ED%94%84%EB%A0%88%EC%9E%84%EC%9B%8C%ED%81%AC-%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D%EC%9D%84-%EC%9C%84%ED%95%9C-%EA%B0%80%EC%9E%A5-%EA%B0%95%EB%A0%A5%ED%95%9C-%EC%96%B8%EC%96%B412

http://anyflow.net/entry/CCLI-NET-%ED%94%84%EB%A0%88%EC%9E%84%EC%9B%8C%ED%81%AC-%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D%EC%9D%84-%EC%9C%84%ED%95%9C-%EA%B0%80%EC%9E%A5-%EA%B0%95%EB%A0%A5%ED%95%9C-%EC%96%B8%EC%96%B422

C++/CLI 의 설계 원리와 발전 과정

http://msdn.microsoft.com/ko-kr/magazine/cc163484.aspx

앞에서 ExecuteQueryAsync 에 대한 내용과 Silverlight 웹 파트에 대한 내용을 알아보았는데 이번 블로그에서는 Silverlight Client Object Model의 또 다른 예를 살펴보도록 하겠습니다.

Silverlight 응용 프로그램을 생성하고 아래와 같이 디자인 합니다.

Silverlight Client Object Model 어셈블리를 참조 추가합니다.

Button의 Click 이벤트를 발생시키고 코드 보기에서 using 구문에 아래 코드를 작성합니다.

using Microsoft.SharePoint.Client;

 

생성자 위에 비동기적으로 UI 스레드를 처리하기 위해 아래 코드를 추가합니다. Dispatcher 의 BeginInvoke 에서 사용되어야 합니다. ListInfo는 LoadQuery를 통해 List 개체를 담게 됩니다.

private delegate void UpdateUIMethod();

IEnumerable<List> listInfo;   

 

아래는 목록 정보를 액세스하는 코드입니다. Button 의 Click 이벤트에 아래 코드를 통해 LoadQuery 메서드를 호출합니다.

ClientContext context = new ClientContext("http://sp.webtime.co.kr");

Web site = context.Web;

ListCollection collList = site.Lists;

context.Load(site, website => website.Title);

            listInfo = context.LoadQuery(

                collList.Include(

                    list => list.Title).Where(

                    list => list.OnQuickLaunch== true));

context.ExecuteQueryAsync(Succeeded, Failed);

빠른 실행에 표시되는 List의 Title을 담게 됩니다.

 

DisplayInfo 메서드에서 ListBox 컨트롤에 바인딩하는 코드입니다.

private void Succeeded(object sender, ClientRequestSucceededEventArgs e)

        {

            UpdateUIMethod updateUI = DisplayInfo;

            this.Dispatcher.BeginInvoke(updateUI);

        }

private void DisplayInfo()

        {

       

            this.listBox1.DisplayMemberPath = "Title";

            this.listBox1.ItemsSource = listInfo.ToList();

        }

private void Failed(object sender, ClientRequestFailedEventArgs e)

        {

            MessageBox.Show("Create Fail");

        }

 

 

 

 Xap 파일을 라이브러리에 업로드하고 Silverlight 웹 파트를 추가해서 경로를 지정합니다.

버튼을 클릭하면 빠른 실행에 있는 목록들의 Silverlight Client Object Model을 이용해서 알 수 있습니다.

SDK의 아래 주소를 참고하실 수 있습니다.

http://msdn.microsoft.com/en-us/library/ee538971(office.14).aspx

Silverlight Client Object Model을 알아보았고 다음 블로그에서 Javascript를 이용한 내용을 알아보도록 하겠습니다.

앞에서 .NET Managed Client Object Model에 대한 내용을 알아보았습니다. 이번 블로그에서는Client Object Model(개체 모델)을 Silverlight을 이용해서 액세스해보도록 하겠습니다.

SharePoint 2010에서 Media 웹 파트, Silverlight 웹 파트가 기본적으로 제공이 되고 있어 웹 파트를 만들지 않아도 되고 그냥 콘텐트를 생성하면 됩니다.

Client OM을 액세스하기 전에 Silverlight 지원되는 내용을 먼저 알아보겠습니다.

1. 사이트 작업의 기타 옵션을 클릭해서 여러 목록이나 라이브러리를 생성할 수 있습니다. 클릭했을 때의 화면이 Silverlight 콘텐트입니다.

2. Silverlight 미디어 웹 파트를 제공해주고 있습니다. 또한 이미지 라이브러리에 동영상을 업로드해서 바로 재생하기가 가능합니다.

3. Silverlight 웹 파트를 제공하고 있습니다.

그 외 지원되는 내용도 있지만 생략하고 바로 Silverlight을 통해 Client OM을 액세스해보도록 하겠습니다.

본격적으로 Silverlight Client Object Model을 살펴보도록 하겠습니다.

Visual Studio 2010에서 Silverlight 응용 프로그램을 생성합니다.

프로젝트이름은 SilverlightClientOMDemo으로 지정했습니다. Silverlight 응용 프로그램의 디자인은 아래와 같이 TextBox 컨트롤 2개와 Button 컨트롤 1개로 구성되어 있습니다.

Client OM을 액세스하기 위해 아래 어셈블리를 참조 추가합니다.

Microsoft.SharePoint.Client.Silverlight.dll

Microsoft.SharePoint.Client.Silverlight.Runtime.dll

 

아래 경로에 어셈블리들이 위치해 있습니다.

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\ClientBin

 

Using 구문에 다음과 같은 코드를 입력합니다.

using Microsoft.SharePoint.Client;

 

 

생성자 위에 비동기적으로 UI 스레드를 처리하기 위해 아래 코드를 추가합니다. Dispatcher 의 BeginInvoke 에서 사용되어야 합니다.

private delegate void UpdateUIMethod();

 

 

Client OM Button의 Click 이벤트에서 아래와 같은 코드를 작성합니다.

ClientContext context = new ClientContext("http://sp.webtime.co.kr");

Web site = context.Web;

List list = context.Web.Lists.GetByTitle("HJ");

ListItem listitem = list.AddItem(new ListItemCreationInformation());

listitem["Title"] = this.txtTitle.Text;

listitem["Body"] = this.txtBody.Text; ;

listitem.Update();      

context.ExecuteQueryAsync(Succeeded, Failed);

 

맨 마지막 라인을 제외하면 .NET Managed Client Object Model가 동일합니다.

Succeeded, Failed 에 대한 메서드는 아래와 같이 정의합니다.

private void Succeeded(object sender, ClientRequestSucceededEventArgs e)

        {

            UpdateUIMethod updateUI = DisplayInfo;

            this.Dispatcher.BeginInvoke(updateUI);

        }

private void DisplayInfo()

        {

            this.lblInfo.Text = "Success ";

        }

private void Failed(object sender, ClientRequestFailedEventArgs e)

        {

            MessageBox.Show("Create Fail");

        }

 

Silverlight 응용 프로그램을 빌드하여 이상이 없으면 xap 파일을 SharePoint 2010 사이트의 문서 라이브러리로 업로드합니다. 14 폴더의 ClientBin 폴더에 배포할 수도 있습니다.

업로드하고 나서 xap 파일을 오른쪽 클릭하여 바로 가기를 복사합니다.

HJ 공지사항을 클릭하여 페이지 편집으로 Silverlight 웹 파트를 추가합니다.

Silverlight 웹 파트 대화 상자에서 이전에 복사했던 바로 가기를 붙여넣기 합니다.

페이지 편집을 중지하고 TextBox 에 값을 입력하고 버튼을 클릭합니다.

공지사항 내용 보기를 통해서도 확인이 가능합니다.

Silverlight Client Object Model을 액세스 해보았습니다. 비동기적으로 호출하는 것(ExecuteQueryAsync)만 유념하면 .NET Managed Client Object Model과 거의 동일합니다.

다음 블로그에서는 Silverlight Client Object Model의 다른 예(LoadQuery)를 알아보도록 하겠습니다.

안녕하세요. Visual Studio 2010 팀 블로그에 새로 참여하는 새내기, Visual C# MVP 남정현입니다. 데브피아 C# 포럼 SYSOP으로 활동 중이기도 하고, 데브피아 오프라인 세미나를 통해서 .NET 커뮤니티 개발자 여러분들과도 몇 번 인사드렸던 적이 있었는데, 이번에 VSTS 2010 팀 블로그에서 인사를 드리게 되었습니다. 반갑습니다. :-)

요즈음 클라우드 컴퓨팅에 관해서 이곳 저곳에서 이야기도 많이 회자되고 있는 것을 볼 수 있습니다. 2008년 후반에 Buzz Keyword로 급부상했던 아이템이 점차 트렌드로 바뀌어가고 있는 추세인데, 여러 유수 IT 기업들이 클라우드 컴퓨팅에 대한 다양한 해석과 아이디어를 더하여 자신들만의 플랫폼 구축에 열과 성을 다하고 있습니다. Microsoft에서도 지난 2월, 미국, 유럽, 일부 아시아 국가를 대상으로 Windows Azure Platform을 정식으로 런칭하였습니다.

VSTS 2010 팀 블로그를 통하여 제가 연재하게 될 Article Series인 "Hello Windows Azure"의 내용은, Windows Azure Platform에서 실행되는 응용프로그램을 Visual Studio 2010을 통하여 개발하는 과정을 주로 소개하는 내용으로, Visual Studio 2010 이외의 다른 IDE를 활용한 개발 방법 및 Windows Azure Platform 기반의 상호 운용성에 대한 주제는 저의 블로그 (http://www.rkttu.com/) - 또는 - 저의 개인 메일 (rkttu nospam rkttu dot com)을 통하여 질문, 토론, 의견 등을 받고자 합니다. 많은 관심 부탁드립니다.

Windows Azure Platform 개요

Windows Azure Platform은 Microsoft Data Center 위에서 실행되는 Public Cloud Platform으로, 응용프로그램을 호스팅하고 실행하는 기능을 제공하는 Windows Azure, 관계형 데이터베이스 (RDBMS) 데이터를 호스팅하고 제공하는 SQL Azure, 분산 컴퓨팅 기술의 구현과 Hybrid Cloud Platform의 구현을 가능하게 하는 AppFabric, 실시간으로 제공되는 동적 데이터 카탈로그를 구현할 수 있는 SQL Data Services (Codename: Dallas) 등으로 구성됩니다.

그 외에 부수적으로는 Windows Azure Platform과 조합하였을 때 훨씬 더 효과적으로 사용할 수 있는 Microsoft의 다른 Web SDK 및 온라인 서비스들 (예: Facebook SDK, Windows Live ID 및 Windows Live 관련 SDK)을 접목한다면 더욱 사용성이 편리하고 우수한 클라우드 기반 응용프로그램을 만드실 수 있습니다.

위의 그림에서 보여지는 것처럼, Windows Azure Platform은 핵심 인프라를 기반으로하여, End User들에게는 실제 클라우드 응용프로그램이 제공하는 서비스를 활용할 수 있게 하고, 개발자들에게는 Visual Studio 및 기존에 자신이 사용하던 IDE를 이용하여 Cloud Application을 개발할 수 있게 하고, 호스팅되는 Cloud Application의 재량이지만, SOAP, REST, XML-RPC 등의 통신 프로토콜을 통하여 기존의 On-Premise 기반 소프트웨어에서도 클라우드 응용프로그램의 이점을 누릴 수 있게함을 보여줍니다.

특히, Visual Studio는 이 블로그를 찾아주시는 여러분들께서 제일 많이 애용하시는 개발 도구일 것입니다. 익숙한 프로그래밍 언어 (C#, VB.NET, F#)들을 활용해서 최신의, 그리고 강력한 컴퓨팅 환경 위에서 구동 가능한 응용프로그램을 자유롭게 개발하실 수 있다는 것을 뜻합니다. 아직까지 국내에 정식 출시되지 않은 서비스이지만, Windows Azure가 실제로 어떻게 동작하고, 어떤 절차를 거쳐서 개발이 이루어지는지에 대해서 먼저 아실 수 있다면 그 또한 좋은 이득이 되지 않겠는가 하는 생각입니다.

Windows Azure에 대하여

아래 그림은 Windows Azure Platform을 이루는 주요 구성 요소들을 Layer별로 표현한 모식도입니다. 아래 그림에서 몇 가지 핵심적인 요소들을 살펴보겠습니다.

Windows Azure는 Windows Azure Platform에서 운영 체제에 해당하는 인프라 구성 요소입니다. 내부적으로 Windows Server 2008 R2 x64를 Guest OS로 사용하여, Hypervisor 및 Load Balancer를 기반으로 외부에서 발생하는 요청을 항상 고성능 / 실시간으로 처리하고 결과를 내보낼 수 있도록 돕습니다. Windows Azure는 응용프로그램을 게시하고 실행할 수 있는 Compute 서비스와, 인스턴스 및 응용프로그램의 개수나 종류에 관계없이 동일한 영속성을 부여하기 위한 Storage 서비스를 제공합니다.

Compute 서비스를 통하여 실행되는 Windows Azure 응용프로그램은 보통 여러 개의 역할 (Role) 구성 요소가 동시에 실행됩니다. Role 하나에는 하나 이상의 Virtual Machine Instance가 복제되어 서비스를 담당하게 됩니다. 이 때, Load Balancer가 하는 일은, 실행되는 Virtual Machine Instance의 네트워크 부하, CPU 부하 등을 측정하여 현 시점에서 제일 최적의 성능을 낼 수 있는 Instance가 처리를 대행하도록 연결해주는 일입니다. Compute 서비스를 통하여 실행할 수 있는 Role의 종류는 크게 두 가지인데, Web Role과 Worker Role이 있습니다.

Web Role은 IIS를 내장하고 있는 OS 템플릿을 바탕으로 구축됩니다. IIS를 이용하여 기본적으로는 ASP.NET 응용프로그램을 호스팅할 수 있게 되어있습니다. 여기에 IIS 7.x 이후부터는 Fast CGI를 지원할 수 있게 되어 PHP, Perl, Python 등 대중의 인기를 많이 받는 새로운 웹 프로그래밍 언어까지 더할 수 있고, 특별히 Windows Azure SDK for Visual Studio에서는 Windows Azure용 Fast CGI를 개발할 수 있는 템플릿도 제공하고 있어서 더욱 편리하게 웹 응용프로그램을 개발할 수 있는 것이 특징입니다.

Worker Role은 OS의 핵심 기능을 템플릿으로 하여 구축됩니다. 별도의 기본 서비스 없이, 최소한의 운영 체제의 기능을 이용하여 고속의 연산 처리나 백그라운드 응용프로그램 처리 작업을 개발할 때에는 유용하게 쓰일 수 있습니다.

이전다음

012345678910

동일하게 복제된 여러 Virtual Machine Instance는, 장애나 Load Balancer의 판단으로 내부적으로 외부의 응답을 처리하는 Instance가 계속 바뀌게 됩니다. 이에 따라, 여러 Instance들이 동일한 내용을 보고 처리할 수 있게 하기 위해서는 외부적인 저장소가 필요한 데, 이 때 사용할 수 있는 것이 바로 Storage 서비스를 통하여 제공되는 Table, Queue, BLOB Storage입니다. Table Storage는 행과 열로 구성된 2차원 행렬 타입의 테이블 자료 구조를 구현하고, Queue Storage는 응용프로그램간 실시간 메시지 교환을 목적으로 사용하는 FIFO (First In First Out) 타입의 큐 자료 구조를 구현하며, BLOB Storage는 파일 크기에 관계없이 대용량의 BLOB (Binary Large Object)를 저장하고 로드할 수 있도록 한 것입니다. 특별히 BLOB Storage의 경우, BLOB Storage의 파일을 외부에서 안정적으로 다운로드할 수 있도록, CDN (Contents Delivery Network) 서비스와 연계하는 기능을 제공합니다. 이 글을 작성하는 시점에서 CDN 서비스와의 연동은 아직 CTP (Community Technology Preview) 단계에 머물러 있습니다.

그리고 최근에는 Windows 7, Windows Server 2008 R2 이후부터 본격적으로 Native Format으로 자리잡은 VHD File을 이용하여 Win32 I/O API를 통한 파일 입/출력을 가능하게 하는 Windows Azure Drive API가 새롭게 런칭되었습니다. Windows Azure Drive API를 이용하여 VHD를 생성하고, 마운트하는 기능을 제공하며, VHD 파일 내부적으로는 NTFS 파티션을 자동으로 생성합니다. Windows Azure Drive와 BLOB Storage 사이의 가장 큰 차이점을 꼽는다면, Windows Azure Drive는 CreateFile 같은 Win32 API로 파일 입/출력이 가능한 저장소이고, BLOB Storage는 외부에 파일을 직접 노출하거나, 서로 다른 시스템간에 파일을 교환할 수 있다는 것입니다. 상황과 조건에 따라서 적절한 방법을 택할 수 있을것입니다.

다음 시간에는

이번 첫 Article에서는 Windows Azure Platform에 대한 개요와 Windows Azure의 기본적인 구성 요소에 대해서 살펴보는 내용을 다루었습니다. 다음 시간에는 Windows Azure Platform 서비스를 신청하고 활용하는 방법을 소개하고, 몇 가지 실제 Windows Azure 기반 응용프로그램 및 개발 사례들을 소개하도록 하겠습니다.

감사합니다. 즐거운 하루 되세요. :-)

이미지 파일 인용: Microsoft Cloud Platform - David Chou / Microsoft

시작하면서

안녕하세요? Microsoft의 클라우드 컴퓨팅 기술에 대해 포스팅 하고 있는 안준석 입니다.

그 동안 Window Azure Platform 에 대한 기본적인 개념에서 사용법까지 살펴 봤었습니다. 특히 클라우드를 하드웨어와 플랫폼 측면에서 이야기 했습니다.

앞으로는 Azure 라는 클라우드 환경에서 애플리케이션을 어떻게 설계하고 만들어야 하는지에 대해 알아보려고 합니다.

핵심 키워드는 "분산" 과 "하이브리드" 그리고 "Window Azure Platform AppFabric" 입니다.

앞으로 포스팅 될 글들에 대한 전체 개요는 이 링크를 보시면 됩니다.

Windows Azure 遺憾(유감)

개발자로써 그 동안 Microsoft 의 Azure 플랫폼을 공부하고 사용하면서 재미도 있었지만 한편으론 많이 따분했었습니다.

"내가 개발 하던 방법 그대로 개발 하면 되네"

Microsoft의 저력이 느껴지는 부분이기도 한데요, 다양한 기술들을 묶어 통일 된 패러다임이 녹아든 제품을 만들어 내는 능력을 보면 감탄사가 절로 나옵니다. 특히 클라우드 컴퓨팅은 새로 나온 기술이 아니라 그 동안 축적 된 기술들의 총아라고 할 수 있는데요, 이 클라우드 컴퓨팅에서도 Microsoft 의 제품들은 한 가지 색을 갖고 개발자에게 이전과 동일한 사용자 경험을 제공합니다.

따라서 Visual Studio 에서 예전과 같이 개발하고 마우스 오른쪽 클릭 "Public" 하고 결과물을 Azure 웹 포탈에 업로드 하면 내 프로그램이 클라우드에서 작동 하게 됩니다.

"무한한 성능을 제공하는 큰 새로운 컴퓨터가 생긴 건가?.. 재미없다!"

개발은 동일하게 하고 배포만 Azure 로 하면 된다? Microsoft 가 제공하는 기능은 편리하지만 자유도가 떨어지죠. 실제로 클라우드 자원을 자유롭게 조작해 볼 수 없습니다. 클라우드에서 할 수 있는 것이 별로 없고 내 애플리케이션은 예전처럼 만든다면 클라우드든 로컬이든 개발자에게는 다를 게 없잖아요?

"아차! 잘못 생각하고 있었다!"

클라우드 컴퓨팅을 애플리케이션 개발 측면에서 접근 한 것이 아니라 하드웨어 기반(IaaS)과 플랫폼 기반(PaaS)을 이해 하고 사용하는 데만 집중 하고 있던 것이 문제 였습니다. 이런 기반들 위에서 작동하는 애플리케이션은 어떤 구조로 만들어야 하는지에 대한 고민이 부족해서 오해가 생겼던 것이었습니다. 아하!

그 동안 잠시 잊고 있던 그 것!

클라우드 환경에서 애플리케이션이 탑재해야 할 기본 개념이 있으니 바로 "분산" 입니다.

분산 : 클라우드 기반 애플리케이션 개발을 위한 핵심 키워드

클라우드 컴퓨팅에서 분산은 무엇을 의미 할까요? 일반적으로 다음과 같은 것을 의미합니다.

논리적 또는 물리적으로 분리 되어 있는 애플리케이션들이 네트워크로 연결 되어 상호 연동 되는 것을 "분산 시스템" 이라고 말합니다.

클라우드 환경에서의 애플리케이션은 이렇게 분산 되고 상호 작용을 통해 하나의 시스템으로 통합되는 것을 전제로 개발 되야 합니다.

그런데 애플리케이션들이 물리적으로 떨어져 있고 네트워크를 통해 상호 연동하게 하려면 참 많은 것들이 필요합니다. 네트워크 연결 주소는? 프로토콜은? 암호화는? OS가 달라? 서버장비가 달라? 방화벽은 어떻게 통과하지? 보안은? 등등 많은 이슈를 해결해야 합니다.

이를 위해 Windows Azure Platform 에서 제공하는 것이 있으니 바로 AppFabric 입니다.

Windows Azure Platform AppFabric

분산 애플리케이션을 위한 기반 컴포넌트입니다. 애플리케이션을 분산 시켜 상호 연동 할 때 발생하는 다양한 문제들을 미리 해결 해 놓은 Application Infrastructure 입니다.

앞으로는 몇 회에 걸쳐 Application Infrastructure 의 Key 플레이어인 Windows Azure Platform AppFabric 을 통해 클라우드 컴퓨팅 환경에서 어떻게 분산 애플리케이션을 개발 하면 되는지 알아보겠습니다. 이게 무엇인지 궁금하시죠? ;)

(주의!  Windows Server AppFabric 과 Windows Azure Platform AppFabric 은 다른 것입니다.)

마치면서

클라우드 컴퓨팅에 대한 관심은 커지고 있지만 아직까지 애플리케이션(App) 개발자들에게 와 닿는 부분은 적습니다. 그 한 가지 이유로 클라우드 컴퓨팅을 이야기 할 때면 주로 물리적인 인프라의 구성과 활용 시 이점을 이야기 한다거나 제공되는 플랫폼을 사용하는 방법 등에 대해 다뤄지고 있었기 때문입니다.

이번 글에서는 애플리케이션(App) 개발자가 클라우드 환경에서 "분산" 시스템 구축을 전제로 개발해야 한다는 것을 이야기 했고 Microsoft 에서 제공하는 AppFabric 이 이를 위한 기반을 제공한다고 언급했습니다.

다음 회에는 분산 애플리케이션(App) 개발자들을 위한 Windows Azure Platform AppFabic 을 본격적으로 파헤쳐 보겠습니다 ;)

이전 블로그에서 설명한 SharePoint 2010 데이터 기술 중에서 Client OM(개체 모델)에 대한 내용을 알아보도록 하겠습니다.

SharePoint 2010 데이터 기술에 대한 내용은 아래 주소를 참고하시기 바랍니다.

http://www.vsts2010.net/224

 

SharePoint 2010 박스 위가 아닌 원격에 떨어져 있을 경우 SharePoint 개체를 액세스하려면 웹 서비스를 통해 힘들게 해야 하지만 SharePoint 2010에서는 아주 손쉽게 접근할 수 있도록 Client OM을 제공해주고 있습니다. 생성할 수 있는 유형은 .NET, Silverlight, Javascript 를 통해 접근할 수 있습니다.

 

아래 표를 보시면 클래스와 메서드 등의 경우 서버 개체 모델과 거의 유사하게 구성되어 있습니다.

Server (Microsoft .SharePoint)	.NET Managed (Microsoft.SharePoint .Client)	Silverlight (Microsoft.SharePoint .Client.Silverlight)	JavaScript (SP.js)
SPContext	ClientContext	ClientContext	ClientContext
SPSite	Site	Site	Site
SPWeb	Web	Web	Web
SPList	List	List	List
SPListItem	ListItem	ListItem	ListItem
SPField	Field	Field	Field

 

표에서 보듯이 SP 라는 글자가 없어지고 거의 동일하게 작업이 가능합니다. 하지만 일부는 변경되어 있습니다. 웹 서비스를 통해 CAML을 처리하지 않아도 API를 통해 정말 편하게 접근이 가능합니다.

 

먼저 .NET Client OM을 알아보도록 하겠습니다. 그리고 다음 블로그에서 Silverlight, Javascript를 알아보도록 하겠습니다.

 

Visual Studio 2010을 통해 WPF 응용 프로그램을 생성합니다. 이름은 WpfClientOMDemo라고 하겠습니다.

Button 컨트롤을 디자인 영역으로 드래그하고 Click 이벤트를 생성합니다.

.NET Managed Client OM을 이용하기 위해서는 아래 어셈블리를 참조해야 합니다.

Microsoft.SharePoint.Client.dll

Microsoft.SharePoint.Client.Runtime.dll

 

경로는 아래와 같습니다.

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\ISAPI

코드보기로 이동하여 소스 코드에 아래 using 구문을 추가합니다.

using Microsoft.SharePoint.Client;

using SP=Microsoft.SharePoint.Client;

 

InitializeComponent() 아래 부분에 다음과 같은 코드를 입력하고 프로젝트 속성에서

.NET Framework 4.0 Client Profile 을 .NET Framework 4.0으로 변경하고 실행해봅니다.

x86은 그대로 두고 진행하면 됩니다.

ClientContext context = new ClientContext("http://sp.webtime.co.kr");

Web site = context.Web;

context.Load(site);

context.ExecuteQuery();

site.Title = site.Title + " Client OM";

site.Update();

context.ExecuteQuery();

위 코드는 SP 라는 이름이 붙어있다면 서버 개체 모델과 동일하다는 것을 알 수 있습니다.

 

결과는 아래처럼 “Home Client OM”으로 변경되어 있습니다.

디자인 보기로 이동하여 ListBox 컨트롤을 드래그합니다.

코드 보기에서 위에서 작성한 코드는 주석처리하고 아래와 같은 코드를 입력합니다.

아래 코드는 목록들의 이름을 리스트박스에 추가해서 나타내는 내용입니다.

 

ClientContext context = new ClientContext("http://sp.webtime.co.kr");

Web site = context.Web;

ListCollection lists = site.Lists;

IEnumerable<Microsoft.SharePoint.Client.List> listcollection =

context.LoadQuery(lists.Include(l => l.Title, l => l.Id));

context.ExecuteQuery();

listbox1.ItemsSource = listcollection;

listbox1.DisplayMemberPath = "Title";

 

 

결과는 다음과 같습니다.

작성한 코드는 주석처리하고 아래와 같은 코드를 입력합니다.

아래 코드는 사이트에 HJ 라는 공지사항을 생성하고 빠른 실행에 표시해주는 코드입니다. 이런 내용을 서버 개체 모델로 하는 것이 아니라 클라이언트 개체 모델로 해주고 있습니다.

ClientContext context = new ClientContext("http://sp.webtime.co.kr");

Web site = context.Web;

ListCreationInformation listCI = new ListCreationInformation();

listCI.Title = "HJ";

listCI.TemplateType = (int)SP.ListTemplateType.Announcements;

listCI.QuickLaunchOption = SP.QuickLaunchOptions.On;

SP.List li = site.Lists.Add(listCI);

site.Update();

 

위에서 생성한 HJ라는 공지사항에 항목을 입력해보겠습니다. 작성된 코드를 주석처리하고

HJ를 찾아서 ListItem을 생성하는 코드를 아래와 같이 작성합니다. ListItemCreationInformation 이라는 클래스를 이용합니다.

 

ClientContext context = new ClientContext("http://sp.webtime.co.kr");

Web site = context.Web;

SP.List li = site.Lists.GetByTitle("HJ");

            ListItemCreationInformation listitemCI = new ListItemCreationInformation();

SP.ListItem item = li.AddItem(listitemCI);

item["Title"] = "hongju";

item["Body"] = "Consulting Services";

item.Update();

context.ExecuteQuery();

 

HJ 라는 공지 사항에 항목이 하나 추가되어 있는 것을 아래 그림과 같이 확인이 가능합니다.

위에서 Client Object Model에 대한 개요와 .NET Managed Client Object Model에 대한 내용을 알아보았습니다. 서버 개체 모델은 서버 박스 위에서 실행되는 웹 파트나 유틸리티를 통해 처리되지만 원격의 클라이언트에서 실행되도록 하려면 SharePoint 2010에서는 Client OM을 사용할 수 있습니다. 다음 블로그에서 Silverlight Client Object Model 을 알아보도록 하겠습니다.

 

Microsoft.Common.v1.1.targets

Microsoft.CSharp.v1.1.targets

Visual Studio 2010, 2008 버전에서는 .NET Framework 2.0, 3.5, 3.5 SP1 을 선택할 수 있는 Multi Targeting(멀티 타게팅) 기능을 제공합니다. 최신의 .NET Framework 버전을 선택하여 개발할 수 있으며, 하위 호환성 있는 개발을 위해 최신의 Visual Studio 에서 하위 .NET Framework 버전을 선택할 수 있습니다.

하지만 Visual Studio 2010, 2008 의 Multi Targeting 은 .NET Framework 1.x 를 지원하지 않습니다. 프레임워크 버전과 개발 도구간의 비호환성 문제 때문에 .NET Framework 1.x 버전은 Visual Studio 2003 으로만 개발이 가능합니다.

이번에 소개하는 방법을 통하여 Visual Studio 2010, 2008, 2005 도구를 이용하여 .NET Framework 1.x 를 개발할 수 있는 환경을 구성할 수 있습니다.

단, 기존의 Visual Studio 2003 은 MSBuild(Microsoft 통합 빌드 솔루션) 를 지원하지 않기 때문에, .NET Framework 4.0 SDK 에 포함된 MSBuild Targets 를 사용하였습니다.

(Visual Studio 2008, 2005 버전에서도 아래와 같은 방식으로 MSBuild Targets 을 수정하시면 .NET Framework 1.1 개발 및 빌드 환경을 구축할 수 있습니다)

Visual Studio 2003 으로 개발된 프로그램

아래와 같이 간단한 ConsoleApplication1 프로젝트를 만들었습니다.

이 응용 프로그램을 실행하면 다음과 같은 결과가 나옵니다.

Mscorlib.dll 의 버전이 1.0.5000.0 인 것을 확인할 수 있습니다.

Visual Studio 2010 으로 프로젝트 컨버팅 하기

만들어진 Visual Studio 2003 프로젝트를 Visual Studio 2010 버전으로 컨버전합니다.

컨버전이 완료되었으면 프로젝트 파일(.csproj) 을 열어 아래와 같이 수정합니다.

먼저 기존의 .NET Framework 어셈블리를 .NET Framework 1.1 의 어셈블리로 강제로 변경해 줍니다. Visual Studio IDE 에서 .NET Framework 1.1 을 추가하면 2.0 이상의 어셈블리가 추가되므로 반드시 .csproj 파일에서 변경해 주어야 합니다.

그리고 Import 노드에 Microsoft.Csharp.v1.1.targets 의 라인을 추가해 줍니다.

Microsoft.CSharp.v1.1.targets 파일 만들기

$(MSBuildToolsPath) 의 폴더인 C:\Windows\Microsoft.NET\Framework\v4.0.30128 경로에서 Microsoft.CSharp.targets 파일의 복사본 이름을 Microsoft.CSharp.v1.1.targets 파일로 만들어 줍니다.

위의 방법으로 Microsoft.Common.target 파일을 Microsoft.Common.v1.1.targets 파일 이름으로 복사본을 만듭니다.

Microsoft.CSharp.v1.1.targets 파일 수정하기

아래의 노드를 찾아서 <NoWarn> 노드의 1701; 1702 값을 제거합니다. 이 값은 .NET Framework 1.1 의 경고 값으로 사용할 수 없는 값입니다.

그리고 아래의 CSC 노드를 찾아서 ErrorReport 속성을 제거합니다. .NET Framework 1.1 SDK 의 CSC.exe 는 ErrorReport 기능이 존재하지 않기 때문입니다.

추가로 CSC 노드의 ToolPath 의 경로를 아래와 같이 수정합니다. 이 경로에 포함되는 csc.exe 를 사용하여 .NET Framework 1.1 로 빌드하는 중요한 구문입니다.

아래의 Import 노드를 찾아서 복사본으로 만들었던 Microsoft.Common.v1.1.targets 파일명으로 변경합니다.

Microsoft.Common.v1.1.targets 파일 수정하기

아래의 노드를 찾아 붉은 영역의 노드를 추가합니다. 만약 TargetFrameworkVersion 노드를 .csproj 파일에 명시적으로 수정하게 되면, Visual Studio 2010 은 v2.0 이상 버전으로 변경을 해야 프로젝트 파일을 로드할 수 있기 때문에 Microsoft.Common.v1.1.targets 파일에서 변경해야 합니다.

아래의 ReportingServiceTargets 노드를 찾아 주석으로 처리하거나 삭제합니다.

아래의 _DebugSymbolsIntermediatePath 노드의 ItemGroup 을 주석으로 처리합니다. $(IntermediateOutputPath) 이미 기존의 Microsoft.CSharp.targets 에서 값이 선언되었으므로 같은 값이 추가되거나 할 경우 Collection Type 으로 간주하기 때문에 이 구문은 필요가 없습니다.

마찬가지로 아래의 구문도 $(IntermediateOutputPath) 는 Collection Type 으로 처리가 되는 것을 방지하기 위해 아래의 구문도 주석으로 처리하거나 제거합니다.

아래의 구문도 위와 같은 이유로 제거하거나 주석으로 처리합니다.

아래의 Code Analysis 기능은 Visual Studio 2003 에서 통합되어 제공되지 않기 때문에 제거하거나 삭제합니다.

Visual Studio 2010 에서 .NET Framework 1.1 빌드 하기

모든 구성이 완료 되었으면, Visual Studio 2010 에서 ConsoleApplication 을 실행해 봅니다. 빌드가 .NET Framework 1.1 로 빌드된 것을 확인할 수 있습니다.

이번 세션에서는 SharePoint 2010 Server Object Model 중에서 새롭게 등장한 LINQ to SharePoint 를 알아보도록 하겠습니다. 서버 개체 모델이므로 웹 파트 등 서버박스 위에서 실행됩니다.

LINQ 에 대한 내용은 잘 알고 계실 것이므로 구체적으로 언급하지 않아도 될 듯 하구요.
SharePoint 에서는 2010 버전에서 SharePoint 개체에 대한 LINQ를 사용할 수 있습니다.
LINQ to SharePoint 를 SPLinq 라고도 부릅니다.

LINQ to SharePoint 가 별거 아니라고 볼 수도 있지만 CAML을 가지고 작업하는 것 보다는 생산성이
백만 배 향상되었다고 개인적으로 생각합니다.

CAML은 SPQuery 라는 클래스의 Query 라는 속성에 미리 정의되어 있는 XML 태그를 사용합니다.

간단한 예를 보시면 아래와 같습니다.

query.Query =@ "<Where>

                  <And>

                    <Eq><FieldRef Name=Title/><Value Type='Text'>”+

                      title +

                    "</Value></Eq>

                    <And>

                     </Where>";

위의 구문은 조건식이 하나로 Title이라는 필드의 값이 일치하는 것만 필터링하는 내용입니다. 위 구문 정도야 그냥 쓰면 되지 라고 하실 수 있지만 조건식이 AND, OR 가 여러 개 처리된다거나 다른 목록과 조인을 한다거나 요구사항이 조금만 복잡해지면 만들기 정말 복잡합니다. 에러는 발생하지 않는데 CAML이 틀려 값이 나오지 않으면 원인 해결에도 시간이 상당히 걸립니다.

 

그래서 SharePoint 2010에서는 SPLinq를 통해서 생산성을 높여주고 있습니다.

SPLinq를 사용하기 위해서는 먼저 SharePoint 개체 모델에 대한 Entity 클래스가 생성되어야 합니다. 그리고 나면 Entity 클래스를 이용해서 LINQ 구문을 작성하면 됩니다.

 

아래로 이동해서 “SPMETAL.EXE” 를 실행하면 됩니다. /? 로 도움말을 확인하실 수 있습니다.

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\BIN

SPMETAL 이 Entity 클래스를 생성해주는 유틸리티이며 사이트 컬렉션 주소를 주면 해당 개체에 대한 프록시 클래스 형태를 제공해줍니다.

  

제가 적용할 시나리오는 아래와 같습니다.

아래처럼 공지사항이 있는데 SharePoint 라는 말이 제목에 있는 항목들만 필터링한 결과를 SPLinq를 통해 액세스해보도록 하겠습니다.

웹 파트를 만들거나 서버 박스 위에서 실행되는 유틸리티를 통해서 접근할 수 있습니다. 먼저 EXE를 통해 액세스 해봅니다.

 

Visual Studio 2010을 이용하여 WPF 응용 프로그램을 하나 생성합니다. 이름은 WpfSPLinqDemo 라고 하겠습니다.

 

이제 Entity 클래스를 생성해보도록 하겠습니다.

HJ 라는 클래스를 프로젝트에 추가해서 LINQ를 통해 액세스 하면 됩니다.

HJ 클래스를 살펴보면 SharePoint 목록에 대한 클래스와 속성을 가지고 있는 것을 알 수 있습니다.

위에서 보시는 것처럼 한글 SharePoint 를 액세스하면 클래스와 속성 이름이 한글로 나타나는 측면이 있으며 C# 코드에서도 한글로 클래스를 정의해야 한다는 것이 좀 이상해집니다. 헐~

 

이제 LINQ to SharePoint 코드를 작성해서 결과를 확인합니다.

WPF의 ListBox 컨트롤에 LINQ 결과를 바인딩해서 표시해줄 수 있습니다.

결과는 아래와 같습니다.

웹파트에 SPLinq를 적용한 결과는 아래와 같습니다.

SPLinq를 알아보았는데 실행시에는 CAML로 변경되어 처리가 됩니다. 개발자들이 직접 CAML을 작성하는 것보다는 SPLinq를 통해 생산성이 향상되는 내용을 알아보았습니다.

안녕하세요. 저는 작년에 스터디에 합류하면서 C++0x나 VC++ 10의 Concurrency Runtime에 대해서 글을 적고 강연을 했었습니다. 아직 C++0x나 Concurrency Runtime에 대한 모든 것을 다 다루지 못했지만 이번에 새로운 멤버들이 합류하여 이 분들이 제가 이전에 맡았던 부분을 맡아서 할 예정이므로 저는 새로운 것을 하려고 합니다.

제가 하려는 것은 C++/CLI에 대한 것입니다.

사실 원래 작년부터 저는 C++/CLI을 공부하면서 정리해 보려고 했는데 작년 4월에 스터디에 합류하면서 계속 미루어졌습니다.

보통 .NET에서 프로그래밍을 한다고 하면 C#으로 프로그래밍 한다고 생각합니다. 그리고 네이티브 프로그래밍을 한다고 하면 C++입니다. 그럼 C++/CLI는 무엇일까요?

이름으로 유추 해 볼까요? ‘C++/CLI의 첫 단어는 ‘C++’입니다. ‘C++’ 이라고 하니 딱 네이티브 냄새가 나는군요. 두 번째 단어는 ‘CLI’입니다. C#으로 프로그래밍 하시는 분들은 ‘CLI’가 무엇을 뜻하는지 아시죠? ‘CLI’는 .NET의 냄새를 풀풀 풍깁니다. ‘C++/CLI’라는 단어는 네이티브와 .NET의 냄새가 동시에 나지 않나요? 만약 그렇다고 생각하신 분들은 냄새를 잘 맡은 것입니다.^^

‘C++/CLI’가 네이티브와 .NET의 냄새를 동시에 풍기듯이 프로그래밍 측면에서도 ‘C++/CLI’는 네이티브와 .NET의 중간 지점에 있는 언어라고 할 수 있습니다.

폭 넓은 또는 이도 저도 아닌 어중간한

어떤 영역에서 중간 정도의 위치에 있으면 좋은 말로는 한쪽에 쏠리지 않으면서 양쪽 모든 것을 다 할 수 있다고 들을 수 있지만, 나쁜 말로는 이도 저도 아니라는 말도 들을 수 있습니다.

C++/CLI도 그런 것 같습니다.

먼저 C++/CLI의 나쁜 점은 .NET 프로그래머와 네이티브 프로그래머 양쪽 모두가 썩 마음에 들어하지 않는 언어라는 것입니다. .NET 프로그래머가 보기에는 이미 C#이라는 좋은 언어가 있어서 다른 언어는 눈에 잘 들어오지도 않고, 네이티브에는 관심이 없는 분들도 많습니다.

네이티브 프로그래머에게는 C++라는 걸출한 언어가 있고 일의 특성상 .NET으로는 하기 힘들어서 .NET 프로그래머가 사랑하는 C#도 들어올 공간이 없을 정도입니다. 그런데 C++/CLI를 보니 ‘C++’이라는 단어에 반가움을 가지고 봤더니 C++와 비슷한 것 같으면서 문법이 미묘하게 다른 것이 꽤 마음에 들지 않습니다(C++ 프로그래머가 보기에는 해괴하게 생겼습니다).

C#, C++ 어느 하나도 제대로 마스터하기 힘든데 C++/CLI를 제대로 사용하기 위해서는 .NET 프로그래머는 C++을 알아야 하고, C++ 프로그래머는 .NET을 알아야 합니다. 이 바쁜 세상에 하나도 제대로 마스터하기 힘든데 두 개나 알아야 합니다. -__-

혹시 여기까지 읽고 “C++/CLI 나쁜 언어군. 이런 잉여 언어”라고 생각하고 창을 닫으려고 하는 건 아니겠죠? 조금만 더 기다려 보세요. 이제 좋은 말을 좀 할 테니 이것도 보세요^^

그럼 이제 좋은 점을 말해 보겠습니다.

.NET과 C++(네이티브) 둘 다 각각의 장점을 많이 가지고 있지만 완벽하지는 않습니다.

.NET 프로그래머 입장에서는 아직 세상에는 C++나 C로 만들어진 라이브러리가 많고, .NET은 C++에 비해서 아직은 성능이 낮기 때문에 .NET만으로는 부족한 경우가 있습니다. 또 C++ 프로그래머 입장에서는 요즘 같이 생산성을 추구하는 환경에서 .NET에 비해 낮은 생산성 때문에.NET 환경이 부럽습니다. C++/CLI는 이런.NET 프로그래머와 C++(네이티브) 프로그래머의 아쉬운 부분을 해결해 줄 수 있습니다.

물론 C++/CLI를 사용하지 않아도 .NET에서 네이티브 라이브러리를 사용하고, C++ 프로그래머는 .NET으로 만들어진 라이브러리를 사용할 수 있지만 규모가 작지 않은 경우라면 C++/CLI를 사용하는 것보다 까다롭습니다.

제가 일하고 있는 게임 업계에서는 주력 언어는 C++이고, 예전이나 지금 만들고 있는 대 부분의 라이브러리는 C++을 사용하여 만들고 있습니다. 그러나 게임 개발을 위한 회사에서 사용할 인하우스 툴을 만들 때는 C++만큼의 고 성능을 필요로 하지 않으면서 C++로 만든 라이브러리를 사용하고, 빠르게 개발하고 유지보수가 간편하기를 원하므로 .NET과 네이티브가 결합되기를 바랍니다. 바로 이럴 때가 ‘C++/CLI’가 적격입니다.

C++/CLI의 가장 큰 단점은 C# 프로그래머가 보기에도 이상하고, C++ 프로그래머가 보기에도 생김새가 이상해서 흥미를 일으키지 못한다는 점과, C++/CLI를 올바르게 알기 위해서는 .NET과 C++을 모두 알아야 된다는 점이라고 생각합니다.

그러나 이 단점이라는 부분이 .NET과 C++ 양쪽 모두를 아는 프로그래머에게는 어느 한쪽만을 아는 프로그래머에 비해 양쪽의 장점을 적절하게 다 가져갈 수 있습니다.

.NET이나 C++ 한쪽만을 아는 사람에게는 C++/CLI는 미운 오리새끼이지만 양쪽 모두 아는 사람에게는 백조가 될 수 있습니다.

이 블로그를 통해서 아직까지는 미운 오리새끼로 취급 받고 있는 C++/CLI를 백조가 될 수 있도록 해보겠습니다.

적다 보니 생각보다 글이 길어졌네요. 첫 글을 너무 쓸데 없이 주절댄 것은 아닌가 모르겠습니다.^^;

다음부터는 .NET에서의 C++/CLI의 의미에 대해서 정리하고, C++/CLI에 대한 설명, C++/CLI를 사용한 .NET과 네이티브의 결합, C++/CLI로 .NET Framework 4 사용 이라는 순서로 글을 올려보겠습니다.

ps : C++/CLI는 .NET이 처음 나올 때는 ‘Managed C++’이라는 이름으로 불렸습니다. 그러다가 VS 2005가 나오면서 C++/CLI로 이름이 바뀌었습니다. 또한 문법적인 면에서도 차이가 있습니다.

SourceSafe 보다 더 좋은 VS TFS 2010  3부작~ 1편

울 팀장 : "XX 씨~"

나 : "네~(룰루 랄라~)"

울 팀장 : "현재 쓰고 있는 VS 2008 하고 VS 2005는 SourceSafe 에 있는거 사용하고, 신규부터 VS TFS 2010 사용하죠."

나 : "네? 그거 전부 VS TFS에 올리는 거 아닌가용????"

울 팀장: "잉? 뭐야 VS 2008에 있는거? VS TFS 2010으로 연결해서 사용할 수 있어? 그리고 TFS 2010 에서 소스 관리하는거 새로 배워야 하는거 아냐?"

나 : "네??? 왜 새로 배워요? 걍 SourceSafe 사용했던 것 처럼 체크 인/ 아웃 하면 돼요~"

울 팀장: "새로 안배워도 돼? 정말? 그리고 VS 2008 에 있는거 SourceSafe 말고 VS TFS 2010 써도 돼?"

나 : "네~~~ 훠~~ 얼씬 안정빵으로 소스 관리할 수있어요~ 이번에도 저만 믿으세요~ ㅋㅋㅋㅋ(이번엔 울 팀장에게 저녁 사달라 할까? 울 마눌님 친정갔는데 ㅋㅋㅋ)"

울 팀장 : "오 그래? 해봐"(킁 이번에도 밥 내기 해봐? 그런데 저 웃음은 뭐지??? 킁 불안해 확실할 때 해야겠당...)

넵 이제 드뎌 사용편입니다. 3부작으로 천천히 하죠 ㅎㅎㅎ

1편 : VSS 에서 VS TFS 2010으로 업그레이드 준비 작업하기
 

사용편에서는 Visual SourceSafe 2005를 사용하는 사용자 분들을 위해 앞에서 설치, 구성을 한 상태에서 진행하셔야 합니다. VS TFS 2010 을 우선 기존의 사용하는 방법 그대로 사용하면서 추가 기능을 알아보는게 더 좋을 것 같습니다.

즉~ Visual SourceSafe 2005(VSS 2005) 업그레이드 대 작전(?) 입니다.

VSS 2005 이라고 불리는 녀석이 울 회사 프로젝트의 모든 소스를 관리하는 녀석으로 한 20개 정도가 있다고 가정합니다.~ (가정 넵 요 VS 2005 하고 2008 같이 사용하는 회사도 있습니다. ^^)

울 회사는(전 백수입니다 ㅠ.ㅠ) VS 2005 부터 VS 2008 까지 프로젝트로 진행하고 있으며 개발자들은 모두 두개의 VS 를 설치하고 있다고 가정합니다. 이런 상황에서 VS TFS 2010을 사용할 수 있으냐? 넵 사용 가능합니다. 처음 부터 VS 2010을 사용하면 좋지만… 여러가지 이유로 당분간 VS 2005, 2008 을 사용해야 하는 어쩔수 없는 상황도 있을 수 있습니다.

울 VS TFS 2010을 만들어낸 Microsoft 에서는 이런 상황에 대한 지원은 기본이라 할 수있습니다.( VS 2003 은 번외편으로 하죠 ㅎㅎ 아직 완전하지는 않은듯 합니다 ^^ 제가 테스트 하구요^^)

이제 본론으로 넘어와서 이 TFS 2010 이란 녀석을 활용해야 하는데.. 솔직히 기존 프로젝트를 VS 2010으로 업그레이드 하는 것이 젤루 좋지만…. 앞에서 설명한 여러가지 이유중에 회사마다 돈을 내고 사용하는 VS의 추가 콤포넌트들이 있을 경우에는 바로 업그레이드 하기에는 조금 위험하기 때문에.. 그냥 VS의 기존 버전을 사용하는 경우도 있습니다. 그렇다면, 정말 연결을 하려면 어떻게 해야 하는가??

기존 버전에서 VS TFS 2010으로 연결하기 위해서는 다음 과 같은 파일들을 다운로드 받아서 설치만 하면 됩니다.

VS 2005 SP1 용 호환성 업데이트

VS 2008 SP1 용 호환성 업데이트

오~ 이 2개만 있으면.. 바로 사용할 수 있다는 것입니다.(한글판 다운로드입니다.^^)

그런데~~ 여기서 잠깐 주의 하실 것이 있습니다.

VS 2005에서는 최소한 Visual Studio Team System 제품군이여야 한다는 전제조건이 있습니다. VS 2008은 Professional 에서 Team Explorer 2008을 설치해서 접속해도 되지만… VS 2005는 약간 부끄러움을 타는건지(?) Team System 계열만 가능합니다.

또 하나. 바로 Service Pack관련 부분으로 어느 회사에서는 Service Pack1을 설치하지 않는 경우도 있습니다. 이 Service Pack1은 닷넷은 아닙니다. 개발자분들이 오해하시는 것중에 하나가 .NET 서비스팩 업그레이드 했으니 VS도 업그레이드 된거 아냐? 하시는데.. 넵 아닙니다.

그래서 절대 주의 하셔야 합니다.

Visual SourceSafe 2005 에서 Visual Studio Team Foundation Server 2010 으로 가기 위한 작업

Visual Studio 2005 인 경우

 - Visual Studio Team System 제품군인지 확인

 - Visual Studio Team Explorer 2005 설치

 - Visual Studio 2005 Service Pack 1 설치

Visual Studio2008 인 경우

 - Visual Studio Team Explorer 2008 설치

 - Visual Studio 2008 Service Pack 1 설치

이런 순서로 진행하셔야 합니다.

Service Pack 1 설치 후에 Team Explorer을 설치하시면.. 다시 Service Pack 1 을 설치하셔야 합니다.

그런 이제 VS TFS 2010을 접속할 수 있는 환경으로 전환이 된 것 입니다.

그런데… 울 회사 개발팀들.. 한 마디 씩 합니다. 왜 TFS 2010으로 가야 하는데????

윽~ 걍 소주 한잔 하시죠?? 하고 이야기 하면.. 소주값 만이 들어갑니다.(한달 월급이 얼마인데 ㅠ.ㅠ 잘못 카드값이 나오면 마눌님에게 둑는데 ㅠㅠ)

그래서 다음과 같이 정리 했습니다.

ㅎㅎㅎ 넵.. 이런 이유로 사용하면 좋다는 것인데요.. 일단 VSS 2005 아니 VSS 오랫 동안 사용해보신 분들이라면.. 다들 VSS 때문에 약속이나 소스 원복으로 인한 철야 작업들이 기억나실 겁니다.

VS TFS는 SQL Server를 사용하기 때문에 DB 백업/복구만 잘되어 있다면 언제든지 복구가 가능하다는 것이죠. SQL 이긴 하지만, Database의 장점과 Windows의 계정의 활용등등.. 여러 가지 장점이 있다는 것입니다. 앞에서 정리한 것으로 개발팀원들과 이야기가 끝났다면… 이제 사용해야 겠죠?

넵.. 바로 Service Pack 1 설치 다음이 사용자 계정과 소스를 TFS 2010으로 이전 작업입니다.

사용자 계정과 소스 이전 작업은 다음에~~ Soon 입니다~

Intro

안녕하세요. MFC 카테고리의 꽃집총각입니다.

한동안 여러 가지 다른 행사와 게으름으로(;;) 포스팅이 많이 늦어졌습니다 ^^; 지난 글에서는 ( [윈도우 7 멀티터치] #1 : 멀티터치 UX를 적용하는 3단계 전략 ) 멀티터치 프로그래밍을 내 애플리케이션에 적용하는 방법을 3단계로 나누어 설명하였습니다. 이 중 첫 번째 단계인 ‘추가 코딩 없이도 기본적으로 얻을 수 있는 기능들’에 대해 자세히 알아보았고, 나머지 두 단계는 기본적인 내용만 소개해 드렸습니다. 이번엔 이중에서 두 번째 단계인 제스처(gesture) 이용한 프로그래밍 방법에 대해 자세히 알아보도록 하겠습니다.

note : 지난번 까지는 프로그래밍 이야기 보다는 개념적인 설명이 위주였기 때문에 ‘Windows 7 Development’ 카테고리에 글을 올렸습니다만… 이제부터는 본격적으로 구현에 대한 이야기가 시작되니까 ‘MFC’ 카테고리에서 연재하도록 하겠습니다. 앞부분은 어느 언어를 사용하든 멀티터치 프로그래밍을 위해 알아두어야 할 공통적인 내용들이었고요, 제가 앞으로 말씀드릴 부분은 주로 MFC를 위한 구현방법이니까, 이게 맞는 거겠지요. :)

제스처를 인식하는 첫 번째 예제 프로그램

이제까지는 제가 주로 개념설명이나 이론적인 부분들을 모두 말씀 드리고 나서 예제 코드를 알아봤었는데, 이런 쌍팔년도식 학습법은 요즘은 별로 어울리지 않는 듯 합니다 ^^;… 일단은 돌아가는 예제 프로그램을 간단하게 한 번 작성해 보기로 하지요. 그게 자질구레한 설명도 줄여주고, 공부하기도 좀 더 쉬울 것 같네요 ㅎㅎ

첫 번째로 구현해볼 예제는 view 영역에 그려진 box를 터치로 조작, 변환하는 프로그램 입니다.

view 영역에 box를 하나 표시하고, 손가락으로 사각형을 이동, 회전, 확대/축소 할 수도 있고, Press  & Tap 제스처를 통해 색상을 변경할 수도 있고, Twi Finger Tap 제스처로 X표시를 하거나 지울 수도 있는 프로그램입니다. 예제를 따라서 작성해 보면 MFC 애플리케이션에서 어떻게 제스처를 다룰 수 있는지 쉽게 이해하실 수 있습니다. 해당 예제는 Windows 7 SDK에 들어있는 MFC 샘플 중에 하나입니다. 영어에 부담이 없으신 분들은 직접 Windows 7 SDK를 확인해 보셔도 좋을 것 같군요 ^^ ( http://channel9.msdn.com/learn/courses/Windows7/Multitouch/Win7MultiTouchGestureMFC/Exercise-1-Build-a-Multitouch-Gesture-Application/ )

Task 1 : MFC Application 프로젝트를 만들자

우선 Visual Studio 2010에서 MFC Application 프로젝트를 하나 만드세요. Application Wizard에서는 고전 MFC 스타일의 SDI 타입을 지정해 줍니다. Wizard의 설정 화면을 활자 설명 대신 스크린샷으로 대신하겠습니다.

Task 2 : 하드웨어 상태를 알아봅시다

본격적인 멀티터치 UX를 구현하기에 앞서, 현재 구동중인 실행환경이 멀티터치가 가능한 상태인지를 확인해야 합니다. 멀티터치를 인식 가능한 하드웨어가 연결되어 있는지, 그리고 사용 가능한 상태인지를 알 수 있어야겠지요. 이런 정보를 얻고자 할 때는 예전부터 익히 사용해오던  ::GetSystemMetrics(…) 함수를 이용하면 됩니다.

int WINAPI GetSystemMetrics( __in  int nIndex );
http://msdn.microsoft.com/en-us/library/ms724385(VS.85).aspx

GetSystemMetrics는 운영체제의 여러 가지 설정 정보들을 얻어올 수 있는 API로 예전부터 자주 사용되던 함수입니다. 윈도우 캡션 영역, 메뉴 영역 등의 너비를 얻을 수 있기 때문에 UI 작업할 때 많이 사용해 보셨을 겁니다. MFC/Win32 API에 새롭게 추가되는 기능들은 상당 부분 이렇게 이전 인터페이스를 그대로 사용하고 있기 때문에 공부하기가 특히 어렵지 않은 느낌이어서 마음에 듭니다 ㅎㅎ 이 함수로 터치인식 정보를 얻고 싶을 땐 아래의 새로운 flag들을 사용합니다.

• SM_DIGITIGER : 입력장치 상태 확인
• SM_TABLETPC : 타블렛 pc 여부 확인
• SM_MAXIMUMTOUCHES : 최대 동시입력 가능한 터치 개수

이번에 공부하면서 보니, 윈도우 XP가 타블렛 PC edition이란게 따로 있었더군요… SM_TABLETPC는 이런 정보를 확인할 때 쓰는 값이고, 나머지 두 flag는 Vista 이하 OS에서는 인식하지 않습니다. 각 항목의 자세한 값은 MSDN을 참고하시면 되고요, 기본적인 경우라면 아래의 코드를 가져다 사용하시면 되겠습니다. 현재 멀티터치 입력 가능 여부와 동시 입력 개수를 알아보는 코드입니다.

   1: BYTE digitizerStatus = (BYTE) GetSystemMetrics(SM_DIGITIZER);

   2: if ((digitizerStatus & (NID_READY | NID_MULTI_INPUT)) == 0) //Stack Ready + MultiTouch

   3: {

   4:     AfxMessageBox(L"현재 터치 입력이 불가능한 상태입니다.");

   5:     return FALSE;

   6: }

   7:  

   8: BYTE nInputs = (BYTE) GetSystemMetrics(SM_MAXIMUMTOUCHES);

   9:  

  10: CString str;

  11: str.Format(L"현재 %d개의 터치를 동시 인식할 수 있습니다.", nInputs);

  12: AfxMessageBox(str);

그리고… 멀티터치 프로그래밍 공부가 하고 싶은데 하드웨어가 마땅치 않을 때… 제가 예전에 말씀 드렸던 시뮬레이션 환경 설정 ( http://multitouchvista.codeplex.com/ ) 기억하고 계시죠? 기억이 안 나시는 분은 ( [멀티터치]멀티터치 프로그래밍 환경 구축하기 ) 링크를 참고해 주세요 ^^

위에 있는 코드를 그대로 복사해서 CTouchGestureDemoApp::InitInstance() 함수에 넣어주세요. 그리고 애플리케이션을 실행하면 아래와 같은 창이 뜹니다.

아따, 많기도 하여라 @.@… 동시에 255개의 터치를 인식할 수 있군요. 저도 터치 입력 환경을 시뮬레이션 해서 공부하고 있는데, 이런 경우 동시 입력 개수가 255개로 나오게 됩니다 ㅎㅎ

Task 3 : View 영역에 사각형을 그리자!

샘플을 따라 해보기 위해서 화면에 box를 그려주는 코드를 우리가 일일이 직접 작성할 필요는 없겠죠. 지금은 제스처의 인식 방법을 알아보고 싶은 거니까요. Windows 7 SDK에서 box 드로잉을 해주는 코드를 제공하고 있으니, 이 코드를 사용하도록 하겠습니다. 그리고 우리는 멀티터치 제스처를 이용하는 방법에만 집중하기로 합시다. box를 그려주는 CDrawingObject라는 클래스의 소스는 아래에서 다운 받으실 수 있습니다.

DrawingObject.cpp

DrawingObject.h

위의 파일을 다운 받으셔서 프로젝트에 포함하고, stdafx.h 파일의 아래쪽에 헤더파일 인클루드 구문을 넣어줍니다. 기본적으로 작성되어 있는 상태에서 #include <afxcontrolbars.h> 아래에 넣어주면 됩니다.

   1: #include "DrawingObject.h"

그리고 ChildView.h를 열고 View 클래스의 멤버 변수로 CDrawingObject 객체를 하나 선언해 줍니다.

   1: // The drawing object

   2: CDrawingObject m_drawingObject;

마찬가지로 View 클래스의 멤버 변수로, box의 확대/축소와 이동을 처리하기 위해 필요한 변수들을 몇 가지 더 추가해 줍니다.

   1: // Needed for drawing object position and size calculations

   2: double m_dblZoomRatioStart;

   3: double m_dblZoomRatioTotal;

   4: CPoint m_ptCenter;

그리고 box를 그려주기 위해서, CChildView.cpp에 있는 CChildView::OnPaint() 함수의 제일 아래쪽에 box drawing 코드를 넣어줍니다.

   1: m_drawingObject.Paint(&dc);

그다음, 윈도우 크기를 변경할 때 box의 크기와 위치를 기본값으로 초기화 해주는 코드를 넣어줍니다. box가 화면영역을 벗어나거나 한 경우 초기화 코드가 있으면 좋겠지요. 그러기 위해서 먼저 WM_SIZE 메세지 핸들러를 추가합니다.

Ctrl + Shift + X 키를 눌러 MFC 클래스 위자드(MFC Class Wizard)를 띄웁니다. MFC 클래스 위자드는 VC++ 6.0에 있던 툴인데, Visual Studio .NET 2002 통합 환경으로 변경되면서 사라졌지만 이번에 Vusial Studio 2010에서 새롭게 부활했습니다. 거의 10년 만이라고 할 수 있군요. 예전에 사용해 보신 분들이라면 아주 익숙한 인터페이스 일겁니다. 여기에서 CChildView의 WM_SIZE 메세지를 선택해서 핸들러를 추가해 줍니다. 아래 스크린샷을 참고하세요.

MFC 클래스 마법사의 부활은 VS2010의 핵심적인 변화 요소중에 하나입니다. 클래스 마법사의 활용 부분은 다음 기회에 별도의 포스팅으로 자세하게 설명하도록 하겠습니다.

생성된 CChildView::OnSize 함수에 아래의 코드를 넣어줍니다.

   1: m_drawingObject.ResetObject(cx, cy);

여기까지 진행했다면 이제 drawing 처리의 완성입니다. 프로젝트를 빌드하고 애플리케이션을 실행하면 아래와 같이 빨간 box가 drawing 되는 모습을 확인하실 수 있습니다.

Outro

한 번의 포스팅에서 예제의 완성과 추가설명까지 모두 다루려고 했지만 그러기엔 글이 너무 길어질 것 같네요. 이쯤에서 한 번 호흡을 끊고, 다음 포스팅에서 실질적인 제스처 인식 코딩 방법과 추가설명을 정리하도록 하겠습니다. (下편은 바로 올릴 예정이니 조금만 기다려 주세요)

이번 글에서는 제스처를 인식하는 예제 프로그램의 작성 방법을 단계적으로 소개하고, 하드웨어의 멀티터치 인식 여부 확인 방법을 알아보았고, 아주 짧게나마 VS2010에서 새롭게 부활한 MFC 클래스 마법사에 대한 언급이 있었고, 첫 번째 멀티터치 예제의 작성 방법을 절차적으로 알아보았습니다. 제스처를 이용한 멀티터치 구현 하(下)편에서는 제스처를 인식해 box를 이동, 변환 시키는 코드의 작성과 샘플을 통해 알아볼 제스처 인식 프로그래밍의 부가 정보 및 팁들을 소개해 드리도록 하겠습니다.

그럼 곧바로 하(下)편으로 찾아 뵙겠습니다.
감사합니다 ^^*

Reference

• http://msdn.microsoft.com/en-us/library/dd940543(v=VS.85).aspx
• http://channel9.msdn.com/learn/courses/Windows7/Multitouch/Win7MultiTouchGestureMFC/Exercise-1-Build-a-Multitouch-Gesture-Application/