이번 글은 길이가 좀 깁니다. 내용은 복잡한 것이 아니니 길다고 중간에 포기하지 마시고 쭉 읽어주세요^^


이전 회에서는 PPL에 대한 개념을 간단하게 설명했고, 이번에는 PPL의 세가지 feature 중 태스크(Task)에 대해서 설명하려고 합니다. 태스크에 대한 설명은 이미 이전에 정재원님께서 블로그를 통해서 설명한 적이 있습니다. 정재원님의 글은 태스크 사용 예제 코드를 중심으로 설명한 것으로 저는 그 글에서 빠진 부분과 기초적인 부분을 좀 더 설명하려고 합니다.

 

태스크라는 것은 작업 단위라고 생각하면 좋을 것 같습니다. 작업이라는 것은 여러 가지가 될 수 있습니다. 피보나치 수 계산, 배열에 있는 숫자 더하기, 그림 파일 크기 변경 등 작고 큰 작업이 있습니다. 보통 크기가 큰 작업은 이것을 작은 작업 단위로 나누어 병렬 처리를 하기도 합니다.

 

PPL의 태스크는 작업을 그룹 단위로 묶어서 병렬로 처리하고 대기 및 취소를 할 수 있습니다.

 

 


태스크 핸들

태스크 핸들은 각각의 태스크 항목을 가리키며 PPL에서는 task_handle 클래스를 사용합니다. 이 클래스는 람다 함수 또는 함수 오브젝트 등을 태스크를 실행하는 코드로 캡슐화 합니다. 태스크 핸들은 캡슐화 된 태스크 함수의 유효 기간을 관리하기 때문에 중요합니다. 예를들면 태스크 그룹에 태스크 핸들을 넘길 때는 태스크 그룹이 완료 될때까지 유효해야합니다.


보통 태스크 관련 예제 코드를 보면 task_handle 대신 C++0x의 auto를 사용하는 편이 코드가 더 간결해지므로 task_handle 보다는 auto를 사용하고 있습니다.


 

 

unstructured structured Task Groups

태스크 그룹은 unstructured structured 두 개로 나누어집니다.

두개의 태스크 그룹의 차이는 스레드 세이프하냐 안하느냐의 차이입니다.

unstructured는 스레드 세이프 하고 structured는 스레드 세이프 하지 않습니다.


태스크 관련 예제에 자주 나오는 task_group 클래스는 unstructured 태스크 그룹이고, structured_task_group 클래스는 structured 태스크 그룹을 뜻합니다.

 

unstructured 태스크 그룹은 structured 태스크 그룹보다 유연합니다. 스레드 세이프 하며 작업 중 taks_group::wait를 호출하여 대기한 후 태스크를 추가한 후 실행할 수 있습니다. 그렇지만 성능면에서 structured 태스크 그룹이 스레드 세이프 하지 않으므로 unstructured 태스크 그룹보다 훨씬 더 좋으므로 적절하게 선택해서 사용해야 합니다.

 

structured 작업 그룹은 스레드 세이프 하지 않기 때문에 Concurrency Runtime에서는 몇가지 제한이 있습니다.

- structured 작업 그룹 안에 다른 structured 작업 그룹이 있을 경우 내부의 작업 그룹은 외부의 작업 그룹보다 먼저 완료해야 한다.

- structured_task_group::wait 멤버를 호출한 후에는 다른 작업을 추가한 후 실행할 수 없다.


 

 

초간단!!! 6단계로 끝내는 태스크 사용 방법


1. ppl.h 파일을 포함합니다.

   #include <ppl.h>

 

2. Concurrency Runtime의 네임 스페이를 선언합니다.

   using namespace Concurrency;

 

3. 태스크 그룹을 정의합니다.

  structured_task_group structured_tasks;

 

4. 태스크를 정의합니다.

  auto structured_task1 = make_task([&] { Plus(arraynum1, true); } );

 

5. 태스크를 태스크 그룹에 추가한 후 실행합니다.

  structured_tasks.run( structured_task1 );

 

6. 태스크 그룹에 있는 태스크가 완료될 때까지 기다립니다.

  structured_tasks.wait();

 

위의 순서대로 하면 태스크를 사용할 수 있습니다. 태스크 사용 참 쉽죠잉~ ^^.

참고로 여러 개의 태스크를 그룹에 추가하고 싶다면 6번 이전에 4번과 5번을 추가할 개수만큼 반복하면 됩니다.


* 4번의 Plus(arraynum1, true);는 하나의 태스크에서 실행할 함수입니다.

 


PPL의 태스크를 사용하면 병렬 프로그래밍을 간단한 6단계만으로 끝낼 수 있습니다. 만약 현재의 Win32 API로 이것을 구현하기 위해서는 학습에 많은 시간을 보낸 후 저수준의 API를 사용하여 구현해야 되기 때문에 구현 시간과 안정성에서 PPL의 태스크보다 손해를 봅니다.




태스크 그룹과 스레드 세이프

unstructured structured 태스크 그룹의 차이가 스레드 세이프 유무의 차이라고 했는데 이 말은

unstructured 태스크 그룹은 복수의 스레드에서 호출 및 대기를 할 수 있지만 structured 태스크 그룹은 그것을 생성한 스레드에서만 호출 및 대기를 할 수 있습니다.


예를 들면 스레드 A, 스레드 B가 있는 경우 스레드 A와 B에서 태스크를 실행 후 대기를 한다면 unstructured 태스크 그룹을 사용해야하고, 오직 하나의 스레드에서만(스레드 A에서만) 태스크를 실행 후 대기를 한다면 structured 태스크 그룹을 사용합니다.


스레드 세이프는 스레드 세이프 하지 않는 것보다 오버헤드가 발생합니다. 즉 스레드 세이프 버전은 스레드 세이프 하지 않은 버전보다 성능이 떨어진다는 것이죠.

그러니 태스크 그룹을 어떤 방식으로 사용할지 파악 후 스레드 세이프 필요성에 따라서 unstructured 태스크 그룹과 structured 태스크 그룹 중 상황에 알맞은 것을 선택해서 사용해야 합니다.




ps : 제가 8월 14일 글을 공개할 때 태스크 그룹의 스레드 세이프 특성을 잘 못 이해하여 잘못된 내용을 전달하였습니다. 그래서 오늘 글을 다시 수정하였습니다. ;;;;;;

다음부터는 틀린 글을 올리지 않도록 조심하겠습니다. ^^;;;;;;


< 인사 및 소개 >

안녕하세요.
저는 이번에 vsts2010 에 참여하게 된 조진현 이라고 합니다.

어떤 주제에 대해서 글을 쓰다는 것은 무척 어려운 일입니다.

그렇기 때문에, 이 스터디 참가를 굉장히 망설이기도 했습니다.
많은 분들과 함께 열정을 가지고 참가를 결심했고, 드디어 처음으로 글을 남기게 되었습니다.
제가 가장 우려하는 것은 잘못된 지식을 전달하는 것입니다.
그래서 조심스러운 마음으로 글을 작성할 것입니다.
잘못된 부분이나 미흡한 부분이 있으면, 바로 지적해주시면 감사하겠습니다.

제가 언급할 큰 주제는 DirectX 11 과 관련이 있습니다.
그 중에서도 멀티 코어를 활용한 DirectX 사용에 초점을 두고 글을 전개할 생각입니다.
글의 주요 대상은 DirectX9 를 사용하시다가 DirectX11 을 사용하고자 하시는 분들입니다.

일단 방대한 변화에 대해서 모두 나열하기는 힘듭니다.

그래서 간단히 제가 코딩을 하면서 필요했던 API 위주로 살펴보면서 변화를 언급하고자 합니다.
그런데 하나 문제가 있습니다.
현재 DirectX 11 은 하드웨어 가속이 지원되지 않습니다.
오직 REF 모드로만 작동을 합니다.
아마도 아직 정식으로 widnows 7 이 출시가 이루어지지 않아서 그런 듯 합니다.
이점, 꼭 주의하시기 바랍니다.
괜히 DirectX 11 예제 실행했다가, 실행 성능이 떨어진다고 컴퓨터를 부수는 행위는 자제해 주세요.^^


< 사라진 Direct3D 오브젝트를 찾아서... >

우리가 가장 먼저 접하게 되는 DirectX 의 API 는 CreateDevice() 일 것입니다.
사실 이전 버전까지는 CreateDevice() 에 대해서 별도로 언급할 내용이 없었을 것이지만,
늘(?) 그렇듯이 DirectX 의 변화를 설명해주는 API 가 바로 CreateDevice() 입니다.
일단 CreateDevice() 를 위한 관련 변수들부터 봐야겠죠?
 



잠깐!!
가장 먼저 헤더 파일들을 살펴보는게 순서이죠.

헤더는 다음과 같이 변경되었습니다.
굳이 헤더의 용도에 대해서 일일이 나열하지는 않았습니다.

// Direct3D11 includes
#include <dxgi.h>
#include <d3d11.h>
#include <d3dCompiler.h>
#include <d3dx11.h>
#include <dxerr.h>

 

라이브러리 링크는 아래의 것들을 해주시면 됩니다.

#pragma comment( lib, "dxguid.lib" )
#pragma comment( lib, "d3dcompiler.lib" )
#pragma comment( lib, "dxerr.lib" )
#pragma comment( lib, "dxgi.lib" )
#pragma comment( lib, "d3d11.lib" )
#pragma comment( lib, "d3dx11.lib" )




