Visual Studio 2010 공식 팀 블로그 @vsts2010

이전 회에서는 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일 글을 공개할 때 태스크 그룹의 스레드 세이프 특성을 잘 못 이해하여 잘못된 내용을 전달하였습니다. 그래서 오늘 글을 다시 수정하였습니다. ;;;;;;

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

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

제가 언급할 큰 주제는 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 인터페이스가 사라진 것을 찾으셨습니까?

 여기서 또 하나 생소한 것이 등장했습니다.
바로 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 를 이용한 초기화 작업에 대해서 다루고자 합니다.
즉, 우리가 앞서 선언했던 변수들에 대한 이야기를 하겠습니다.

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 알고리즘입니다.

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 >

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와 애플리케이션 사이에 위치합니다.

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

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

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

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

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 팀 블로그는 .NET Framework 4.0 과 VSTS 2010 에 대한 정보를 제공하는 공식 팀 블로그 입니다.

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

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

VSTS 2010 팀 활동 분야   

모집 대상

지원 방법

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

마감

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 은 아래의 링크를 통해 자세한 내용을 확인하세요.

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 버전이 출시가 된지 몇 일 안된것을 고려한다면 그리 적은 양은 아닌 것 같네요. 현재까지 제공되는 확장 기능을 가지고 노는 것만으로 쏠쏠한 재미가 될 듯 하네요...

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 Server와 SQL 서버(혹은 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 송재두(짜두)

통합 개발 도구인 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 에서 참고하세요.

또한 멀티 모니터를 지원하여 더 넓고 크게 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) 로 사용하기에 부족함이 있지만, 앞으로 더욱 개선되어질 것으로 보입니다.

그리고 메서드 및 클래스의 호출을 관계를 쉽게 이해할 수 있도록 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 참조).
 

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

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

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

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

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

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

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

[작업 항목 링크 컨트롤]

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

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

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

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

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

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

[작업 항목 쿼리]

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

작업 항목을 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에서 쿼리를 작성하는 것과 동일합니다.

• Work Items and Direct Links

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

• Tree of Work Items

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

 
이상으로 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