윈도우 8, 요즘 인기가 많다. 일반 사용자들의 후기도 많이 보이고, 더불어 개발자들에게도 기존의 개발 경험을 살려 그래도 개발이 가능해서 인기가 많다. 더불어 C++/CX와 HTML5로 개발이 가능하다.

   

WinRT와 WinMD

그 중에서 C#/XAML을 이용하여 앱을 개발할 경우 Windows 8 Runtime(WinRT)의 라이브러리를 이용하여 개발하게 되는데, 마이크로소프트에서는 이 WinRT를 관리 언어가(Managed 플랫폼 환경) 아닌 C++로 만들어진 네이티브(Native)로 컴파일 되어 있다. 확장된 COM 기반이기 때문에 C#과 HTML5에서 모두 이 라이브러리 APIs 집합을 사용할 수 있다. 이것은 매우 큰 장점이 분명하다.

그런데 말이다. 이 WinRT 자체가 매우 성급하게 만들어진 라이브러리라는 것이 여럿 보인다. 그 중 네이티브로 컴파일된 환경에서 C#과 유사하게 런타임상의 객체나 타입 정보를 알아내기 위해 RTTI(RunTime Type Identification)을 C++/CX 컴파일 시에 자동으로 구현이 된다. 그리고 RTTI를 위해 사용되는 WinRT의 API 정보의 일부는 .WinMD 파일로 저장이 된다. 이를 윈도우 런타임 라이브러리(Windows Runtime Library)라고 하며, 이 라이브러리는 윈도우 8 앱을 개발하는 환경 모두에서 사용할 수 있다.

   

   

   

   

윈도우8 WinRT, XAML의 미완성을 의미하는 IXamlMetadataProvider와 IXamlType 인터페이스

여기에서 문제가 발생한다. 모든 객체들은 C++/CX과 C#에서 XAML(eXtensible Application Markup Language)에서 다룰 수 있다. 그리고 Windows.UI.Xaml 네임스페이스에 XAML과 관련된 APIs 집합이 있다. 그런데 WinRT는 XAML을 핸들링 할 수 있는 라이브러리를 완벽하게 구현해 놓지 못했다.

그래서 WinRT의 IXamlMetadataProviderIXamlType 인터페이스가 생겼다. 이 인터페이스가 WinRT가 XAML을 (꽁수로) 핸들링하기 위해 만들어진 인터페이스로 보인다.

코드에서 새로운 객체를 생성해서 사용하고 싶으면 var obj = new LoginView(); 와 같이 새로운 객체를 생성하는 new 키워드를 사용하면 된다.

객체지향을 완벽하게 표현하는 XAML에서도 마찬가지다. XAML에서 다음처럼 LoginView 객체를 생성할 수 있다.

   

   

여기에서 IXamlMetadataProvider가 미완성 XAML임을 증명해 준다. 윈도우8 모던 앱(Modern App)에서 XAML에서 객체가 생성되는 경우 컴파일 시에 자동으로 생성되는 XamlMetadataProvider.g.cs 파일에서 객체를 생성해 준다. (g는 Generated를 의미한다). 자동으로 생성되는 이 코드는 다음과 같은 코드가 포함이 되어있다.   

   

XAML에서 LoginView 객체 생성을 요청할 경우 IXamlMetadataProvider를 구현한 코드를 통해 객체를 대신 생성한다. 다시 말해, 하드 코딩이 되어있다.   

이는 매우 유감이다. 이는 즉, 런타임상에 동적으로 생성되는 객체나 앱 컴파일 시에 해당 클래스가 포함이 되어 있지 않다면, XAML은 객체를 생성하지 못하게 된다. 동적인 무언가에 의해 생성되는 객체는 XAML에서 명시적으로 객체를 생성할 수 있는 방법이 없어진 것이다. (단, 명시적인 호출)

   

   

사용자가 구현하는 IXamlMetadataProvider

일단 WinRT가 이렇게 구현되어 있으니, 어쩔 수 없다. 동적으로 생성되는 객체에 대해서 XAML에서 명시적으로 객체를 생성하기 위해서는 Custom IXamlMetadataProvider를 구현해 주어야 한다.   

아래는 필자가 개발 중인 Umc.Core.WinRT.dll 에 포함된 Custom IXamlMetadataProvider이다. 윈도우8 모던 앱을 컴파일할 때 MSBuild는 참조되는 어셈블리의 메타데이터를 검색하여 IXamlMetadataProvider 인터페이스를 구현한 객체를 XamlMetadataProvider.g.cs 코드에 자동으로 추가를 해준다. 그리고 컴파일이 된다.

   

   

   

IXamlMetadataProvider가 필요한 경우의 예시

아마 일반적으로 윈도우8 앱을 개발할 때 이 인터페이스를 구현할 필요는 없다. 하지만, 앱을 캡슐화하려고 하고, IoC(Inversion of Control) Container 등을 활용하고자 하고, 동적인 객체가 필요한 경우라면 이 인터페이스를 구현해야 할 필요가 있을 것이다.   


C#이 지원하는 System.Dynamic.ExpandoObject 객체를 생성한다면 이 객체는 XAML에서 명시적으로 호출을 할 수 없다.   

또, System.Dynamic.DynamicObject 를 구현하는 객체도 마찬가지이다. 아래는 Umc.Core.WinRT에 포함된 코드의 일부이다.

   

위와 같은 코드를 이용하여 동적인 객체를 생성하였다면, 명시적으로 구현한 클래스가 없으므로 당연히 XAML에서도 이 객체를 생성할 수 없다.   

이와 같은 경우에 IXamlMetadataProvider를 구현하면 된다.

   


그 밖에 필요한 것들