변수들을 나열해 보겠습니다.




 생소한 부분이 눈에 보이시나요?
 'ID3D11DeviceContext' 라는 것이 새롭게 등장했습니다. ( 다음 번에 언급할 것입니다. )
 그리고 Direct3D 인터페이스가 사라진 것을 찾으셨습니까?




위의 그림은 DirectX 9 의 아키텍쳐입니다.
우리가 작성하는 프로그램은 오직 Direct3D 나 GDI 를 통해서 저수준의 하드웨어와 통신을 할 수 있었습니다.

그런데 현재의 DirectX 아키텍쳐는 아래와 같습니다.



 여기서 또 하나 생소한 것이 등장했습니다.
바로 DXGI ( DirectX Graphics Infrastructure ) 입니다.
"DirectX9 에서 사라진 'Direct3D 오브젝트'를 'DXGI' 가 대체하는게 아닐까?" 라는 의문이 들었다면,
박수를 보내드리고 싶습니다.( 브라보~~ )


네, 맞습니다.
'DXGI' 라는 것이 바로 사라진 'Direct3D 오브젝트' 입니다.
'Direct3D 오브젝트' 의 역활에 대해서 혹시 기억하십니까?
하드웨어와 연결된 디바이스들을 나열하고, 모니터로 출력되는 결과들을 관리해주기도 했었습니다.
우리가 관리하기 힘든 저 수준의 작업들을 바로 이 'Direct3D 오브젝트'가 했었습니다.
그런데 이제는 이것을 'DXGI' 가 해주고 있습니다.
( IDXGISwapChain 보이시나요? 이것도 다음 회에 언급하겠습니다. )
 

아키텍쳐 구조를 보시면 아시겠지만, DirectX9 까지는 일반 애플리케이션에서 DirectX API 를 통하지 않고는
DirectX 를 사용할 수 없었습니다.
그런데 최근에는 일반 애플리케이션은 모두 DXGI 를 통해서 DirectX 를 사용하고 있습니다.
( 저만 놀라운 것은 아니겠죠? +_+ )
마이크로소프트에서도 강조하고 있는 사실 중에 하나가 바로 DirectX 는 더 이상 게임만을 위한 것이 아니라는 것입니다.
이제 사라진 줄 알았던 'Direct3D 오브젝트' 가 DXGI 라는 사실을 알았습니다.
앞으로 저수준의 작업이 필요하면 DXGI 를 직접 제어하거나 DirectX API 를 이용하셔도 됩니다.


< 다음 회에는... >

다음 번에는 실제로 DirectX API 를 이용한 초기화 작업에 대해서 다루고자 합니다.
즉, 우리가 앞서 선언했던 변수들에 대한 이야기를 하겠습니다.


이제 본격적으로 VC++ 10의 병렬 프로그래밍에 대한 이야기를 시작합니다.

첫 번째는 이름만 들어도 딱 '병렬 프로그래밍' 이라는느낌을 주고 가장 많이 사용될 것으로 생각하는 Parallel Patterns Library (PPL)입니다정말 이름에서 딱 느낌이 오죠 ^^



PPL은 크게 세 개의 features로 나누어집니다.

1. Task Parallelism : 병렬적으로 여러 가지 작업 처리

2. Parallel algorithms : 데이터 컬렉션을 제너릭 알고리즘으로병렬 처리

3. Parallel containers and objects :concurrent 접근이 가능한 제너릭 컨테이너

 


PPL 모델은 C++의 Standard Template Library(STL)과비슷합니다.

예를 들면 STL에는 for_each 라는 것이 있는데 PPL에는 이것의 병렬 버전인 parallel_for_each가 있습니다. 뒤에 설명하겠지만 parallel_for_each에 대해서 간단하게 말하면 array의 항목을 순회하는 parallel 알고리즘입니다.



PPL을 사용하기 위해서는 먼저 namespace Concurrency를 선언한 후 ppl.h 파일을 포함합니다.
........
#include <ppl.h>

using namespace Concurrency;
..............


먼저 parallel_for_each를 사용한 코드를 보여 드리겠습니다. parallel_for_each는 다음에 자세히 설명하겠으니 이번은 PPL 이라는 것이 어떻게 사용하는지만 아래 코드를 통해서 보세요^^

< 리스트 1. parallel_for_each 예제 >

#include <ppl.h>

#include <array>

#include <algorithm>

 

using namespace std;

using namespace std::tr1;

using namespace Concurrency;

 

int main()

{

   // Create anarray object that contains a few elements.

   array<int, 3> a = {13, 26, 39};

 

   // Use thefor_each algorithm to perform an operation on each element

   // of the arrayserially.

  for_each(a.begin(), a.end(), [&](int n) {

      // TODO:Perform some operation on n.

   });

 

   // Use theparallel_for_each algorithm to perform the same operation

   // in parallel.

  parallel_for_each(a.begin(), a.end(), [&](int n) {

      // TODO:Perform some operation on n.

   });

}


<리스트 1>의 코드를 보면 람다를 사용한 부분도 보이죠? 예전에 제가 C++0x의 새로운 기능에 의해 C++의 성능과 표현력이 향상 되었다고 이야기 했습니다. 이런 장점들이 PPL에 많은 기여를 하였습니다.




PPL과 OpenMP

예전에 PPL이 MSDN 매거진을 통해서 공개 되었을 때 많은 분들이 OpenMP와 비슷하게 보시고 왜 기존에 있는 것과 같은 것을 또 만드냐 라는 이야기를 하는 것을 들은 적이 있습니다.

PPL과 OpenMP는 같은 것이 아닙니다. 표현 방법이 얼핏 비슷하게 보일지 몰라도 개념이나 기반은 많이 다릅니다.

OpenMP는 pragma 지신문이고 PPL은 순수 C++ 템플릿으로 만들어진 라이브러리입니다.
그래서 PPL은 표현성과 유연성이 OpenMP에서 비해서 훨씬 더 뛰어납니다.
또한 PPL은 Concurrency Runtime 기반 위에 구축되므로 동일한 런타임을 기반으로 하는 다른 라이브러리와 잠재적 상호 운용성이 제공됩니다.

PPL은 어떤 것인지, 왜 OpenMP 보다 더 좋은지 이후에 제가 적을 글을 보면 쉽게 알 수 있으리라 생각합니다.


오늘은 PPL의 개념에 대한 이야기로 마치고 다음에는 PPL의 하나인 task에 대해서 이야기 하겠습니다.
시간 여유가 있거나 task에 대해서 빨리 알고 싶은 분들은 일전에 정재원님이 task 예제를 설명한 글을 올린 적이 있으니 먼저 그것을 보면서 예습을 하는 것도 좋습니다.



Concurrency Runtime

VC++ 10 Concurrency Runtime 2009.07.30 06:00 Posted by 흥배

VSTS 2010 VC++ 10의 큰 핵심 feature 두 가지를 뽑으라고 하면 저는 C++0x와 Concurrency Runtime 두 가지를 뽑고 싶습니다.

VC++ 10
은 시대의 변화에 맞추어 새로운 C++ 표준과 병렬 프로그래밍을 받아들였습니다.

현재도 Win32 API에 있는 Thread  관련 API를 사용하여 병렬 프로그래밍을 할수 있습니다. 하지만 이것만으로 병렬 프로그래밍을 하기에는 너무 불편합니다.
그래서 VC++ 10에는 Concurrency Runtime 이라는 것이 생겼습니다.



Concurrency
Parallel의 차이


Concurrency는 병행, Parallel은 병렬이라고 합니다.

Concurrency는 독립된 요구를 동시에 처리하고, Parallel은 하나의 task를 가능한 Concurrency로 실행할 수 있도록 분해하여 처리합니다.

< 그림 출처 : http://blogs.msdn.com/photos/hiroyuk/picture9341188.aspx >


VSTS 2010에서는 Concurrency는 런타임 용어 Paralell은 프로그래밍 모델 용어가 됩니다.
이를테면 프로그래밍 때에 분해하여 런타팀에 넘기면(이것이 병렬화), 런타임은 그것을 Parallel로 실행합니다. Concurrency Runtime은 Parallel 런타임으로 이해하면 될 것 같습니다.




Concurrency Runtime

< 그림 출처 : http://blogs.msdn.com/photos/hiroyuk/picture9341189.aspx >

Cuncurrency Runtime은 C++ 병행 프로그래밍 프레임워크입니다. Cuncurrency Runtime복잡한 parallel code 작성을 줄여주고, 간단하게 강력하고, 확장성 있고 응답성 좋은 parallel 애플리케이션을 만듭니다. 또한 공통 작업 스케줄러를 제공하며 이것은 work-stealing 알고리즘을 사용하여 프로세싱 리소스를 증가시켜 애플리케이션의 확장성을 높여줍니다.

 


Cuncurrency Runtime에 의해 다음의 이점을 얻을 수 있습니다.

1. data parallelism 향상 : Parallel algorithms은 컬럭션이나 데이터 모음을 복수의 프로세서를 사용하여 배분하여 처리합니다.

2. Task parallelism : Task objects는 프로세서 처리에 독립적으로 복수 개로 배분합니다.

3. Declarative data parallelism : Asynchronous agents와 메시지 전달로 어떻게 실행하지 몰라도 계산을 선언하면 실행됩니다.

4. Asynchrony : Asynchronous agents는 데이터에 어떤 일을 처리하는 동안 기다리게 합니다.

 

 

Cuncurrency Runtime 컴포넌트는 네 가지로 나누어집니다.

1. Parallel Patterns Library (PPL)

2. Asynchronous Agents Library (AAL)

3. work scheduler

4. resource manager

 

