'.NET Framework 4.0'에 해당되는 글 29건

  1. 2011.06.17 [Visual Studio 2010 SP1] HTML5, CSS3 지원
  2. 2011.06.16 [Visual Studio 2010 SP1] ASP.NET DEPLOYABLE DEPENDENCIES
  3. 2011.06.15 [Visual Studio 2010 SP1] Razor 지원 및 WEB PLATFORM INSTALLER 통합
  4. 2011.06.14 [Visual Studio 2010 SP1] IIS EXPRESS 기능 추가
  5. 2011.06.13 [Visual Studio 2010 SP1] 실버라이트 성능 프로파일 지원
  6. 2011.06.10 [Visual Studio 2010 SP1] .NET FRAMEWORK 3.5 단위 테스트 호환
  7. 2011.06.09 [Visual Studio 2010 SP1] 실버라이트 4 지원
  8. 2011.05.30 Visual Studio Korea 팀의 무료 온라인 백서 공개 (1)
  9. 2011.01.10 2011년 .NET 개발자의 생존전략 (3)
  10. 2010.04.16 Visual Studio 2010 RTM 추가 완소 정보
  11. 2010.04.16 .NET Framework 4.0 마이그레이션 이슈
  12. 2010.01.28 Windows Server AppFabric - Velocity 시작하기
  13. 2010.01.28 Windows Server AppFabric - 호스트 추가하기
  14. 2010.01.27 MEF 에 Generic Type 을 지원하기 위해서..?
  15. 2010.01.27 Windows Server AppFabric - Velocity 란?
  16. 2010.01.26 MEF 는 Generic Type 을 지원하지 않는다!
  17. 2009.10.06 VSTS 2010 팀 트위터를 오픈하였습니다. (2)
  18. 2009.07.20 MEF Preview 6 공개
  19. 2009.05.17 [MEF] 10. Querying the Composition Container
  20. 2009.04.20 [MEF] 9. Recomposition (2)
  21. 2009.04.17 [MEF] 8. Strongly Typed Metadata
  22. 2009.04.16 [MEF] 7. Exports and Metadata (1)
  23. 2009.04.13 [MEF] 6. Lazy Exports
  24. 2009.04.09 MEF Preview 5 Released
  25. 2009.04.07 [MEF] 4. Import 선언 (6)
  26. 2009.03.29 [MEF] 3. Export 선언
  27. 2009.03.22 [MEF] 2. Parts 와 Contracts 선언
  28. 2009.03.16 [MEF] 1. Managed Extensibility Framework 이란?
  29. 2009.02.09 .NET Framework 4.0 의 특징

처음 Visual Studio 2010 릴리즈 되었을 때는 HTML5 기능이 추가가 되지 않았습니다. 그래서 XML Schema 를 이용하는 방법으로 HTML 텍스트 에디터에서 HTML5 구문을 사용하기도 하였습니다. 하지만 이번 Visual Studio 2010 SP1에는 정식으로 HTML5 인텔리센스와 유효성을 검사할 수 있는 기능이 추가가 되었습니다.

이 기능을 활성화하기 위해서 도구->옵션의 텍스트 에디터->HTML->유효성에서 HTML5 유효성 검사를 지정할 수 있습니다.

 

HTML5가 지원하는 여러 구문을 인텔리센스에서 자연스럽게 보여줍니다.

 

더불어 CSS3 를 완벽하게 지원하지는 않지만, 일부분 CSS3를 지원해 줍니다. CSS3 기능은 앞으로 그 기능을 보강할 수 있는 확장 기능으로 Visual Studio Gallery 에서 배포가 되길 기대해봅니다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

배포 가능한 종속성(Deployable Dependencies) 는 이번 Visual Studio 2010 SP1 에서 새롭게 추가된 기능입니다. 웹 응용 프로그램을 서버로 배포하기 위해서는 필수 구성 요소들이 설치가 되어 있어야 하는데, 배포 가능한 종속성 기능을 이용하면 웹 응용 프로그램이 동작에 필요한 일부 컴포넌트를 바로 배포할 수 있도록 도와줍니다.

웹 응용 프로그램에서 마우스 오른쪽 버튼을 클릭하여 컨텍스트 메뉴를 활성화하면 다음과 같은 메뉴 항목이 추가가 되어 있습니다.

 

메뉴 항목을 선택하면 아래와 같은 창이 나타납니다. 이 창에서는 ASP.NET MVC3 에서 사용하는 Razor 컴포넌트와 SQL Server Compact 를 선택할 수 있습니다.

 

위와 같이 배포 시 포함할 종속된 어셈블리/컴포넌트를 선택하여 확인 버튼을 클릭하면, 다음과 같이 웹 응용 프로그램 프로젝트에 _bin_deployableAssemblies 폴더가 생성이 되고, 이 하위에 관련된 어셈블리가 추가가 됩니다.

 

웹 응용 프로그램을 게시를 하게 되면, 위의 _bin_deployableAssemblies 폴더의 어셈블리는 웹 응용 프로그램의 bin 폴더로 배포가 됩니다.

 

물론, 웹 배포 패키지로 .ZIP 파일로 생성을 하여도 종속성을 추가한 어셈블리는 BIN 폴더에 추가가 되며, 이 패키지를 이용하여 배포할 서버에 컴포넌트의 설치 없이 바로 배포할 수 있습니다.

 

다만 현재는 여러 가지 배포 어셈블리/컴포넌트를 지원하지 않고 아래의 3개지의 컴포넌트만 배포를 지원해 줍니다.

  • ASP.NET Web Pages / Razor
  • SQL Server Compact 4.0
  • ASP.NET MVC 3
Posted by 땡초 POWERUMC

댓글을 달아 주세요

Razor 지원

ASP.NET MVC3 가 릴리즈 되면서 이에 발맞추어 Visual Studio 2010 SP1이 개발 도구에서 ASP.NET MVC3를 지원합니다. 특히 ASP.NET MVC3 Beta 버전에서는 지원하지 않았던, ASP.NET MVC3의 중요한 기능 중의 하나인 Razor View Engine인데, Razor View Engine의 Syntax 및 Intellisence 도 함께 지원합니다.

새로운 프로젝트를 만들 때 ASP.NET MVC3 프로젝트 템플릿에서 Razor 뷰를 선택하면 Razor View Engine을 사용할 수 있습니다.

 

 

더불어 일반 ASP.NET MVC3의 ASPX 페이지 또한 새로운 뷰를 추가할 때 Razor 뷰로 추가하면, 기존 ASP.NET MVC3의 Razor Engine을 그대로 사용할 수 있습니다.

 

Web Platform Installer 통합

Visual Studio 2010과 Web Platform Installer(WPI) 가 통합이 되었습니다. Visual Studio 2010에서 WPI를 바로 실행할 수 있는 툴바가 추가 되었습니다.

 

WPI를 통해 아래의 최신 제품을 다운로드 받을 수 있습니다.

  • SQL Server Compact 4.0
  • IIS 7.5 express
  • ASP.NET MVC3
  • WebMatrix
  • 기타…

 

  

Posted by 땡초 POWERUMC

댓글을 달아 주세요

기본적으로 웹 응용 프로그램을 개발할 경우 로컬에서 동작하는 ASP.NET Development Server 가 활성화가 됩니다.

그림 1 로컬 ASP.NET Development Server 가 동작하는 화면

웹을 개발할 때 Visual Studio가 제공하는 로컬에서 동작하는 ASP.NET Development Server 로 충분히 어려움 없이 개발을 할 수 있으나 웹 개발의 여러 가지 상황을 고려해 보면 기능이 충분하지는 않았습니다.

예를 들면, 기존의 로컬에서 동작하는 ASP.NET Development Server는 특정 웹 페이지나 XML 웹 서비스, WCF 서비스가 SSL(Secure Sockets Layer)로 동작한다거나 WCF의 NET.TCP, NET.PIPE 등의 바인딩을 사용할 수 없었습니다.

이런 여러 가지 기능적으로 IIS Express 를 사용할 경우 얻을 수 있는 이점이 많고, 기존 웹 응용 프로그램을 IIS Express에서 동작하도록 변경하기 위한 절차 또한 매우 간단합니다.

IIS Express가 설치되어 있다면, 웹 응용 프로그램에서 마우스 오른쪽 버튼을 클릭하여 IIS Express 사용을 선택하면 즉시 IIS Express 에서 웹 응용 프로그램이 동작하도록 할 수 있습니다.

 

그리고 다음의 확인 메시지에서 '예'를 클릭하면 바로 IIS Express로 웹 응용 프로그램을 개발할 수 있습니다.

 

IIS Express는 윈도우의 알림 영역에서 찾을 수 있으며 이 아이콘을 이용하여 여러 개의 호스팅 되고 있는 웹 응용 프로그램을 관리할 수 있습니다.

 

IIS Express를 사용하여 Visual Studio 2010에서 여러 가지 설정을 즉시 변경해 줄 수 있습니다.

그림 2 IIS Express 설치시 웹 응용 프로그램 속성

그림 3 기존 ASP.NET Development Server 속성

 

 

 

IIS 7과 IIS Express 버전의 비교표:

Area

IIS 7

IIS Express

Shipping mechanism

Ships with the OS.

Ships out-of-band. It is automatically included with WebMatrix but can also be installed separately.

Supported Windows editions

Limited number of Windows Vista and Windows 7 editions

Most editions of Windows Server 2003, 2008 and 2008 R2

All editions of Windows XP, Vista, Windows 7

All editions of Windows Server 2008 and 2008 R2

Supported .NET Framework versions

v2.0 SP1 and above

v2.0 SP1 and above (.NET 4.0 is required).

Supported programming languages

Classic ASP, ASP.NET, and PHP

Classic ASP, ASP.NET, and PHP

Process model

Windows Process Activation Service (WAS) automatically manages configured sites.

User launches and terminates sites.

Hosted WebCore (aka Hostable Web Core) support

Yes

Yes. IIS Express is implemented as a layer over HWC.

Supported protocols

HTTP, FTP, WebDAV, HTTPS, and WCF (including over TCP, Named Pipes, and MSMQ)

HTTP, HTTPS, and WCF over HTTP

Non-admin support

WAS must run with administrator user rights.

A standard user is allowed to complete most tasks.

Multi-developer support

None

Yes. Configuration files, settings, and Web content are maintained on a per-user basis.

Visual Studio support

Yes

VS 2010 SP1 Beta allows IIS Express to be used instead of Cassini. VS 2008 can also be manually configured to use IIS Express.

Runtime extensions

See http://www.iis.net/download/All for a complete list.

URL Rewrite and FastCGI. These extensions are built into IIS Express.

Management tools

IIS Manager, appcmd.exe

Appcmd.exe. Common IIS Express management tasks are also built into WebMatrix and Visual Studio 2010 SP1 Beta.

System tray support

None

Yes

Includes built-in IIS 7x modules for authentication, authorization, compression, etc.

Yes

Yes

 

참고

IIS Express Overview

http://learn.iis.net/page.aspx/868/iis-express-overview/

 

IIS Express를 설치하기 위해 WPI(Web Platform Installer) 다운로드 페이지

http://www.microsoft.com/web/gallery/install.aspx?appid=iisexpress

 

그림 4 Web Platform Installer 초기 설치 화면

 

그림 5 기본적인 구성 요소인 IIS Express 설치 화면

 

Posted by 땡초 POWERUMC

댓글을 달아 주세요

실버라이트 4 이전의 버전에서 Visual Studio에서 성능 프로파일을 지원하지 않은 것은 아닙니다. 다만, 개발 도구에서 지원하지 않았을 뿐이고, Command Line을 이용하여 브라우저를 Attached 하여 성능 프로파일을 할 수 있었습니다.

물론, 예전에도 실버라이트에서 성능 프로파일링을 위해 커맨드 라인으로 프로파일링을 할 수 있었습니다. 아래와 같은 순서대로 커맨드를 실행하면 되었습니다.

  1. VSPerfClrEnv /sampleon
  2. "c:\Program Files (x86)\Internet Explorer\iexplore.exe" C:\Breakout\Breakout\Bin\Release\TestPage.html
  3. VSPerfCmd /start:sample /output:MyFile /attach:<PID of iexplore.exe process>
  4. Run your scenario
  5. VSPerfCmd /detach
  6. VSPerfCmd /shutdown
  7. VSPerfClrEnv /off

 

이번 Visual Studio 2010 SP1에서는 개발 도구에서 직접 성능 프로파일을 지원합니다. 번거로이 Command Line을 사용할 필요 없이, 기존의 성능 프로파일의 사용 경험을 그대로 실버라이트 4에 적용할 수 있습니다.

Visual Studio 2010의 분석->성능 마법사 시작 메뉴를 클릭하여 실버라이트 응용 프로그램을 프로파일링 할 준비를 합니다.

 

아래와 같이 성능 프로파일을 시작하면 성능 마법사 페이지가 실행됩니다.

  • CPU 샘플링
    예를 들어, 많은 데이터 작업이나 UI요소 핸들링에서 CPU에 얼만큼의 부담을 주는지 측정할 수 있는 방법입니다.

  • 계측
    관리되는 응용 프로그램이 런타임에 얼마만큼의 리소스와 실행 시간을 갖는지 측정할 수 있습니다. 모듈/클래스/메서드 수준에서 성능을 측정할 수 있는 방법입니다.

  • .NET 메모리 할당
    관리되는 응용 프로그램이 얼만큼의 메모리를 소비하고, 가비지 컬렉션(Garbage Collection) 되는지 등의 수준 높은 메모리 정보를 제공합니다.

  • 동시성
    운영체제 차원에서 메모리의 교착 및 컨텍스트 스위칭(Context Switching)을 관찰하고 다른 프로세스에 어떤 영향을 받는지 Low Level의 정보를 제공합니다.

     

 
필자는 CPU 샘플링을 선택하였고, 2단계 페이지에서는 어떤 응용 프로그램을 프로파일링 할 지 선택합니다. 만약 솔루션 탐색기에 로드 되지 않은 프로젝트는 실행 파일(.EXE) 형태의 파일을 선택하면 소스 코드 없이 다음 단계로 이동할 수 있습니다.

 

3단계 마법사 페이지는 즉시 프로파일링을 시작할지 여부를 선택합니다. 기본 설정으로 마침을 선택하면 선택한 프로젝트 또는 실행 파일을 실행하고 프로파일링을 시작하게 됩니다.

 

응용 프로그램이 실행되면 다양한 테스트 시나리오로 테스트를 진행하고, 응용 프로그램을 마치면 수집된 프로파일링 정보로 프로파일링 결과 페이지를 볼 수 있습니다.

 

 

화면의 좌측 상단의 뷰를 변경하면서 성능 구간을 다양한 측면에서 분석을 할 수 있습니다.

 

Posted by 땡초 POWERUMC

댓글을 달아 주세요

Visual Studio 2010에서 단위 테스트 프로젝트를 생성하면 .NET Framework 4.0 의 단위 테스트 프로젝트를 지원했습니다. 단위 테스트 프로젝트를 .NET Framework 3.5 로 변경을 하게 되면 올바로 단위 테스트가 수행되지 않았던 문제가 있었습니다. 바로 아래와 같이 .NET Framework 버전을 변경하게 되면 발생하는 오류 메시지입니다.

 

그림 1 Visual Studio 2010에서 .NET Framework 3.5 로 변경할 경우

 

때문에 MSBuild 4.0으로 .NET Framework 3.5 빌드 및 테스트를 하게 되면 올바르게 빌드가 되지 않는 문제가 있었습니다.

필자 또한 이러한 문제로 인하여 다음과 같은 불편한 과정을 겪어야 했습니다.

참고

VS2008 을 VS2010 에서 동시에 개발하기

http://blog.powerumc.kr/314

 

VS2008 과 VS2010 동시에 개발하기 : 테스트 프로젝트가 포함 될 경우

http://blog.powerumc.kr/315

 

Visual Studio 2010 SP1은 이제 .NET Framework 3.5 버전의 단위 테스트도 지원이 가능하게 되었습니다.

그림 2 Visual Studio 2010에서 .NET Framework 3.5, 4.0 모두 단위 테스트 지원

 

다만, Visual Studio 2010 SP1은 .NET Framework 3.5까지 단위 테스트 프로젝트를 지원하며, 그 이하(.NET Framework 2.0, 3.0) 단위 테스트는 지원하지 않습니다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

Visual Studio 2010 SP1 의 실버라이트 4 개발 환경

Visual Studio 2010 SP1은 실버라이트 4 개발자 툴 킷이 포함이 되어 바로 실버라이트 4 개발을 할 수 있습니다.

 

그림 4 실버라이트 프로젝트 템플릿 선택

 

기존의 실버라이트 프로젝트 템플릿을 선택하여 프로젝트를 생성하면, 실버라이트 버전을 선택하여 원하는 실버라이트 버전으로 개발을 할 수 있습니다.

그림 5 실버라이트 버전 선택

 

실버라이트 4는 많은 사용자의 요구 사항과 코어의 변화가 있습니다. 자세한 내용은 아래의 링크를 ㅋ통해 MSDN 을 참고하십시오

참고

Silverlight 4의 새로운 기능 http://msdn.microsoft.com/ko-kr/library/dd772166(v=vs.95).aspx

 

실버라이트 4 의 새로운 기능

  • 컨트롤
  • 브라우저 외부에서 실행
  • 미디어
  • 네트워킹
  • 인쇄
  • 사용자 인터페이스
  • XAML
  • 데이터
  • 응용 프로그램 모델
  • 코어
  • Silverlight 디자이너
  • Windows Forms 플랫폼 지원
  • 관련 항목
Posted by 땡초 POWERUMC

댓글을 달아 주세요

그간 저희 Visual Studio Korea 팀에서 2010년 6월 1일 REMIX10 무료 온라인 백서를 참석 전원에게 드린 적이 있었습니다.

http://vsts2010.net/338
Visual Studio 2010 최신 PDF 자료를 MSDN 에서 다운로드 받으세요

그리고 지난 2011년 4월 18일, 그 두 번째 온라인 무료 백서를 공개하게 되었습니다.

 

VISUAL STUDIO KOREA 팀의 온라인 백서 다운로드 사이트

http://msdn.microsoft.com/ko-kr/gg620748

Visual Studio 응용 프로그램 모델링 완전 정복 백서

엄준일 MVP (엔씨소프트) – 다운받기

 

"Visual Studio 응용 프로그램 모델링 완전 정복 백서" 개발자에서 뛰어난 개발자로 안내하는 효과적인 백서입니다. 최종 산출물인 동작하는 소스 코드를 위해, 모델링에 대한 배경과 방법을 개발자의 관점에서 설명합니다. 그리고 Visual Studio 2010 이용하여 개발자가 효과적으로 모델링을 있는 환경을 제시합니다.

개발자들이여, 이제는 "개발자는 코드로 말한다" 관념을 버리십시오.현대의 소프트웨어 개발에서는 언제까지 당신의 코드가 나오기까지 기다려주지 않습니다.선택과 집중의 개발 생태계에서 당신이 올바른 방향을 바라보고 발을 내딛는다는 것을 아무도 믿어주지 않습니다.

코드로 말하기 이전에 자신의 목적과 목표를 명확하게 시각화하여 말하는 것이야 말로 우리 시대가 원하는 뛰어난 개발자임이 확신합니다.

 

ASP.NET MVC - M, V 그리고 C 각방생활

박세식 (유니위스) - 다운받기

  

ASP.NET 가려운 곳을 긁어줄 대안의 프레임워크가 나왔으니 바로 ASP.NET MVC 프레임워크입니다. MVC 각각 담당하고 있는 일이 있습니다. 컨트롤러는 사용자 요청의 흐름을 제어하고 그에 따른 모델과 뷰를 선택하는 , 모델은 데이터와 유효성 검사, 비즈니스 로직을 담당하는 , 뷰는 컨트롤러에서 전달받은 데이터를 UI에서 처리하는 일을 합니다. 이렇게 모델, , 컨트롤러로 명확하게 분리된 구조가 여느 복잡한 어플리케이션도 구조적으로 쉽게 개발할 있도록 도와줍니다. 여기 백서를 통해 개발의 도움을 주는 M, V 그리고 C 각방생활을 소개합니다.

남자의 Visual Studio 2010 TDD(Test Driven Development)이야기

강보람 MVP (IT Flow 선임 컨설턴트), 박세식 (유니위스) - 다운받기

  

TDD(Test Driven Development), 테스트 주도 개발은 애자일한 개발을 지원하기 위한 하나의 실천적 도구입니다. 하지만, 단순히 세부적으로 어떻게 해야 되는 것인지를 묻는 'How'만으로는 TDD 제대로 이해할 수가 없습니다. 어째서 TDD 소개되었으며, TDD 통해서 어떤 장점을 얻을 있는지를 이야기 하는 'Why' 'What' 동반되어야 TDD 이해할 있는 기반을 마련하는 것이시죠. 여기 개발자가 TDD 대해 나눈 대화를 흥미롭게 재구성해 기록한 백서가 있습니다. 백서를 통해서 TDD 대한 'Why', 'What' 그리고 Visual Studio 2010 개발에 TDD 적용한 'How' 같이 얻으시기 바랍니다.

  

 

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 맨날맑음 2011.05.30 08:36 Address Modify/Delete Reply

    좋은 백서 감사합니다^.^

최근 2년 동안 다양한 개발 분야의 기술들이 물망에 오르는 굉장히 뜻 깊은 해였습니다. 2년 전이면 Microsoft 강성재 차장과 함께 처음으로 "Visual Studio 한국 공식 팀"을 창설하면서 http://vsts2010.net 이 탄생한 시기이군요. 2008년 12월에 팀이 창설되고, 2009년 1월 5일이 팀 블로그 2주년이 되는 날이었군요.

바로 저희 "Visual Studio 한국 공식 팀" 블로그에서 한홀 한홀 정성스럽게 작성된 포스트들이 2년 여간의 기술 흐름을 대변해 주고 있으며, 그리고 2011년의 기술도 짐작해 볼 수 있는 짧지만 굵은 변화의 흐름과 함께 여기까지 온 것 같습니다.