아마 WinRT는 윈도우폰7 의 API 보다 더 작다. 작은 만큼 없는 것이 많고, 포기해야 하는 것이 많다. 아래에 나열되는 구현체는 http://umcore.codeplex.com 의 필자가 만든 코드를 WinRT용으로 마이그레이션한 것들이다. 조만간 Umc.Core.WinRT도 공개할 것을 약속한다.   

1. WinRT 설계 자체가 IoC Container를 활용하기 매우 너그럽지 못한 구조이다. 그래서 기본적인 WinRT 구조를 많이 벗어난 구조를 직접 구현해야 했다.      


2. MarkupExtension등을 지원하지 않아 Markup 확장이 불가능하여 다른 형태의 XAML답지 못한 요소나 속성들을 따로 만들어야 한다. MarkupExtension등으로 IoC Container 등과 통합을 쉽게 할 수 있으나, 어쩔 수 없이 필자는 Attached Property로 아래와 같이 구현해야 했다.

또는 아래와 같이 LambdaExpression을 이용하여 동적 Compile() 하여 사용하는 형태로 다음과 같이 사용이 가능토록 할 것이다. 이 경우, 위의 방법보다 더 나은 성능을 보여줄 것이다.

 

3. Frame.Navigation은 객체의 Type으로 뷰를 이동한다. 하지만, 하나의 타입에 두 개의 뷰를 만들 수 있는 APIs 를 제공해 주지 않는다 따라서 INavigationService와 NavigationServiceFrame을 직접 구현하여 다음과 같이 하나의 Type 으로 생성되는 뷰는 여러 개의 뷰 객체를 생성할 수 있도록 했다.

다음과 같이 인터페이스를 정의하였고, 기존의 Windows.UI.Xaml.Controls.Frame은 Umc.Core.ModernApp.NavigationServiceFrame으로 대체하도록 하였고, UniquqKey로 구분하여 하나의 Type에 여러 뷰를 생성하여 네비게이션 할 수 있도록 했다.

   

4. IoC Container와 통합된 EventAggregator

뷰에 이벤트를 전달하거나 전역 이벤트를 전달하기 위해서 좀 쉬운 구조로 가기 위해 IoC Container에 EventAggregator를 함께 넣어보았다. Message 방식을 통해 뷰의 이벤트나 전역 이벤트를 구독할 수 있다.

   

그리고 구독을 뷰에서 제어할 수 있도록 하였다.

   

5. IoC Container와 통합된 인젝션. 객체의 인젝션(Injection-주입)은 다음과 같이 이루어진다.

   

6. IoC Container의 Configuration File 구성

이건 이전에 http://umccore.codeplex.com 에 구현해 놓은 것을 WinRT 용으로 마이그레이션 하였다. patterns & practices - Unity의 경우 Configuration을 지원하지 않지만, UmC Core의 IoC는 이를 한번 더 Wrapping 하였기 때문에 구성 파일로 만드는 것이 가능하다.

   

7. IoC Container에서 지원하는 AOP

이는 WinRT 구조상 이를 구현하기가 그리 쉽지는 않다. WinRT에서는 직접 MSIL(MS Intermediate Language)을 이용하여 런타임에 Instructions을 생성할 수 없다. 다만, APIs 가 모자란 만큼 모자란 대로 구현을 할 수 밖에 없다.

예를 들면, C#의 dynamic 을 이용하여 다음과 같이 구현 가능하겠다.

   

   

다음 버전의 윈도우8 앱 SDK 구조는 또 얼마나 바뀔까 걱정!

실버라이트의 일부와 윈도우 폰7에서도 그러하듯 이번 WinRT도 초기 버전이라는 생각이 든다. 생각해보라. 실버라이트 1,2까지 얼마나 개발자의 Needs를 만족해주지 못하였는지. 앞으로 등장할 윈도우 폰8 개발 SDK도 하위 호환성을 일부 포기한다고 알고 있다.   

현재까지 윈도우8 앱 개발 SDK 환경을 본다면, 기존에 가능하던 것들이 WinRT 환경에서 매우 많은 제약이 따른다는 것이 불편하다. 현재 WinRT와 윈도우8 앱 개발 플랫폼의 구조를 본다면, 차기 개발 SDK에서는 WinRT를 얼마나 개선할 수 있을지 알 수는 없다. 아마 WinRT/SDK를 만드신 분들도 참 많이 고민을 했을 것이다.   

다만 WinRT/SDK를 사용하는 개발자에게 그 동안 밟아왔던 원망스러웠던 수순을 밟지 않기를 바랄 뿐이다. 

어쨌든, 윈도우8 WinRT/SDK의 불합리하거나 불편했던 부분을 필자가 구현한 이전에 공개했던 http://umccore.codeplex.com 에 추가로 공개할 예정이다.

'O/S > Windows 8' 카테고리의 다른 글

윈도우 8, 무서운 드라이버와 궁합  (0) 2013.06.05
윈도우 8, 반토막짜리 WinRT와 WinRT SDK  (1) 2012.10.30
Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 김종남 2016.05.15 21:03 Address Modify/Delete Reply

    글 잘 보았습니다.

본 글을 월간 마이크로소프트 2012년 5월호 특집 기사로 다루어진 내용입니다. Visual Studio 11이 Visual Studio 2012로 변경됨에 따라 본문의 내용을 일부 수정하였습니다. 


[월간 마이크로소프트 5월호 특집기사] Windows 8 시대를 준비하는 Visual Studio 2012
[월간 마이크로소프트 5월호 특집기사] C++ 매트로 앱 개발을 위한 C++/CX 언어
[월간 마이크로소프트 5월호 특집기사] Windows 8 시대를 준비하는 Visual Studio 2012를 마치며


본 글 이외에 Visual Studio 팀 블로그를 함께 운영하는 강보람 MVP님의 "Welcome to Metro User Interface" 컬럼과 남정현 MVP님의 "Windows Server 8 미리 보기" 컬럼은 필자의 블로그에 기재하지 않은 점 또한 참고하기 바라며, 저작자의 동의하에 추후에 공개가 될 수 있습니다.