이 컴포넌트는 OS와 애플리케이션 사이에 위치합니다.


< 그림 출처 : MSDN >


Cuncurrency Runtime의 각 컴포넌트는 아래의 네 개의 헤더 파일과 관련 되어집니다.

컴포넌트

헤더 파일

Parallel Patterns Library (PPL)

ppl.h

Asynchronous Agents Library (AAL)

agents.h

Concurrency Runtime work scheduler

concrt.h

Concurrency Runtime resource manager

concrtrm.h

 

 

Concurrency Runtime을 사용하기 위해서는  namespace Concurrency를 선업합니다.

Concurrency RuntimeC Runtime Library (CRT)를 제공합니다.


Concurrency Runtime의 대부분의 type와 알고리즘은 C++의 템플릿으로 만들어졌습니다. 또한 이 프레임워크에는 C++0x의 새로운 기능이 많이 사용되었습니다.

대부분의 알고리즘은 파라메터 루틴을 가지고 작업을 실행합니다. 이 파라메터는 람다 함수, 함수 오브젝트, 함수 포인터입니다.



처음 들어보는 단어를 처음부터 막 나오기 시작해서 잘 이해가 안가는 분들이 있지 않을까 걱정이 되네요. 그래서 핵심만 한번 더 추려 보겠습니다.^^

1. Concurrency는 병행, Parallel은 병렬.
2. VSTS 2010에서는 Concurrency는 런타임 용어로 Paralell은 프로그래밍 모델 용어.
3. 프로그래밍 때에 분해하여 런타팀에 넘기면(이것이 병렬화), 런타임은 그것을 Parallel로 실행.
4. Cuncurrency Runtime은 C++ 병행 프로그래밍 프레임워크로 복잡한 parallel code 작성을 줄여주고, 간단하게 강력하고, 확장성 있고 응답성 좋은 parallel 애플리케이션을 만들수 있으며 공통 작업 스케줄러를 제공하며 이것은 work-stealing 알고리즘을 사용하여 프로세싱 리소스를 증가시켜 애플리케이션의 확장성을 높여준다.

5. Cuncurrency Runtime 컴포넌트는 네 가지로 나누어진다.

  1. Parallel Patterns Library (PPL)

  2. Asynchronous Agents Library (AAL)

  3. work scheduler

  4. resource manager



그럼 다음에는 Parallel Patterns Library(PPL)에 대해서 이야기 하겠습니다.^^





VSTS 2010 팀 3분기 맴버 모집

VSTS 2010 팀 블로그 2009.07.06 15:22 Posted by POWERUMC

안녕하세요. 저희 VSTS 2010 팀 블로그는 .NET Framework 4.0 과 VSTS 2010 에 대한 정보를 제공하는 공식 팀 블로그 입니다.

   

현재 저희 팀은 학생을 비롯하여, 개발자, 아키텍처, 컨설턴트 등 다양한 분야의 전문가와 Microsoft MVP 분들이 현재까지도 활동을 하고 계십니다.

VSTS 2010 팀의 지난 2분기 활동을 모두 마치고, 올해 3분기를 이끌어가실 새로운 팀 맴버를 모집합니다. 저희 팀에서는 아래와 같은 활동을 하게 됩니다.

   

VSTS 2010 팀 활동 분야   

스터디

매월 2 오프라인 스터디를 운영하여, 기술적인 부분을 공유하고 토론하는 시간을 갖습니다.

블로그

팀 블로그를 통해 자신만의 분야 또는 배우고 싶은 분야를 공부하여 블로그에 게시할 수 있는 공간을 제공합니다. 다양한 분야의 전문가들도 함께 참여하여 VSTS 2010 에 대한  중요한 피드를 제공합니다.

세미나 기타 활동

세미나 강사 또는 다양한 외부 활동의 기회를 제공해 줍니다.

Microsoft MVP 추천

Microsoft Korea MVP Lead, Microsoft D&PE, Microsoft MVP 추천을 드리며 적극 지원해 드립니다.


모집 대상

대상

무관

지원 자격

1.     .NET Framework 3.5 와 Visual Studio 2008 의 신 기능에 대해 알고 있는 분
2.     자신의 블로그를 운영하고 계신 분
3.     무언가에 도전하고 싶은 열정을 갖은 분

모집 분야

  • Cloud Development
  • Parallel Development
  • Web Development
  • Windows 7 Development
  • RIA Development
  • Architect Development
  • Office Business Application Development
  • .NET Framework 4.0
  • Visual Studio 2010
  • Visual Studio Team System 2010
  • ETC…

   

   

지원 방법

아래의 자신의 프로필을 umc골뱅이dotnetxpert.com 으로 보내주십시오. 반드시 아래의 양식을 지켜주십시오.

이름

홍길동

블로그

자신의 블로그 주소

소개

회사 및 소속, 자신의 소개

지원 분야

Web Development (중복 가능)

   

마감

2009년 7월 16일까지 지원 메일을 받습니다. 많은 지원 바랍니다. ^^

   

참고로 배우고자 지원하시는 분들은 정중히 사과드립니다. 저희 팀의 스터디에서는 여러분들에게 아무것도 가르쳐주지 않습니다.

저희 팀에서는 실력을 보고 맴버를 선발하지 않습니다. 물론 실력이 출중하면 좋겠지만 새로운 VSTS 2010 분야는 어느 누구도 밟아보지 않은 새로운 황야와 같습니다. 새로운 길을 함께 가실 활동력이 충분하신 분들은 꼭 지원해 주시기 바랍니다. ^^

새롭게 추가된 Extension Manager

이번 Visual Studio 2010 에서는 새로운 Visual Studio 확장 가능한 기능을 제공합니다. 이전의 Visual Studio Extensibility(VSX) 는 그 개발하기 위한 환경을 갖추는 것도 힘들었지만, 아마도 좋은 확장 기능을 찾는 것이 더 힘들었었지요.

이러한 Visual Studio 확장 기능과 Industry Partner 의 제품을 소개하고 검색할 수 있는 Visual Studio Gallery 웹 사이트가 아마도 가장 신뢰할 수 있고 유일한 곳이었습니다. 지금 보이는 웹 사이트는 Visual Studio 2010 과 서비스를 통합하기 위하여 얼마 전에 개편이 되었습니다. 그리고 새롭게 확장된 기능들로 카테고리도 새롭게 정비하고 추가가 되었네요.

[그림1] Visual Studio Gallery 웹 사이트 리뉴얼

 

새로운 표준적인 배포 패키징

그리고 Visual Studio 2010 은 확장 기능을 신뢰할 수 있고, 쉽게 배포하고 사용할 수 있는 배포 방법으로 VSIX 배포 패키징을 지원하게 되었습니다. VSIX 는 .NET Framework 에서 제공하는 패키징 방법으로 System.IO.Packaging 으로 신뢰할 수 있고 범용적인 ZIP 압축 방법을 통한 패키징 방법입니다.

System.IO.Packaging 은 .NET Framework 3.0 부터 지원하는 XPS Document 를 배포하기 위해 지원이 되었고 최근에는 실버라이트의 XAP 에도 표준적인 패키징 기술이 적용된 것으로 알고 있습니다.

System.IO.Packaging 은 아래의 링크를 통해 자세한 내용을 확인하세요.

A New Standard For Packaging Your Data
http://msdn.microsoft.com/en-us/magazine/cc163372.aspx

 

Visual Studio Extension Manager

Visual Studio 2010 에서는 확장 기능을 개발하기 위해 MEF Component 를 제공합니다. 개발자가 Visual Studio 의 코드 편집기를 가장 많이 사용하고, 그래서인지 Visual Studio 2010 의 WPF 기술은 코드 편집기가 주 타겟이 되었던 것 같습니다. 그래서 코드 편집기는 WPF 를 통해 화려한 모습으로 변신하였고 내부적인 코드 편집기의 아키텍처링도 완전히 바뀐 모습입니다.

새로운 코드 편집기는 기존의 인터페이스를 모두 버리고, Wpf 접두어가 붙힌 IWpfTextView 등의 인터페이스가 대거 등장하게 되었습니다. 그리고 대부분의 확장 기능은 코드 편집기를 쉽게 확장할 수 있는 인터페이스를 제공합니다. 여기에 MEF(Managed Extensibility Framework) 를 사용하여 인터페이스가 원하는 표준적인 메타데이터(Metadata) 만 선언해 주면 쉽게 확장 기능을 개발도 할 수 있습니다.

사설은 여기까지 마치고 Visual Studio 2010 의 Extension Manager 를 구경해 볼까요?

[그림2] Tools>Extension Manager

   

[그림3] 쉬운 확장 기능 검색과 설치

Online Gallery 를 통해 Visual Studio Gallery 사이트에 등록된 Visual Studio 2010 을 지원하는 컴포넌트를 자동으로 검색하고 DownLoad 버튼을 누르면 바로 설치를 할 수 있습니다.

[그림4] Demo Dashboard 확장 기능을 설치한 모습

아직은 많은 확장 기능 컴포넌트가 등록되지 않았지만, Beta 1 버전이 출시가 된지 몇 일 안된것을 고려한다면 그리 적은 양은 아닌 것 같네요. 현재까지 제공되는 확장 기능을 가지고 노는 것만으로 쏠쏠한 재미가 될 듯 하네요...

   

Visual Studio 2010 Beta 1 이 Microsoft MVP 에게 공개되는 것을 시점으로 지난 20일에는 일반인들에게도 공개가 되었습니다. 이미 구글 검색을 해보면 알겠지만 이번 Beta 1 릴리즈에 대한 소식이 미어 터질 정도로 쏟아져 나오고 있습니다.
 