우리 팀이 함께 해왔던 핵심 키워드의 태그는 무엇이었을까요?

  • Visual Studio 2010
  • .NET 4.0, .NET Framework 4.0
  • ASP.NET MVC
  • C# 4.0
  • C++0x, C++/CLI
  • Parallel Computing
  • WCF
  • Cloud
  • Application Lifecycle Management

   

그리고 위의 태그들에 대해 더 자세히 살펴보더라도 생소한 기술과 이름, 아키텍처, 환경 등이 2년 동안 격변을 일으키며 변화를 해왔다는 사실입니다.

2011년 이전까지는 여러분들에게 선택권이었던 것들이, 이제는 필수가 되어야 한다고 해도 과언이 아닐 겁니다. 비즈니스 요구사항의 단면을 보면 업무적인 요인, 시대적인 배경 등인데, 이 시대적인 배경에는 트랜드+시장+기술+… 이 있을테고요. 그리고 '우리가 이 시대적인 배경 중 '기술'에 한 배를 타고 흐르고 있는가…?' 에 다시 한번 생각해 볼만 합니다.

예전 2010년 6월 1일 REMIX10 세미나에서 여러분에게 말씀 드린 마지막 문구가 다시금 생각이 나네요.

http://www.techdays.co.kr/2010spring/remix10/session3_1.html

   

여러분의 생존전력은 바로 아래에 해답이 있습니다. 여러분들에게 필요한 것, 그리고 그 가능성이 있다고 판단하시면 2011년 생존을 위하여 달려보는 것은 매우 멋진 2011년 한 해가 될 것입니다.

   

.NET 프레임워크

.NET Framework .NET 의 과거와 현재, 그리고 미래
.NET Framework .NET Framework 4.0 의 특징
.NET Framework .NET Framework 4.0 마이그레이션 이슈
.NET Framework .NET 스마트클라이언트 한계 극복 [1]
.NET Framework .NET 스마트클라이언트 한계 극복 [2]
CLR 1. Hello 世界
CLR 2. CLR! CLR! CLR!
CLR 3. MSCorLib & Metadata
CLR 4. Assembly
CLR 5. Assembly - Strongly named assemblies
CLR 6. Assembly - GAC(Global Assembly Cache)
CLR 7. System.Object
CLR 8. System.Object (2)
CLR 닷넷4.0에서 네이티브코드와 매나지드코드의 동거 part 1.
CLR 닷넷4.0에서 네이티브코드와 매나지드코드의 동거 part 2-1.
CLR 닷넷4.0에서 네이티브코드와 매나지드코드의 동거 part 2-2. 네이티브 랩퍼 만들기
Managed Extensibility Framework [MEF] 1. Managed Extensibility Framework 이란?
Managed Extensibility Framework [MEF] 2. Parts 와 Contracts 선언
Managed Extensibility Framework [MEF] 3. Export 선언
Managed Extensibility Framework [MEF] 4. Import 선언
Managed Extensibility Framework [MEF] 5. Catalog 사용
Managed Extensibility Framework [MEF] 6. Lazy Exports
Managed Extensibility Framework [MEF] 7. Exports and Metadata
Managed Extensibility Framework [MEF] 8. Strongly Typed Metadata
Managed Extensibility Framework [MEF] 9. Recomposition
Managed Extensibility Framework [MEF] 10. Querying the CompositionContainer
Managed Extensibility Framework MEF Preview 6 공개
Managed Extensibility Framework MEF 는 Generic Type 을 지원하지 않는다!
Managed Extensibility Framework MEF 에 Generic Type 을 지원하기 위해서..?
Managed Extensibility Framework MEFGeneric 코드 플랙스에 공개합니다.

   

애자일 개발

Agile Development [Better Code]TDD의 개념이 완벽히 녹아 들어간 VSTS 2010
Agile Development [Better Code]Visual Studio 2010 Code Analysis Enhancements - 1.개요
Agile Development [Better Code]Visual Studio 2010 Code Analysis Enhancements - 2. Rule Sets Feature
Agile Development [Better Code]PEX, Automated Whitebox Testing for .NET - 1. 개요
Agile Development [Better Code]Visualize Code Relationships
Agile Development [Testing] TDD (Test-Driven Development-테스트 주도 개발)
Agile Development [Testing] BDD (Behavior-Driven Development?행위 주도 개발)
Agile Development [Testing] Moq.NET (T/B Driven Development)
Agile Development [Better Code]Visual Studio Code Analysis Enhancements - 3. Data Flow Rules and Phoenix Engine
Agile Development 애자일에 대한 고찰
Agile Development [ALM-Test] 1. 왜 단위 테스트를 해야 하는가?
Agile Development [ALM-Test] 2. 한국적인 애자일 모델의 필요성
Agile Development [협업 1] 협업 도구의 통일성과 협업 인프라 관리
Agile Development [ALM-Test] 3. 테스터에 대한 오해와 진실
Agile Development [ALM-Test] 4. 테스터(SDET) 의 역할
Agile Development [ALM-Test] 5. 테스트 계획
Agile Development [ALM-Test] 6. Load Runner vs Visual Studio 2010 테스팅 비교 분석 - http://willstory.tistory.com/4 제공
Agile Development [ALM-Test] 7. TDD vs 계약기반 테스트
Architect Development Architect Development ?
Architect Development 몽당연필과 함께하는 VSTS 2010 모델링 0/4
Architect Development 몽당연필과 함께 하는 VSTS 2010 모델링 1/4
Architect Development Windows Server AppFabric - Velocity 란?
Architect Development WCF=SOA 에 대한 고찰

   

ASP.NET 4.0

ASP.NET 4.0 [ASP.NET 4.0] 1. Core Service - Extensible Output Caching
ASP.NET 4.0 [ASP.NET 4.0] 2. AJAX - Declarative Client Template Rendering
ASP.NET 4.0 ASP.NET 4 와 Visual Studio 2010 Web Development Beta 2 Overview - Dynamic Data(1)
ASP.NET 4.0 ASP.NET 4 와 Visual Studio 2010 Web Development Beta 2 Overview - Dynamic Data(2)
ASP.NET 4.0 ASP.NET 4 와 Visual Studio 2010 Web Development Beta 2 Overview - Web Designer & Deployment
ASP.NET 4.0 ASP.NET 4 와 Visual Studio 2010 Web Development Beta 2 Overview - Core Services
ASP.NET 4.0 ASP.NET 4 와 Visual Studio 2010 Web Development Beta 2 Overview - New Features in the Microsoft Ajax Library
ASP.NET 4.0 ASP.NET 4 와 Visual Studio 2010 Web Development Beta 2 Overview - Web Forms(1)
ASP.NET 4.0 Razor in WebMatrix
ASP.NET 4.0 Razor in WebMatrix(2) 코드의 재 사용
ASP.NET 4.0 Razor in WebMatrix(3) ? WebMatrix Helper
ASP.NET 4.0 ASP.NET 4 와 Visual Studio 2010 Web Development Beta 2 Overview - Web Forms(2)
ASP.NET 4.0 ASP.NET 4 와 Visual Studio 2010 Web Development Beta 2 Overview - Web Forms(3)
ASP.NET 4.0 ASP.NET 4 와 Visual Studio 2010 Web Development Beta 2 Overview - Web Forms(4)
ASP.NET 4.0 ASP.NET 4 와 Visual Studio 2010 Web Development Beta 2 Overview - Web Forms(5)
ASP.NET MVC M, V 그리고 C의 각방생활(1) - ASP.NET MVC vs ASP.NET WEB FORM
ASP.NET MVC M, V 그리고 C의 각방생활(2) - ASP.NET MVC와 인사나누기
ASP.NET MVC M, V 그리고 C의 각방생활(3) - 초간단 사이트 만들기(1)
ASP.NET MVC M, V 그리고 C의 각방생활(4) - 유효성 검사
ASP.NET MVC M, V 그리고 C의 각방생활(5) - 초간단 사이트 만들기(2)
ASP.NET MVC M, V 그리고 C의 각방생활(6) - 유효성 검사(2)
ASP.NET MVC M, V 그리고 C의 각방생활(7) - 함께 즐겨요~ jQuery
ASP.NET MVC M, V 그리고 C의 각방생활(8) - jQuery와 탭메뉴 그리고 파샬뷰
ASP.NET MVC M, V 그리고 C의 각방생활(9) - jqGrid 사용해보자
ASP.NET MVC M, V 그리고 C의 각방생활(10) - jqGrid를 이용한 paging과 sorting
ASP.NET MVC ASP.NET MVC 3 Preview 1 이 릴리즈 되었습니다.
ASP.NET MVC M, V 그리고 C의 각방생활(11) - jqGrid로 데이터 추가,편집,삭제해보기
ASP.NET MVC M, V 그리고 C의 각방생활(12) - 테스팅 그거, 아무나 하나?
ASP.NET MVC JailBreak From Controllers and Actions
ASP.NET MVC VSTS2010 에서 Razor 코드 하이라이팅 지원하기

   

C# 4.0

C# [C# 4.0] Named and Optional Parameters
C# [C# 4.0] Duck Typing
C# [C# 4.0] New Extension Method "Zip"
C# [C# 4.0] Generic Covariance And Contra Variance
C# Welcome to Dynamic C#(1) - 첫만남.
C# Welcome to Dynamic C#(2) - Wanna be a polyglot.
C# Welcome to Dynamic C#(3) - 마음이 넒어진 C#
C# Welcome to Dynamic C#(4) - 극과극 비교체험.
C# Welcome to Dynamic C#(5) - Return to Dynamic.
C# Welcome to Dynamic C#(6) - Return to Dynamic (2)
C# Welcome to Dynamic C#(7) - 아낌없이 표현해 주는 나무
C# Welcome to Dynamic C#(8) - DLR이 나무를 사랑하는 이유
C# Welcome to dynamic C# 외전(1) - Generate From Usage.
C# Welcome to dynamic C# 외전(2) - Generic Method.
C# Welcome to dynamic C# 외전(3) - 감시하는 자와 감시당하는 자.
C# Welcome to Dynamic C#(9) - Dynamic Returns Again.
C# Welcome to Dynamic C#(10) - Dynamic Returns Again.(2)
C# Welcome to Dynamic C#(11) - The Phantom of The Dynamic
C# Welcome to Dynamic C#(12) - dynamic은 외로운 아이.
C# Welcome to Dynamic C#(13) - 아직도 가야할 길.
C# Welcome to Dynamic C#(14) - 철지난 만우절에 낚여서 파닥파닥.
C# Welcome to Dynamic C#(15) - A/S for dynamic.
C# Welcome to Dynamic C#(16) - dynamic이라도 이건 안되는 거임.
C# Welcome to Dynamic C#(17) - 필요한 말만 하고 삽시다.
C# Welcome to Dynamic C#(18) - 이름을 붙이면서 벌어진 일들.
C# Welcome to Dynamic C#(19) - 위너 고르기.
C# Welcome to Dynamic C#(20) - 어르신과 대화하는 법.
C# Welcome to Dynamic C#(21) - 인덱스의 힘.
C# Welcome to Asynchronous C#(0) - C#의 전설.
C# Parallel Programming [C# 4.0] Parallel Extension - [1] 병렬 처리
C# Parallel Programming [C# 4.0] Parallel Extension - [2] 병렬 처리 아키텍처
C# Parallel Programming [C# 4.0] Parallel Extension - [3] TPL(Task Parallel Library)
C# Parallel Programming Welcome to Parellel world(1) - Here comes a new challenger!
C# Parallel Programming Welcome to Parallel C#(1) - 굿바이, 그리고 안녕~~?
C# Parallel Programming Welcome to Parallel C#(2) - 계속 되는 개념 찾기.
C# Parallel Programming Welcome to Parallel C#(3) - 작업의 기본.
C# Parallel Programming Welcome to Parallel C#(4) - 작업의 기본 Part 2.
C# Parallel Programming Welcome to Parallel C#(5) - 병렬작업에서 예외가 생기면 어케...?
C# Parallel Programming Welcome to Parallel C#(6) - To be continue...
C# Parallel Programming Welcome to Parallel C#(7) - Excuse me.
C# Parallel Programming Welcome to Parallel C#(8) - 취소 쉽게 하기.
C# Parallel Programming Welcome to Parallel C#(9) - 백지장은 맞들지 말엉.
C# Parallel Programming Welcome to Parallel C#(10) - 이보게, 잠깐 뒤를 돌아보지 않겠나.

   

C++/CLI

C++/CLI C++/CLI는 미운 오리새끼 or 백조
C++/CLI .NET에서의 C++/CLI의 의미
C++/CLI [Step 01] 'C++/CLI가 뭐야?'에 답하기 && 가장 많은 프로그래밍 언어로 만드는 프로그램 만들기
C++/CLI [Step 02-1] 클래스(class), 핸들(^), 그리고 구조체(struct)
C++/CLI [Step.02-2] 클래스(class), 핸들(^), 그리고 구조체(struct)
C++/CLI [step.03] 배열
C++/CLI [Step. 04] nullptr, interior_ptr, pin_ptr
C++/CLI [Step. 05] 관리 코드의 array를 비관리 코드에 포인터로 전달
C++/CLI [Step. 06-1] 관리코드의 문자열과 비관리코드의 문자열 변환
C++/CLI [Step. 06-2] 관리코드의 문자열과 비관리코드의 문자열 변환
C++/CLI [Step. 07] 비관리 클래스에서 관리 클래스를 멤버로, 관리 클래스에서 비관리 클래스를 멤버로
C++/CLI [Step. 08] 프로퍼티 ( property )
C++/CLI [Step. 09] 델리게이트 (delegate)
C++/CLI [Step. 10] 이벤트 ( event )
C++/CLI [Step. 11] 열거형( enum )
C++/CLI [Step. 12] for each
C++/CLI [Step. 13] parameter array
C++/CLI [Step. 15] static 생성자, initonly, literal
C++/CLI [Step. 14] 인터페이스 ( interface )
C++/CLI [Step. 16] array 클래스에 non-CLI 오브젝트 사용
C++/CLI [Step. 17] 델리게이트에 비관리 함수를 할당하기 그리고 다음 예고
C++/CLI [Step. 18] 순수 가상 함수
C++/CLI [Step. 19] char* -> 관리코드, 관리코드 -> char*
C++/CLI [Step. 20] 닷넷에서 HalfNetwork를 사용하자 - 1
C++/CLI [Step. 21] 닷넷에서 HalfNetwork를 사용하자 - 2
C++/CLI [Step. 22] 닷넷에서 HalfNetwork를 사용하자 ? 3
C++/CLI [Step. 23] 닷넷에서 HalfNetwork를 사용하자 ? 4
C++/CLI [Step. 24] 닷넷에서 HalfNetwork를 사용하자 ? 5
C++/CLI [Step. 25] 닷넷에서 HalfNetwork를 사용하자 ? 6(마지막)

   

C++0x

C++0x [VC++] 1. 큰 변화가 기대되는 Visual C++( VC++ )
C++0x [VC++] 2. C++0x의 auto
C++0x [VC++] 3. static_assert
C++0x [VC++] 4. 우측 값 참조( RValue Reference ) - 첫 번째
C++0x [VC++] 5. 우측 값 참조( RValue Reference ) ? 두 번째
C++0x [VC++] 6. 우측 값 참조( RValue Reference ) - 세 번째
C++0x [VC++] 7. 우측 값 참조( RValue Reference ) - 네 번째
C++0x [VC++] 8. 우측 값 참조( RValue Reference ) ? 다섯 번째
C++0x [VC++] 9. Lambda ( 람다 ) - 첫 번째
C++0x [VC++] 11. Lambda - 두 번째
C++0x [VC++] 12. Lambda - 세 번째
C++0x [VC++] 13. Lambda - 네 번째
C++0x [VC++] 14. decltype
C++0x 대용량 파일 조작을 위한 C++0x의 변화
C++0x nullptr
C++0x VC++ 10에 구현된 C++0x의 코어 언어 기능들
C++0x C++0x 관련 책 "Visual C++ 10과 C++0x"
C++0x "Visual C++ 10과 C++0x" pdf 파일
C++0x [Plus C++0x] 람다(Lambda) 이야기 (1)
C++0x [Plus C++0x] 람다(Lambda) 이야기 (2)
C++0x [Plus C++0x] 람다(Lambda) 이야기 (3)
C++0x [Plus C++0x] 람다(Lambda) 이야기 (마지막회)
C++0x [STL] 1. What's new in VC++ 2010?
C++0x [STL] 2. unique_ptr (1/2)
C++0x [STL] 3. unique_ptr (2/2)
C++0x [STL] 4. make_shared
C++0x [STL] 5. 에 추가된 새로운 함수들 (1/5)
C++0x [STL] 6. 에 추가된 새로운 함수들 all_of, any_of, none_of (2/5)
C++0x VS2010에서 nullptr의 알려진 버그
C++0x RValue Reference에 의한 STL의 성능향상 테스트
C++0x [STL] 7. 에 추가된 새로운 함수들 copy_if, copy_n, find_if_not (3/5)
VC++ 10 Concurrency Runtime C++ 개발자를 위한 병렬 프로그래밍 동영상 [0]
VC++ 10 Concurrency Runtime C++ 개발자를 위한 병렬 프로그래밍 동영상 [1]
VC++ 10 Concurrency Runtime C++ 개발자를 위한 병렬 프로그래밍 동영상 [2]
VC++ 10 Concurrency Runtime C++ 개발자를 위한 병렬 프로그래밍 동영상 [3]
VC++ 10 Concurrency Runtime C++ 개발자를 위한 병렬 프로그래밍 동영상 [4]
VC++ 10 Concurrency Runtime C++ 개발자를 위한 병렬 프로그래밍 동영상 [5]
VC++ 10 Concurrency Runtime C++ 개발자를 위한 병렬 프로그래밍 동영상 [6/7] 완결!
VC++ 10 Concurrency Runtime PPL task를 이용한 피보나치 수 계산
VC++ 10 Concurrency Runtime 인사 및 Multi Core, Multi Thread...그리고 VC++ 10
VC++ 10 Concurrency Runtime Concurrency Runtime
VC++ 10 Concurrency Runtime Parallel Patterns Library (PPL)
VC++ 10 Concurrency Runtime 양보할 줄 아는 Concurrency Runtime의 event
VC++ 10 Concurrency Runtime Parallel Patterns Library(PPL) - Task
VC++ 10 Concurrency Runtime Parallel Patterns Library(PPL) - 병렬 알고리즘
VC++ 10 Concurrency Runtime Parallel Patterns Library(PPL) - parallel_for 알고리즘
VC++ 10 Concurrency Runtime Asynchronous Agents Library로 Dining Philosophers 문제 해결하기 - 1
VC++ 10 Concurrency Runtime Parallel Patterns Library(PPL) - parallel_for_each 알고리즘
VC++ 10 Concurrency Runtime Asynchronous Agents Library로 Dining Philosophers 문제 해결하기 - 2
VC++ 10 Concurrency Runtime Parallel Patterns Library(PPL) - parallel_invoke
VC++ 10 Concurrency Runtime Asynchronous Agents Library로 Dining Philosophers 문제 해결하기 - 마지막회
VC++ 10 Concurrency Runtime Parallel Patterns Library(PPL) - combinable
VC++ 10 Concurrency Runtime Parallel Patterns Library(PPL) - task group에서의 병렬 작업 취소 - 1
VC++ 10 Concurrency Runtime Parallel Patterns Library(PPL) - task group에서의 병렬 작업 취소 - 2
VC++ 10 Concurrency Runtime Parallel Patterns Library(PPL) - concurrent_vector - 1
VC++ 10 Concurrency Runtime Parallel Patterns Library(PPL) - concurrent_vector - 2
VC++ 10 Concurrency Runtime Parallel Patterns Library(PPL) - concurrent_queue - 1
VC++ 10 Concurrency Runtime Parallel Patterns Library(PPL) - concurrent_queue - 2
VC++ 10 Concurrency Runtime Concurrency Runtime(ConcRT)의 디버그 모드에서 메모리 leak 문제
VC++ 10 Concurrency Runtime Asynchronous Agents Library 소개
VC++ 10 Concurrency Runtime Asynchronous Agents Library - agent. 1 ( 상태 )
VC++ 10 Concurrency Runtime Asynchronous Agents Library ? agent. 2 ( 기능 )
VC++ 10 Concurrency Runtime Asynchronous Agents Library - message 전달 함수. 1 ( 전송 )
VC++ 10 Concurrency Runtime Asynchronous Agents Library ? message 전달 함수. 2 ( 수신 )
VC++ 10 Concurrency Runtime Asynchronous Agents Library ? message block 1. ( 인터페이스 )
VC++ 10 Concurrency Runtime Asynchronous Agents Library ? message block 2. ( unbounded_buffer )
VC++ 10 Concurrency Runtime Asynchronous Agents Library ? message block 3. ( overwrite_buffer & single_assignment )
VC++ 10 Concurrency Runtime Asynchronous Agents Library ? message block 4. ( call )
VC++ 10 Concurrency Runtime Asynchronous Agents Library ? message block 5. ( transformer )
VC++ 10 Concurrency Runtime Asynchronous Agents Library ? message block 6. ( choice )
VC++ 10 Concurrency Runtime Asynchronous Agents Library ? message block 7. ( join & multitype_join )
VC++ 10 Concurrency Runtime Asynchronous Agents Library ? message block 8. ( timer )
VC++ 10 Concurrency Runtime Concurrency Runtime ? 동기화 객체 1. ( critical_section & reader_writer_lock )
VC++ 10 Concurrency Runtime Concurrency Runtime ? 동기화 객체 2. ( event )
VC++ 10 Concurrency Runtime Asynchronous Agents Library ? message block 9. ( custom )
VC++ 10 Concurrency Runtime Concurrency Runtime - 만델브로트 프랙탈 ( Mandelbrot Fractal ) 예제
VC++ 10 Concurrency Runtime Concurrency Runtime ? Task Scheduler 1. ( Scheduler )
VC++ 10 Concurrency Runtime Concurrency Runtime ? Task Scheduler 2. ( SchedulerPolicy )
VC++ 10 Concurrency Runtime Concurrency Runtime ? Task Scheduler 3. ( ScheduleGroup )
VC++ 10 Concurrency Runtime Concurrency Runtime ? Task Scheduler 4. ( ScheduleTask )
VC++ 10 Concurrency Runtime Concurrency Runtime ? Task Scheduler 5. ( Context blocking )
Visual C++ 10 About Visual C++ 10
Visual C++ 10 디버깅 모드에서 역어셈블리 코드 보기
Visual C++ 10 Visual C++ 10의 변화
Visual C++ 10 [Upgrade to VC++ 10] _WIN32_WINNT 버전 문제
Visual C++ 10 VS2010 C++ 프로젝트의 디렉토리 설정

   