시대가 바뀌면서 Windows도 전통적인 모습에서 벗어나서 새로운 흐름을 만들고자 하는 노력이 시작된 것 같다. 물론 기존의 데스크 탑은 여전히 널리 사용될 것이다. 일상적인 업무에서 사용하는 응용 프로그램이 굳이 메트로 사용자 인터페이스 형태를 띌 필요는 전혀 없을 테니 말이다. 그리고 앞으로도 계속해서 기존의 데스크 탑을 타겟으로 하는 윈폼이나, WPF의 개발도 지속될 것이다. 하지만, 새로운 기회는 작은 틈에서 나오는 것이니 이 틈새를 잘 이해하기 위해서는 Windows 8의 메트로 환경을 잘 이해할 필요가 있다.

 

Windows 8과 Visual Studio 2012은 그야말로 N스크린에 감히 필수적인 환경이라고 말하고 싶다. 그 어떤 플랫폼도 데스크 탑과 테블릿, 모바일 등의 모든 기기와 환경 모두를 지원하는 것은 매우 어려운 일이다. 일반 사용자가 기기마다 사용하는 용도와 스타일이 다르고, 모바일 기기마다 해상도와 특징이 다르기 때문이기도 하지만, 하나의 개발 도구로 모든 상황을 대응할 수 있는 통합 개발 도구가 없는 것도 한 몫을 한다. 아니라고 말하는 독자도 있겠지만, 필자는 데스크 탑 환경까지 확장하는 N스크린을 말하는 것이고, 모든 N개의 스크린에서 똑같은 사용자 경험을 제공하는 것을 말한다. 이런 관점에서 Windows 8과 Visual Studio 2012은 그 해답을 제시하고 있으며, 충분히 가치 있고, 도전해 볼만하다. 이런 이유로 벌써부터 필자는 매우 흥분이 된다.

 

그리고 이 글에서 모두 소개하기는 어려웠지만, Windows Server 8은 그 동안의 Windows 운영 체제가 보여주었던 정적인 모습을 탈피하여 대규모 데이터 센터가 아닌 비용 문제 때문에 고민이 많은 수 많은 중소 규모의 IT 인프라에서도 효율적으로 시스템을 운영하고 애플리케이션 개발자들이 핵심에만 접근할 수 있도록 도와줄 방법을 제공하고 있다. 또한 메트로 스타일의 앱은 단순히 사용자 인터페이스에 관한 새로운 접근일 뿐만 아니라 데스크톱 가상화나 서버 관리자를 위한 새로운 종류의 서비스로 자리잡을 수 있다. 여전히 Charm Bar의 기능은 유용하게 사용할 수 있으며, Application Contract를 정확하게 지원하는 서버용 메트로 앱을 만들어 서버 관리자의 일을 덜어내거나 전혀 새로운 경험의 터치 기반 KIOSK를 손쉽게 만들 수도 있을 것이다. 이것은 전적으로 여러분의 선택에 달려있는 일이 될 것이다. 더 나아가서, Windows Server 8의 여러 기술들이 각종 호스팅 환경은 물론 Windows Azure나 Amazon과 같은 Public Cloud Computing 환경에도 전면적으로 도입이 된다면 더 멋지고 유용한 서비스들이 대거 등장하지 않겠는가 하는 것이 개인적인 생각이다.

 

참고 자료


Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 아크몬드 2012.08.02 10:05 Address Modify/Delete Reply

    재밌게 읽고 갑니다.

본 글을 월간 마이크로소프트 2012년 5월호 특집 기사로 다루어진 내용입니다. Visual Studio 11이 Visual Studio 2012로 변경됨에 따라 본문의 내용을 일부 수정하였습니다. 그리고 현재 필자는 NCSOFT에 재직하지 않음을 참고하기 바랍니다.


[월간 마이크로소프트 5월호 특집기사] Windows 8 시대를 준비하는 Visual Studio 2012
[월간 마이크로소프트 5월호 특집기사] C++ 매트로 앱 개발을 위한 C++/CX 언어
[월간 마이크로소프트 5월호 특집기사] Windows 8 시대를 준비하는 Visual Studio 2012를 마치며

 

엄준일 – 현재 NCSOFT에 재직 중이며, Microsoft ALM MVP와 한국 Visual Studio 팀과 블로그를 운영하고 있다.. 주로 .NET 기술을 전파하고 있고, 마이크로소프트가 지향하는 소프트웨어 개발 프로세스와 통합 및 테스팅 분야를 4년 동안 공부해왔다. 그 외에 CodePlex 오픈 소스 사이트를 통해 프레임워크, 툴 그리고 라이브러리 등을 공개하여 운영 중이다.



 

성큼 다가온 Visual Studio 2012

Microsoft의 대표적인 통합 개발 도구인 Visual Studio 2012의 성장세가 무척 빠르다. 지난 10년전 .NET 플랫폼과 함께 대표적인 개발 도구인 Visual Studio.NET (2003버전)를 내놓았다. 그 때의 시간이 바로 엊그제 같은데 그 이후 Visual Studio 2005, 2008, 2010을 지나 Visual Studio 2012베타 버전을 필자가 사용하고 있으니, 짧은 10년동안 Microsoft를 비롯하여 개발 언어, 개발 툴, 이 모든 것이 굉장히 많이 변해 왔음을 새삼 다시 느껴진다. 이제 Windows 8라는 새로운 운영체제가 기다리고 있다. 그리고 이를 빛내줄 Visual Studio 2012.

 

성큼 다가온 Visual Studio 2012과 그 발자취