Visual Studio 2010 Beta 1 SDK 도 Microsoft Download Center 에서 Shell-Integrated 만을 먼저 공개하였습니다. SDK 까지 내놓았다는 것은 이미 Visual Studio 2010 Beta 1 버전임에도 왠만한 IDE 의 아키텍트는 구현이 되었다는 증거겠죠?
 
Visual Studio 2010 SDK Beta 1
 
 
Microsoft MVP 에게는 이번 Beta 1 버전이 나오기 전에 신청자에 한해서 이와 유사한 버전이 공개가 되었었습니다. 이번 Beta 1 과는 빌드 버전이 크게 차이는 없습니다만 이번 Beta 1 에서는 내부적으로 훨씬 많은 기능 향상이 있었습니다. Parallel Debugging 도 완성이 되었고 Visual Studio Gallery 의 리뉴얼과 함께 Extension Manager 도 정상적으로 가동이 되는 듯 합니다.
 
특히나 이유 없이 뻗어버리던 거센 반항은 이번 Beta 1 에서는 겪어보지 못했습니다. (MSDN Forum 에서는 Hang 하신 분들이 몇 분 계시더군요)
 
그런데 문제는 내부적으로 크게 변화된 점은 눈에 띄지 않습니다만, VSX 쪽에서는 미미하게, 그리고 많은 폭으로 (도대체 무슨 의미? -_-) 변화가 찾아왔습니다. 이번 Visual Studio 2010 Beta 1 는 Managed Extensibility Framework 의 Plugin Architect 로 만들어졌으며 Managed Extensibility Framework 을 모르고서는 Visual Studio 2010 을 안다고도 할 수 없어졌습니다. 이미 Beta 1 의 상당한 확장 기능은 MEF 로 구현되었고 이번에 새롭게 추가된 Extension Manager 의 확장 기능도 MEF 가 그 기본이 되고 있기 때문입니다.
 
 
어쨌든 기존의 Visual Studio 2008 의 Package 들을 Visual Studio 2010 으로 마이그레이션 하면서 파악하기 힘든 오류를 턱턱 뱉어냈는데 다행히도 아래의 링크에서 그 문제 해결 방법을 가이드하고 있네요.
 
[그림1] Visual Studio 2008 Package 마이그레이션 오류
 
Visual Studio 2010 SDK Beta 1 Readme
 
 
일단 Visual Studio 2010 의 출발은 굉장히 시원시원 한 것 같습니다. 아직은 기존의 Visual Studio 2008 버전의 대부분이 Visual Studio 2010 으로 컨버팅 된 수준입니다만 2010 버전을 시점으로 IDE 도 Managed 환경으로 탈바꿈 할 준비를 하려는 모양입니다.
 
약간의 거부 반응을 일으켰던 2010 버전의 UI 도 이제는 포근해져가네요. 얼른 기존의 프로젝트를 2010 버전으로 변환해야겠네요^^
 
알아 두면 피가 되고 살이 되는 닷넷엑스퍼트 사람들의 포스트
 
기타 참고
 


지난 포스트에서 Parallel Extension 과 LINQ 를 이용한 PLINQ 에 대해서 살펴보았습니다. 지난번에 얘기했듯이 Manual Parallelism 는 Parallel Extension 의 성능을 절대 따라올 수 없다고 하였습니다. 왜냐하면, Parallel Extension 은 Manual Parallelism 의 병렬 처리 방식보다 더 복잡하고 정밀한 병렬 처리 알고리즘으로 처리하기 때문입니다.
 
Parallel Extension 이란?
 
Parallel Extension 은 전혀 새로운 것이 아닙니다. C# 3.0 의 LINQ 는 LINQ 쿼리식을 제공하기 위해 새로운 컴파일러(Compiler) 가 필요했습니다. 정확히 말하자면 C# 의 Language Service 의 버전이 업그레이드 되었고, LINQ 쿼리식을 편하게 쓸 수 있도록 Visual Studio 2008 을 사용해야 했습니다. 다시 말하자면, LINQ 쿼리식이 아닌 확장 메서드(Extension Methods) 만으로 쿼리가 가능했다는 것이 이것을 증명해 줍니다. 확장 메서드(Extension Methods) 는 결국 IL 레벨에서는 정적(Static) 인 인스턴스(Instance) 에 불과하니까요.
 
Parallel Extension 은 새로운 컴파일러(Compiler) 가 필요하지 않습니다. .NET 의 기본적인 코어(Core) 인 mscorelib.dll, System.dll, System.Core.dll 만을 사용하여 구현이 되었습니다. 그리고, 기존의 ThreadPool 을 개선하였고, LINQ 와 통합하여 선언적으로 Parallel Extension 을 사용할 수도 있게 되었죠.
 
Task Parallel Library 를 통해 데이터 처리와 어떤 작업(Task)에 대해서도 병렬 처리도 가능해 졌습니다. 이제는 데이터의 병렬 처리뿐만 아니라, 작업(Task) 단위로서도 Task Parallel Library 로 병렬 처리가 가능합니다.
 
이제는 병렬 처리가 된다는 것이 중요한 게 아니라, 병렬 처리의 내부적인 예외 핸들링이나 Visual Studio 에서 디버깅(Debugging) 이 가능합니다. 이러한 새로운 매커니즘으로 내부적으로는 새로운 예외 핸들링 모델(Exception Handling Model)이 필요했습니다.
 
또한 .NET Framework 4.0 의 Parallel Extension 은 다양한 언어를 지원합니다. C#, VB.NET, C++, F# 그리고 .NET 컴파일러(Compiler) 로 컴파일(Compile) 되는 언어라면 상관없습니다. RoR/PHP 라도 .NET 컴파일러(Compiler)에 의해 컴파일(Compile) 된다면 Parallel Extension 을 사용하는데 전혀 문제가 없습니다.
 
 
Parallel Extension 아키텍처
 
 
[그림1] Parallel Extension 아키텍처 (클릭하면 확대)
 
Parallel Extension 의 병렬 처리는 .NET 컴파일러(Compiler) 로 컴파일(Compile) 되는 어떤 언어든 차별을 두지 않고, 병렬 처리 기능을 사용할 수 있습니다. PLINQ 로 작성된 쿼리(Query)는 별도의 PLINQ Provider 의 엔진(Engine) 에서 쿼리를 분석하는 과정을 거치게 됩니다. 쿼리 분석(Query Analysis) 에 의해 선언된 LINQ 쿼리식을 분석하여 최적의 알고리즘으로 각각의 작업을 배치하게 됩니다.
 

[그림2] Parallel Extension 작업 분할
 
각각 분배되는 작업은 쓰레드 큐(Thread Queue) 에 쌓이고, 이 큐에 쌓이는 작업(Task) 는 실제 작업자 쓰레드(Worker Thread) 에 할당이 됩니다. 하지만, Parallel Extension 은 단지 쓰레드에 할당하는 것으로 작업이 마치기를 기다리지 않습니다. 만약, 작업을 분배하는 것은 Manual Parallel 과 크게 다르지 않기 때문이죠.
 

[그림3] Parallel Extension 작업 분할
 
Parallel Extension Library 는 병렬 처리의 작업을 지속적으로 최적의 상태를 감시합니다. 예를 들어, A 의 작업이 Task 1, Task 2, Task 3 인데, B 의 작업은 모두 마친 상태라고 할 때, Parallel Extension Library 는 A 의 작업을 놀고 있는 B 에게 또 다시 분배합니다. 이러한 반복적으로 병렬 처리의 작업이 최적화 될 수 있도록 하여, 병렬 처리의 성능을 극한으로 끌어올립니다.
 
LINQ 만 알면 난 병렬 처리 개발자
 
Parallel Extension 은 LINQ 와 통합하기 위한 프로바이더(Provider) 를 제공합니다. 아직 LINQ 잘 모르신다구요? 30분만 투자하시면 LINQ 를 사용하는데 큰 지장이 없습니다. 그리고 그만큼 쉽습니다. LINQ 를 이해하기 위해 제네릭(Generic), 확장 메서드(Extension Methods), 익명 타입(Anonymous Methods) 도 함께 공부하시면 좋습니다.
 
예전에 이런 광고도 있었죠.
“비트 박스를 잘하려면?” “북치기, 박치기만 잘하면 됩니다”
 
“그럼 PLINQ 개발자가 되기 위해서는?” “AsParallel() 만 잘하면 됩니다.”
 
맞습니다. Parallel Extension Library 의 AsParallel() 확장 메서드(Extension Methods) 만 알면 당신도 이제 병렬 처리 개발자입니다. 이전 포스트의 PLINQ 예제에서 처럼 AsParallel() 만 붙이면 그것을 PLINQ 라고 부릅니다^^ (병렬 처리를 위한 확장 메서드와 옵션은 더 많이 존재합니다 )
 
아래는 AsParallel() 의 예 입니다.
private static void ParallelSort(List<Person> people)
{
       var resultPerson = from person in people.AsParallel()
                                    where person.Age >= 50
                                    orderby person.Age ascending
                                    select person;
 
       foreach (var item in resultPeople) { }
}
 
하지만, 무조건적인 병렬 처리는 오히려 성능을 저하시킬 수 있습니다. 특히 PLINQ 를 사용하는 병렬 처리는 .NET Framework 내부적으로 쿼리 분석(Query Analysis) 과정을 거치게 됩니다. 각각 프로세서(Processor) 에 분배된 데이터는 또 분배되고, 최적화가 가능할 때까지 계속적으로 분배됩니다. 마치 세포 분할이 일어나는 것처럼 말이죠.
 