클라우드 컴퓨팅

Cloud 구름 속의 미래 : Windows® Azure™ Platform [1]
Cloud SQL Azure - CTP1
Cloud SQL Azure 알아보기 (1) - 데이터베이스 개체 생성
Cloud SQL Azure 알아보기(2) ? 데이터베이스 스키마 마이그레이션, 데이터 전송
Cloud 구름 속의 미래 : Windows® Azure™ Platform [2]
Cloud SQL Azure 사용 시 주의점(1) - 방화벽 설정
Cloud SQL Azure 알아보기(3) ?SQL Server 2008 R2 Nov CTP
Cloud SQL Azure 알아보기(4) ? SQL Azure Cloud App
Cloud SQL Azure 알아보기 (5)- SQL Azure 이점과 T-SQL 지원
Cloud [MS@클라우드컨퍼런스] MS 클라우드 기술과 플랫폼
Cloud 클라우드 기반 분산 컴퓨팅을 위한 AppFabric (1) : 아하! App 분산!
Cloud Hello Windows Azure / Windows Azure Platform의 이해
Cloud Hello Windows Azure / Gallery of 'Powered by Windows Azure Platform'
Cloud Hello Windows Azure / Windows Azure 개발 환경의 구축
Cloud Hello Windows Azure / Understanding Windows Azure Development Process
Cloud Hello Windows Azure / Windows Azure Tools for Visual Studio 1.2 출시
Cloud Hello Windows Azure / Windows Azure Platform 최신 소식 업데이트 (종합) [수정]
Cloud Hello Windows Azure / Twitter 스타일 방명록 만들기 #1
Cloud Windows Azure Update: Microsoft Project Code-Named "Houston" CTP 1
Cloud SQL Azure와 Excel 2010의 PowerPivot
Cloud Hello Windows Azure / Twitter 스타일 방명록 만들기 #2
Cloud Windows Azure Update: CloudStorageAccount 클래스 사용 시 주의 사항
Cloud SQL Azure Update: Dynamic Management View
Cloud Hello Windows Azure / Twitter 스타일 방명록 만들기 #3
Cloud Windows Azure Update: myAzureStorage
Cloud SQL Azure 와 SQL Reporting Service
Cloud Windows Azure Update: Windows Azure CDN의 활용
Cloud [작업 중] Windows Azure Update: Adaptive Smooth Streaming with Windows Azure Storage

   

게임 개발