Visual Studio 2012를 먼저 논하기 전에 Visual Studio가 어떤 발자취를 남기며 발전해 왔는지 간단하게 살펴보는 것도 독자들이 Visual Studio 2012를 이해할 수 있는 좋은 방법이라고 생각한다. 물론 짧고 간단하게 모든 것을 설명할 수는 없지만, 전반적인 특징만으로 그 동안 개발 트랜드가 어떻게 바뀌었고, 시장의 요구 사항이 어떻게 변화하여 왔는지 한 눈에 알 수 있는 가장 좋은 방법이라고 생각한다.

 

Microsoft의 첫 번째 진정한 통합 제품으로 평가 받는 제품이 Visual Studio.NET (2003버전)이다. Microsoft의 전략적인 언어인 C# 1.0과 VB.NET(v7.0)이 .NET 개발의 대표적인 언어가 되었다. 기존의 VB를 세련된 객체지향 언어로 탈바꿈하면서 이전의 VB개발자들에게 .NET 개발의 문턱을 낮출 수 있는 매우 좋은 사례이기도 하다. (단, Visual Studio 2002는 논외로 하겠다)

이 이전의 개발도구는 하나의 도구에서는 하나의 언어로만 개발을 할 수 있었고, 개발 툴 역시 그 언어에 매우 종속적이고, 다른 언어로 전환하려면 이전의 개발 도구와 개발 경험 역시 많은 부분을 새로 습득해야 했다. 특히 J# 이라고 하는 Java 언어와 라이브러리를 제공하였는데, Java 개발자들을 .NET 플랫폼 안으로 끌어안기 위한 매우 독특한 사례이기도 하다. 실제로 J#은 웬만한 Java 소스 코드를 변경 없이 .NET 목적 파일로 컴파일 할 수 있었다.

Visual Studio는 하나의 개발 도구를 통해 여러 가지 언어를 선택하여 웹 응용 프로그램, 윈도우 응용 프로그램, 모바일 개발, XML, XML 웹 서비스를 개발을 통합하고, 여기에 포함되는 .NET Framework 1.0은 응용 프로그램을 빌드하고 실행하는 구성요소로서, ADO.NET, ASP.NET, Windows Forms 등을 포함하는 .NET Framework 클래스 라이브러리와 CLR(Common Language Runtime-공용 언어 런타임)을 제공, 이 CLR 을 통해 공통된 API 집합을 만들어 다양한 언어간의 상속, 오류 처리, 디버깅이 가능하며 개발자들은 사용하려는 언어를 자유롭게 선택할 수 있게 되었다.

이 후, Windows Server 2003 제품에 표준으로 탑재하여 .NET Framework의 확산에 큰 공을 이루게 되었고, 실제로 엔터프라이즈 시장에서 이 버전을 기준으로 많은 기업용 시스템에 도입이 되었다. 현재까지도 이 버전을 기준으로 운영이 되는 기업용 시스템이 상당수 존재하고 있을 정도이다.

 

때는 2005년. Visual Studio 2005버전은 파격 그 자체다. 여기에 포함된 런타임인 ..NET Framework 2.0은 이전 .NET Framework 1.x에 사용된 코드를 대부분 갈아 엎었을 정도이다. .NET Framework의 뼛속까지 변신한 것이다. ASP.NET 2.0, ADO.NET 2.0, Windows Forms 2.0, C# 2.0 과 같이 '~2.0' 이라는 버전 번호를 붙였고, 많은 기능이 보완되고 확장되었다. .NET Framework 2.0 의 주요 컴포넌트들은 더 이상 .NET Framework 1.1 에 의존하지 않게 되었으며, .NET Framework 2.0 은 .NET Framework 3.5 SP1 까지 .NET Framework의 모태가 된다.

모든 것이 생소할 정도로 많은 변신이 있었는데, 그 중에서 C#과 VB.NET 언어가 대표적이다. Boxing(박싱), Unboxing(언박싱)의 반복적인 캐스팅(Casting) 의 비효율을 개선하고, 보다 객체지향적인 코드 품질을 생산할 수 있는 제네릭(Generic)이 등장하였다. 이와 함께 .NET Framework 클래스 라이브러리에 다수의 제네릭(Generic) 클래스가 추가되었다. 개발 툴도 많은 변화가 있었는데, IDE 자체의 외관도 많이 변했고, 개발 툴의 내부적인 코드에서 변화가 왔고 다양한 내부 인터페이스가 추가되었다. Visual Studio의 솔루션 탐색기에서 흔히 사용하는 '솔루션 폴더'도 이때 등장하였다.

그리고, 이 제품의 버전부터 Visual Studio Team Suite + Team Foundation Server 의 제품을 조합하여 Visual Studio Team System(VSTS) 라는 새로운 개발 패러다임을 .NET 에서도 지원하게 되었다. VSTS 를 통해 ALM(Application Lifecycle Management-애플케이션 수명 주기 관리) 을 수행할 수 있게 되었으며, IT 조직의 비지니스 전반의 생산성을 향상 시키고, 사람과 개발 조직의 변화를 가져다 주는 시초가 되었다.

 

.NET Framework 3.0은 새로운 개발 도구와 출시되지 않았다. 2005년 중순 Windows Vista 운영체제가 출시되면서 이에 대응하는 라이브러리가 포함이 되었다. 함께 새로운 기술도 대거 포함이 되었는데, 그 중에서 대표적으로 꼽으라고 하면 WPF와 WCF이다. XAML(Extensible Application Markup Language) 과 함께 WPF 의 출연으로 UX(User Experience) 의 시대 흐름에 진입하게 되었다. 또한, WCF는 여러 가지의 분산 통신 기술이 통합되었다. 이전의 Remoting, XML Web Services, MSMQ 등이 하나의 WCF 컴포넌트에서 제공하게 됨으로써 Messaging Model 기반으로 통합할 수 있게 되었다.

 


 

 