최소한 병렬 처리를 위해서 데이터에 대한 이해와 추측이 가능해야 합니다.
 
1.     추측 가능한 데이터의 양
2.     추측 가능한 데이터의 내용
3.     추측 가능한 데이터 처리 시간
 
이러한 최소한의 예측 작업을 하지 않는다면, 오히려 PLINQ 를 이용할 때 성능은 저하될 수 있습니다. 예를 들어, 평균 데이터의 양이 2개라고 가정한다면, PLINQ 의 쿼리 분석(Query Analysis) 작업은 오히려 성능 저하의 요인이 됩니다. PLINQ 쿼리 분석(Query Analysis) 에 의해 두 번째 프로세서(Processor) 의 사용량이 많다고 판단된다면, 병렬 작업은 의미가 없어지고 오히려 성능을 저하시킬 테니까요. ‘쿼리 분석(Query Analysis) 작업이 눈 깜빡 거리는 시간(1/40(0.025)초) 이라고 가정한다면, 만 건의 쿼리 분석(Query Analysis) 작업 시간은 250초’가 될 테니까요.
 

VSTS 2010 팀 블로그가 생긴지도 어느덧 한달이 되었군요. 얼마나 많은 활동을 했는가 보다는 얼마나 알찬 내용들을 담아내려고 했는지가 중요한 것 같습니다. 개인적으로 뭐가 되었든 간에 저는 처음 블로깅이군요. ^^; 저는 SharePoint MVP로서 팀블로그에도 SharePoint의 차기 버전을 담으려는 욕심이 있었습니다. 새버전의 Object Model 에서 향상된 점이라던가 UI 측면에서의 변경된 사항등에 말이죠. 헌데 SharePoint 차기 버전 및 이에 대한 VS 2010의 정보도 Microsoft 내부에서도 이는 극비인 모양인 것 같습니다. 짧은 인맥과 정보가 있을만한 곳을 아무리 뒤져보아도 아는 사람이 없군요. 아무래도 하루가 다르게 치솟아 오르는 SharePoint 의 인기탓인 듯 싶습니다.(국내는 예외로 해두죠 ^^;) 여튼 이런저런 이유로 새로운 버전에 대한 내용은 아쉬움을 뒤로하기로 하였습니다.

대신 ’ Visual Studio 2010 에게 바란다 - SharePoint 14 Development’ 라는 주제로 현재 SharePoint 개발에 있어서의 문제점과 아쉬운 부분들을 살펴보고 이에대한 개선점을 살펴 보도록 하겠습니다.

 

 

오늘은 간만에 대학 도서관을 찾았습니다. 졸업시즌 이기도 한 요즘이라 한번 찾아오고 싶더군요. 여튼 학창시절 생각도 나고 사회생활을 시작한 초기 미친듯 일만 하던 시절 토요일이나 일요일에 새로운 닷넷기술을 공부하던 것 생각나서 겸사겸사 찾아왔습니다. 학교를 찾아오는 길이 낫설지 않았지만 새로운 몇몇 가지들이 눈에 띄더군요. 첫번째로 학교에 올라가기가 쉬워졌습니다. 버스가 다니더군요. 높은 곳에 위치한 탓에 운동을 따로 하지 않아도 되었던 그 시절과는 다르게 버스가 수시로 다니고 있었습니다. 학교 정문을 통과하고 도서관 앞에 다다랐는데 에스컬레이터가 있습니다. 와우~ 4층까지 되는 높이를 숨한번 차지않고 올라오다닛!!! 이런 눈부신 발전이!!!

이래저래 도서관에서 새로운 자리를 잡고 오늘은 무슨 공부를 해볼까 하는 중에 급 배가아파오기 시작하더군요. (이놈의 쾌변욕구는 때와 장소를 가리지 않습니다.) 재빠르게 노트북을 덮고 화장실에 갔는데 화장실이 광이나더군요~ 개다가 히터까지 나옵니다. 예전에는 창문이 바로 옆에 있어서 추위에 떨면서 볼일을 보았던 것이 기억나는데…. ~ 매우 편안합니다. ^^; 이런것들을 누리고 있는 재학생들이 얼마나 부럽던지~ 그리고 또 한편으로는 발전하고 있는 학교가 뿌듯하기도 하더군요.

 

현 시국에 대학생을 부러워 한다는 것이 어쩌면 그들에게 맞아 죽을지도 모르는 말들이겠죠. 하지만 학교에서 당연히 해줘야 하는것들에 대해서 내가 누리지 못했던 것들을 이제는 그들이 누릴 수 있게 된다는 사실은 부러움과 함께 뿌듯한 무언가를 몰고 옵니다.

 

그럼 현재의 SharePoint 개발은 어떤가요?

 

SharePoint 의 개발영역은 크게 6가지 정도로 나눌 수 있습니다.

l  리스트나 문서라이브러리에 추가할 수 있는 커스텀 어셈블리(Event Handler, Web Part)

l  리스트 정의나 사이트 정의 같은 Custom XM

l  마스터 페이지나 레이아웃 페이지 및 컨트롤

l  문서라이브러리의 문서템플릿 혹은 폼 템플릿

l  배포 패키지

l  아웃룩에서 클라이언트 연결을 위한 Client Integration

 

그리고 현재시점에서 위와 같은 것들을 개발하려면 최소한 아래의 툴들이 필요합니다.

l  Visual Studio 2008 (2005 도 가능)

l  Windows SharePoint Services 3.0 도구: Visual Studio 2008 Extensions, 버전 1.2

l  WSS 3.0 or MOSS 2007

 

위에 나열한 요소들 개발하려고 보면 SharePoint 개발는 지원받아야 하는 당연한 것들을 지원받지 못하고 있다는 것을 알게 됩니다. 아래 예를 살펴보도록 하죠.

 

만약 제가 SharePoint 에서 리스트를 만들고 이 리스트에 대한 사용자 워크플로우를 생성한 후 바인딩하고 이를 테스트 및 적용하려고 한다면 과연 몇가지의 일들을 해야할까요?

 

1.     WSS 3.0 MOSS 2007 을 설치 - 만약 위의 서비스 및 제품이 설치되어 있지 않다면 디버깅이 불가능 하죠. ,.

2.     (Vissual Studio 가 설치되어 있다는 전제하에)Windows SharePoint Services 3.0 도구: Visual Studio 2008 Extensions, 버전 1.2 를 설치 - 이로써 개발환경 세팅이 끝납니다.

3.     리스트 정의를 생성 여기에서는 GUID, Title 등의 값을 입력하고 이벤트 핸들러등을 작성합니다.

4.     워크 플로우템플릿 정의 생성 - 3에서의 작업과 유사

5.     실제 워크플로우를 디자인하고 비하인드 코드를 작성합니다.

6.     VS 2008 에서 빌드하고 어셈블리를 등록

7.     로컬 서버 개발 환경에서 실제 소스 디버깅

8.     DDF 파일을 생성하고 이를 WSP 형태로 수정

9.     WSP 파일을 실 서버에 복사

10.   STSADM 툴을 사용하여 서버에 설치

11.   동작 테스트

 

위에 나열한 바와 같이 많은 작업들을 우리는 알게 모르게 하고 있습니다.

실제로 하나하나 따져보면 간단한 일들이 아닌 것 많습니다. 위의 1번의 WSS MOSS 2007 설치만 보더라도 간단한 일이 아니죠. WSS 혹은 MOSS 2007d을 설치하려면 반드시 Windows ServerSQL 서버(혹은 SQL Express) 를 설치해야 한다는 의미입니다. (Vista 에서는 WSS를 설치할 수 있는 방법이 있긴 합니다. ^^;)

또한 리스트 정의등을 생성할때는 VS Extension 툴을 이용하면 됩니다. 헌데 이것도 혼자 개발하고 테스트 할때는 매우 편리 합니다만, 대규모 프로젝트에서는 이에대 한 관리가 매우 난감해 집니다. 예를 들어 GUID 관리라던가 리스트의 Static Name 에 대한 네이밍룰 정의 등이죠. 여기서 파생되는 문제는 또 한가지가 있습니다. 팀 개발이 어렵다는 문제죠. 즉 팀 개발에 있어서의 정형화된 Rule 등을 세팅할 수 있는 것이 부재한 상황이죠.

마지막으로 Visual 한 개발 환경을 지원하지 못하고 있습니다. 현재의 Visual Studio 2008 만 살펴보더라도 만은 것들을 Visual 한 환경에서 개발 할 수 있도록 지원을 하고 있죠. SharePoint 도 이를 위하여 SharePoint Designer 를 사용하고 있지만 커스텀 코드를 추가할 수 없다는 단점이 여전히 존재합니다.

 

Visual Studio 2010 에서 SharePoint 14 개발은...

 

위에서 나열한 이러한 단점들이 Visual Studio 2010 에서는 이루어 졌으면 하는 작은 소망이 있습니다. 허나 앞에서도 언급하였지만 현재 WSS Vista 에서 설치가 가능하며 이를 설치하면 로컬 PC 환경에서도 SharePoint 모듈을 개발 할 수 있습니다. 사실 이것만 해결되어도 안그래도 어려운 SharePoint 개발 진입이 조금은 쉬워지지 않을까 하는 생각입니다. ! 그리고 리스트 정의나 사이트 정의같이 CAML 을 직접 생성하려고 할 때 Code Intelligence 등을 지원하면 리스트나 사이트 정의를 생성하는 것이 한결 수월할 것 같군요.