Direct3d Mobile [d3dm 기초] 1. wm6.x 개발환경 세팅
Direct3d Mobile .NET 기반에서 공개소스 게임엔진 포팅하기
DirectX 11 [JumpToDX11-1] 사라진 Direct3D 오브젝트를 찾아서...
DirectX 11 [JumpToDX11-2]DeviceContext...넌 누구냣!!
DirectX 11 [JumpToDX11-3] Feature Level
DirectX 11 [JumpToDX11-4] ID3D11View
DirectX 11 [DX11_#1]D3D Buffer( 1 / 2 )
DirectX 11 [DX11_#2]D3D Buffer( 2 / 2 )
DirectX 11 [DX11_#3]기본적인 설정
DirectX 11 [JumpToDX11-5] 새로운 시대를 여는 DirectX11...
DirectX 11 [JumpToDX11-6] 커맨드(Command)...
DirectX 11 [DX11_#4]텍스트, 버튼 출력
DirectX 11 [JumpToDX11-7] 간편해진 리소스 처리.
DirectX 11 [JumpToDX11-8] Deferred Contexts
DirectX 11 [JumpToDX11-9] Multi-threaded Rendering 을 위한 API.
DirectX 11 [JumpToDX11-10] GPGPU 를 위한 DirectCompute.
DirectX 11 [JumpToDX11-11] DirectCompute 를 위한 한걸음!
DirectX 11 [JumpToDX11-12] DirectCompute 의 절차.
DirectX 11 [JumpToDX11-13] Tessellation 등장.
DirectX 11 [DX11_#5]DirectX11의 활용 사례(1/3)
DirectX 11 [JumpToDX11-14] DirectX9 세대의 테셀레이션( ID3DXPatchMesh 편 )
DirectX 11 [JumpToDX11-15] DirectX9 세대의 테셀레이션( IDirect3DDevice9::DrawXXXPatch편 )
DirectX 11 [알콜코더의 미리 배워보는 DirectX 11 - 입문편] 0. 누구를 위한 연재인가
DirectX 11 [알콜코더의 미리 배워보는 DirectX11-입문편] 1.튜터리얼 01 : 다이렉트 3D 기초 #1
DirectX 11 [알콜코더의 미리 배워보는 DirectX11-입문편] 1.튜터리얼 01 : 다이렉트 3D 기초 #2
DirectX 11 [JumpToDX11-16] DirectX9 세대의 테셀레이션( D3DXTessellateNPatches편 )
DirectX 11 [알콜코더의 미리 배워보는 DX11 ? 입문편] DX11에서 무엇이 추가되었나?
DirectX 11 [JumpToDX11-17] DirectX9 세대의 테셀레이션( ATI 라이브러리편 )
DirectX 11 [발표자료] 예제로 느껴보는 다이렉트X 11의 매력
DirectX 11 [JumpToDX11-18] DirectX11의 테셀레이션 ( 테셀레이션을 위한 하드웨어의 등장편 )
DirectX 11 [알콜코더의 미리 배워보는DX11 입문편] DirectX 11의 특징들
DirectX 11 [알콜코더의 미리배워보는 DX11-입문편] 1. 튜터리얼01 : 디바이스와 스왑체인의 생성

   

F#

F# Welcome to F#(1) - 첫만남.
F# Welcome to F#(2) - 두번째 만남.
F# Welcome to F#(3) - 사소한 탐색전.
F# Welcome to F#(4) - 과거와 배경을 좀 더 알고싶어.
F# Welcome to F#(5) - 아주 조금씩 심화되는 탐색전.
F# Welcome to F#(6) - 비교본능.
F# Welcome to F#(7) - 클리프 행어.
F# Welcome to F#(8) - 은총알과 엄친아.
F# Welcome to F#(9) - 메이져 데뷰.
F# Welcome to F#(10) - 인도음식 카레.....?
F# Welcome to F#(11) - 차별을 권장하는 언어인거임?!?!
F# Welcome to F#(12) - 공동작업 좋치아니항가

   

MFC

MFC [MFC] 리스타트 매니저(Restart Manager) - (1/3) : 기능 소개
MFC [MFC] 리스타트 매니저(Restart Manager) - (2/3) : 사용하기
MFC [MFC] 리스타트 매니저(Restart Manager) - (3/3) : 활용하기
MFC [MFC] 태스크 대화상자(Task Dialog) - (1/3) : 기능 소개
MFC [MFC] 태스크 대화상자(Task Dialog) - (2/3) : 사용하기
MFC [MFC] 태스크 대화상자(Task Dialog) - (3/3) : 활용하기
MFC [MFC] 태스크 대화상자(Task Dialog) - 예제 코드 올립니다.
MFC [MFC/윈도우 7 멀티터치] #2 : 제스처(gesture)를 이용한 구현()
MFC [MFC/윈도우 7 멀티터치] #3 : 제스처(gesture)를 이용한 구현()
MFC [MFC/윈도우 7 멀티터치] #4 : WM_TOUCH 메세지를 이용한 구현()
MFC [MFC/윈도우 7 멀티터치] #5 : WM_TOUCH 메세지를 이용한 구현()
MFC [MFC/윈도우 7 멀티터치] #6 : 예제 코드 올립니다

   

RIA

RIA Expression Blend3 preview - 1.인터페이스
RIA Expression Blend3 preview - 2. Photoshop import
RIA Silverlight 3 & Blend 3 RC 공개!!!
RIA Silverlight 4 Beta 공개
RIA .Net Ria Service + IIS6 + Silverlight 4 Troubleshooting!!
RIA 실버라이트 비하인드 코드에서 바인딩하기.
RIA .Net Ria Service 와 Entities 그리고 Stored Procedure 하다가 생긴일..
RIA 실버라이트 프로그래머가 할 수 있는 최소한의 블랜드 디자이너를 위한 배려

   

SharePoint 2010

SharePoint 2010 Visual Studio 2010 에게 바란다 - SharePoint 14 Development
SharePoint 2010 SharePoint 2010 Overview
SharePoint 2010 SharePoint 2010 개발 환경 구성
SharePoint 2010 SharePoint 2010 개발 환경- Hello World 웹 파트 생성 및 배포하기
SharePoint 2010 SharePoint 2010 Web Part 생성
SharePoint 2010 SharePoint 2010 Visual Web Part
SharePoint 2010 SharePoint 2010 Feature
SharePoint 2010 SharePoint 2010 Event Receiver
SharePoint 2010 SharePoint 2010 데이터 기술
SharePoint 2010 SharePoint 2010 Server Object Model
SharePoint 2010 Visual Studio 2010 출시에 따른 SharePoint Developer Tools
SharePoint 2010 SharePoint 2010 LINQ to SharePoint
SharePoint 2010 Client Object Model - .NET
SharePoint 2010 Client Object Model ? Silverlight (1)
SharePoint 2010 Client Object Model ? Silverlight (2)
SharePoint 2010 Client Object Model - Javascript(1)
SharePoint 2010 Client Object Model - Javascript(2)
SharePoint 2010 Client Object Model ? 정리
SharePoint 2010 SharePoint 2010 개발환경 구축 가이드
SharePoint 2010 REST -.NET
SharePoint 2010 REST ? Silverlight
SharePoint 2010 REST - jQuery
SharePoint 2010 SharePoint 2010 프로젝트 디버깅
SharePoint 2010 SharePoint 2010 Developer Dashboard

   

Team Foundation Server

Team Foundation Server Visual Studio Team System 2010 (CTP10) - 작업 항목 링크
Team Foundation Server TFS 2010 설치 하기
Team Foundation Server TFS 2010 Build Service 설치
Team Foundation Server TFS 2010 설치 과정 중에 TF255040 문제
Team Foundation Server Visual Studio 2010을 활용한 ALM (1-5) - ALM 이란 무엇인가
Team Foundation Server Team Foundation 트러블 슈팅 가이드
Team Foundation Server Visual Studio Team Foundation Server 2010 를 설치해보자
Team Foundation Server Visual Studio Team Foundation Server 2010 설치 전 할일
Team Foundation Server VS TFS 2010 설치편 - 설치전 IIS, .NET 설치
Team Foundation Server VS TFS 2010 설치편 - 설치 시작
Team Foundation Server VS TFS 2010 구성편 - 설치 후 TFS 구성으로 점심 얻어먹기 편
Team Foundation Server VS TFS 2010 사용편 - SourceSafe? 버려~
Team Foundation Server [HowTo] Team Foundation Server 의 로컬 매핑 캐시 제거하기
Team Foundation Server [HowTo] SharePoint 2010 Beta 깨끗하게 제거하기
Team Foundation Server [HowTo] SCVMM 의 Install Virtual Guest Service 작업 중 2941 오류
Team Foundation Server [HowTo] TFS2010 의 Tfs_Analysis 웨어하우스 데이터베이스가 망가졌을 경우
Team Foundation Server [PPT] 테스트와 가상화의 만남 - 테스트 가상화(Lab Management)
Team Foundation Server Team Foundation Server 2010으로 업그레이드, 마이그레이션, 동기화
Team Foundation Server Visual Source Safe 사용자를 위한 TFS2010 시리즈

   

Visual Studio 2010

Visual Studio 2010 Visual Studio Team System 2010 CTP 만료 해결하기
Visual Studio 2010 Visual Studio 2010 의 특징
Visual Studio 2010 Visual Studio 2010 내부 빌드 최신 동영상: C# 4.0 Language + IDE + WPF Shell + Editor
Visual Studio 2010 Visual Studio 2010 & .NET 4.0 참고 자료들
Visual Studio 2010 Visual Studio 2010 Beta 1 설치부터 살펴보기
Visual Studio 2010 멀티 모니터 사용
Visual Studio 2010 Visual Studio 2010 Beta 2 출시
Visual Studio 2010 Visual Studio 2010 Beta 2 설치 미리 보기
Visual Studio 2010 VS 2010 Beta 2 설치 과정에서 Silverlight SDK 문제
Visual Studio 2010 VS2010 베타2의 WPF & Silverlight 디자이너 성능 향상 팁
Visual Studio 2010 VS 2010 기능 소개 01 인텔리 센스 기능의 변화
Visual Studio 2010 Visual Studio 2010과 Blend Preview for .NET 4 통합 문제
Visual Studio 2010 VS 2010 기능 소개 02 - IDE의 기능 추가
Visual Studio 2010 VS 2010 기능 소개 03 - IDE의 변화
Visual Studio 2010 Visual Studio 2010 출시 일정
Visual Studio 2010 VS 2010 기능소개 04 - Visual C#&VB 개발자 IDE Tips & Tricks 첫번째
Visual Studio 2010 VS 2010 기능소개 05 - Visual C#&VB 개발자 IDE Tips & Tricks 두번째
Visual Studio 2010 Visual Studio 2010 RC 공개 임박!
Visual Studio 2010 Visual Studio 2010 RC 공개
Visual Studio 2010 C#에서 IntelliSense가 동작하지 않을 때 문제 해결 방법
Visual Studio 2010 똑똑한 검색을 지원하는 VSTS 2010의 "Navigate To" 검색
Visual Studio 2010 실버라이트4 RC와 블렌드 4 베타 공개
Visual Studio 2010 윈도우폰 7 개발환경 공개
Visual Studio 2010 Visual Studio 2010! 나랑 놀아보자 ? 기본편 (2회) - VS IDE
Visual Studio 2010 Visual Studio 2010! 나랑 놀아보자 ? 기본편 (3회) - Box Selection
Visual Studio 2010 Visual Studio 2010! 나랑 놀아보자 ? 기본편 (4회) - Call Hierarchy
Visual Studio 2010 Visual Studio 2010 출시와 완소 정보 총 정리
Visual Studio 2010 Visual Studio 2010 e-book 무료로 다운로드 하세요
Visual Studio 2010 Visual Studio 2010! 나랑 놀아보자 ? 기본편 (5회) - Navigate To
Visual Studio 2010 Visual Studio 2010 RTM 추가 완소 정보
Visual Studio 2010 Visual Studio 2010! 나랑 놀아보자 ? 기본편 (6회) - Generate from Usage
Visual Studio 2010 VS 2010 기능소개 05 - Visual C#&VB 개발자 IDE Tips & Tricks 두번째
Visual Studio 2010 Visual Studio 2010, 2008, 2005 에서 .NET Framework 1.1 개발하기
Visual Studio 2010 Visual Studio 2010, 2008, 2005 에서 .NET Framework 1.1 개발하기
Visual Studio 2010 Just for fun! / Visual Studio Express Edition
Visual Studio 2010 왜 Visual Studio 2010 이여야 하는가?
Visual Studio 2010 Visual Studio 2010 최신 PDF 자료를 MSDN 에서 다운로드 받으세요
Visual Studio 2010 Just for fun! / DreamSpark는 대학생 여러분을 위한 솔루션입니다.
Visual Studio 2010 VS2008 을 VS2010 에서 동시에 개발하기
Visual Studio 2010 VS2008 과 VS2010 동시에 개발하기 : 테스트 프로젝트가 포함 될 경우
Visual Studio 2010 Introducing Visual Studio LightSwitch! - Enjoy your development
Visual Studio 2010 Visual Studio Hotfix List
Visual Studio 2010 곧 다가올 기술, Microsoft Research [1/2]
Visual Studio 2010 곧 다가올 기술, Microsoft Research [2/2]
Visual Studio 2010 Visual Studio 31 (1) - 시작, 그리고 Intellisense
Visual Studio 2010 Visual Studio 31 (2) - Startpage
Visual Studio 2010 Visual Studio 31 (3) - Temp Project
Visual Studio 2010 Visual Studio 31 (4.1) - Visual Studio 2010 Productivity Power Tools, Part 1
VIsual Studio Extensibility [Blueprints] S+S Blueprints
VIsual Studio Extensibility Visual Studio 2010 SDK 와 Readme
VIsual Studio Extensibility Visual Studio 2010 Extension Manager
VIsual Studio Extensibility [VSIX] 1. What is different from before version?
VIsual Studio Extensibility [VSIX] 2-1. How to start VSIX programming
VIsual Studio Extensibility [VSIX] 2-2. How to start VSIX programming
VIsual Studio Extensibility MousePresentationTracker - MEF 세미나 예제
VIsual Studio Extensibility [VSX] 1. Visual Studio Extensibility,, 그 시작
VIsual Studio Extensibility Visual Studio 2010 확장 모델인 VSIX 버그
VIsual Studio Extensibility VSGesture v2.0 for VS2010 is now available for download

   

우리 블로그 소식

VSTS 2010 팀 블로그 Visual Studio Team System 2010 공식 팀 블로그 맴버소개
VSTS 2010 팀 블로그 Visual Studio Team System 2010 팀 블로그 소개
VSTS 2010 팀 블로그 VSTS 2010 팀 블로그/스터디 맴버를 모집합니다.
VSTS 2010 팀 블로그 VSTS 2010 팀 맴버 지원을 마감합니다
VSTS 2010 팀 블로그 Visual Studio Team System 2010 Beta 1 공개
VSTS 2010 팀 블로그 [MSDN 주간 세미나] 발표자료 / .NET Framework와 Visual Studio : 현재와 미래 1, 2
VSTS 2010 팀 블로그 VSTS 2010 팀 3분기 맴버 모집
VSTS 2010 팀 블로그 VSTS 2010 팀 세미나 동영상 - 6월 10일
VSTS 2010 팀 블로그 VSTS 2010 팀 맴버 추가 모집
VSTS 2010 팀 블로그 VSTS 2010 팀 트위터를 오픈하였습니다.
VSTS 2010 팀 블로그 TECH DAY 2009 행사 오픈!!!
VSTS 2010 팀 블로그 VSTS 2010 공식 블로그 Viva 2010팀 멤버 추가 모집 공고
VSTS 2010 팀 블로그 [세미나] 차세대 응용 프로그램 구축 방법 및 사례 소개 세미나
VSTS 2010 팀 블로그 Visual Studio 2010 팀에서 팀원 모집합니다.
VSTS 2010 팀 블로그 한국 Visual Studio 2010 사용자를 위한 트위터 커뮤니케이션
VSTS 2010 팀 블로그 C++ 개발자와 함께하는 Visual Studio 2010
VSTS 2010 팀 블로그 [무료 세미나] ReMIX 10
VSTS 2010 팀 블로그 6월 1일, 대한민국 웹 컨퍼런스의 지존 ReMIX 10가 개최됩니다!
VSTS 2010 팀 블로그 REMIX10 의 VS2010 팀 후기
VSTS 2010 팀 블로그 6월 1일, REMIX10 세미나 세션 공개
VSTS 2010 팀 블로그 [세미나] Visual Studio Camp #1
VSTS 2010 팀 블로그 [세미나 후기] Visual Studio Camp #1
VSTS 2010 팀 블로그 [세미나 발표 자료] Visual Studio Camp #1
VSTS 2010 팀 블로그 [세미나] Visual Studio Seminar #1 / 2010년 9월 28일
VSTS 2010 팀 블로그 9월 13일에 개최하는 KGC에서 강연을 합니다.
VSTS 2010 팀 블로그 KGC10에서의 VS2010 스터디 팀의 활약 모습
VSTS 2010 팀 블로그 [VSKOREA] Visual Studio 2010 정보가 한 눈에…
VSTS 2010 팀 블로그 [세미나 후기] Visual Studio Seminar #1
VSTS 2010 팀 블로그 [세미나 발표 자료] Visual Studio Seminar #1
VSTS 2010 팀 블로그 [후기] C++ & 게임 개발자를 위한 개발 생산성 및 퍼포먼스 향상 전략 세미나

   

WCF

WCF WCF란 무엇인가?
WCF 기본 WCF 프로그래밍 - 첫 WCF 서비스 만들기
WCF 기본 WCF 프로그래밍 - 첫 WCF 서비스 만들기 2
WCF WCF의 기본 - Service Contract
WCF WCF의 기본 - Data Contract
WCF WCF 서비스의 동시성(Concurrency) - 1
WCF WCF 서비스의 동시성(Concurrency) - 2
WCF WCF - Serialization
WCF WCF Hosting - WAS를 이용한 Hosting
WCF 도메인을 여러개 등록했을때 WCF 서비스를 호스팅 할수 없어요 ㅠㅠ
WCF WCF Hosting(2) - ASP.NET 호환성(Compatibility)
WCF WCF Hosting (3) - Windows Service를 이용한 Hosting
WCF WCF Security (1) - SSL을 이용한 전송계층에서의 보안 설정
WCF WCF Security (2) - 전송 계층에서의 메세지 인증 (사용자 지정 인증)
WCF WCF Troubleshooting (1)
WCF WCF Service Configuration Editor
WCF WCF Troubleshooting (2)

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 아크몬드 2011.01.11 00:15 Address Modify/Delete Reply

    대박이군요!

  2. 구조신호 2011.06.03 18:09 Address Modify/Delete Reply

    오 한곳에 다 모여있으니 좋네요~~~~!!!!
    감사합니다!!

Visual Studio 2010 과 .NET Framework 4.0 트레이닝 키트

Visual Studio 2010 과 .NET Framework 4.0 트레이닝 키트를 다운로드 할 수 있습니다. 마이크로소프트는 Visual Studio 2010 CTP 버전부터 지속적으로 트레이닝 키트를 제공했습니다. 특히 고마운 것은 Visual Studio 2010 RTM 까지 이 트레이닝 킷의 업데이트를 소홀하지 않았다는 것입니다.

이 트레이닝 키트에는 PPT 파일, Hands-on Lab, 데모 소스 코드, 동영상이 포함이 되어있으며, 아래와 같은 범위의 내용이 포함이 되어있습니다.

  • C# 4
  • Visual Basic 10
  • F#
  • Parallel Extensions
  • Windows Communication Foundation
  • Windows Workflow
  • Windows Presentation Foundation
  • ASP.NET 4
  • Windows 7
  • Entity Framework
  • ADO.NET Data Services
  • Managed Extensibility Framework
  • Visual Studio Team System

다운로드
http://www.microsoft.com/downloads/details.aspx?FamilyID=752CB725-969B-4732-A383-ED5740F02E93&displaylang=en

   

   

Visual Studio 2010 과 .NET Framework 4.0 트레이닝 코스 (Channel 9)

MSDN 의 Channel 9 사이트는 동영상으로 콘텐트를 제공하는 사이트입니다. 물론 Visual Studio 2010 과 관련된 동영상 콘텐트들이 상당히 많이 준비가 되어있습니다.

아래의 Channel 9 사이트에는 C# 4.0, Visual Basic 10, F#, Parallel Computing Platform, WCF, WF, WPF, ASP.NET AJAX 4.0, ASP.NET MVC Dynamic Data 등이 포함되어 있습니다.

Visual Studio 2010 Channel 9 사이트
http://channel9.msdn.com/learn/courses/vs2010/

   

   

Channel 9 Shows

Channel 9 Show 사이트는 좀더 심도 있는 내용의 볼거리를 제공하는 사이트 입니다.

Channel 9 Shows 사이트
http://channel9.msdn.com/shows/

여러가지 카테고리를 제공하고 있는데 특히 10-4 카테고리에는 팟케스트(Podcast) 로 시리즈로 동영상을 제공하며 심도 있게 다루는 내용이 많습니다.    

Channel 9 Shows 사이트의 10-4 카테고리 (강추)
http://channel9.msdn.com/shows/10-4/

Posted by 땡초 POWERUMC

댓글을 달아 주세요

아마 .NET Framework 4.0 을 출시로 향상된 프레임워크의 API 를 사용하기 위해 .NET Framework 4.0 으로 개발하거나 마이그레이션의 계획을 할 예정이라면 반드시 아래의 문서를 보시기 바랍니다.

 

.NET Framework 4.0 으로 마이그레이션 이슈

.NET Framework 4.0 은 구조적으로 전혀 새로워지고 향상된 프레임워크입니다. 그로 인하여 .NET Framework 4.0 은 기존의 구조 또는 API 들이 호환되지 않는 경우가 있습니다. 어플리케이션 레벨과 코어 레벨에서 변경된 사항들로 인한 이슈와 변경 방법을 참고 하십시오.

.NET Framework 4 Migration Issues

   

.NET Franework 4.0 호환성

특히 .NET Framework 4.0 부터는 기존의 .NET Framework 2.0 부터 .NET Framework 3.5 SP1 까지 사용된 CAS(Code Access Security) 와 관련한 변경 사항으로 .NET Framework 의 전반적인 보안 관련 정책이 변경이 되었습니다.

Code Access Security Policy Compatibility and Migration

그 외에도 .NET Framework 4.0 환경에서 기존의 어플리케이션이나 콤포넌트를 정상적으로 동작시키기 위하여 아래의 문서를 참고하시기 바랍니다.

Version Compatibility in the .NET Framework
.NET Framework 4 Application Compatibility Walkthrough

   

ObsoleteAttribute 특성을 피할 것

또한, 상당히 많은 양의 클래스나 구조체들이 ObsoleteAttribute 특성이 적용되었습니다.

장기적으로 지속 가능한 어플리케이션을 위하여 ObsoleteAttribute 특성이 적용된 API 는 절대 사용하지 않는 것을 권장하며, 아래의 문서를 참고하십시오.

Obsolete in the .NET Framework Version 3.5
.NET Framework V2.0 Obsolete Type/Member List (By Namespace)

Obsolete Types in the .NET Framework 4

   

그래도 문제가 발생한다면…?

혹시 그래로 문제가 발생하시나요? 그럼 Microsoft Connect 사이트에서 당신의 문제를 보고하시기 바랍니다. 또는 netfxcf@microsoft.com 으로 버그 번호와 함께 이메일을 보내시기 바랍니다.

(MSDN 문서에서 이곳으로 오류를 보고하라고 하네요 ^^)

Posted by 땡초 POWERUMC

댓글을 달아 주세요

혹시 위의 CMD 에서 키보드를 잘못 누른경우 아래의 인터넷 옵션의 인증서 창에서 신뢰되지 않은 게시자를 지우기 바랍니다.

캐시 서버 시작

   

콘솔 프로젝트에 참조 추가

CTP2 에서 System.Data.Caching 이 Microsoft.Data.Caching 으로 네임스페이스가 변경되었습니다.

   

NamedCache 를 만듭니다.

New-Cache -CacheName NamedCache1 -Secondaries 1 -TTL 15

   

App.Config 의 설정입니다.

App.config

<?xml version="1.0" encoding="utf-8" ?>

<configuration>

   

<!--configSections must be the FIRST element -->

<configSections>

   

<!-- required to read the <dataCacheClient> element -->

<section name="dataCacheClient"

type="Microsoft.Data.Caching.DataCacheClientSection,

CacheBaseLibrary"

allowLocation="true"

allowDefinition="Everywhere"/>

   

<!-- required to read the <fabric> element, when present -->

<section name="fabric"

type="System.Data.Fabric.Common.ConfigFile,

FabricCommon"

allowLocation="true"

allowDefinition="Everywhere"/>

   

</configSections>

   

<!-- simple client -->

<dataCacheClient deployment="simple">

   

<!-- (optional) specify local cache

<localCache

isEnabled="true"

sync="TTLBased"

objectCount="100000"

ttlValue="300" />

-->

   

<!-- note: cache notifications are

not supported with simple client -->

   

<!-- cache host(s) -->

<hosts>

<host

name="DPOWERUMC"

cachePort="22233"

cacheHostName="DistributedCacheService"/>

</hosts>

</dataCacheClient>

</configuration>

   

아래는 간단한 샘플 소스 코드입니다.

Program.cs

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

   

using Microsoft.Data.Caching;

   

namespace ConsoleApplication1

{

class Program

{

static void Main(string[] args)

{

//declare array for cache host(s)

DataCacheServerEndpoint[] servers = new DataCacheServerEndpoint[1];

   

//specify cache host(s)

servers[0] = new DataCacheServerEndpoint("DPOWERUMC",

22233, "DistributedCacheService");

   

//specify cache client configuration

DataCacheFactory mycacheFactory

= new DataCacheFactory(servers, true, true);

   

   

//get cache client for cache "NamedCache1"

DataCache myDefaultCache = mycacheFactory.GetCache("NamedCache1");

   

   

   

}

}

}

   

   

아래는 캐시 서버를 중지하는 방법입니다.

   

   

그리고 ShareFolder 로 설치하면 Compact 3.5 Database 인 .SDF 파일이 생깁니다. 캐시 서버가 동작할 경우 파일 공유가 불가능하여 데이터베이스의 내용을 볼 수 없습니다. 필자의 견해로는 Compact DB 가 아닌 SQL Server Database 로 설치할 것을 권장합니다.

 

설치를 수정하려면 C:\Program Files\Microsoft Distributed Cache\V1.0\Uninstall-128913592820152769.exe 를 실행하시면 됩니다. 단, 프로그램 추가/제거에서 찾을 수 없답니다. ^^

Posted by 땡초 POWERUMC

댓글을 달아 주세요

C:\Program Files\Microsoft Distributed Cache\V1.0 폴더를 모두 새로운 클러스터 서비스의 폴더로 이동합니다.

필자는 C:\VELOCITY\DPOWERUMC_CLUSTOR01 요기에다가 이동했습니다.

단, 등호와 값 사이에는 공백이 한 칸 있어야 한다. -_-; (잘보세요… 그렇지 않으면 오류가 납니다 ^^;)

클러스터링 할 데이터베이스도 만들 수 있습니다.

   

그리고 DistributeCache.exe.config 에서 아래의 항목을 수정하시면 됩니다.
cacheHostName 속성
Log location 속성의 경로
DB Connection 정보


필자는 로컬 머신에 클러스터를 추가했습니다. 아래와 같이 서비스 항목에 추가된 호스트가 등록이 되었고, 서비스를 시작해 주시면 됩니다.

   

Posted by 땡초 POWERUMC

댓글을 달아 주세요

먼저 이전 포스트의 "MEF 는 Generic Type 을 지원하지 않는다!" 에서 언급했고, .NET CLR 2.0 부터 Generic Type 을 지원함에도 불구하고, .NET Framework 4.0 에 포함되는 MEF 가 Generic Type 을 지원하지 않는다는 것은 솔직히 납득하기가 어렵습니다. MEF 개발 PM 이 말하는 강력한 계약 기반(Strongly Contract Based) 의 모델이라는 점은 머리로는 이해는 되지만, 사실 안될 것도 없습니다. -_-;

MEF 가 갖는 대표적인 키워드인 Composable 은 현재 Generic Type 을 지원하지 않지만, 상당히 매력이 있습니다. 이미 현대적인 프레임워크는 Modular 에 집중하고 있고, MEF 는 더 나아가 Modular + Composite 이라는 상당한 매력을 가진 프레임워크입니다.

일단 서두는 이쯤에서 접어두고, MEF 가 Generic Type 을 지원하기 위한 몇 가지 공개되어 있는 방법을 알아보고, 다시 이야기를 나누어 봅시다. 
   

How to support Generic Type of MEF ?    

첫 번째 방법 - Factory Provider

가장 간단한 방법이 바로 Factory Pattern 을 이용한 방식입니다. 객체의 생성은 Factory 를 통해 생성하도록 하고, Factory 는 객체의 Type 을 받음으로써 객체의 생성을 Factory 에게 모두 의존하는 방법입니다. 우선 아래의 링크를 참고하세요.

MEF + Factories Using an Export Provider
http://blog.eworldui.net/post/2008/11/MEF-2b-Factories-Using-an-Export-Provider.aspx

 ExportProvider 를 재정의하여 객체의 Type 을 등록하여 원하는 Type 의 객체를 생성하도록 합니다.

1: public interface IService { }

2: public interface IUserService : IService { }

3:  

4: [Export]

5: public class UserController {

6: [ImportingConstructor]

7: public UserController(IUserService userService) { }

8: }

9:  

10: // in your application

11: private void Compose() {

12: var catalog = new AttributedAssemblyPartCatalog(Assembly.GetExecutingAssembly());

13: var factoryProvider = new FactoryExportProvider<IService>(GetService);

14: var container = new CompositionContainer(catalog, factoryProvider);

15: container.AddPart(this);

16: container.Compose();

17: }

18:  

19: public IService GetService(Type type) { return ... }

   

하지만, 이 방법은 상당히 문제가 많은 방법입니다. 가장 즐겨쓰고, 흔히 볼 수 있는 Pattern 이기 때문에 추가되는 Factory 마다 객체 등을 Factory Provider 에 등록을 해 주어야 합니다. 그 뿐만이 아니죠. Factory Pattern 의 특성상 객체를 생성하는 Factory 는 일일이 각 객체의 타입을 체크하여 반환해 주어야 합니다.

그리고 위의 코드에서는 Type 인자가 1개이지만, 그 이상이라면??? 가령, Generic Type Class<T1,T2,T3,T4,T5> 가 된다면 대략 난감하겠죠. 일단 작은 코드에서는 쓸만할 수 있지만, 꾸준히 성장하는 코드라면 이러한 Factory 방식은 코드의 변경이 너무 잦아집니다.

   

두 번째 방법 - Type Mapping

MEF 는 Codeplex 에 공개가 되어있고, MEF Contrib 으로 불리우는 MEF 의 확장 라이브러리 입니다. MEF Contrib 의 가장 큰 특징 중에 하나인 ComposablePartCatalog 를 재정의 하는 Generic Catalog 를 지원해 줍니다. 이 링크에서 Type Mapping 을 통한 문서를 볼 수 있습니다.

public class GenericCatalogContext
{
protected AggregateCatalog _aggegateCatalog;
protected GenericCatalog _genericCatalog;
protected ImportDefinition _repositoryImportDefinition;

public GenericCatalogContext()
{
var typeCatalog = new TypeCatalog(typeof(OrderProcessor), typeof(RepositoryTypeLocator));
_aggegateCatalog =
new AggregateCatalog();
_aggegateCatalog.Catalogs.Add(typeCatalog);
_genericCatalog =
new GenericCatalog(_aggegateCatalog);
string orderProcessorContract = AttributedModelServices.GetContractName(typeof(OrderProcessor));
var orderProcessPartDefinition = typeCatalog.Parts.Single(p => p.ExportDefinitions.Any(d => d.ContractName == orderProcessorContract));
_repositoryImportDefinition = orderProcessPartDefinition.ImportDefinitions.First();
Context();
}

public virtual void Context()
{

}
}

[InheritedExport]
public abstract class GenericContractTypeMapping
{
public GenericContractTypeMapping(Type genericContractTypeDefinition, Type genericImplementationTypeDefinition)
{
}

public Type GenericContractTypeDefinition { get; }
public Type GenericImplementationTypeDefinition { get; }
}

public class RepositoryTypeLocator : GenericContractTypeMapping
{
public RepositoryTypeLocator()
:
base(typeof(IRepository<>), typeof(Repository<>))
{
}
}

public class Repository<T> : IRepository<T>
{
}

이러이러한 과정을 통해서 아래와 같이 Type Mapping 을 통해 Generic Type 을 사용할 수 있습니다.

[TestFixture]
public class When_querying_catalog_for_an_order_repository_and_no_closed_repository_is_present : GenericCatalogContext
{
[Test]
public void order_repository_part_definition_is_created()
{
Assert.IsNotNull(_result.Item1);
}

[Test]
public void order_repository_export_is_created()
{
Assert.IsNotNull(_result.Item2);
}

public override void Context()
{
_result = _genericCatalog.GetExports(_repositoryImportDefinition).Single();
}

private Tuple<ComposablePartDefinition, ExportDefinition> _result;
}

Contract Type 와 Mapping Type 을 매핑하여 Locator 로 등록하여 주고, 각각 Mapping Class 를 통해 실제 계약의 Generic Type 매핑이 이루어 집니다.

다시 말해서, Generic Class 별로 Locator Class, Mapping Class, 그리고 Mapping Context Class 를 만들어주어야 합니다. 배보다 배꼽이 더 커지는 격입니다. 일단, 아이디어는 좋지만 안쓰고 말랍니다.

   

세 번째 방법 - MEF + Unity 조합

아마도 가장 이상적인 방법이긴 합니다. Unity Application Block 은 Unity Container Extension 을 지원하기 때문에 객체의 Register, Resolve 등의 이벤트를 가로채서 Unity 의 기능을 확장할 수 있습니다. 이 이벤트를 MEF 에서 받도록 하여 MEF 의 ExportProvider 의 GetExportsCore 를 통해 Unity 의 객체에서 Resolve 하도록 하는 방법입니다.

UnityContainerExtension 을 재정의하여, 아래와 같이 이벤트를 받고, 이것을 MEF ExportProvider 로 전달하는 방법입니다.

UnityContainerExntension 에서는 아래와 같이...

protected override void Initialize()
{
this.Context.Registering += new EventHandler<RegisterEventArgs>(Context_Registering);
this.Context.RegisteringInstance += new EventHandler<RegisterInstanceEventArgs>(Context_RegisteringInstance);
}

MEF 의 ExportProvider 에서는 아래와 같이…

protected override IEnumerable<Export> GetExportsCore(ImportDefinition definition, AtomicComposition atomicComposition)
{
if (definition.ContractName != null)
{
Type contractType;
if(Mapping.TryGetValue(definition.ContractName, out contractType))
{
if (definition.Cardinality == ImportCardinality.ExactlyOne || definition.Cardinality == ImportCardinality.ExactlyOne)
{
var export = new Export(definition.ContractName, () => serviceLocator.GetInstance(contractType));
return new List<Export> { export };
}

}
}
return Enumerable.Empty<Export>();
}

일단 가장 완벽해 보입니다만, 이 속에는 그 이상 많은 문제들이 생기게 됩니다. MEF 도 내부적으로 Injection(주입) 기법을 사용하고, Unity 에서도 Injection 을 사용하는데 바로 이 Injection 방법이 달라지게 되는 것입니다. 즉, MEF 기반의 코드와 Unity 기반의 코드의 Injection 선언 방법이 틀려지고, 서로 호환할 수 없다는 것입니다.

결국 DI 프레임워크는 특정 DI Container 에 의존할 수 밖에 없어지고, 더불어 Compisite 과 Injection 은 두 가지의 사용 방법이 혼재될 수 밖에 없다는 것이죠.

   

Conclusion

MEF 에서 Generic Type 을 사용하고 싶어서 안달이 난 1은 여러 가지 방법을 찾아보았지만, 사용성, 재사용성, 확장성, 유연성 등 모든 면에서 원하는 해답을 찾지 못했습니다. 그리고 현재까지 MEF 에서 Generic Type 을 지원하기 위한 대략적인 3가지 방법을 정리해보도록 하죠.

  

장점

단점

MEF Factory Export Provider

  • 구현이 쉽다
  • Factory 의 관리가 힘들다
  • Factory 의 확장이 힘들다
  • 모든 Factory 를 Catalog 로 관리해야 한다.

MEF Contrib Type Mapping

  • 합리적이다
  • Type Mapping 코드가 복잡하다
  • Mapping/Locator/Context 클래스를 구현해야 한다
  • 상속 기반이다

MEF + Unity Integrated

  • 합리적이고 , 구현이 쉽다
  • Injection 기법이 서로 달라진다
  • Injection 코드가 서로 달라진다
  • Injection 이 호환되지 않는다
  • 각각의 객체간의 Composite 이 불가능하다

이제 슬슬 머리가 아파옵니다. 향후 .NET Framework 4.0 에서 가장 큰 빛을 보게 될 MEF 이지만, Generic Type 을 지원하지 않는다는 것은 가장 큰 오점이 아닐까 생각합니다. 우선 이쯤에서 마무리하고 어떻게 해야 할지 생각해 보도록 하지요.


MEF 에서 Generic Type 문제는 코드 플랙스에 MEFGeneric 으로 공개하였습니다.
[.NET/.NET Framework] - MEFGeneric 코드 플랙스에 공개합니다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

때는 바야흐로 2009년 7월이네요. Velocity 를 공부하면서 메모해 놓은 것을 이제서야 발견하여 포스팅을 하고 있습니다. ^^;

현재는 Windows Server AppFabric 이라는 이름으로 공개가 되고 있으며, 코드명은 바로 "Velocity" 라는 이름입니다. 현재 AppFabric Beta 1 까지 출시되었고 이제는 거의 모습을 찾아가고 있는 것 같습니다. 차후에 Velocity 의 현재 제품이름인 AppFabric 을 자세히 살펴보기로 하며, Velocity CTP 3 기준으로 설치와 사용 방법을 간단히 알아보고자 합니다.

   

Why Windows Server AppFabric (Codename "Velocity") ?

Velocity 는 분산 캐싱 프레임워크입니다. 우선 분산 캐싱이 왜 필요한지 이해가 필요합니다. 기존에는 캐싱이라고 함은 in-proc 캐싱을 의미했으며 즉 메모리 상에서 객체를 캐싱(Caching)하거나 풀링(Pooling)하기 위해 시스템의 리소스(Resource) 를 사용했습니다.

하지만 점차 엔터프라이즈 솔루션은 대규모, 대용량화 되어감에 따라 in-proc 캐싱은 시스템 리소스나 성능에 영향을 받게 되었습니다. 기존의 엔터프라이즈 솔루션은 데이터베이스의 대용량 아키텍처에 민감했고, 즉 데이터 중심의 아키텍처링을 할 수 밖에 없었습니다. 데이터의 정합성, 안정성, 성능은 기업에서 돈(Money) 와 직결되는 문제이기 때문이죠.

하지만 이미 데이터와 관련된 기술과 노하우는 이미 포화 상태이고, 엔터프라이즈 전체적인 아키텍처를 보았을때 단지 병목은 데이터에서만 존재하는 것이 아니었다는 것입니다. Middleware 나 Application Server 의 아키텍처링도 이미 포화 상태이고, 이것을 극복하기 위해서는 바로 캐싱(Caching) 이라는 기술이 필요했습니다.

위에서도 언급하였듯이 in-proc 캐싱은 굉장히 단순한 아키텍처입니다. 서버의 리소스가 받쳐 주느냐 그렇지 않느냐의 문제였고 in-proc 그리고 더 나아가 out-proc 를 이용하여 서버 자원을 최대한 활용하고자 합니다. 하지만 여기에서 또 문제가 발생합니다. 분산 out-proc 캐싱을 하자니 분산된 캐싱 데이터의 정합성을 어떻게 보장하느냐 입니다. 즉, out-proc 로 인해 캐싱은 중앙 집중화가 될 수 밖에 없으며 이것은 서버의 리소스에 의존하는 문제의 원점으로 돌아간다는 것이죠.

   

About Windows Server AppFabric (Codename "Velocity")

이러한 엔터프라이즈 환경의 서비스 확장에 대해서 고질적인 문제였던, 그리고 성능을 극대화 할 수 있는 캐싱이라는 기술을 어떻게 활용하느냐에 관심을 갖게 되었습니다. 현재 이런 문제를 해결할 수 있는 솔루션이 Windows Server AppFabric(Codename "Velocity") 입니다.

데이터의 정합성, 안정성, 성능은 기존의 아키텍처를 버리고 전용 Repository 를 통해 해결할 수 있습니다. 그것은 데이터베이스가 될 수 있고, 그 밖에 다른 Repository 가 될 수 도 있겠죠. 바로 이러한 컨셉은 캐싱을 어떤 분산 시스템간이라도 공유한다는 의미입니다. 이러한 캐싱을 클러스터링한다는 것은 흔히 Caching Dependency 를 해결할 수 있는 아주 좋은 해결 방법이기도 합니다. 어떤 로컬 시스템이건, 어떤 원격 시스템이건 캐싱 정책을 적용받게 되는 것입니다.

   

   

   

Install Windows Server AppFabric (Codename "Velocity")

아래는 필자는 게으름으로 Velocity CTP 3 기준으로 설치하는 방법입니다. (지금이라도 포스팅 하는걸 보면 대견스럽습니다만;;;)

기본적으로 캐싱 데이터는 데이터베이스를 사용합니다. 데이터베이스의 파일이 저장이 될 경로를 입력하거나 Storage 타입을 정하시면 됩니다.

 

   

Posted by 땡초 POWERUMC

댓글을 달아 주세요

.NET Framework 4.0 에 포함이 될 Managed Extensibility Framework(이하 MEF) 는 Generic Type 을 지원하지 않습니다. ( MEF is not supporting Generic Type!!!! )   

상당히 충격입니다. MEF 는 현재 Generic Type 을 지원하지 않습니다. 이것을 가지고 현재 중요한 프로젝트를 진행하기 위해 여러 가지 리뷰를 해 보고 있습니다만, MEF 가 Generic Type 을 지원하지 않는 것은 쉽게 말해 'MEF 는 아직…' 이라는 결론이 나는군요.    


Managed Extensibility Framework Basic

이것을 이해하기 위해서는 MEF 의 기본부터 이해해야 할 필요가 있습니다. 자세한 내용은 아래의 필자의 블로그 링크를 클릭하시면 Managed Extensibility Framework 에 대한 아티클을 볼 수 있습니다.

Managed Extensibility Framework
http://blog.powerumc.kr/tag/Managed%20Extensibility%20Framework

우선 이러한 원인은 MEF 가 Contract Model(계약 모델) 기반이라는 있다는 이유 입니다. 우리가 흔히 사용하는 계약 모델은 쉽게 이야기하면 제공자와 소비자로 구분할 수 있습니다. 제공자와 소비자의 거래가 성립이 되기 위해서는 바로 계약이라는 것이 필요하죠. MEF 로 비유하자만 Import/Export 가 바로 그것이며 그 계약을 성립시켜 주는 것이 MEF Container 와 Composition Batch 로 볼 수 있습니다.

바로 이러한 계약 기반과 Composable Part 라는 개념으로 기존의 컴포넌트의 재사용성을 높일 수 있게 되며, 좀 더 동적이며, 추상화가 가능한 프레임워크 입니다. 더 쉽게 얘기하면, 새로운 C 라는 컴포넌트는 A 와 B 라는 컴포넌트와 계약하여 결합시키거나, 기존 컴포넌트를 변형시키는 등 Composable Application 을 만들기 위해 계약의 명세만 알면 다양한 컴포넌트를 재생산, 변형, 다양성, 재활용 등을 할 수 있습니다.

 

MEF 는 내부적으로 이러한 명확한 계약을 위해 여러 가지 방법으로 계약을 정의할 수 있습니다. 기본적으로 ExportAttribute 을 사용하여 String, CLR Type, ExportMetadata 를 사용하게 되어 있지요. 하지만 MEF 는 모든 계약의 명세는 바로 String 을 사용하는 데에서 문제가 발생하게 됩니다. 그리고 이것이 Dependency Injection(DI) 와 Inversion Of Control(IoC) 와 다른 점입니다. 대부분의 DI 프레임워크는 Object 의 Lifecycle 을 관리하고 객체의 의존성을 낮추기 위해 역제어 하는 것에 초점이 맞추어져 있기 때문에 CLR Type 기반으로 Container 에 등록이 됩니다.

예를 들어 보면, 아래와 같은 것이 MEF 에서는 계약 명세 규격에 어긋난다는 의미입니다. (특정 DI 프레임워크에 종속되지 않는 코드입니다)

var container = new Container();
container.Register<IUMC<>>();

var obj = container.Resolve<IUMC<string>>();
obj.SayHello();

   

Why MEF is not supporting Generic Type?

MEF 가 Generic Type 을 지원하지 않는 것에 이미 많은 사람들이 문제를 발견했고, 몇 가지 해결 방법이 있긴 있습니다.

이미 Ayende Rahien 이라는 사람의 블로그에는 MEF 가 Generic Type 을 지원하지 않는 것에 대한 이야기를 합니다. 내용을 보면 처음부터 Microsoft 의 MEF 개발 팀은 Generic Type 을 배제하고 있었던 것 같습니다. 하지만 Ayende Rahien 씨는 이 문제에 대해 반드시 해결해야 한다는 이야기를 MEF 개발 팀과 나누었습니다. 저도 이 문제가 반드시 해결 되리라 생각합니다만… 현재로써는 글쎄 ^^;

여기에서 MEF 개발 팀은 조금 구차한 변명을 합니다. 위에서 얘기한 MEF 의 기본은 계약 기반의 프레임워크라는 것입니다. 이 문제에 대해 추측을 해보면, MEF 가 Generic Type 을 지원한다는 것은 Strongly Contract Based 가 될 수 없기 때문이고, Generic Type 으로 인해 명확한 계약이 이루어질 수 없다는 것입니다. 특히 MEF 는 계약의 명세가 모두 MEF 가 내부적으로 관리하고 있기 때문에, Generic Type 에 의한 객체 의 계약 관리는 엄청난 메모리 사용량을 증가로 이어질 가능성이 충분합니다.

실제로 Microsoft 에서 MEF 개발 팀의 PM 을 맡고 있는 Glenn Block 씨는 이 아티클에서는 MEF v1 에서는 Generic Type 을 지원하지 못할 것이라고 합니다. 만약에 Generic Type 을 지원하게 된다면 차기 버전이 될 듯 합니다.

하지만, 다시 한번 MEF 는 계약 기반의 모델이라는 것을 생각하지 않을 수 없습니다. 만약 계약이 명확하지 않다면 계약 자체가 불명확하다는 의미입니다. C# 2.0 부터 지원하는 Generic Type 의 명확하지 않는 타입이 계약에 존재한다면 이것은 계약 자체가 성립되기 힘들다는 전제 조건을 포함하게 됩니다.

MEF 의 예를 들어 봅시다. 아래와 같은 Generic Type 의 계약이 존재합니다. (현재의 MEF 로는 전혀 불가능한 코드입니다^^;)

public interface IUMC<T>
{

void SayHello<T>();
}

[Export(typeof(IUMC<>))]
public class UMC<T> : IUMC<T>
{
public void SayHello()
{
// TODO Impl...
}
}

CLR(Common Language Runtime) 의 Generic Type 의 특성상 Generic T Parameter 는 굉장히 다형적입니다. UMC<string> 또는 UMC<int> 또는 모든 Class Type 이 T Parameter 에 대입될 수 있습니다. 단순히 어떤 타입도 올 수 있다는 것을 떠나 물건을 팔 사람은 도대체 소비자가 누구와 계약한 것인지 알 수 없고, 실제 상거래와 같은 상황이라면 사기와도 같다는 것이죠. 굳이 예를 들자면, 주민등록번호가 다름에도 불구하고, 주민등록증의 이름이 같은 동명인에게 언제든지 계약을 할 수 있다는 것이죠.

DI(Dependency Injection / IoC) 는 CLR Type 을 기반으로 합니다. 일부 DI 프레임워크는 Tag 와 같은 Contract Data 를 제공하기는 하지만 이것은 Metadata 그 이상의 역활을 하지 않습니다. 즉 Contract(계약) 와는 전혀 무관하다는 이야기 입니다. 객체를 질의(Query) 하기 위함이지 Composable 을 위한 것은 아닙니다.

 

OK! I'm understand. But…!!

처음부터 MEF 는 계약 기반의 Composable/Plugin Model/Contract Based 라는 용어를 자주 만나게 됩니다. 그리고 계약 자체라는 의미에서 Generic Type 은 가장 큰 장애 요소임이 확실합니다. 그렇기 때문에 현존하는 모든 DI(Dependency Injection) 프레임워크는 계약(Contract) 라는 용어를 절대 사용하지 않습니다. 목적 자체가 계약과는 전혀 무관하기 때문입니다.

하지만, MEF 의 계약 모델은 내부적으로 String Based Contract 를 사용하고 있고, Generic Type 또한 String 으로 표현이 가능하기 때문에, 문자열의 Parsing 만으로 어느 정도의 Generic Type 을 지원할 수 있을 거라고 생각했습니다.

필자는 처음 MEF 를 본 순간 "이것을 물건이다!" 라는 걸 느꼈습니다만, 아마도 MEF 개발 팀은 두 가지의 고민을 했을 거라고 생각합니다. Silverlight 를 지원할지, Generic Type 을 지원할지에 대한 범용성에 대해서 말입니다. 하지만, Generic 에 대해 많은 피드백을 받음에도 불구하고 MEF v1 에 지원하지 않을 듯한 대답은 사실 "구차한 변명" 으로 밖에 들리지 않는답니다. 결국, 현재 MEF 는 Silverlight 를 지원하는 등 .NET Framework 의 범용성에 치중하였고, 결국 Generic Type 은 현재 시점에서 릴리즈 시점까지 구현이 불가능할 거라고 예상합니다.

아쉽긴 하지만, 현재 MEF 가 불가능한 Generic Type 에 대한 영역은 몇 가지 Open Source 에서 제공을 하고 있습니다. 단지 실제 사용성에 대한 의구심과 필자의 견해로는 안쓰는게 나을 것 같다는 판단입니다.

다음에 당장 지원하지 않는 Generic Type 을 어떻게 사용할지 알아보고 함께 돌파구를 찾아보도록 하겠습니다.


MEF 에서 Generic Type 문제는 코드 플랙스에 MEFGeneric 으로 공개하였습니다.
[.NET/.NET Framework] - MEFGeneric 코드 플랙스에 공개합니다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

안녕하세요. VSTS 2010 공식 팀에서 Twitter 를 시작했습니다. Twitter 를 통해 차마 시간이 없어 정리하지 못한 정보나 알아두면 좋은 팁과 정보 등을 단문 메시지로 여러분들에게 전달해 드릴 예정입니다.

차세대 플랫폼인 Visual Studio / Team System 2010 등 관심 있는 분들의 많은 Following 을 부탁 드립니다.

http://twitter.com/vsts2010

   

 

   

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 하나둘넷 2009.10.06 23:42 Address Modify/Delete Reply

    트위터에 좋은 내용들이 짧게 올라오네용.. 잘 보고 가요~^^

    • 땡초 2009.10.07 09:17 Address Modify/Delete

      저는 트위터를 twhirl 이라는 클라이언트 어플케이션으로 사용하고 있답니다.
      제가 써 본 것중에는 제일 편하네요.
      http://www.twhirl.org/download

MEF(Managed Extensibility Framework) 이 2009년 7월 13일에 릴리즈되어 14일에 공개가 되었습니다. 특히 MEF 는 .NET Framework 4.0 에 포함이 되어있으며, CodePlex 에서 굉장히 빠른 속도로 발전하고 있는 프레임워크 중에 하나 입니다.    

CodePlex MEF 사이트에 등록된 릴리즈 노트 입니다.

그 중에서 몇 가지만 살펴보도록 하겠습니다.

실버라이트 3 지원

특히 이번에 눈여겨 볼 만한 것이 Silverlight 3 를 지원하는 것입니다. 이미 Preview 5 이전의 MEF 에서는 실버라이트를 지원하기 위해 코드에서 전처리 명령 구문을 사용하여 프레임워크 실버라이트가 지원되긴 했습니다. 그것을 기반으로 이번 Preview 6 버전에서는 실버라이트 3 용 솔루션이 제공됩니다. 이 솔루션을 통해 실버라이트용 MEF 프레임워크를 빌드 하시면 됩니다.

   

ExportAttribute 의 seal 키워드 제거

이번 MEF Preview 6 에서 ExportAttribute 의 seal 키워드가 제거됩니다. 이 전 Preview 5 에서는 ExportAttribute 을 절대 상속할 수 없는 구조였기 때문에 독자적인 Export 를 제공할 수 없었기, Metadata 를 ExportAttribute 와 같은 기능울 개별적으로 지정해야 하는 등의 Export 기능의 확장에 불합리한 구조로 되어있었습니다. 하지만 이번 Preview 6 버전에서는 ExportAttribute 클래스의 seal 키워드가 제거 됨으로써 ExportAttribute 의 확장이 용이하게 되었습니다.

 

ImportMany 로 통일된 컬렉션 처리

이제 모든 컬렉션은 ImportMany 로 통일되었습니다. Preview 5 에서는 ExportCollection<T> 또는 IEnumerable<T> 와 같이 사용하기도 까다롭고 이것으로 반환된 객체를 처리하기에도 편리한 구조는 아니였습니다. Preview 5 에서도 ImportMany 의 기능이 존재하였지만, 이번 Preview 6 는 이것으로 모든 컬렉션 처리를 하도록 통일되었다는게 혼란스러웠던 부분을 간소화할 수 있을 것 같습니다.

   

기타 그 밖에도 구조적으로 보다 안정되었고, 메서드나 클래스의 네이밍이 변경되었고, 예외 시에 Composition 동작의 분석을 추적하기 쉽도록 덤프(Dump) 를 뜰 수 있는 로깅 기능 등 다양한 기능이 추가되었습니다. 정식 버전의 MEF 는 어떤 모습으로 나올지 정말 기대가 됩니다. 더 자세한 내용은 아래의 링크를 통해 더 쉽게 설명이 되어있으니 참고 하십시오.


참고문헌
MEF Preview 6 Available
http://blogs.msdn.com/nblumhardt/archive/2009/07/09/mef-preview-6-available.aspx

'.NET > .NET Framework' 카테고리의 다른 글

MEF 에 Generic Type 을 지원하기 위해서..?  (0) 2010.01.27
MEF 는 Generic Type 을 지원하지 않는다!  (0) 2010.01.26
MEF Preview 6 공개  (0) 2009.07.20
MEF 세미나 동영상 - 6월 10일  (0) 2009.07.08
CodeFx 프로젝트  (0) 2009.06.24
MEF 세미나 자료  (0) 2009.06.22
Posted by 땡초 POWERUMC

댓글을 달아 주세요

Querying the CompositionContainer
 
CompositionContainer 의 Exported 구성 요소를 취득하기 위해서는 컨테이너에 하나의 구성 요소만이 존재해야 합니다. 쿼리(Query) 를 통해 이러한 객체들이 여러 개 존재할 경우 MEF 는 예외를 발생하게 됩니다.
 
바로 아래와 같은 경우이죠.
l 하나의 인스턴스를 요청할 때, 인스턴스를 찾지 못했을 경우
l 하나의 인스턴스를 요청할 때, 인스턴스가 여러 개일 경우
 
GetExportedObject
 
일반적으로 ExportAttribute 에 인자가 전달되지 않은 경우는 클래스의 타입이 키 값이 되어, 아래와 같이 구성 요소를 취득할 수 있습니다.
 
class Program
{
        static void Main(string[] args)
        {
               var container = new CompositionContainer(new AssemblyCatalog(Assembly.GetExecutingAssembly()));
              
               var export = container.GetExportedObject<Export1>();
               export.Say();
 
               Console.ReadKey();
        }
}
 
[Export]
class Export1
{
        public void Say()
        {
               Console.WriteLine("Export1 Say..");
        }
}
 
 
만약, ExportAttribute 에 Contract Name 이 선언이 될 경우는 클래스의 타입 정보와 Contract Name 이 일치해야 구성요소를 취득할 수 있습니다.
 
class Program
{
        static void Main(string[] args)
        {
               var container = new CompositionContainer(new AssemblyCatalog(Assembly.GetExecutingAssembly()));
              
               var export = container.GetExportedObject<Export2>("export2");
               export.Say();
 
               Console.ReadKey();
        }
}
 
[Export("export2")]
public class Export2
{
        public void Say()
        {
               Console.WriteLine("Export2 Say..");
        }
}
 
 
GetExport
 
만약 여러 개의 구성 요소의 인스턴스가 필요하다면 GetExport 메서드를 통해 Export 의 구성 정보를 가져오면 됩니다.
 
var exports = container.GetExport<Export1>();
exports.GetExportedObject().Say();
 
필요하다면 ExportAttribute 의 Contract Name 으로 질의(Query) 할 수 있습니다.
 
var exports = container.GetExport<Export2>("export2");
exports.GetExportedObject().Say();
 
아쉽게도 MEF Preview 4 까지 지원하던 C# 3.0 의 Expression 을 통해 질의하는 방법은 MEF Preview 5 이후 없어진 것이 아쉽네요.
 
GetExportedObjectOrDefault
 
일반적으로 MEF 에서는 질의(Query) 결과가 없을 경우 예외를 발생하게 되는데, GetExportedObjectOrDefault 메서드를 통해 결과가 없을 경우 Null 값으로 대체할 수 있습니다.
 
var obj = container.GetExportedObjectOrDefault<Export1>("A");
if( obj != null )
        obj.Say();
 
 

'.NET > .NET Framework' 카테고리의 다른 글

CodeFx 프로젝트  (0) 2009.06.24
MEF 세미나 자료  (0) 2009.06.22
[MEF] 10. Querying the Composition Container  (0) 2009.05.17
[MEF] 9. Recomposition  (2) 2009.04.20
[MEF] 8. Strongly Typed Metadata  (0) 2009.04.17
[MEF] 7. Exports and Metadata  (1) 2009.04.16
Posted by 땡초 POWERUMC

댓글을 달아 주세요

Recomposition
 
이전 포스트의 MEF 의 특징 중에 MEF 의 플러그인 모델(Plugin Model) 은 교체가 용이하다고 하였습니다. Composable Part 는 구성 요소로써 고유의 기능을 구현합니다. 그리고 MEF 는 각각의 Composable Part 를 조립하여 다양한 컴포넌트 또는 애플리케이션을 완성합니다.
 
어떠한 경우에는 특정한 구성 구성요소를 사용하다가 그것이 필요 없어질 경우 구성 요소를 언로드(Unload) 하거나 다른 구성요소로 교체할 필요가 있습니다.
 
MEF 의 이러한 유연함의 예를 들어보죠.
 
예를 들어, 어플리케이션의 로그(Log) 기능을 생각해볼 수 있습니다. 만약 어플리케이션이 동작하는 환경이 인터넷에 연결되지 않는 환경이라면 사용자의 컴퓨터 로컬에 로그를 기록하다가, 인터넷에 연결될 경우 외부 데이터베이스로 로그를 기록하는 시나리오를 가정할 수 있습니다. 그리고 이러한 기능 또는 요구 사항이 언제 변경될지도 모르는 일입니다.
 
일단 위의 시나리오를 구현하기 여러 가지 고려해야 할 사항이 있고, 기능 또는 요구 사항이 변경될 경우도 고려해야 합니다. 결국, MEF 는 이러한 변화에 굉장히 유연하게 대처할 수 있습니다.
 
MEF 에서 ImportAttribute 의 AllowRecomposition 프로퍼티를 통해 구성 요소를 런타임(Runtime) 시 동적(Dynamic) 으로 교체할 수 있도록 합니다.
 
아래는 위의 예로 든 시나리오를 구현하기 위해 작성한 간단한 소스 코드 입니다.
 
ILogger 인터페이스
public interface ILogger
{
        void Write();
}
 
ILogger 인터페이스는 Write 메서드를 통해 로그를 기록할 수 있는 예입니다.
 
 
TextLogger 클래스
[Export(typeof(ILogger))]
public class TextLogger : ILogger
{
        public void Write()
        {
               Console.WriteLine("Logged TextLogger");
        }
}
 
 
DatabaseLogger 클래스
[Export(typeof(ILogger))]
public class DatabaseLogger : ILogger
{
        public void Write()
        {
               Console.WriteLine("Logged DatabaseLogger");
        }
}
 
 
LoggerContext 클래스
[Export]
public class LoggerContext
{
        [Import(AllowRecomposition=true)]
        public ILogger Context { get; set; }
 
        [ImportingConstructor]
        public LoggerContext(ILogger sender)
        {
        }
}
 
여기에서 ImportAttribute 의 AllowRecomposition 프로퍼티의 값을 true 로 지정해 주었습니다. AllowRecomposition 프로퍼티가 true 일 경우 Imported 된 구성 요소를 동적(Dynamic)하게 교체할 수 있도록 합니다.
 
 
Main 어플리케이션
class Program
{
        static void Main(string[] args)
        {
               Program p = new Program();
               p.Run();
        }
 
        void Run()
        {
               var catalog    = new AggregateCatalog(new TypeCatalog(typeof(LoggerContext)));
 
               var container = new CompositionContainer(catalog);
               var batch = new CompositionBatch();
               var defaultPart = batch.AddPart(new TextLogger());
               container.Compose(batch);
 
               var obj = container.GetExportedObject<LoggerContext>();
 
               obj.Context.Write();
              
               batch = new CompositionBatch();
               batch.RemovePart(defaultPart);
               batch.AddPart(new DatabaseLogger());
               container.Compose(batch);
 
               obj.Context.Write();
        }
}
 
이 코드는 처음에 TextLogger 를 사용하다가, 필요 없어진 TextLogger 를 제거하고 DatabaseLogger 로 교체하는 코드입니다.
 
아래는 위의 소스 코드를 실행한 결과입니다.
 

[그림1] 소스 코드 실행 결과
 
 
Wow! Recomposition
 
사실 이러한 것이 기존에는 기능의 정의 또는 요구 사항에 따라 직접 구현할 수 있었지만, MEF 의 특징인 플러그인 모델(Plugin Model) 은 이러한 고민에 대해 좋은 방법을 제공해 줍니다. 개발자는 자신이 구현해야 할 기능에 더 충실하고, 비즈니스 로직에 대한 고민만을 하면 됩니다. 그리고 정책에 따라 그것을 집행하는 결정권을 가진 자는 구현된 구성 요소를 조립하고 교체하여 기존의 정적인(Static) 어플리케이션에게 동적인(Dynamic) 유연함을 제공합니다.
 
기존에 정적인 어플리케이션은 변화에 따라 유지 보수를 위해 지속적인 많은 리소스가 필요하였지만, 플러그인 모델(Plugin Model) 의 동적인 어플리케이션은 그러한 변화에 능동적으로 대처할 수 있는 큰 기쁨을 줄 수 있을 것입니다.

'.NET > .NET Framework' 카테고리의 다른 글

MEF 세미나 자료  (0) 2009.06.22
[MEF] 10. Querying the Composition Container  (0) 2009.05.17
[MEF] 9. Recomposition  (2) 2009.04.20
[MEF] 8. Strongly Typed Metadata  (0) 2009.04.17
[MEF] 7. Exports and Metadata  (1) 2009.04.16
[MEF] 6. Lazy Exports  (0) 2009.04.13
Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 윤성민 2009.07.26 17:18 Address Modify/Delete Reply

    꼭 MEF가 아니더라도 상기 예제는 Interface만으로도 구현이 가능하지 않을까요?
    그것과 MEF가 가지는 장점은 무엇인지가.. 개인적으로 궁금합니다.

    • 땡초 POWERUMC 2009.07.26 23:44 신고 Address Modify/Delete

      이미 윤성민님께서 "~가능하지 않을까?" 라는 고민에 MEF 가 가이드를 제시해 주고 있습니다.
      (직접 구현한다면 불가능한 것이 없겠습니다만)
      DI/IoC 와 Addin Framework 의 불편함을 겪어 보셨다면 이미 충분한 답이 될 것 같습니다.

      그래도 제가 생각하는 MEF 의 최대 장점은 Composable 이 아닐까 생각합니다.
      이미 WPF 에서도 이러한 Composable 한 패턴을 위해 MVVM 등으로 풀어가는 단적인 예만 본다면,
      단지 Object 로만 바라보던 기존 패러다임과는 분명히 다르지 않겠습니까?? ^^

      세미나 발표 자료에서 언급했듯이 IoC+Addin=MEF 외에도 Composable 로 인하여 1:n, 조립, 결합, 구성이라는 장점을 누릴 수 있습니다.

Strongly Typed Metadata
 
[.NET/.NET Framework] - [MEF] 7. Exports and Metadata 를 통해 Export 의 Contract 에 Metadata 를 제공하는 방법을 알아보았습니다.
 
MetadataAttribute 을 선언하여 Export 의 Metadata 를 제공하는 방법입니다.
 
[Export(typeof(IMessageSender))]
[ExportMetadata("SenderType", "Email")]
[ExportMetadata("Logging", true)]
public class EmailMessageSender : IMessageSender
{
        public void Say()
        {
               Console.WriteLine("Import EmailMessageSender");
        }
}
 
Export 에 Metadata 를 제공해 주어서 무척 고맙지만, 위의 방법처럼 MetadataAttribute 를 선언하는 방법을 사용하기에 그다지 내키지 않는 구석이 있습니다.
 
아무래도 아래와 같은 이유 때문이겠죠?
 
l 메타데이터의 타입 불안정
l 빌드 시 오류를 해결이 어려움
l 사용상 모든 키값을 외우기 어렵고, 오타 발생 위험
 
위의 이유 때문에 Metadata 를 사용하기 위해 강력한 타입을 원하게 될 것입니다. 그리고 강력한 타입의 Metadata 를 사용하길 권장 드립니다.
 
 
Declaring Strongly Typed Metadata
 
Attribute 을 상속받아 Export 의 Metadata 를 Strongly Typed 으로 확장시키는 방법입니다.
 
아래의 Stringly Typed Metadata 를 위해 Attribute 클래스를 만드는 소스 코드 입니다.
 
[MetadataAttribute]
[AttributeUsage(AttributeTargets.Class, AllowMultiple=false)]
public class MessageSenderTypeAttribute : Attribute
{
        public MessageSenderTransport Transport { get; set; }
        public bool IsSecure { get; set; }
 
        public MessageSenderTypeAttribute() { }
 
        public MessageSenderTypeAttribute(MessageSenderTransport transport)
               : this(transport, false)
        {
        }
 
        public MessageSenderTypeAttribute(MessageSenderTransport transport, bool isSecure)
        {
               this.Transport = transport;
               this.IsSecure = IsSecure;
        }
}
 
public enum MessageSenderTransport
{
        Email,
        Phone,
        Sms
}
 
Strongly Typed Metadata 를 위한 Attribute 클래스를 완성하였으면, 이것을 그대로 ExportAttribute 과 함께 추가적으로 선언하면 됩니다.
 
그리고 ExportAttribute 을 선언한 코드에 위의 Attribute 특성을 부여합니다. 아래는 그 소스 코드의 일부입니다.
 
[Export(typeof(IMessageSender))]
[MessageSenderType(MessageSenderTransport.Email)]
public class EmailMessageSender : IMessageSender
{
        public void Say()
        {
               Console.WriteLine("Import EmailMessageSender");
        }
}
 
[Export(typeof(IMessageSender))]
[MessageSenderType(MessageSenderTransport.Phone, true)]
public class PhoneMessageSneder : IMessageSender
{
        public void Say()
        {
               Console.WriteLine("Import PhoneMessageSneder");
        }
}
 
[Export(typeof(IMessageSender))]
[MessageSenderType(Transport=MessageSenderTransport.Sms, IsSecure=true)]
public class SmsMessageSender : IMessageSender
{
        public void Say()
        {
               Console.WriteLine("Import SmsMessageSender");
        }
}
 
그렇다면 아래와 같이 Metadata 를 Strongly Typed 으로 질의(Query) 할 수 있게 됩니다.
 
아래의 소스 코드는 지난 포스트의 소스 전체 소스 코드를 참고하십시오.
 
foreach (var export in program.Sender)
{
        if ((MessageSenderTransport)export.Metadata["Transport"] == MessageSenderTransport.Sms)
        {
               export.GetExportedObject().Say();
 
               if ((bool)export.Metadata["IsSecure"] == true)
               {
                       Console.WriteLine("Security message");
               }
        }
}
 
위의 소스 코드 실행 결과는 원하던 결과대로 다음과 같습니다.
 

[그림1] Strongly Typed 질의 결과
 
 
하지만 아직도 문제는 남아 있는 것 같아 보이네요. Strongly Typed 으로 Export Metadata 를 선언하였지만 여전히 질의(Query) 과정은 똑같은 문제점을 가지고 있습니다.
 
l 메타데이터의 질의(Query) 과정의 타입 불안정
l 빌드 시 오류를 해결이 어려움
l 사용상 모든 키값을 외우기 어렵고, 오타 발생 위험
 
 
More Strongly Typed Metadata Query
 
Metadata 를 질의(Query) 하기 위해 MEF 는 보다 강력하게 Import 하는 방법을 제공해 줍니다. 확장된 MetadataAttribute 에 인터페이스(Interface) 를 구현하도록 하여 Import 시에 인터페이스(Interface) 를 통한 Metadata 를 질의(Query) 하는 방법입니다.
 
우선 Attribute 에 사용되는 프로퍼티를 인터페이스로 선언합니다.
 
public interface IMessageSenderTypeAttribute
{
        bool IsSecure { get; }
        MessageSenderTransport Transport { get; }
}
 
단, 여기에서 반드시 Getter 만 선언하셔야 합니다. Setter 를 선언하시면 MEF 는 Setter 프로퍼티로 인해 유효하지 않는 Attribute 으로 인식하여 예외를 발생하게 됩니다.
 
아래의 소스 코드는 Metadata Attribute 클래스에 위의 인터페이스를 구현한 코드 입니다.
 
[MetadataAttribute]
[AttributeUsage(AttributeTargets.Class, AllowMultiple=false)]
public class MessageSenderTypeAttribute : Attribute, IMessageSenderTypeAttribute
{
        public MessageSenderTransport Transport { get; set; }
        public bool IsSecure { get; set; }
 
        public MessageSenderTypeAttribute() { }
 
        public MessageSenderTypeAttribute(MessageSenderTransport transport)
               : this(transport, false)
        {
        }
 
        public MessageSenderTypeAttribute(MessageSenderTransport transport, bool isSecure)
        {
               this.Transport = transport;
               this.IsSecure = IsSecure;
        }
}
 
 
이제 Export 의 MetadataView 로 질의할 수 있도록 MetadataView 의 인터페이스를 알려주도록 해야 합니다.
 
[Import(typeof(IMessageSender))]
ExportCollection<IMessageSender, IMessageSenderTypeAttribute> Sender { get; set; }
 
아래의 소스 코드는 MetadataView 를 통해 Strongly Typed 으로 Export Metadata 를 질의(Query) 하는 소스 코드 입니다.
 
[Import(typeof(IMessageSender))]
ExportCollection<IMessageSender, IMessageSenderTypeAttribute> Sender { get; set; }
                                             
static void Main(string[] args)
{
        Program program = new Program();
        program.Run();
 
        foreach (var export in program.Sender)
        {
               if (export.MetadataView.Transport == MessageSenderTransport.Email)
               {
                       export.GetExportedObject().Say();
               }
        }
}
 

'.NET > .NET Framework' 카테고리의 다른 글

[MEF] 10. Querying the Composition Container  (0) 2009.05.17
[MEF] 9. Recomposition  (2) 2009.04.20
[MEF] 8. Strongly Typed Metadata  (0) 2009.04.17
[MEF] 7. Exports and Metadata  (1) 2009.04.16
[MEF] 6. Lazy Exports  (0) 2009.04.13
MEF Preview 5 Released  (0) 2009.04.09
Posted by 땡초 POWERUMC

댓글을 달아 주세요

Exports and Metadata
 
Export 에 Metadata 를 등록하고 제어하는 방법입니다. 지난 포스트에서 알 수 있듯이 Export 는 구성 요소간에 Contact 를 제공하여 이들을 구성(Composition) 할 수 있는 플러그인 모델(Plugin Model) 을 제공해 줍니다.
 
하지만 Contract 가 제공되어 구성 요소를 확장하고 구성하는 것은 매우 용이하다는 것을 알게 되었으나 Contract 로 인해 파생된 다양한 구성 요소를 어떻게 제어하느냐의 고민을 하게 됩니다. 즉, 다양한 구성 요소 가운데 내가 필요로 하는 구성 요소를 골라낼 수 있도록 Metadata 를 제공하여 구성 요소를 질의(Query)할 수 있도록 하는 것입니다.
 

예를 들어 아래와 같은 Export 구성 요소 중 어떻게 EmailMessageSender 로 Say() 를 호출할 것인가가 문제인 것이죠.

[Export(typeof(IMessageSender))]
public class EmailMessageSender : IMessageSender
{
        public void Say()
        {
               Console.WriteLine("Import EmailMessageSender");
        }
}
 
[Export(typeof(IMessageSender))]
public class PhoneMessageSneder : IMessageSender
{
        public void Say()
        {
               Console.WriteLine("Import PhoneMessageSneder");
        }
}
 
[Export(typeof(IMessageSender))]
public class SmsMessageSender : IMessageSender
{
        public void Say()
        {
               Console.WriteLine("Import SmsMessageSender");
        }
}
 
이런 경우, 원초적인 방법으로 리플랙션(Reflection) 을 이용하여 Type 검사를 통해 EmailMessageSender 를 골라내서 사용하면 되지만, 직접적으로 Type 을 검사하기 위해서는 Tightly Coupling 이 발생하여 결국 유연한 플러그인 모델을 구현하기 위해 아무런 도움이 되지 않습니다.
 
이러한 방법을 해소하기 위해 또 다른 우회 방법은 리플랙션을 통해 Modules Name 으로 비교하는 방법이지만, 이것 또한 플러그인 모델에서 구성 요소가 교체 되었을 경우를 생각하면 전혀 대응할 수 없는 방법입니다.
 
MEF 에서는 이런 문제를 해소하기 위해 Contract 에 Metadata 를 제공하며 정적/동적인 방법을 제공해 줍니다.
 
 
Attaching Metadata to an Export
 
Export 에 Metadata 를 제공해 주기 위해서 MEF 에서는 ExportMetadataAttribute 특성을 제공해 줍니다.
 
[AttributeUsage(AttributeTargets.Class | AttributeTargets.Property | AttributeTargets.Method | AttributeTargets.Field,
                    AllowMultiple = true, Inherited = false)]
public ExportMetadataAttribute(string name, object value)
 
왜 ExportMetadata 클래스는 sealed 로 선언이 되었나요?
 
일반적으로 sealed 로 클래스를 봉인할 경우 리플랙션의 성능이 향상됩니다.
 
 
ExportMetadata 는 키와 값(Key/Value) 을 지정하여 Contract 에 Metadata 를 제공해 줄 수 있습니다. 그리고 하나의 Export 에 여러 개의 Metadata 를 제공할 수 있도록 AllowMultiple 을 지원합니다.
 
Metadata 는 여러 가지의 정보를 포함할 수 있습니다. Export 가 제공하는 기능의 특성을 기술할 수 있으며, 예를 들어, 권한, 로깅, 구성 요소 분류 방법 등이 될 수 있을 것입니다.
 
아래의 소스 코드는 Metadata 를 지정하는 예를 보여줍니다.
 
[Export(typeof(IMessageSender))]
[ExportMetadata("SenderType", "Email")]
[ExportMetadata("Logging", true)]
public class EmailMessageSender : IMessageSender
{
        public void Say()
        {
               Console.WriteLine("Import EmailMessageSender");
        }
}
 
[Export(typeof(IMessageSender))]
[ExportMetadata("SenderType", "Phone")]
public class PhoneMessageSneder : IMessageSender
{
        public void Say()
        {
               Console.WriteLine("Import PhoneMessageSneder");
        }
}
 
[Export(typeof(IMessageSender))]
[ExportMetadata("SenderType", "Sms")]
public class SmsMessageSender : IMessageSender
{
        public void Say()
        {
               Console.WriteLine("Import SmsMessageSender");
        }
}
 
 
 
Constraining Imports statically
 
MEF Preview 5 에서는 ImportRequiredMetadataAttribute 클래스가 제거되었습니다.
 
MEF Preview 4 에서는 선언적인 방법으로 ImportRequiredMetadataAttribute 를 통해 Metadata 를 질의할 수 있었으나, MEF Preview 5 에서는 ImportRequiredMetadataAttribute 클래스가 제거되었습니다.
 
아마도 추측으로는 ImportRequiredMetadataAttribute 를 선언 시에 여러 개의 구성 요소가 검색될 경우 Exception 이 발생하는데, Exception 을 최소화 하고자 제거가 된 것 같습니다.
 
혹시 Statically 한 방법으로 ImportRequiredMetadataAttribute 에 대응되는 클래스를 아시면 저에게 알려주세요.
 
 
Constraining Imports dynamically
 
이 방법은 Export 의 ExportMetadata 를 런타임 시에 질의(Query) 하는 방법입니다.
 
Import 시 ExportCollection<T> 을 사용하여 Export 를 수동적으로 질의(Query) 하는 방법입니다. 이 방법은 지난 포스트의 Lazy Load 를 이용한 방법으로 단지 Metadata 만 질의(Query) 뿐이고, 객체의 생성에 대한 판단은 필요 시에만 GetExportedobject() 메서드를 이용하여 생성할 수 있습니다.
 
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
 
using System.ComponentModel.Composition;
using System.ComponentModel.Composition.Hosting;
using System.Reflection;
 
namespace MetadataSample
{
        class Program
        {
               [Import(typeof(IMessageSender))]
               ExportCollection<IMessageSender> Sender { get; set; }
 
               static void Main(string[] args)
               {
                       Program program = new Program();
                       program.Run();
 
                       foreach (var export in program.Sender)
                       {
                              if ((string)export.Metadata["SenderType"] == "Email")
                                      export.GetExportedObject().Say();
 
                              if (export.Metadata.ContainsKey("Logging") &&
                                      (bool)export.Metadata["Logging"] == true)
                                      Console.WriteLine("Logged success");
                       }
               }
 
               void Run()
               {
                       var catalog = new AggregateCatalog(new AssemblyCatalog(Assembly.GetExecutingAssembly()));
 
                       var container = new CompositionContainer(catalog);
                       var batch = new CompositionBatch();
                       batch.AddPart(this);
                       container.Compose(batch);
               }
 
               public interface IMessageSender
               {
                       void Say();
               }
 
               [Export(typeof(IMessageSender))]
               [ExportMetadata("SenderType", "Email")]
               [ExportMetadata("Logging", true)]
               public class EmailMessageSender : IMessageSender
               {
                       public void Say()
                       {
                              Console.WriteLine("Import EmailMessageSender");
                       }
               }
 
               [Export(typeof(IMessageSender))]
               [ExportMetadata("SenderType", "Phone")]
               public class PhoneMessageSneder : IMessageSender
               {
                       public void Say()
                       {
                              Console.WriteLine("Import PhoneMessageSneder");
                       }
               }
 
               [Export(typeof(IMessageSender))]
               [ExportMetadata("SenderType", "Sms")]
               public class SmsMessageSender : IMessageSender
               {
                       public void Say()
                       {
                              Console.WriteLine("Import SmsMessageSender");
                       }
               }
        }
}
 

실행 결과는 예상할 수 있듯이 아래와 같이 런타임 시에 결과를 보여줍니다.


'.NET > .NET Framework' 카테고리의 다른 글

[MEF] 9. Recomposition  (2) 2009.04.20
[MEF] 8. Strongly Typed Metadata  (0) 2009.04.17
[MEF] 7. Exports and Metadata  (1) 2009.04.16
[MEF] 6. Lazy Exports  (0) 2009.04.13
MEF Preview 5 Released  (0) 2009.04.09
[MEF] 4. Import 선언  (6) 2009.04.07
Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. Yeon 2014.11.21 18:33 Address Modify/Delete Reply

    ExportCollection 부분이 안뜨게 되는데

    2009년 글이라....

    버전업하면서 방식이 따로 바뀐건가요?

일반적인 Exports
 
Composable Part 를 구성하는 동안 특정 Part 에 대한 요청으로 객체 내부의 객체가 필요할 때가 있습니다. 만약 객체가 이런 연관 관계가 있을 경우 객체 내부에 ImportAttribute 을 선언하여 외부 Part 를 Import 할 수 있습니다. 이런 경우는 객체 내부에 Export 간의 Related 관계를 갖게 됨으로써 자동적으로 객체를 초기화할 수 있게 됩니다. ([MEF] 3. Export 선언 참조)
 
일반적인 Export 를 통해 객체 내부에 Import 를 선언하는 방법입니다.
 
class Program
{
        static void Main(string[] args)
        {
               Program p = new Program();
               p.Run();
        }
 
        void Run()
        {
               var catalog = new AggregateCatalog(new AssemblyCatalog(Assembly.GetExecutingAssembly()));
 
               var container = new CompositionContainer(catalog);
               var batch = new CompositionBatch();
               batch.AddPart(this);
 
               container.Compose(batch);
 
               var obj = container.GetExportedObject<EmailMessageSender>();
               obj.Sender.Say();
        }
}
 
[Export]
public class MessageSender
{
        public void Say()
        {
               Console.WriteLine("Say Method");
        }
}
 
[Export]
public class EmailMessageSender
{
        [Import]
        public MessageSender Sender { get; set; }
}
 
 
Lazy Exports
 
하지만 비용이 비싼 객체를 생성할 경우 위의 [일반적인 Exports] 는 매우 비효율적일 수 있습니다. 객체 내부의 Import Object 를 사용하지 않을 가능성이 크거나, 객체의 생성 비용이 클 경우는 Lazy Export 를 고려해야 합니다. 그리고 내부 객체가 동기적(Synchronicity)이 아닌 비동기성(Asynchronism) 성격의 객체일 경우에도 반드시 필요한 기법입니다.
 
이런 경우 내부 객체의 생성을 선택적, 수동적으로 제어하여, 게으른 초기화(Lazy Initialization) 를 할 필요가 있습니다.
 
아래의 굵은 표시의 코드가 Lazy Export 로 제어하는 코드입니다.
 
class Program
{
        static void Main(string[] args)
        {
               Program p = new Program();
               p.Run();
        }
 
        void Run()
        {
               var catalog = new AggregateCatalog(new AssemblyCatalog(Assembly.GetExecutingAssembly()));
 
               var container = new CompositionContainer(catalog);
               var batch = new CompositionBatch();
               batch.AddPart(this);
 
               container.Compose(batch);
 
               var obj = container.GetExportedObject<EmailMessageSender>();
               obj.Sender.Say();
 
               var lazyObj = container.GetExportedObject<EmailMessageSenderByLazyExport>();
               lazyObj.Sender.GetExportedObject().Say();
        }
}
 
[Export]
public class MessageSender
{
        public void Say()
        {
               Console.WriteLine("Say Method");
        }
}
 
[Export]
public class EmailMessageSender
{
        [Import]
        public MessageSender Sender { get; set; }
}
 
[Export]
public class EmailMessageSenderByLazyExport
{
        [Import]
        public Export<MessageSender> Sender { get; set; }
}
 
ImportAttribute 의 프로퍼티를 Export<T> 타입으로 변경하면 내부 객체를 GetExportedObject() 메서드를 이용하여 지연하여 객체를 생성할 수 있습니다.

'.NET > .NET Framework' 카테고리의 다른 글

[MEF] 8. Strongly Typed Metadata  (0) 2009.04.17
[MEF] 7. Exports and Metadata  (1) 2009.04.16
[MEF] 6. Lazy Exports  (0) 2009.04.13
MEF Preview 5 Released  (0) 2009.04.09
[MEF] 4. Import 선언  (6) 2009.04.07
ASP.NET 에서 Entity Framework 바인딩 문제  (2) 2009.03.29
Posted by 땡초 POWERUMC

댓글을 달아 주세요

MEF Preview 5 Released
 
MEF Preview 5 Released
 
 
 
Managed Extensibility Framework(이하 MEF) 의 Preview 5 가 릴리즈 되었습니다. 새로운 기능적인 면 보다는 기존의 체제에 약간의 변경 내역과 불필요한 기능들의 제거 등이 대부분입니다.
 
그리고 Caching 의 새로운 Infrastructure 로 개량되었으며, Import/Export 의 Contract 방법도 개선된 방법이 추가가 되었습니다. 아래는 MEF Preview 5 의 Release Notes 입니다.
 
 
Namespace changes
  • System.ComponentModel.Composition – For part authors. This namespace contains the import and export attributes as well as other APIs that part authors are likely to use.
  • System.ComponentModel.Composition.Hosting – For hosters. This namespace contains the CompositionContainer, catalog implementations, and other APIs that hosters are likely to use.
Part discovery changes
  • CompositionOptionsAttribute and DiscoveryMode have been removed.
  • PartNotDiscoverableAttribute replaces [CompositionOptions(DiscoveryMode = DiscoveryMode.Never)]
  • PartCreationPolicyAttribute can be used to specify part creation policy (Replaces CompositionOptionsAttribute.CreationPolicy)
  • By default, exports on a base class will not be included in the exports for a derived class.
  • The PartExportsInheritedAttribute can be applied to a base class to specify that exports on that class will be included in derived classes. NOTE: If this attribute is used, and both the base and derived class have export attributes applied to them, there will be multiple exports created for the same class. Also note that whatever metadata is applied to the export on the base class can’t be added to or overridden by the derived class
Collection imports
  • ImportManyAttribute should now be used on collection imports (in the future, an ImportAttribute will not be interpreted as a collection import even if it is applied to a collection type).
  • Array imports are now supported.
Typed Imports/Exports
  • Imports and Exports now match on type as well as contract.
  • Exporters of string contracts such as [Export(“Foo”)] must now specify the type they expect to be imported as well. e.g. [Export(“Foo”, typeof(string))]
Method exports
  • Method exports can now be imported as custom delegates in addition to Action<…> and Func<…> delegates
Directory Catalog
  • The directory watching functionality has been removed. The Refresh() method has been added to explicitly update the catalog with new assemblies in the directory.
Removal of Caching / new infrastructure
  • The old caching infrastructure has been removed. We’ve added a general purpose API that allows the implementation of catalog caching as well as supporting builders of custom programming models. The APIs are members of the static class System.ComponentModel.Composition.ReflectionModel.ReflectionModelServices. In the future we plan to ship a sample that shows how these APIs can be used to create cached catalogs.
New sample application
  • MEF Studio – a designer hosting sample.
Common compilation errors to expect when migrating previous code bases
  • System.ComponentModel.Composition.Container does not exist -> Add reference to System.ComponentModel.Composition.Hosting namespace
  • CompositionContainer does not contain method AddPart or Compose -> Need to start using CompositionBatch, or one of the helper extension methods ComposeParts or ComposeExportedObjects
  • CompositionOptionsAttribute does not exist -> For CreationPolicy use PartCreationPolicyAttribute
  • INotifyImportCompleted does not exist -> Use IPartImportsSatisfiedNotification interface and change method from ImportCompleted to OnImportsSatisfied
 
 
아래는 MEF Preview 5 에서 새롭게 추가된 MEF Studio 예제입니다. MEF 의 특징을 잘 보여주고 있는 것 같네요.
 
[그림1] MEF Studio Sample


'.NET > .NET Framework' 카테고리의 다른 글

[MEF] 7. Exports and Metadata  (1) 2009.04.16
[MEF] 6. Lazy Exports  (0) 2009.04.13
MEF Preview 5 Released  (0) 2009.04.09
[MEF] 4. Import 선언  (6) 2009.04.07
ASP.NET 에서 Entity Framework 바인딩 문제  (2) 2009.03.29
[MEF] 3. Export 선언  (0) 2009.03.29
Posted by 땡초 POWERUMC

댓글을 달아 주세요

Import 선언
 
MEF 의 구성 요소에 System.ComponentModel.Composition.ImportAttribute 특성을 선언하여 Import 를 선언할 수 있습니다. Import 는 Export 와 사용 방법이 매우 유사합니다. Import 는 프로퍼티(Properties), 필드(Fields), 생성자(Constructors) 에 선언할 수 있으며, 계약된 Export 구성 요소들을 Import 할 수 있습니다.
 
 
Property Import
 
프로퍼티로 값을 가져오기 위해 ImportAttribute 특성을 선언하면 됩니다.
 
Import 특성은 세 가지의 시그너처(Signature) 를 제공합니다.
 
public ImportAttribute();
public ImportAttribute(string contractName);
public ImportAttribute(Type contractType);
 
일반적으로 타입을 명시하지 않을 경우 프로퍼티의 타입이 Export 의 계약(Contract) 을 결정하게 됩니다.
 
아래는 프로퍼티에 Import 를 사용하는 방법입니다.
 
[Import]
MessageProcess MessageProcess { get; set; }
 
 
Field Import
 
필드의 Import 는 프로퍼티에 Import 를 선언하는 방법과 동일합니다.
 
[Import]
MessageProcess _messageProcess;
 
 
Constructor Parameters (생성자 파라메터)
 
Constructor Parameters 는 ImportingConstructor 특성을 사용하여 정의합니다. 특히 Constructor Parameters 는 여러 구성 요소를 사용하기 위해 프로퍼티 또는 필드로 선언되는 Import 의 선언을 생략할 수 있어 편리하게 사용할 수 있습니다. 또한, 암시적인 Import 가 가능하기 때문에 수동적으로 이것을 제어할 필요가 없으며, 구성 요소의 교체가 매우 용이합니다.
 
아래의 코드는 ImportingConstructor 특성을 이용하여 암시적으로 Import 하는 예입니다.
 
[Export]
public class Controller
{
   public View CurrentView { get; set; }
   public Model CurrentModel { get; set; }
 
   [ImportingConstructor]
   public Controller(View view, Model model)
   {
       this.CurrentView = view;
       this.CurrentModel = model;
   }
}
 
명시적인 Import 를 하기 위해서는 생성자 파라메터에 ImportAttribute 특성을 명시해 주면 됩니다.
 
아래는 Constructor Parameters 예의 전체 소스 코드입니다.
 
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Reflection;
 
using System.ComponentModel.Composition;
using System.ComponentModel.Composition.Hosting;
 
namespace ImportSample
{
   class Program
   {
       [STAThread]
       static void Main(string[] args)
       {
             Program p = new Program();
             p.Run();
       }
      
       private void Run()
       {
              var catalog = new AggregateCatalog();
             catalog.Catalogs.Add(new AssemblyCatalog(Assembly.GetExecutingAssembly()));
 
             var container = new CompositionContainer(catalog);
             var batch = new CompositionBatch();
             batch.AddPart(this);
             container.Compose(batch);
 
             var controller = container.GetExportedObject<Controller>();
 
            
             Console.WriteLine(controller.CurrentView.ToString());
             Console.WriteLine(controller.CurrentModel.ToString());
       }
   }
 
   [Export]
   public class Controller
   {
       public View CurrentView { get; set; }
       public Model CurrentModel { get; set; }
 
       [ImportingConstructor]
       public Controller(View view, Model model)
       {
             this.CurrentView = view;
             this.CurrentModel = model;
       }
   }
 
   [Export]
   public class View
   {
       public override string ToString()
       {
             return "Export View";
       }
   }
 
   [Export]
   public class Model
   {
       public override string ToString()
       {
             return "Export Model";
       }
   }
}
 
실행 결과는
 
[그림1] Constructor Parameters 예제 소스 코드 실행 결과
 
 
Importing Collection
 
MEF 는 Composable Container 의 모든 Contract 의 인스턴스를 컬렉션으로 가져올 수 있습니다. MEF 는 플러그인 모델(Plugin Model) 로써 구성 요소를 교체와 추가/제거가 용이하다고 하였습니다. 이러한 구성 요소가 동적으로 교체 또는 컨테이너에 의해 관리가 되면서 구성 요소는 업데이트 또는 Recomposable(재구성 가능한) 될 수 있습니다.
 
Contract 기반의 MEF 구성 요소는 동적인(Dynamic)한 환경을 제공하며, 이것을 관리하기 위해 컬렉션으로 제어할 수 있습니다.
 
아래는 Importing Collection 의 예제 소스 코드입니다.
 
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Reflection;
 
using System.ComponentModel.Composition;
using System.ComponentModel.Composition.Hosting;
 
namespace ImportSample
{
   class Program
   {
       [Import]
       IEnumerable<IMessageSender> MessageSenders;
 
       [STAThread]
       static void Main(string[] args)
       {
             Program p = new Program();
             p.Run();
 
             foreach (var sender in p.MessageSenders)
             {
                    sender.Say();
             }
       }
      
       private void Run()
       {
             var catalog = new AggregateCatalog();
             catalog.Catalogs.Add(new AssemblyCatalog(Assembly.GetExecutingAssembly()));
 
             var container = new CompositionContainer(catalog);
             var batch = new CompositionBatch();
             batch.AddPart(this);
             container.Compose(batch);
       }
   }
 
   public interface IMessageSender
   {
       void Say();
   }
 
   [Export(typeof(IMessageSender))]
   public class PhoneMessageSender : IMessageSender
   {
       public void Say()
       {
             Console.WriteLine("Message Send - Phone");
       }
   }
 
   [Export(typeof(IMessageSender))]
   public class EMailMessageSender : IMessageSender
   {
       public void Say()
       {
             Console.WriteLine("Message Send - EMail");
       }
   }
}
 
IMessageSender 인터페이스를 구현한 구성 요소를 컬렉션으로 루핑하여 호출한 결과입니다.
 
[그림2] Importing Collection 예제 소스 코드 실행 결과
 
 
INotifyImportSatisfaction
 
MEF Preview 5 부터 INotifyImportSatisfaction 인터페이스는 IPartImportsSatisfiedNotification 으로 변경되었습니다.

INotifyImportSatisfaction 인터페이스는 Import 처리가 완료가 되었을 때 통보되는 인터페이스 입니다. System.ComponentModel.Composition.INotifyImportSatisfaction 인터페이스는 ImportCompleted() 메서드만 구현하면 됩니다. 클래스내 모든 Import 처리가 완료가 되었을 경우 ImportCompleted() 메서드가 호출됩니다.
 
아래 소스 코드는 INotifyImportSatisfaction 인터페이스를 구현한 예 입니다.
 
class Program : INotifyImportSatisfaction
{
 
   public void ImportCompleted()
   {
       Console.WriteLine("Completed");
   }
 
}
 
 
 
MEF 다시 보기
 
MEF 는 마치 어린 아이들이 좋아하던 조립 로봇을 보는 듯한 인상입니다. 로봇의 몸체만 있다면 팔, 다리를 끼워 로봇을 어렵지 않게 완성하는 것처럼 말입니다. 플라스틱 로봇에게 강철 옷을 입히고 싶다면, 로봇을 전부 때려부시고 새로 만들지 않고서도 MEF 를 이용하면 가능합니다. 그리고 칼과 방패를 채워주고 싶다면 그렇게 하시면 됩니다.
 
[그림3] MEF 와 조립 로봇 (그림 출처는 여기)
 
MEF 를 볼수록 하나의 작은 SOA(Service Oriented Architecture) 라고 봐도 무방할 것 같습니다. (비교하는 것이 무리이긴 하지만…) MEF 의 플러그인 모델(Plugin Model) 은 느슨한 결합(Loose Coupling) 으로 Service 와 EndPoint 의 Contract 기반의 유연한 확장성을 제공해 줍니다. 아마도 단시간내에 새로운 아키텍처의 모델로써 주목을 받을 수 있지 않을까 기대해봅니다.

'.NET > .NET Framework' 카테고리의 다른 글

[MEF] 6. Lazy Exports  (0) 2009.04.13
MEF Preview 5 Released  (0) 2009.04.09
[MEF] 4. Import 선언  (6) 2009.04.07
ASP.NET 에서 Entity Framework 바인딩 문제  (2) 2009.03.29
[MEF] 3. Export 선언  (0) 2009.03.29
[MEF] 2. Parts 와 Contracts 선언  (0) 2009.03.22
Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 길버트 2010.01.29 11:42 Address Modify/Delete Reply

    엄준일 MVP이 정리해 놓은 .NET Framework 4.0 MEF 강좌가
    Silverlight MEF 공부하기 위한 기반을 닦는데
    많이 도움이 되고 있습니다.

    감사드리구요.

    작은 질문하나 드립니다.
    Importing Collection에 인스턴스가 담기게 되는 기본순서(Default Order)는
    코드에 선언된 순서이겠지요?

    • 땡초 POWERUMC 2010.01.29 12:58 신고 Address Modify/Delete

      안녕하세요. 길벗님^_^
      먼저 Importing 순서라는 것은 존재하지 않구요.
      ComposablePartDefinition 을 통해
      Import <-> Export 관계가 성립이 됩니다.
      결국은 Export 에 따라서 Imports 가 결정이 되는데,
      그 순서는 Catalog 를 어떤것을 쓰느냐도 밀접하게 관련이 있습니다.

      아마도 굳이 순서를 매기고 싶으시면 ExportMetadata 등을 사용하시면 좋을 것 같아요.

  2. 길버트 2010.01.29 15:42 Address Modify/Delete Reply

    답변 감사드려요. 제가 질문이 정확하지 못했던 것 같아서 다시 질문을 드리자면,
    [Import]를 선언한 프로퍼티 IEnumerable<IMessageSender> MessageSenders; 를 통해서
    [Export(typeof(IMessageSender))]를 선언한 IMessageSender 클래스 인스턴스들에
    접근하게 되는데요.

    이때 MessageSenders에 담기게 된 IMessageSender가 실행한 샘플 예제를 보면,
    PhoneMessageSender, EMailMessageSender 순서인 것을 확인 할 수 있습니다.
    이런 순서는 어떻게 정해진 것인지 궁금합니다. 코드 상에 선언된 순서를 바꾸면
    실행 결과도 EMailMessageSender, PhoneMessageSender 바뀌는 것인지 궁금해서
    질문을 드렸습니다.

    (한번 해보면 알텐데 저도 참 게으르네요. ^^)

    • 땡초 POWERUMC 2010.01.30 00:05 신고 Address Modify/Delete

      하하하^^
      길벗님이 귀차니즘이 있다니 놀랍네요 +_+ㅋ

      내부적으로 리플랙션으로 타입을 가져오기 때문에
      순서를 바꾸는 것을 떠나서,
      리플랙터가 타입을 가져오는 순서가 될 듯 싶습니다.

      사실 IL 코드 자체가 내부적으로 정렬 기준이 없고
      컴파일된 내부 IL 코드 순서대로 가져오기 때문에
      클래스가 파일별로 나뉘어져있고, 프로젝트가 분리되는 상황이라면
      순서는 어떻다고 제가 장담드릴 순 없을 듯 합니다요. +_+;

  3. 길버트 2010.01.31 12:24 Address Modify/Delete Reply

    답변 감사드려요.
    그럼 의도하는 정렬 순서가 있을 때는
    콜렉션을 사용하기 전에 linq 등으로
    소트해서 사용하면 되겠군요.

    감사합니다.
    2010 글로벌 써밋 가십니까?

    • 땡초 POWERUMC 2010.02.01 01:21 신고 Address Modify/Delete

      저는 서밋 안가요 ^_^
      갠적인 생각으로는 PDC 재탕하는거라 ;;;

      글구 정렬 등 임의 순서를 원하시면
      LINQ 로 소트하는 것 보다는,
      ExportMetadataAttribute 을 이용해서
      Order 프로퍼티를 추가해서 사용하심이 좋을 듯 한데요.

Exports 선언
 
MEF 는 Export 를 통해 외부로 구성요소를 노출할 수 있습니다. Export 는 System.ComponentModel.Composition.ExportAttribute 특성을 통해 선언합니다. 이 특성은 클래스 뿐만 아니라 프로퍼티와 메서드에도 선언을 할 수 있습니다.
 
 
구성요소 Export 하기
 
ExportAttribute 특성을 사용하여 아래와 같이 구성요소를 외부로 노출하게 됩니다. ExportAttribute 은 몇 가지의 시그너처(Signature) 를 제공하는데 매개변수를 생략하게 될 경우 MEF 은 클래스의 타입으로 Contract 를 매핑하게 됩니다.
 
[Export]
class MessageSender
{
 
}
 
 
프로퍼티 Export
 
프로퍼티를 Export 하는 방법입니다. 프로퍼티를 Export 할 수 있게 되어 여러 가지 면에서 유리할 수 있습니다.
 
Core CLR 이 제공하는 타입(Type) 뿐만 아니라 외부의 다양한 타입(Type) 을 사용할 수 있습니다. 프로퍼티에 Export 를 선언할 수 있음으로써 Export 를 구조적으로 분리하여 단순화 할 수 있습니다. 그러므로 같은 구성요소 내에서 Export 간의 Related 관계를 가질 수 있습니다.
 
아래의 코드와 같이 Timeout 프로퍼티는 Contract 를 맺게 됩니다.
 
public class Configuration
{
   [Export("Timeout")]
   public int Timeout
   {
       get { return int.Parse(ConfigurationManager.AppSettings["Timeout"]); }
   }
}
 
[Export]
public class UsesTimeout
{
   [Import("Timeout")]
   public int Timeout { get; set; }
}
 
 
메서드 Export
 
구성요소의 메서드를 Export 할 수 있습니다. 메서드의 Export 는 기본적으로 대리자(Delegate) 를 통해 호출하게 됩니다. 메서드를 Export 하게되면 보다 더 세세한 제어를 가능하게 하고, 심플하게 방법으로 Code Generating 이 가능합니다.
 
public class MessageSender
{
   [Export(typeof(Action<string>))]
   public void Say(string message)
   {
       Console.WriteLine(message);
   }
}
 
[Export]
public class MessageProcess
{
   [Import(typeof(Action<string>))]
   public Action<string> MessageSender { get; set; }
 
   public void Send()
   {
       MessageSender("Call send process in MessageProcess");
   }
}
 
그리고 ExportAttribute 은 타입(Type) 대신 문자열을 사용하여 Contract 를 사용할 수 있습니다.
 
public class MessageSender
{
   [Export("MessageSender")]
   public void Say(string message)
   {
       Console.WriteLine(message);
   }
}
 
[Export]
public class MessageProcess
{
   [Import("MessageSender")]
   public Action<string> MessageSender { get; set; }
 
   public void Send()
   {
       MessageSender("Call send process in MessageProcess");
   }
}
 
 
아래의 소스 코드는 이번 예제에서 사용된 전체 소스 코드입니다.
namespace ExportSample
{
   class Program
   {
       [Import]
       MessageProcess MessageProcess { get; set; }
 
       [STAThread]
       static void Main(string[] args)
       {
             Program p = new Program();
             p.Run();
 
             p.MessageProcess.Send();
       }
 
       private void Run()
       {
             var catalog = new AggregateCatalog();
             catalog.Catalogs.Add(new AssemblyCatalog(Assembly.GetExecutingAssembly()));
 
             var container = new CompositionContainer(catalog);
             var batch = new CompositionBatch();
             batch.AddPart(this);
             container.Compose(batch);
       }
   }
 
   public class MessageSender
   {
       [Export("MessageSender")]
       public void Say(string message)
       {
           Console.WriteLine(message);
       }
   }
 
   [Export]
   public class MessageProcess
   {
       [Import("MessageSender")]
       public Action<string> MessageSender { get; set; }
 
       public void Send()
       {
             MessageSender("Call send process in MessageProcess");
       }
   }
}
 
 
Export 요약
 
이렇게 ExportAttribute 을 사용하여 Contract 를 제공하는 것은 굉장히 중요한 의미를 가지게 됩니다. 플러그인 모델(Plugin Model) 에서 Export 는 구성요소를 외부로 노출하는, 즉 Contract 의 방법을 제공해 주게 됩니다.
 
 
Contract 맺음으로써 개발자는 Contract Base 로 단지 Contract 만 제공받으면 됩니다. 이러한 Contract 는 제한된 상호작용을 극복하여 대부분의 커플링(Coupling)을 해소할 수 있으며, 플로그인 모델(Plugin Model) 에서 보다 쉽게 구성요소를 캡슐화 할 수 있습니다.

'.NET > .NET Framework' 카테고리의 다른 글

[MEF] 4. Import 선언  (6) 2009.04.07
ASP.NET 에서 Entity Framework 바인딩 문제  (2) 2009.03.29
[MEF] 3. Export 선언  (0) 2009.03.29
[MEF] 2. Parts 와 Contracts 선언  (0) 2009.03.22
[MEF] 1. Managed Extensibility Framework 이란?  (0) 2009.03.16
.NET Framework 4.0 의 특징  (0) 2009.02.09
Posted by 땡초 POWERUMC

댓글을 달아 주세요

시작하기 전에
 
MEF 는 이미 CodePlex 사이트의 Wiki 에 코드를 중심으로 설명이 잘되어 있습니다. 그렇기 때문에 저도 CodePlex 의 사이트를 참고하여 나름대로 각색하여 작성을 하고자 합니다. 레퍼런스가 이미 CodePlex 에 충분하지만, 저는 나만의 시각에서 바라보고 느낀 바를, 그리고 소스 코드를 만들어 가고자 합니다^^ (사실 Wiki 의 설명은 미약할 다름입니다^^;)
 
CodePlex 의 Wiki 를 먼저 보실 분은 최신 버전이 적용이 되지 않은 예제도 있으니 이런 부분은 조심해서 리뷰하시기 바랍니다.
 
 
어플리케이션에 MEF 호스팅하기
 
[그림1] Composition Container
 
Composable Part
 
MEF 에 어플리케이션을 호스팅하기 위해서는 몇 가지의 반복적인 절차를 거치면 됩니다. 먼저 MEF 를 호스팅할 수 있는 컨테이너(Container) 를 만들어야 합니다. 컨테이너는 MEF 에서 상위 그룹에 존재하며 MEF 의 파트(Part) 를 관리하며 핵심 역할을 담당합니다.
 
MEF 의 컨테이너는 배치(Batch) 를 구조적으로 구성하고 캡슐화 합니다. 배치(Batch) 의 각 구성 단위를 파트(Part) 라고 부릅니다. 각 파트(Part) 는 닷넷 어셈블리에서 타입(Type) 이 될 수 있으며, 타입(Type) 을 배치(Batch) 로 등록할 수 있습니다.
 
파트(Part) 는 메인 호스트(Main Host) 가 반드시 포함되어야 하며, 아래의 소스 코드에서 보는 것처럼 this 키워드가 바로 메인 호스트(Main Host) 가 됩니다.
 
Contract
 
이러한 Composable Part 는 다른 컴포넌트와 의존 관계를 갖지 않습니다. 모든 외부 기능(Export) 는 계약(Contract) 를 맺게되며 이것이 필요할 경우에는 Import 할 수 있습니다.
 
MEF 의 컨테이너는 Contract 정보의 타입 정보나 메타 데이터를 통해 Export 와 Import 를 매칭합니다.
 
 
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
 
using System.ComponentModel.Composition;
using System.ComponentModel.Composition.Hosting;
 
class Program
{
    static void Main(string[] args)
    {
        Program p = new Program();
        p.Run();
    }
 
    public void Run()
    {
        var container = new CompositionContainer();
        var batch = new CompositionBatch();
        batch.AddPart(this);
        container.Compose(batch);
    }
}
 
이러한 파트(Part) 를 제어하는 작업은 어플리케이션 차원에서 유일해야 하므로 스레드(Thread) 작업에 안전하도록 lock 으로 블로킹(Blocking) 되어있습니다.
 
이 작업은 메인 호스트(Main Host) 를 등록하는 과정에 불과하며 실행 시에 아무런 결과가 없습니다.
 
 
외부로 기능 노출하기 (Export)
 
이제 어떤 플러그인(Plugin) 을 외부로 노출해야 합니다. 외부로 노출하는 이유는 내/외부에서 노출된 확장 기능을 가져다 쓰기 위해서입니다. 확장 기능을 노출하기 위해서는 단지 Export Attribute 을 정의해 주면 됩니다.
 
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
 
using System.ComponentModel.Composition;
using System.ComponentModel.Composition.Hosting;
 
namespace MEFLab_Hosting_MEF
{
    class Program
    {
        static void Main(string[] args)
        {
               Program p = new Program();
               p.Run();
        }
 
        public void Run()
        {
               var container = new CompositionContainer();
               var batch = new CompositionBatch();
               batch.AddPart(this);
               container.Compose(batch);
        }
    }
 
    public interface IHelloWorld
    {
        void Say();
    }
 
    [Export(typeof(IHelloWorld))]
    public class HellowWorld : IHelloWorld
    {
        public void Say()
        {
               Console.WriteLine("Hello MEF!");
        }
    }
 
인터페이스(Interface) 를 구현한 HelloWorld 클래스는 Export Attribute 를 정의합니다. Export 의 파라메터는 메타 데이터(Meta Data)로 사용되기 때문에 타입(Type) 을 정의해 주어야 합니다.
 
혹자는 왜 인터페이스를 정의해야 하느냐고 궁금해 하기도 합니다. 정답을 드리자면, 반드시 인터페이스를 정의하지 않아도 됩니다. 하지만 특히 MEF 에서 인터페이스는 다형적이고 표준적인 메타 데이터를 제공하기 위해 인터페이스를 선언하여 사용하는 것이 좋을 것 같네요^^
 
 
외부 기능 가져오기 (Import)
 
Export Attribute 으로 외부로 노출된 확장 기능은 Import Attribute 으로 가져올 수 있습니다. 단, 배치(Batch) 의 파트(Part) 로 등록이 되어 있어야 합니다. 내부적으로 Import 의 타입을 생략할 경우 Export 의 타입의 메타 데이터를 통해 Import 의 개체를 쿼리(Query) 하여 생성하게 됩니다.
 
class Program
{
    static void Main(string[] args)
    {
        Program p = new Program();
        p.Run();
    }
 
    [Import]
    IHelloWorld HelloWorldCompoent { get; set; }
 
    public void Run()
    {
        var container = new CompositionContainer();
        var batch = new CompositionBatch();
        batch.AddPart(new HellowWorld());
        batch.AddPart(this);
        container.Compose(batch);
 
        HelloWorldCompoent.Say();
    }
}
 
public interface IHelloWorld
{
    void Say();
}
 
[Export(typeof(IHelloWorld))]
public class HellowWorld : IHelloWorld
{
    public void Say()
    {
        Console.WriteLine("Hello MEF!");
    }
}
 
이 예제에서 알 수 있듯이 코드에서 모듈(Module) 이나 타입(Type) 의 관계를 크게 신경 쓰지 않았습니다. Export 와 Import 를 통해서 의존(Dependency) 는 어느 정도 해소된 것처럼 보입니다. (인터페이스만 잘 활용하면 MEF 없이도 충분히 가능합니다)
 
이것이 끝이라면 정말 재미가 없겠죠. 차차 나오게 될 내용이지만, 이러한 Export 와 Import 를 활용하고 Lazy Load, 그리고 메타 데이터를 이용한 쿼리(Query) 를 활용하게 되면 복잡한 기능을 획기적으로 단순화 할 수 있습니다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

MEF (Managed Extensibility Framework) 란?
 
Menaged Extension Framewkr(이하 MEF) 란? 가장 쉽게 얘기하자면, 어플리케이션과 컴포넌트의 재사용성을 높일 수 있는 프레임워크입니다. 기존의 어플리케이션은 하나의 목적을 하나의 어플리케이션으로 구현한 정적인(Statically) 어플리케이션이라면, MEF 는 보다 동적인(Dynamically) 어플리케이션을 구축할 수 있는 새로운 라이브러리를 제공합니다.
 
기존의 정적인 어플리케이션은 새로운 요구사항으로 기능을 확장할 필요가 있을 경우 새로운 빌드 버전을 필요로 합니다. 그리고 새로운 빌드 버전은 기존 어플리케이션과 확장된 기능간에 종속적인 관계를 탈피할 수 없었습니다. 이미 프로그램 언어를 사용하여 코드를 작성하는 분들이라면 반복적이거나 확장에 대해 많은 고민을 한번쯤 해보았을 것입니다.
 

[그림1] MEF 의 컨셉 이미지
 
MEF 는 플랫폼의 저레벨(Low Level) 에서 공통된 추상적인 기능을 제공하고 여러 곳에 흩어진 이중 작업을 감소시킬 수 있습니다.
 
몇 달 전 마이크로소프트에서는 Application Framework Core 팀이라 부르는 팀이 만들어졌다고 합니다. 이 팀은 ASP.NET, Windows Forms, WPF, Silverlight 의 여러 플랫폼에서 동작하기 위한 BCL(Base Class Library) 과 같은 역할을 한다고 합니다.
 
 
MEF 는 플러그인 모델(Plugin Model)
 
MEF 는 플러그인 모델(Plugin Model) 이라고도 부릅니다. 플러그인 모델을 잘 모르신다면, 전기 콘센트의 플러그를 연상하시면 됩니다. 전기 콘센트의 플러그는 그 수가 제한되어 있지만 어댑터를 추가로 구매하여 꽃으면 몇 개의 콘센트를 꽃을 수 있습니다. 그리고 TV 나 컴퓨터를 사용하고 싶다면 콘센트에 꽃기만 하면 TV 와 컴퓨터를 동작시킬 수 있습니다.
 

[그림2] MEF 는 플러그인 모델(Plugin Model) 이다. (이미지 출처는 여기)
 
만약 더 좋은 TV 나 컴퓨터가 생겼다면 플러그를 빼고 더 좋은 TV 나 컴퓨터의 플러그를 콘센트에 꽂기만 하면 됩니다.
 
이처럼 MEF 는 어플리케이션의 확장을 위한 보다 유연한 아키텍처를 제공하며, 약간의 개념만 이해한다면 사용하기도 쉽습니다.
 
 
어디서 많이 본 듯한 아키텍처?
 
맞습니다. 저도 MEF 를 처음 보는 순간 느꼈습니다. MEF 의 외관은 마치 DI(Dependency Injection) 과 IoC(Inversion of Control) 의 그것과 매우 유사해 보였습니다.
 
용어 설명
 
DI(Dependency Injection) / 의존성 주입
객체간의 의존성과 결합도를 낮추기 위한 기술
 
IoC(Inversion of Control) / 역제어
인스턴스의 관리를 컨테이너에서 인스턴스의 생성과 소멸의 생명주기를 관리
 
하지만 MEF 는 DI 나 IoC 와 전혀 다릅니다. 위에서 얘기한대로 MEF 는 플러그인 모델입니다. 어플리케이션의 확장을 위한 프레임워크이며, DI 와 IoC 는 잊어버리십시오! 아래의 단원에서 DI 와 IoC 를 잊을 수 있는 분명한 근거를 설명하도록 하겠습니다.
 
 
플러그인 모델(Plugin Model) 로 뭘 할 수 있나요?
 
MEF 의 플러그인 모델(Plugin Model) 은 보다 나은 확장성을 제공해 줍니다. 마치 Visual Studio 의 Addin 을 연상하시면 됩니다. Visual Studio Addin 은 Visual Studio 의 기능을 쉽고 강력하게 활용할 수 있도록 도와주며 전혀 새로운 기능을 추가할 수 있는 플러그인(Plugin) 입니다. 그럼 MEF 의 플러그인 모델(Plugin Model) 은 어떠한 장점이 있을까요?
 
MEF 의 플러그인 모델은 아래와 같은 장점을 제공합니다.
 
l 확장 기능에 대한 인스턴스를 생성하는 방법(SingleCall, Singleton)을 제공하며, 인스턴스의 회수할 수 있어야 합니다.
l 상호작용을 할 수 있습니다. 확장 기능간에 메시지의 전달이 쉽고 용이해야 합니다. Global Service 처럼 상호간의 인터페이스가 제공되어야 하고 이러한 메시지에 응답할 수 있어야 합니다.
l 확장 기능은 Lazy Load 할 수 있어야 합니다. 확장 기능은 원하는 시기에 로드해야 합니다. 마치 VSIP(Visual Studio Integration Package) 의 VSCT 와 같이 인터페이스나 이벤트는 노출이 되어 있지만 실제로 확장 기능이 활성화된 것은 아닙니다.
l 확장이 용이해야 합니다. 예를 들어, 확장 기능이 특정 폴더(Addin 폴더라고 가정)로 복사된다면 이를 감지하여 인터페이스를 제공하거나 확장 기능이 활성화 되어야 합니다.
l 교체가 쉬워야 합니다. 새로운 기능이 추가된 확장 기능은 교체가 쉬워야 하며, 필요 없어진 확장 기능을 언로드(Unload) 할 수 있어야 합니다.
 
MEF 는 여러분의 정적인 어플리케이션에 동적인 생명력을 불어넣어 줄 수 있으며, 그 근간은 바로 플러그인 모델(Plugin Model) 입니다.
 
이러한 플러그인 모델은 근본적인 상호간의 의존(Dependency) 관계를 보다 자연스럽게 해결할 수 있으며, 유연하고 매끄럽게 다룰 수 있을 것으로 기대합니다.
 
MEF 설치하기
 
MEF 는 .NET Framework 4.0 에 포함될 예정입니다. 하지만 아쉽게도 .NET Framework 4.0 CTP 버전에는 포함되어 있지 않기 때문에 Visual Studio Team System 2010 의 VPC 이미지에서도 테스트할 수 있는 환경이 갖추어지지 않았습니다.
 
현재 2009-03-16 기준으로 MEF 는 Preview 4 버전이며 CodePlex 에서 소스코드와 바이너리를 다운로드 받을 수 있습니다.
 
MEF (Managed Extensibility Framework) 다운로드
 
 
 
시작이 반이다! 친절한 HelloWorld 따라하기
 
자… 이제 MEF 도 설치했고 언제나 그렇듯 HelloWorld 를 콘솔에 출력하는 코드를 작성해 보도록 합시다. 소스 코드에 대한 설명은 다음 단원으로 넘기도록 하고, 오늘은 MEF 가 어떻게 동작하는지 눈대중만 익히시면 될 것 같습니다.
 
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Reflection;
 
using System.ComponentModel.Composition;
using System.ComponentModel.Composition.Hosting;
 
namespace ConsoleApplication1
{
       class Program
       {
             static void Main(string[] args)
             {
                    Component com = new Component();
            
                    var catalog = new AggregateCatalog();
                    catalog.Catalogs.Add(new AssemblyCatalog(Assembly.GetExecutingAssembly()));
 
                    var container = new CompositionContainer(catalog);
                    var batch = new CompositionBatch();
                    batch.AddPart(com);
                    container.Compose(batch);
 
                    com.HelloWorldComponent.Say();
             }
       }
 
       public class Component
       {
             [Import]
             public IHelloWorld HelloWorldComponent { get; set; }
       }
 
       public interface IHelloWorld
       {
             void Say();
       }
 
       [Export(typeof(IHelloWorld))]
       public class HelloWorld : IHelloWorld
       {
             public void Say()
             {
                    Console.WriteLine("Hello MEF");
             }
       }
}
 
 
출력 결과는
 

[그림3] 소스 코드 실행 결과
 
혹자는 HelloWorld 를 찍는데 왜 이렇게 많은 코드가 필요한가에 불만이 있을지도 모릅니다. 맞습니다. 단순히 결과가 HelloWorld 가 출력되기만 바란다면 이렇게 긴(?) 코드는 필요가 없을지도 모릅니다. 하지만 위의 소스 코드는 보다 큰 어플리케이션을 만들기 위한 초석이며 실제로 큰 어플리케이션에서는 훨씬 적은 코드로 복잡한 요구사항을 구현할 수 있을지도 모르는 일입니다^^
 
 
MEF 는 아직은 Preview
 
언제나 그렇듯이 새로운 프레임워크는 새로운 패러다임을 가져옵니다. 그리고 보다 나은 아키텍처와 개발 방법을 제시합니다. 물론 MEF 도 더 깊이 살펴볼수록 그 놀라운 기능에 감탄을 하게 될 것입니다.
 
하지만 아직 MEF 는 Preview 입니다. MEF 의 플러그인 모델은 충분히 활용 가치가 있지만 아직은 실무에서 즉시 도입하기엔 많은 고민이 따를 것 같습니다. 그리고 이런 애로 사항이 아마로 정식 버전에서는 해결되리라 생각합니다. 시간이 되면 이 부분도 한번 다루어 보도록 하겠습니다.

'.NET > .NET Framework' 카테고리의 다른 글

[MEF] 3. Export 선언  (0) 2009.03.29
[MEF] 2. Parts 와 Contracts 선언  (0) 2009.03.22
[MEF] 1. Managed Extensibility Framework 이란?  (0) 2009.03.16
.NET Framework 4.0 의 특징  (0) 2009.02.09
Enterprise Library 4.0 릴리즈  (0) 2008.05.18
.NET 3.5 Enhancements Training Kit  (0) 2008.05.07
Posted by 땡초 POWERUMC

댓글을 달아 주세요

image

.NET Framework 4.0 은 Visual Studio 2010 에 포함되는 최신 프레임워크입니다. 이전에는 .NET Framework 의 새로운 특징이라면 .NET Framework 의 기능 향상과 안정성, 그리고 기능 개선이었습니다. 하지만 .NET Framework 4.0 은 탄탄한 Based .NET Framework 를 통해 여러 가지 새로운 변화를 가져옵니다.

이제는 .NET Framework 가 Win32 API 와 같이(Win32 API 와 비교하기 적절하지는 않지만…) 라이브러리의 집합이 아닌, 어플케이션의 차원에서 보다 견고하고 세련된 빌딩(Building) 을 할 수 있는 진정한 프레임워크로 거듭납니다. .NET Framework 4.0 의 특징을 살펴 봅니다.

Base Class Library 개선

  • MEF(Managed Extensibility Framework)
    • 확장성이 쉬운 선언과 사용
    • 런타임 확장 모니터링
  • 데이터 구조 추가
    • BigInteger & CodeplexNumber
    • Tuple, SortedSet
  • IO 개선
    • 메모리 매핑 파일
    • 모델 해제 통일

MEF 는 어플케이션과 컴포넌트의 재사용성을 높이기 위한 새로운 라이브러리입니다. 확장성 있는 어플케이션과 프레임워크를 만들기 위해 MEF 가 그 대안이라고 제시하고 있습니다. 이 프로젝트는 현재 CodePlex 를 통해 Preview 4 가 릴리즈되었고, 여기에서 다운로드 받을 수 있습니다.

또한 64 비트 프로그래밍을 위한 새로운 데이터 구조가 추가 되었습니다. 64비트 컴퓨팅 시대에 맞춰 .NET Framework 의 Int32 가 한계였다면, 이제는 그보다 더 큰 비트 연산을 할 수 있는 데이터 구조와 새로운 데이터 구조가 추가 되었습니다.

Parallel Computing

  • Task Parallel Library (TPL)
    • 수평적인 병렬 작업의 실행
    • 최대 효율을 위한 Stealing 알고리즘 작업
    • 상위 레벨을 추상화 ( 더 이상 스레드의 지식이 필요 없다 )
  • Parallel Linq (PLINQ)
    • 선언적인 데이터 병렬처리(초점은 ‘무엇’, ‘어떻게’가 아니다)
    • LINQ to Object 를 사용하여 단순한 병렬 처리
  • Coordination Data Structures (CDS)
    • 병렬 처리를 쉽게 하기 위한 공통 구조

다중 코어 프로세서의 사용을 극대화 하기 위해 이제는 병렬 처리를 위해 스레드를 생성하여 동기화 하는 과정을 더 이상 고민하지 않아도 됩니다. 병렬 처리를 하기 위한 확장 메서드를 제공하며, LINQ 식을 통해 데이터의 병렬 처리가 무척이나 쉬워졌습니다. 이제는 ‘어떻게’가 아닌, '무엇을’ 병렬 처리 할 것인지만 생각하면 됩니다.

.NET Framework Client

  • Windows Presentation Foundation
    • 클라이언트 프로파일(Client Profile)
    • 비지니스 컨트롤에 초점
    • 실버라이트 시너지 효과
    • Windows 7 지원 (멀티터치 등)

ADO.NET 4.0

  • Entity Framework v2
    • Code-Fiirst 개발 지원
    • TDD 지원
    • 외래키(Foreign Key) 지원
    • Lazy 로딩

.NET Framework 3.5 SP1 에 등장한 Entity Framework 의 차기 버전입니다. 이전 버전은 기본 키를 중심으로 한 Entity Data Model 이였다면 새로운 버전에서는 외래 키도 지원하게 되었습니다. 또한, TDD(Test-Driven-Development) 을 지원하며, Code-First 방식의 개발도 지원하게 되었습니다.

ASP.NET 4.0

  • ASP.NET Dynamic Data 개선
  • ASP.NET MVC
  • MVC 에 ASP.NET Dynamic Data 지원
    • 데이터 중심으로 뷰와 커스텀 컨트롤 만들기 쉽게
  • CSS, ID, ViewState 컨트롤이 더 좋아진 ASP.NET
  • 확장할 수 있는 캐싱 프레임워크(Caching Framework)

ASP.NET 4.0 의 가장 큰 매력은 바로 ASP.NET MVC 의 통합입니다. 그 동안 Postback, ViewState 기반의 빠른 생산성이 ASP.NET 의 핵심이었습니다. 하지만, ASP.NET MVC 를 통해 Form 기반에서도 빠른 생산성을 향상시켰습니다. 또한, MVC 를 구현하기 위해 많은 코드와 분리 작업을 자동화 할 수 있는 템플릿을 지원합니다.

Velocity

  • .NET 을 위한 분산 캐싱
  • ASP.NET 의 Session State Provider
  • 유연하고, 서로 다른 캐싱 모델
    • Partitioned
    • Replicated
    • Local

.NET 이 지원하는 가장 대표적인 분산 캐싱이 ASP.NET 의 Session State Provider 입니다. 그렇지만 Session State Provider 의 분산 캐싱 능력에는 한계가 있으며, 이러한 한계를 극복할 수 있는 프레임워크가 바로 Velocity 입니다. 캐싱을 분산 처리 하기 위해 많은 고민을 해야 하며, 이러한 분산 캐싱 환경에서 빠른 응답성, 확장성, 고사용성을 높였습니다.

엔터프라이즈 어플케이션 환경에서 많은 관심을 보일 것이며, 특히 요즘 새롭게 대두 되고 있는 SaaS 나 Cloud Computing 을 위해 빠져서는 안될 핵심 기술이 될 것입니다.

Windows Workflow & Communication Foundation

  • 완전 선언적인 서비스
  • 워크플로우 개선
    • 프로그래밍 모델 개선
    • 새로운 플로우차트 모델 스타일 & 확장 활동 팔레트
    • 워크플로우 규칙 통합
    • 디자이너 경험 향상
    • 상당한 성능 향상
    • 상호 메시지
  • WCF 개선
    • Duplex 내구성
    • In-process Channel
    • WS-Discovery & UDP Channel

ADO.NET Data Services

  • 관계형 데이터 지원
  • ‘오프라인’ 상태 지원

ADO.NET Data Services 도 .NET Framework 3.5 SP1 에서 사용하기 위해 몇 가지 추가 작업이 필요하였으며, 보다 자세한 내용은 여기를 참고 하십시오.

특히, 이 버전에서는 Data Services 의 오프라인을 지원합니다. 오프라인에서도 ADO.NET Services 의 사용은 수 많은 외부 시스템과 연동 시에 서비스의 일관성을 유지해 줄 것입니다.

ASP.NET AJAX

  • 자바스크립트 UI 템플릿과 데이터 바인딩
  • AJAX 컨트롤 툴킷 개선
  • DOM Selection, 애니메이션 등

ASP.NET AJAX 는 요즘 가장 인기 있는 AJAX 프레임워크인 JQuery 와 통합하게 됩니다. JQuery 를 사용하고 인텔리센스를 지원하기 위해 몇 가지 수작업이 있었다면, 이제는 그러한 작업 없이도 JQuery 의 고급 기능을 ASP.NET AJAX 에서 사용할 수 있습니다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요