때는 2007년, 또 한번의 메이저 급 업데이트였다 언어적으로 LINQ라는 새로운 녀석 때문이다. LINQ(Language Integrated Query) 라는 이름에서 알 수 있듯이 익숙한 SQL Query 문법과 유사하여 객체 탐색에 있어 효율성이 매우 높아졌고, 그 성능도 일일이 손으로 짠 코드보다 더 빠른 경우가 있다. 이 LINQ의 기반이 되는 람다식(Lambda Expression), 익명 타입(Anonymous Type), 확장 메서드(Extension Methods)의 언어적인 새로운 스팩이 한데 아우러져 LINQ를 구성한다. XML객체, DataSet, 파일 시스템, 컬렉션 등 모든 대상이 LINQ 쿼리식의 대상이 된다. 이에 영향을 받아 JavaScript와 Java 언어에 영향을 주어 LINQ와 유사한 프레임워크가 등장하였지만, .NET 과 같이 언어적으로 통합이 되지 않았다. 마치 Method Chaining 패턴을 이용한 라이브러리로 분류된다.

이 밖에 정말 헤아릴 수 없을 정도의 많은 진보가 있었다. 개발 도구와 개발 언어, 그리고 .NET 플랫폼의 기술이 발전한다는 것은 분명 매우 좋은 일이겠지만 아마 이 시기부터 많은 .NET 개발자들이 Microsoft의 기술 발전을 따라가기 벅차했었다.

 


2010년에 이르러, Visual Studio 2010버전이 출시되었다. 너무 빠른 .NET 기술의 발전의 탓일까, 이 때는 언어와 .NET Framework보다는 Visual Studio라는 개발 툴에 가장 초점이 맞추어졌다. 그 중 핵심 키워드라고 할 수 있는 것 3가지는 "시각화", "디버깅", "프로세스" 일 것이다. (필자의 의견이므로 Microsoft가 추구했던 것과는 다를 수 있다.) 이 세 가지의 핵심 키워드는 시각화, 협업에 있어 코드의 이해를 좀 더 쉽게, 그리고 복잡한 데이터를 한 눈에 알 기 쉽게… 디버깅-디버깅 시 데이터의 수집이 혁신적으로 발전하였고, 물리적으로 분리된 티어(Tier)간에 데이터 수집… 프로세스, 애자일을 강조하고 애자일한 통합 프로세스를 개발 툴에 제공.

.NET Framework 4.0은 .NET Framework 2.0기반이 아닌 새로운 프레임워크로 구성되었고, 멀티코어 처리를 위해 강력한 병렬 처리 라이브러리(Parallel Libraries)가 있다. 또, 동적 언어 런타임(Dynamic Language Runtime)으로 정적 형식과 동적 형식의 경계를 허물었으며, 루비(Ruby), Lisp, JavaScript, 파이썬(Phython), PHP와 같은 동적 언어와 상호 운용이 가능하다. 예를 들자면, C# 언어로 파이썬 개체와 상호 연동이 가능하다는 것이다.

 

  

제품의 버전 / 특징

2002년

  • Visual Studio .NET 2002 / .NET Framework 1.0 
    첫 통합 개발 환경 
    발매 당초의 제품명은 ' Visual Studio .NET 
  • C# 1.0 / Visual Basic .NET (7.0) 
    C# 은 마이크로소프트의 새로운 객체 지향 언어 
    Visual Basic 도 객체지향 언어

2003년

  • Visual Studio .NET 2003 / .NET Framework 1.1 (5월) 
  • C# 1.1 / Visual Basic .NET (7.1) 
    모두 버전 업 
  • Windows Server 2003 
    .NET Framework 1.1 표준 탑재