여튼 SharePoint 툴이 VS 2010 에서 통합된다는 얘기가 여기저기서 들려오는 현재 입장에서는 일단 희망을 걸어봅니다.

Written by 송재두(짜두)

최근 대부분의 사용자들의 컴퓨터의 사양이 코어2 로 업그레이드 되고 있습니다. CPU 제품에 따라 코어에 대한 아키텍처가 다르지만, 기본적으로 이들 제품은 하나의 컴퓨터에 CPU 가 두 개인 제품들입니다. 인간과 비교하자면 뇌가 두 개인 사람인데 그다지 상상해서 떠올리고 싶지 않네요^^.
 
컴퓨터는 CPU 두 개를 보다 효율적으로 이용하기 위해 바로 Parallelism Processing(병렬 처리)를 하게 됩니다. 하나의 CPU 의 성능을 향상시키는 방법이 아닌, 두 개의 CPU 에게 작업을 할당함으로써 데이터의 처리 성능을 극대화 시키게 됩니다. 우리에게 익숙한 운영체제인 윈도우(Windows) 의 멀티 쓰레딩(Multi Threading) 을 생각하면 병렬 처리(Parallelism Processing) 는 그렇게 어려운 개념은 아닙니다.
 
[그림1] 어쨌든 뇌가 두 개 (여기에서 참조)
 
원래 오픈 소스 프로젝트로 Parallel Extension 프로젝트를 CodePlex 에서 본 기억이 있는데, 지금은 링크의 주소를 찾을 수 가 없네요. 구글을 통해 “Parallel Extension” 을 검색하시면, .NET 에서의 Parallel Programming 의 흔적을 찾아볼 수 있습니다.
 
우선 아래의 Person 클래스를 작성하여 테스트에 사용할 것입니다.
 
class Person
{
    public string Name { get; set; }
    public int Age { get; set; }
}
 
 
General~
 
코어(Core) 하나로 작업할 경우, 개발자는 아무것도 염려 하지 않아도 됩니다. 그 동안 우리가 배웠던 대로 코드를 작성하기만 하면 됩니다. 병렬 처리에 대한 고민을 하지 않고 개발한 코드라면 모두 이 범주에 속하겠네요. 이러한 방법은 가장 보편적으로 작성할 수 있습니다.
 
private static void GeneralSort(List<Person> people)
{
       List<Person> resultPeople = new List<Person>();
       foreach (Person person in people)
       {
             if (person.Age >= 50)
                    resultPeople.Add(person);
       }
 
       resultPeople.Sort((p1, p2) => p1.Age.CompareTo(p2.Age));
 
       foreach (var item in resultPeople) { }
}
 
List<Person> 개체를 파라메터로 넘겨주고, Person 중에 Age 가 50이 넘는 개체를 정렬하는 코드입니다.
바로 이 코드를 병렬 처리를 하고자 합니다. 이 코드를 병렬 처리를 하고자 한다면 코드의 양은 훨씬 늘어나고, 복잡한 처리를 해야 합니다.
 
 
Manual Parallelism
 
일반적으로 데이터의 처리를 병렬 처리로 전환하기 위해서는 쓰레드(Thread) 를 사용합니다. 쓰레드(Thread) 가 생성이 되면 커널 또는 물리적인 프로세서에 의해 의해 유휴 상태 또는 처리가 가능한 코어(Core) 로 작업이 할당되어 다중 작업(Multi Process) 을 가능하게 됩니다.
 
이러한 방법의 병렬 처리는 프로세서(Processor) 개수만큼 쓰레드(Thread) 를 생성하여 비동기 작업을 합니다.
 
private static void ThreadSort(List<Person> people)
{
       var resultPeople = new List<Person>();
       int partitionsCount = Environment.ProcessorCount;
       int remainingCount = partitionsCount;
       var enumerator = (IEnumerator<Person>)people.GetEnumerator();
       try
       {
             using (var done = new ManualResetEvent(false))
             {
                    for (int i = 0; i < partitionsCount; i++)
                    {
                           ThreadPool.QueueUserWorkItem(delegate
                           {
                                 var partialResults = new List<Person>();
                                 while (true)
                                 {
                                        Person baby;
                                        lock (enumerator)
                                        {
                                              if (!enumerator.MoveNext()) break;
                                              baby = enumerator.Current;
                                        }
                                        if (baby.Age >= 50)
                                        {
                                              partialResults.Add(baby);
                                        }
                                 }
                                 lock (resultPeople) resultPeople.AddRange(partialResults);
                                 if (Interlocked.Decrement(ref remainingCount) == 0) done.Set();
                           });
                    }
                    done.WaitOne();
                    resultPeople.Sort((p1, p2) => p1.Age.CompareTo(p2.Age));
             }
       }
       finally
       {
             if (enumerator is IDisposable) ((IDisposable)enumerator).Dispose();
       }
 
       foreach (var item in resultPeople) { }
}
 
중요한 부분은 추출된 데이터의 정렬(Sort) 작업입니다. 이 작업을 하기 위해서는 모든 쓰레드(Thread) 의 작업이 끝나야 합니다. 만약 모든 쓰레드(Thread) 가 종료되지 않은 시점에서 정렬 작업을 하게 되면, 과연 정렬된 데이터를 신뢰할 수 있을까요?? ( 왜 그런지는 여러분의 상상에 맡기도록 합니다. )
 
정렬 작업을 하기 전 ManualResetEvent 의 WaitOne() 메서드를 호출하여 모든 쓰레드(Thread) 의 WaitHandle 이 작업이 신호를 받을 때까지(동기화 작업) 기다려야 합니다. 예를 들어, 두 개의 쓰레드(Thread) 가 생성 되고 첫 번째 쓰레드는 이미 작업을 종료하였지만, 두 번째 쓰레드는 아직 작업이 완료되지 않았다면, 작업을 마친 모든 쓰레드(Thread) 는 가장 늦게 처리가 완료되는 쓰레드를 기다려야 정렬 작업을 진행할 수 있습니다.
 
마지막으로, 위의 코드의 병렬 처리 작업은 성능에 한계가 있습니다. 프로세서(Processor) 개수만큼 쓰레드(Thread) 를 생성하여 작업을 분배하는 방식이기 때문에, 병렬 처리 작업의 성능은 곧 프로세서(Processor) 개수가 될테니까요!
 
 
Parallel Extension
 
C# 4.0 은 병렬 처리를 하기 위해 코드의 양을 획기적으로 줄일 수 있습니다.
 
private static void ParallelSort(List<Person> people)
{
       var resultPerson = from person in people.AsParallel()
                                    where person.Age >= 50
                                    orderby person.Age ascending
                                    select person;
 
       foreach (var item in resultPeople) { }
}
 
LINQ 식을 사용하여 데이터 처리와 정렬 작업을 간단하게 할 수 있습니다. 감격이네요^^ 바로, .NET Framework 4.0 의 Parallel Extension 을 사용하여 LINQ 처럼 사용하는 것을 PLINQ 라고 합니다.
 
Q : foreach (var item in resultPeople) { } 코드를넣었나요?
 
A: 동일한 테스트를 하기 위함입니다. LINQ 식은 내부 구조의 특성상 “쿼리식”에 불과합니다.
보다 자세한 내용은 필자의 블로그를 참고하세요.
 
Parallel Extension 은 Manual Parallelism 보다 더 복잡하고 좋은 성능을 낼 수 있는 알고리즘으로 구현이 되어 있습니다. 그렇기 때문에 아무리 많은 코어를 가진 컴퓨터에서 동일한 테스트를 한다고 하여도 결코 Manual Parallelism 은 Parallel Extension 의 병렬 처리 성능을 기대할 수 없습니다.
 
이제 살며시 그 내부 구조도 궁금해 집니다. (다음에 계속…)

Visual Studio 2010 의 특징

Visual Studio 2010 2009.02.08 23:55 Posted by POWERUMC

 

통합 개발 도구인 Visual Studio IDE 는 보다 사용하기 쉽고, 다양한 플랫폼을 쉽게 개발할 수 있으며, 더 많은 고급 기능이 포함되어 있습니다. 처음 Visual Studio IDE 를 접하는 개발자에게도 쉽게 사용할 수 있는 접근성과 비주얼이 보다 강화되었고, 이제는 IT 조직에서 개발자 뿐만이 아닌, 관리자, 아키텍쳐, 데이터베이스 개발자 들이 모두 사용할 수 있는 편한 툴이 되었습니다.

 

New IDE Improvements

  • Visual Studio 환경
    • WPF 로 개발된 에디터
    • 멀티 모니터 지원
  • 네비게이터
    • 빠른 검색
    • 하이라이트 레퍼런스(Highlight Reference) 기능
  • 프로젝트 시스템
    • 다양한 버전의 소스 코드 사용성
    • 멀티 타게팅(Multi Targeting)

새로운 Visual Studio IDE 와 다수의 패키지(Package) 가 WPF 로 개발이 되었습니다. 현재 CTP 버전에서도 레지스트리를 설정하여 WPF Based Shell 로 동작시킬 수 있습니다. HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0\General\EnableWPFShell 의 DWord 값을 1로 설정하면 Visual Studio 를 WPF Based Shell 로 시작하도록 설정할 수 있습니다. 하지만, 그 동작이 아직은 불안정하며 WPF Based Shell 의 사용을 권장하지 않습니다.

코드를 개발하기 위해 자주 사용하는 에디터도 WPF 로 개발이 되었고, 코드에 하이라이트 레퍼런스(Hightlight Reference) 와 같은 비주얼 요소를 다수 적용하였습니다. 단순히 코드의 컬러로 코드의 시각적인 효과를 주는 이상의 다이나믹한 시각 효과가 다수 추가가 되었습니다. 그리고, Visual Studio 의 시작 페이지도 WPF 기반으로 변경이 되었으며, 아래의 필자의 Umc Blog 에서 참고하세요.

참고
VSTS 2010 – 새로워진 UI

VSTS 2010 – Visualize Code RelationShip ( 코드 관계 시각화 )

또한 멀티 모니터를 지원하여 더 넓고 크게 IDE 를 활용할 수 있습니다. Visual Studio 2010 CTP 버전에서는 Virtual PC 이미지로 제공되기 때문에 멀티 모니터 지원을 확인할 수 없었지만, CTP 이후 버전에서는 멀티 모니터 기능을 확인할 수 있을 것 같습니다.

 

 

Code Focused Development

  • 먼저 사용하고, 나중에 선언 (Consume First, Declare Later)
  • 코드 통찰력(Code insight)
    • Call Hierarchy 기능
    • Inline call tree 기능
  • 레이어
    • 코드 서식
    • 문맥의 정보 제공
  • Document Map Margin 기능

개발자가 코드를 개발하기 위해 좀 더 높은 레벨의 작업이 가능하고, 코드를 이해하기 쉽도록 다양한 기능을 제공합니다. 그 중, 먼저 사용하고, 나중에 선언 (Consume First, Declare Later) 기능은 특정 기능을 구현하기 위해 흐름을 깨지 않고, 지속적으로 기능을 구현할 수 있도록 도와줍니다. 아직까지는 작성중인 프로젝트 외부에 코드의 선언을 추가할 수 없기 때문에 TDD(Test-Driven-Development) 로 사용하기에 부족함이 있지만, 앞으로 더욱 개선되어질 것으로 보입니다.

참고
VSTS 2010 – 똑똑해진 에디터

그리고 메서드 및 클래스의 호출을 관계를 쉽게 이해할 수 있도록 Call Hierarchy 를 제공하여, 이러한 관계를 트리 형태로 보여줍니다. 복잡한 구조의 스텍 정보를 순차적으로 접근할 수 있고, 복잡한 인터페이스 프로그래밍 시에 호출 연관 관계를 구조적으로 표현해 주어 선언과 구현부를 쉽게 검색할 수 있습니다. 또한, 코드 구조 전체를 비주얼하게 파악할 수 있는 Document Map Margin 기능도 유용합니다.

 

Web Development

  • Javascript tooling 강화
  • HTML 스니펫
  • 새로운 MVC 와 Dynamic Data Tooling
  • 웹 개발의 통합

이제 더 이상 Visual Studio 에서의 웹 개발 플랫폼은 ASP.NET 이 아닙니다. ASP.NET 뿐만 아니라 다양한 웹 개발 플랫폼을 통합하게 되었습니다. PHP/RoR 그리고 웹 환경에서의 엔터프라이즈 RIA 를 개발하기 표준적인 개발 환경을 제공해 줍니다.

그리고 ASP.NET MVC 를 개발하기 위해 많은 자동화 기능을 제공합니다. MVC 의 어플케이션 초기 구조를 만들기 위한 마법사가 제공되며, Controller, Action, View 등을 코드 에디터에서 쉽게 추가 하고, MVC 프로젝트의 테스트 프로젝트도 자동으로 생성해 줍니다.

이제는 HTML 도 코드 스니펫(Code Snippet)을 제공합니다. CSS 리팩토링을 지원하게 되며, 외부 스타일시트(CSS) 를 내 프로젝트에 쉽게 추가할 수 있습니다.

 

Office Development

  • 차기 오피스 버전을 위한 Tooling
  • 오피스 배포의 ClickOnce

차기 오피스 버전을 개발하기 위해 Tooling 을 제공합니다. 그리고 이러한 추가 기능을 배포하기 위해 ClickOnce 의 기능도 개선이 됩니다. 다양한 추가 기능(Addin) 솔루션을 생성하고, 유지, 배포하기 쉬워집니다.

 

Sharepoint Development

  • Sharepoint Tooling 과 공통 사용자 정의
    • 개발 –> 디버그 –> 배포 지원

앞으로 Sharepoint 의 개발이 용이하도록 Tooling 을 제공합니다. Sharepoint 기능을 개발하기 하고 배포하기 위해 복잡한 과정을 거쳐야 했습니다. Visual Studio 는 이러한 기능을 개발하기 용이하고 쉽게 디버깅하고 배포할 수 있도록 지원합니다.

 

Debugger

  • 다양한 플랫폼 지원
    • 64 Bit Mixed-Mode 디버깅
    • Managed 와 Mixed-Mode 의 Minidump 디버깅
  • 브레이크 포인트 개선
    • 그룹핑(Grouping)과 레이블(Labeling) 지원
    • 내보내기/가져오기 지원
  • Historical Debugger
    • 디버그 내용을 기록, 재생

Visual Studio 2010 에서 64 비트 플랫폼을 개발할 수 있게 됨으로써, 64 Bit 어플케이션의 디버깅을 지원합니다. 디버깅을 위해 브레이크 포인터를 관리할 수 있는 기능이 강화됩니다. 브레이크 포인트에 레이블을 표시할 수 있으며, 그룹핑을 통해 관련 있는 브레이크 포인트를 쉽게 관리할 수 있고, 관리되는 브레이크 포인트를 내보내고 가져올 수 있습니다.

그리고, 막강한 Historical Debugger 기능이 추가되어, 디버깅 이력을 쉽게 조사할 수 있습니다. 이러한 디버깅 이력을 기록하고 재생하여 반복적인 작업을 최소화 할 수 있고, 시나리오 별로 브레이크 포인트를 관리하는 등 다양한 용도로 이용할 수 있습니다.

 

Team System: Business Alignment

  • 프로젝트 관리
    • 프로젝트 서버
    • 클라이언트 통합
    • 경량의 프로젝트 계획 도구
  • 요구 사항 추적
  • 레포트
  • 개발 대시보드
  • 프로세스 사용자 지정
    • 다양한 예제 제공

프로젝트를 관리하기 위해 프로젝트 서버(Project Server) + 클라이언트 통합 + 경량의 프로젝트 계획 도구를 통해 다양한 팀 프로젝트를 관리할 수 있습니다. 그리고 다른 사람들의 중요한 정보를 검색하기 위해 대시보드도 추가됩니다.

더불어 마이크로소프트와 커뮤니티를 통해 다양한 예제가 포함됩니다. 자신의 팀 조직에 맞는 커스텀 프로세스를 적용하기만 하면 됩니다.

Visual Studio Team System 2010 (CTP10) - 작업 항목 링크

지난 3년여 동안 VSTS에 대한 많은 프리젠테이션과 세미나, 교육을 하면서 가장 많이 들었던 질문 중 하나가 "작업 항목들을 hierarchy 형태로 표현할 수 있나요?"였습니다.. 그러면, 저의 대답은 항상 같았습니다. "아니요. 하지만, Rosario (VSTS 2010 코드 명)에서는 된다고 합니다." 그러면, 질문한 사람의 얼굴에는 '그것도 안 돼?'하는 실망의 빛이 역력했습니다. 사실, 저도 왜 hierarchy 표현이 안되는지 궁금하긴 했습니다.
 그래서, Visual Studio Team System 2010의 CTP가 나왔을 때 가장 먼저 확인해 본 것이 작업 항목들을 hierarchy 구조로 표현해 보는 것이었습니다. 결론적으로 말하면, '된다'입니다.

그러면, 어떤 식으로 작업 항목의 hierarchy 구조를 표현하고, 또 어떤 식으로 조회하는지 살펴보겠습니다.

 (참고로 이 글은 Visual Studio Team System 2010 CTP10을 기준으로 작성되었습니다.)


[작업 항목 링크 추가]

Team Foundation Server 2010 CTP10 (이하 TFS CTP10)에는 작업 항목을 연결하는 링크 유형이 추가되었습니다. 기존의 TFS 2005/2008에는 링크 유형은 한 개 (Related - Related)였습니다.

  • 작업 항목 링크 유형
    • Parent - Child: 작업 항목을 트리 (tree) 형태로 구성할 때 사용. (MS Excel에서 표현 가능).
    • Predecessor - Successor: 작업 항목의 선행/후행 관계를 표현할 때 사용. (MS Excel, MS Project에서 표현 가능)
    • Related - Related: 위의 두 경우 아닌 단순한 relationship을 표현할 때 사용. 

작업 항목 링크은 TFS 2005/2008에서처럼 링크 탭에서 추가합니다. 그러나, 링크 유형 별로 컨트롤이 분리되어 있다면 추가할 링크 유형에 맞는 컨트롤에서 링크를 추가해야 합니다 (그림 1 참조).
 

[그림 1]

링크 탭에서 Add 버튼을 클릭하면 링크 추가 창이 나타납니다. TFS CTP10에 추가된 작업 항목 링크 유형은 [그림 2]에서 보는 바와 같이 Link Type 항목에 나타납니다. 링크 유형을 선택하면 그 유형의 이해를 돕기위한 그림이 아래쪽에 표현됩니다.

 


[그림 2]

 링크로 추가할 작업 항목을 선택하고 comment를 입력하는 방법은 TFS 2005/2008과  동일합니다.

 [그림 3]은 작업 항목에 Parent - Child 링크를 추가한 예입니다.


[그림 3]

작업 항목의 링크를 추가하는 방법은 링크 창을 사용하는 것 외에도 마이스로 drag&drop한다거나 Outdent, Indent 버튼을 클릭하는 것도 있습니다.