2005년

  • Visual Studio 2005 / .NET Framework 2.0 (12월) 
    ClickOnce 배포 
    제네릭 클래스 도입 
    ASP.NET 2.0, ADO.NET 2.0, Windows Form 2.0 
    리팩토링 기능 / 코드 스니펫 
    무료 Express Edition (C#, VB, C++) 
  • C# 2.0 / Visual Basic 2005 (8.0) 
    제네릭 대응 
  • Visual Studio 2005 Team System 
  • SQL Server 2005 지원

2006년

  • .NET Framework 3.0 (11월) 
    코어 부분은 .NET Framework 2.0 그대로 
    WPF(Windows Presentation Foundation) 
    WCF(Windows Communication Foundation) 
    WF(Windows Workflow Foundation) 
    CardSpace 
  • Windows Vista 
    .NET Framework 3.0 기본 탑재

2007년

  • Visual Studio 2005 Service Pack 1 (6월) 
  • ASP.NET AJAX 1.0 (추가 모듈) 
    AJAX Web Application 개발이 용이 
  • Expression Blend 
    Expression Studio 첫 제품 
    WPF 어플케이션의 GUI 구축
  • Visual Studio 2008 / .NET Framework 3.5 (11월 경) 
    개발 코드명 'Orcas' 
    WPF 의 GUI 설계 가능 
    Javascript 디버그 기능 및 IntelliSense 
    ASP.NET AJAX 표준 탑재 
    .NET Framework 2.0, 3.0, 3.5 선택 가능 
  • C# 3.0 / Visual Basic 2008 (9.0) 
    LINQ 기능 
  • SQL Server 2008 
  • Windows Server 2008 
  • Visual Studio Team System 2008

2008년

  • Visual Studio 2008 SP1 / .NET Framework SP1 
    ASP.NET Dynamic Data 
    ADO.NET Entity Framework / Data Services (Astoria) 
    WCF Atom Pub Services 
    클라이언트 프로파일(Client Profile) 
  • VSTS 
    Windows Server 2008 지원 
    SQL Server 2008 지원 
    성능 향상 및 개선 
  • Visual Studio SDK 1.1 (SP1) 
    Visual Studio Shell 재배포 패키지 경량화 
    DSL 출력 미리보기 등… 
  • Visual C++ 2008 
    오피스 리본 스타일 Interface 
    고급 GUI 컨트롤 등…

2010년

  • 사용자 친화적인 Visual Studio IDE
  • 코드 탐색 강화
  • 개발 툴에서 다양한 .NET Framework 개발 환경 제공
  • JavaScript 언어 개발 환경 강화
  • 다양한 플랫폼 지원
    • 64 Bit Mixed-Mode 디버깅
    • Managed 와 Mixed-Mode 의 Minidump 디버깅
  • Historical Debugger
    • 디버그 내용을 기록, 재생
  • 프로젝트 관리 및 프로세스 통합

 

 

Visual Studio 2012와 함께 매트로 앱 개발

Visual Studio 2012의 가장 큰 핵심은 바로 Windows 8 운영체제이다. Windows 8은 매트로 응용프로그램이라는 새로운 환경과 WinRT(Windows Runtime)인 새로운 런타임을 제공한다 그리고 Visual Studio 2012는 Windows 8 운영체제에 가장 최적화된 개발 툴이다. 독자들은 또 새로운 것을 배워야 하나라고 한숨을 쉴 수도 있을 것이다. 하지만 섣부른 독자들의 판단은 잠시 후에 하기 바란다. 왜냐하면 Windows 8 개발은 새로운 환경이면서도 새로운 환경이 아닐 수도 있다. Windows 8 운영체제를 사용하고 WinRT APIs 집합을 사용하는 것 이외에는 아무것도 변한 것이 없기 때문이다. 단지 바뀐 것은 여기에서 개발된 응용 프로그램은 데스크탑 컴퓨터, 테블릿, 모바일 환경 모두 실행되고 배포할 수 있다는 것이다.

최근 개발 환경을 엿보자면 C++을 사용하는 네이티브 개발과, NET에서 지원하는 C#과 같은 관리 언어, 그리고 웹 개발에 필요한 HTML과 JavaScript, 이 중에 단 한가지 기술 영역만 있으면 Windows 8 매트로 응용 프로그램 개발 준비는 끝이라는 것이다. 우리가 흔히 사용하는 스마트 폰을 보면 알 수 있듯이, 개발자는 단지 '위치 정보', '화면의 표현 방법', '데이터 연동', 그리고 스마트 폰을 가로로 볼 때와 세로로 볼 때와 같은 일상적인 기능을 제공하는 APIs를 익히기만 하면 된다. 기존에 Visual Studio를 사용하여 개발해 본 독자라면 그 만큼 진입 장벽이 낮다.

윈도우 폰7 개발처럼 테블릿 시뮬레이터가 제공이 된다. Windows 8 테블릿이 지원하는 대부분의 모든 기능을 이 시뮬레이터에서 테스트를 해 볼 수 있다. 윈도우 폰7 개발처럼 반드시 시뮬레이터가 필요한 것은 아니다. 실제 시뮬레이션이 필요 없다면 곧바로 로컬 데스크 탑에서 매트로 앱을 실행해 볼 수 있다.

Figure 1 Visual Studio 2012 매트로 앱 실행 및 디버깅

 

Figure 2 시뮬레이터 실행 환경

 

더불어 Visual Studio에서 제공하던 성능 측정 도구와 코드 정적 검사를 매트로 앱 개발 환경에서도 그대로 이용할 수 있다. 이는 곧 Visual Studio 2012이 Windows 8 개발에 가장 최적화가 되었다는 의미가 된다.

 

Figure 3 매트로 앱 성능 측정 및 진단

 

간략하게 나마 Visual Studio 2012과 Windows 8 개발에 대해 살펴보았다. 필자가 얘기한 것처럼 개발자에게 있어 새로운 환경이지만, 반대로 전혀 새롭지 않기도 하다. Visual Studio로 간단한 앱을 만들 수 있는 실력이라면 곧바로 Windows 8 매트로 앱을 개발할 수 있을 정도로 진입 장벽이 낮다. 물론, 좀 더 기술적이거나 독창적이고 예쁜 앱을 만드는 것은 더 많은 노력이 필요하다. 단지, 앱 개발자는 자신만의 앱 개발에만 집중하면 된다.

 

Figure 4 Windows 8 개발에서 배포까지

 

Visual Studio 2012과 함께 매트로 환경의 게임 개발

데스크 탑과 테블릿, 그리고 모바일 앱 중에서 단연 게임이 빠질 수 없다. 매트로 환경에서 게임 개발은 아직 시장이 포화되지 않은 장르이다. 그 만큼 게임 개발자에게 있어 매트로 환경에서 게임 개발은 매우 유혹적이기도 하다. 더 반가운 소식은 매트로 게임 개발에 필요한 지식은 게임 개발자에게 익숙한 C++언어와 DirectX다. DirectX를 이용하여 2D, 3D 게임을 개발할 수 있다.

얼마 전까지만 해도 Microsoft가 전략적으로 게임 개발을 지원하던 프레임워크인 XNA를 매트로 게임 개발에 지원하지 않는다. 대신 기존 게임 개발자에게 기존 개발 환경을 그대로 이어갈 수 있는 DirectX를 선택한 것이다.

Figure 5 DirectX 3D 샘플

Figure 6 DirectX 2D 샘플

 

 

Posted by 땡초 POWERUMC

댓글을 달아 주세요

Metro Style App 성능 및 품질 관리

Visual Studio 2005부터 최상위 버전에서 제공하는 기능 중에 하나가 바로 Profile 기능입니다. Visual Studio Profile 기능은 Performance, Memory, Thread 와 같이 눈으로 보거나 사람이 오감을 이용하여 측정할 수 없는 부분을 정교하게 측정할 수 있습니다. Metro Style App 도 이런 Performance 를 측정하고 Code Analysis 로 코드의 품질을 관리할 수 있게 되었네요.

   

Metro Style App을 Profile하기 위해서는 디버깅 상태를 Local Machine으로 변경을 해야 합니다. 그리고 Analyze 메뉴에서 Launch Performance Wizard 를 선택하여 단계별로 원하는 Profile 단계를 선택하면 됩니다. Visual Studio를 이용하여 .NET 응용 프로그램 Profile을 해보신 분이라면 편하신 대로 Profile Windows에서 시작하셔도 됩니다.

   

Metro Style App의 어떤 Performance를 측정할지 정하였다면 아래의 Profile 방법을 하나 선택하시면 됩니다. 다만, Metro Style App 의 Profile 을 몇 가지 제한이 있네요.

CPU Sampling 의 경우 C#, C++, JavaScript Metro Style App 모두 Profile이 가능합니다. 다만, Instrumentation의 계측 형태의 Profile은 JavaScript Metro Style App만 지원을 합니다. 물론 .NET 응용 프로그램인 경우 모든 Profile을 모두 지원해 줍니다.

   

CPU Sampling 을 할 Metro Style App을 선택하고, 쭉 쭉 다음 단계로 이동하면 바로 Profile 을 시작할 수 있습니다. CPU Sampling 을 하려는 응용 프로그램의 모든 기능을 동작시키면 됩니다. 만들어 놓은 기능을 선택도 해보고, 쿡쿡 클릭도 해보고 하신 후, Stop Profile을 클릭하여 성능 측정을 마무리 합니다.

   

그럼, Profile 보고서가 완성이 되면 CPU Sampling 결과를 보여줍니다. 아래와 같은 보고서는 의외로 성능 지표를 분석할 때 중요한 정보를 줍니다. 아래의 Inclusive, Exclusive 등 성능 지표 결과를 보시기 어려우시다면, 꼭 Visual Studio 2010 의 성능 프로파일 MSDN 문서를 확인해보세요.

꾸준히 성능 관리를 하여 샘플링을 떠 놓으면 나중에 얼마나 성능이 좋아지고, CPU 리소스를 덜 차지하는지 비교도 해보고 하시면 Visual Studio 의 막강한 기능에 대해 다시 한번 놀라실 겁니다.

   

Visual Studio Profile 에 대한 자세한 내용은 다음의 링크를 참고 하십시오.

http://msdn.microsoft.com/ko-kr/library/z9z62c29.aspx

   

   

Metro Style App의 Profile이 완료가 되면, 아래의 그림과 같이 성능 보고서를 보여줍니다. 상단의 영역은 CPU Sampling 결과를 그래프로 보여주며, 하단은 구간별로 CPU에 가장 많이 부하를 주는 구간을 리스트업 합니다.

   

CPU Sampling 결과를 다차원으로 분석하기 위해 Current View 영역에서 항목을 선택하시면 됩니다. 프로세스별로 분석하거나 모듈, 클래스, 메서드 등의 단위로 세밀하게 분석할 수 있는 지표를 제공해 줍니다.

   

덧붙여 Metro Style App의 Profile 기능은 Visual Studio가 설치된 환경 뿐만 아니라, Visual Studio 가 설치되지 않은 환경에서도 Profile 기능을 제공 합니다. 다음의 문서에서 자세한 내용을 확인해보세요.

http://msdn.microsoft.com/en-us/library/hh696636(v=vs.110).aspx

   

   

Metro Style App 의 코드 분석

Visual Studio의 Code Analysis를 효과적으로 사용하신 분이라면 좋아할 듯 합니다. Metro Style App에서도 Code Analysis기능을 그대로 적용할 수 있습니다. 개발 초기부터 Globalization, Performance를 염두 해두신다면 Code Analysis가 큰 도움이 될 겁니다.

   

Code Analysis에 대한 자세한 내용은 다음의 링크에서 확인하십시오.

[Better Code]Visual Studio 2010 Code Analysis Enhancements - 1.개요 http://vsts2010.net/39

[Better Code]Visual Studio 2010 Code Analysis Enhancements - 2. Rule Sets Feature http://vsts2010.net/41

   

Posted by 땡초 POWERUMC

댓글을 달아 주세요

Metro Style App 디버깅

C#이나 C++, VB.NET 으로 한번쯤 디버깅을 해본 분이라면 Metro Style App 디버깅도 같은 방식으로 디버깅이 가능합니다. 기존의 .NET 응용 프로그램 디버깅 방식과 별 차이가 없기 때문에, 디버깅 경험 그대로 사용하셔도 됩니다.

   

   

Simulator 로 디버깅

Visual Studio 11에서는 WinRT 디버깅 환경은 일반적으로 Local Machine 디버깅과 Simulator 디버깅, Remote Machine 디버깅이 있습니다. 그 중 Simulator 디버깅 부분의 디버깅 환경이 굉장히 잘 되어있네요. 마치 ARM 코어가 탑재된 테블릿을 조작하는 느낌까지 듭니다. Simulator 디버깅은 시스템이 부팅된 후 Windows 8 구동에서 사용자 로그인까지 그대로 재현이 됩니다.

아래의 그림과 같이 디버깅 툴바 영역에서 Simulator 디버깅을 선택하고 디버깅을 시작하면 Simulator 가 구동이 됩니다.

Simulator 디버깅에 대해 더 자세한 내용은 다음의 링크를 참고하십시오.
http://msdn.microsoft.com/en-us/library/hh441475(v=vs.110).aspx

   

   

Simulator를 선택한 후 디버깅을 시작하면 아래의 그림과 같이 테블릿을 연상케 하는 Simulator 창이 뜹니다. 필자의 집 네트워크 환경은 Active Directory로 묶여 도메인으로 관리를 하고 있는데, Simulator의 사용자 로그인도 마찬가지로 도메인 로그인 되는 것을 확인할 수 있습니다.


Simulator를 통해 WinRT 샘플이 잘 동작하는 것이 확인되는군요.

   

혹시나 싶어 Simulator 디버깅 중에 Metro 바탕 화면에서 데스크탑 바탕화면으로 이동해 보았습니다. 제 로컬 컴퓨터 환경이 그대로 재현이 되네요.

Simulator 우측 패널에 터치 방식을 선택하거나 해상도를 조절하거나 테블릿을 회전시키는 조작을 하는 아이콘들이 있습니다.

   


Metro Style App 배포

Metro Style App 템플릿을 사용하여 프로젝트를 생성하면 모든 형태의 Metro 응용 프로그램의 프로젝트에는 Package.appmanafest 파일이 존재합니다. 이 파일은 Windows Store 에 앱을 배포할 때 앱 정보를 가지고 있는 파일입니다.

자세한 Metro Style App 의 배포에 대한 내용은 다음의 링크를 참고하십시오.
http://msdn.microsoft.com/en-us/library/hh454036(v=vs.110).aspx  

   

   

Metro Style App 프로젝트의 속성 페이지로 이동하면 아래의 그림과 같이 속성 페이지로 이동합니다. 이곳에서 앱의 이름과 Rotaions 타입, 전경색과 배경색 및 Splash 이미지, 그리고 앱의 호환 정보, 장치 정보를 설정하면 됩니다.

   

Posted by 땡초 POWERUMC

댓글을 달아 주세요

지난 2012년 02월 29일, Windows 8 Consumer Preview 와 Visual Studio 11 Beta 버전이 공개가 되었습니다. 그 중 Windows 8 의 가장 큰 특징이라고 하면 WinRT(Windows Runtime)을 이용하여 Metro 응용 프로그램을 만들 수 있는 것이죠. 이전 Windows 7까지 Win32 API 를 이용하여 데스크탑 응용 프로그램을 만들었습니다만, Windows 8 에 와서는 이전 Win32 환경과 새로운 WinRT 환경에서 개발을 할 수 있습니다.

   

더 자세한 정보를 원하시면 다음의 MSDN 링크를 통해 확인하시기 바랍니다.

http://msdn.microsoft.com/en-us/library/bb386063(v=vs.110).aspx

   

쉽게 WinRT는 Metro Style App를 구동하기 위한 API 집합들이며, Win32의 Function APIs 가 아닌, 좀 더 세련되고 객체지향적으로 다듬은 차세대 윈도우 런타임이라고 생각하셔도 됩니다.

   

   

Visual Studio 11 은 Windows 8 의 Metro Style App 을 개발하기 위해 개발 템플릿을 지원해 줍니다. (프로젝트 템플릿 같은 그런 것들이죠). 그럼 Visual Studio 11 에서 제공하는 Metro Style App 의 템플릿은 어떤 것을 지원하는지 한번 볼까요?

   

분할 응용 프로그램

분할 응용 프로그램 템플릿은 사용자 지정하여 2열 보기에서 항목과 항목 세부 정보로 된 목록을 보기 위한 앱을 만들 수 있는 Metro 스타일 앱의 주요 기반이 됩니다. 이 보기에서 사용자는 항목 간에 빠르게 전환할 수 있으며 목록을 동적으로 업데이트할 수도 있습니다. 예를 들어 뉴스 읽기 프로그램, 스포츠 득점 앱, 전자 메일 앱 등이 있습니다. 이 프로젝트 템플릿은 Metro 스타일 앱에 권장되는 탐색 모델을 사용합니다.

표 형태 응용 프로그램

표 형태 응용 프로그램 템플릿을 사용하여 Metro 스타일 앱을 만드는 것이 좋습니다. 이 템플릿을 사용자 지정하여 사용자가 범주 검색을 통해 완전히 빠져드는 콘텐츠를 찾는 앱을 만들 수 있습니다. 예를 들면 쇼핑 앱, 뉴스 앱, 사진 또는 동영상 앱이 있습니다. 이 프로젝트 템플릿은 Metro 스타일 앱에 권장되는 탐색 모델을 사용합니다.

탐색 응용 프로그램

이 JavaScript 템플릿에는 기본 탐색, 앱 바탕 화면 도구 모음(앱 바) 및 표 형태 응용 프로그램과 분할 응용 프로그램 템플릿에서 사용되는 미디어 모드 기반 레이아웃이 제공됩니다. 탐색 템플릿에는 최소 페이지 조각 하나만 포함되어 있으며, 페이지 조각을 손쉽게 추가할 수 있습니다. 그런 다음 콘텐츠를 추가할 수 있습니다. 이 프로젝트 템플릿은 Metro 스타일 앱에 권장되는 탐색 모델을 사용합니다.

고정 레이아웃 응용 프로그램

이 JavaScript 템플릿은 콘텐츠가 고정 뷰포트에 맞게 되어 있다는 점을 제외하고 빈 응용 프로그램 템플릿과 동일한 최소한의 Metro 스타일 앱을 제공합니다. JavaScript에서 개발하는 대부분의 게임 앱에 이 프로젝트 템플릿을 권장합니다

DirectX 응용 프로그램

이 C++ 템플릿은 Metro 스타일 게임 개발에 사용할 수 있습니다.

   

Visual Studio 11 C# 언어에서 제공하는 Metro Style App 템플릿

   

Visual Studio 11 JavaScript 언어로 제공되는 Metro Style App 템플릿

특이하게도 JavaScript 언어로 제공되는 템플릿에만 고정 레이아웃(Fixed Layout) 템플릿을 지원하는군요.

   

Visual Studio 11 C++ 언어에서 제공하는 Metro Style App 템플릿

   

   

템플릿 샘플

각각 템플릿이 어떻게 구성되었는지 보기로 한 참에, 각 언어별로 제공되는 템플릿을 생성하여 Windows 8 에서 실행해 보았습니다.

   

JavaScript 템플릿으로 만든 Metro Style App Sample

   

   

C# 템플릿으로 만든 Metro Style App Sample

   

   

C++ 템플릿으로 만든 Metro Style App Sample

   

Posted by 땡초 POWERUMC

댓글을 달아 주세요