이 기능은 작업 항목 쿼리 유형 중 Tree of Work Items 만 가능합니다 (작업 항목 쿼리 유형은 아래에 설명되어 있습니다).

쿼리 결과에서 작업 항목 (A) 하나를 클릭한 후, 다른 작업 항목 (B) 쪽으로 drag&drop하면 A와 B 작업 항목 사이에 Parent - Child 링크가 추가됩니다 (그림 4 참조)

[그림 4]

또한, 쿼리 결과에서 작업 항목을 선택한 후, Outdent 버튼을 클릭하면 작업 항목의 레벨이 올라가고 아래에 있는 작업 항목들은 그 작업 항목의 Child로 추가됩니다. 만약, 그 작업 항목이 다른 작업 항목의 Child였다면 Parent였던 작업 항목과 동등한 레벨이 됩니다. Indent 버튼을 클릭하면 Outdent와 반대로 레벨이 내려갑니다.
Outdent, Indent는 MS Project의 Outdent, Indent와 유사합니다.

 
[그림 5]

[작업 항목 링크 컨트롤]

작업 항목 링크 유형이 추가되면서, 각 유형 별로 컨트롤을 분리할 수 있게 되었습니다. [그림 1]에서는 Parent - Child 링크 유형이 다른 링크 유형과 분리되어 별도의 컨트롤로 정의되었습다. 이처럼 Predecessor - Successor 링크 유형도 별도의 컨트롤로 분리될 수 있습니다.

아래 Task.xml의 Layout은 [그림 1]의 Implementation 탭을 정의한 것입니다. 

                     <Tab Label="Implementation">
                        <Control Type="LinksControl" Name="Hierarchy" Label="Parents and &amp;Child Tasks:" LabelPosition="Top">
                            <LinksControlOptions>
                                <WorkItemLinkFilters FilterType="include">
                                    <Filter LinkType="System.LinkTypes.Hierarchy" />
                                </WorkItemLinkFilters>
                                <ExternalLinkFilters FilterType="excludeAll"/>
                                <LinkColumns>
                                    <LinkColumn RefName="System.ID" />
                                    <LinkColumn RefName="System.WorkItemType" />
                                    <LinkColumn RefName="System.Title" />
                                    <LinkColumn RefName="System.AssignedTo" />
                                    <LinkColumn RefName="System.State" />
                                    <LinkColumn LinkAttribute="System.Links.Comment" />
                                </LinkColumns>
                            </LinksControlOptions>
                        </Control>
                    </Tab>
[Task.xml]

작업 항목 링크 유형 별 Reference Name은 다음과 같습니다.

  • Parent - Child: System.LinkTypes.Hierarchy
  • Predecessor - Successor: System.LinkTypes.Dependency
  • Related - Related: System.LinkTypes.Related

작업 항목 링크 컨트롤을 분리하지 않고 TFS 2005/2008처럼 하나의 컨트롤로 정의를 하려면 예전처럼 정의하면 됩니다.

           <Tab Label="Links">
            <Control Type="LinksControl" LabelPosition="Top" />
          </Tab>

 [그림 6]은 Parent -Child 유형의 링크 컨트롤의 예입니다.


[그림 6]

[작업 항목 쿼리]

작업 항목의 Parent - Child 또는 Predecessor - Successor 관계는 작업 항목 쿼리를 통해 아래와 같이 조회할 수 있습니다 (그림 7, 그림 8 참조). 작업 항목이 hierarchy 구조로 조회되는 것을 확인할 수 있습니다.

[그림 7]

 

[그림 8] 

작업 항목을 hierarchy 구조로 조회할 수 있도록 작업 항목 쿼리 유형이 두 개 추가되었습니다.

  • Flat List of Work Items: 기존의 쿼리 유형
  • Work Items and Direct Links: 작업 항목과 연결된 작업 항목도 같이 조회. 단, 직접 연결된 작업 항목만 조회 (그림 8 참조)
  • Tree of Work Items: 작업 항목과 연결된 작업 항목도 같이 조회. 작업 항목의 hierarchy 구조를 tree 구조로 표현한다 (그림 7 참조)

작업 항목 쿼리 유형은 쿼리를 작성할 때 선택합니다. 선택한 작업 항목 쿼리 유형에 따라 쿼리를 작성하는 UI가 달라집니다.

  • Flat List of Work Items

이 유형은 기존의 TFS 2005/2008에서 쿼리를 작성하는 것과 동일합니다.

[그림 9]

  • Work Items and Direct Links

이 유형은 작업 항목과 연결된 작업 항목을 조회할 수 있는 서브 쿼리를 작성할 수 있습니다. 서브 쿼리에서는 링크 유형을 선택하여 해당 링크 유형만 조회가 가능합니다.

[그림 10]

  • Tree of Work Items

이 유형은 쿼리를 작성하는 것은 TFS 2005/2008과 같지만 쿼리를 실행했을 때 결과는 Tree 구조로 표현되는 것이 다릅니다(쿼리 결과는 그림 7 참조).

[그림 11]

 
이상으로 TFS CTP10의 작업 항목 링크 유형과 작업 항목 쿼리 유형에 대해 살펴 보았습니다.

작업 항목을 hierarchy 구조로 표현할 수 있게 되므로써 얻을 수 있는 장점은 여러가지가 있습니다.

일단, 작업 항목의 선후 관계나 상하 관계를 직관적으로 알 수 있는 장점이 있습니다. TFS 2005/2008에서는 이런 관계를 명시하기 위해서는 단지 comment에 두 작업 항목의 관계를 입력하는 정도였습니다. 하지만, 그 방법은 comment를 일일이 읽어야 한다는 불편함이 있습니다.

그리고, MS Project와 연계에 있어서 자연스러워졌다는 점입니다. MS Project에서 작업을 tree 구조로 표현한 것과 작업의 선후 관계를 표현한 것이 그대로 TFS에서도 표현이 가능해졌습니다. 따라서, 두 도구의 작업 sync.가 더욱 쉬워졌습니다.

예전에는 작업 항목을 hierarchy 형태로 보려면 보고서를 작성해야 했습니다. 이제 보고서를 작성해야 하는 번거로움이 줄어들었습니다.

앞으로도 블로그를 통해 TFS CTP10에서 새로워진 기능을 중심으로 어떻게 사용하는지, 그리고 그 기능을 통해 어떤 점이 좋아졌는지를 살펴 보겠습니다.

 webmars.

 http://cafe.naver.com/teamsystem


Visual Studio Team System(VSTS) 2010 은 현재 CTP 버전이며, 2008년 10월 31에 공개가 되었습니다. 아직 VSTS 2010 CTP 는 Install Version 이 아니며, Virtual PC 의 VHD Image 파일로 제공이 됩니다. 이 Image 는 Windows Server 2008 과 Visual Studio 2010 버전과 함께 Team Foundation Server 2010 버전도 제공이 되며, 모두 사용 가능하도록 설치되어 있습니다.

Visua Studio Team System 2010 CTP 버전은 아래의 주소에서 다운로드 받을 수 있습니다.
http://www.microsoft.com/downloads/details.aspx?FamilyID=922b4655-93d0-4476-bda4-94cf5f8d4814&DisplayLang=en

하지만, 이 VSTS 2010 CTP 버전을 다시 구동시켜 보기 위해 두 가지 문제가 있습니다. 하나는, Windows Server 2008 의 사용 만료와 VSTS 2010 CTP 가 사용 만료가 되었습니다.

  1. Windows Server 2008 사용 만료

     

    이 문제는 Windows Server 2008 Product key 를 입력하여 해결할 수 있습니다. 그리고, Virtual PC Setting 을 통해 Network 가 인터넷에 연결이 되어 있어야 합니다. Product key 를 입력하여 인터넷(또는 다른 방법)을 통해 Windows Activation 할 수 있습니다.

    하지만, 유감스럽게도 Windows Server 2008 Product key 를 가지고 있지 않다면, 달리 VSTS 2010 CTP 를 구동시켜 볼 수 없을 것 같습니다.

  2. Visual Studio Team System 2010 CTP 사용 만료

     

    첫 번째 Windows Server 2008 만료를 해결한 후에 VSTS 2010 CTP 를 실행하면 또 다시, VSTS 2010 CTP 의 사용 기간이 만료가 되었다는 메시지가 보입니다. 그리고 더 이상 VSTS 2010 CTP 를 동작시킬 수 없습니다.

    이 문제는 Virtual Server Settings File 의 설정을 조작하여 Windows 의 날짜를 되돌리는 방법으로 해결할 수 있습니다.

    우선 노트패드 등을 이용하여 VSTS 2010 CTP 의 Image 가 저장된 폴더에, VisualStudio2010CTP.vmc 파일을 열어 XML 의 <mouse> 노드 다음에 아래의 설정을 해줍니다.

    <integration>
        <microsoft>
            <mouse>
                <allow type="boolean">true</allow>
            </mouse>
            <components>
                <host_time_sync>
                    <enabled type="boolean">false</enabled>
                </host_time_sync>
            </components>

    그리고 한 가지 더, Windows 의 시간 동기화를 반드시 해제 하십시오. 그렇지 않으면 Windows 시간이 동기화 되어 반복적으로 VSTS 2010 CTP 사용이 만료되게 됩니다. 아니면, VPC 의 Network 를 해제하셔도 됩니다.


    참고 문헌
    http://blogs.msdn.com/jeffbe/archive/2008/12/09/dealing-with-the-team-system-2010-ctp-expiration.aspx