마이크로소프트의 말에 따르면 Windows 8 릴리즈 프리뷰 용 앱 개발 시스템을 만들면서 기존 컨슈머 프리뷰용 앱을 정리하고 개선하는 방향으로 작업했기 때문에 기존 컨슈머 프리뷰용 앱을 어렵지 않게 릴리즈 프리뷰 용으로 포팅할 수 있을 거라고 합니다.

 

아래 링크에서 컨슈머 프리뷰용 앱을 릴리즈 프리뷰 버전으로 마이그레이션하는 방법에 대한 문서가 제공됩니다.

http://go.microsoft.com/fwlink/?LinkID=251943

 

 

그런데… 이 문서대로만 해서 바로 된다면 세상 참 편하겠죠? ^^;

실제 작업해보니 문서화되지 않은 세세한 변경 사항들이 꽤 되더군요.

 

그래서, 이번 글에서는 Windows 8 컨슈머 프리뷰 용으로 개발된 .NET 메트로 스타일 앱을 Windows 8 릴리즈 프리뷰에서 작동되도록 마이그레이션하는 방법에 대해서 이야기해볼까 합니다.

 

이 글은 남들보다 먼저 앱을 개발하신 분들에게도 도움이 되겠지만 아직 한 번도 만들어보지 않은 분들에게도 .NET 메트로 스타일 앱의 템플릿의 상세 기능을 살펴보는데에도 도움이 될 수도 있습니다.^^

 

 

 

 

일단 대상이 될 앱이 있어야 한데…. 컨슈머 프리뷰 시절 그나마 가장 설명이 자세했던 Windows Blog RSS Reader 앱을 릴리즈 프리뷰에 맞게 고쳐보도록 합시다.

http://msdn.microsoft.com/ko-kr/library/windows/apps/br211380.aspx

 

여기서 잠깐

이 글을 쓰는 시점에서 영문 문서는 릴리즈 프리뷰로 업데이트되었는데 한글 문서는 아직 컨슈머 프리뷰 버전으로 되어 있으니 이점 참고하세요.


 

 

 

자 시작해봅시다.

 

일단, 마이그레이션하기에 앞서서 테스트 삼아서 Visual Studio 2012 RC로 새 프로젝트를 만들어보면 Visual Studio 11 베타와 기본 골격은 크게 다르지 않음을 확인하실 수 있습니다. 예전처럼 Assets 폴더와 Common 폴더가 있으며 프로젝트 루트에 XAML 페이지와 CS 파일들이 위치합니다. 그리고, 프로젝트 파일과 솔루션 파일도 동일하기 때문에 Visual Studio 11 베타로 만들었던 프로젝트를 Visual Studio 2012 RC로 열어도 잘 열립니다. (물론 잘 열리기만 합니다^^;)

 

image_2.png

 

 

 

여기서 잠깐

지난 포스팅의 Visual Studio 2012 RC 스크린샷과 뭔가 다른 점을 찾으셨다면 당신은 눈썰미가 매우 좋으신 겁니다^^ 기본적으로 상단 메뉴가 전부 대문자로 나오던 것이 이전처럼 소문자로 바꿔버렸습니다.

혹시 여러분도 이렇게 바꾸고 싶으시면 아래 링크에서 레지스트리 파일을 받아서 병합하시면 됩니다.

http://blog.xyzzer.me/2012/06/01/visual-studio-2012-all-caps-vs-old-style/


 

 

보통 이렇게 새 버전이 나온 경우 새 버전으로 프로젝트를 다시 생성한 후 우리가 만든 코드를 집어넣는 편이 수고를 줄여주는데 이 글에서는 여러 가지로 공부할 거리가 있게 하기 위해 기존 프로젝트 파일을 바로 열어서 마이그레이션 하도록 하겠습니다. 사실, 프로젝트 다시 구성하는 것도 좀 귀찮기도 하죠^^;

 

 

일단 기존 프로젝트를 열어서 컴파일을 해보면…. 에러가 나서 컴파일이 안되는군요. 당연하게도 말이죠…

 

image_4.png

 

 

 

 

사실, Visual Studio 2012 RC로 넘어오면서 템플릿이 꽤 바뀌었습니다. 그런데 이 글의 맨 처음에 있는 마이그레이션 가이드 문서에는 그런 내용이 거의 없지요.

 

어떻게 바뀌었는지 비교를 해보기 위해서 같은 이름으로 새 프로젝트를 만들어봅시다.

그러면, 다음과 같이 Common 폴더가 달라졌음을 보실 수 있습니다.

 

Visual Studio 11 Beta                                                          Visual Studio 2012 RC

image_8.png  image_6.png

 

 

위 그림에서 보시는 대로 SuspensionManager.cs 라는 파일이 추가되었습니다. SuspensionManager는 기기가 절전 모드로 들어갔을 때를 처리해주는 클래스입니다.

 

Visual Studio 2012 RC에서 바뀐 템플릿으로 업데이트를 해주는 편이 미래를 위해서 좋겠죠?

 

 

Diff 도구로 변경 사항을 살펴보면 새로 만든 테스트 프로젝트에서 LayoutAwarePage.cs, StandardStyles.xaml, SuspensionManager.cs 파일만 달라졌음을 확인하실 수 있습니다. 따라서 이 3개의 파일을 기존 프로젝트로 복사해주고 프로젝트에 Include 해주세요. 이때, 각 파일을 열어서 맨 윗부분의 네임스페이스를 기존 프로젝트에 맞게 고쳐주셔야 합니다. 만약, 테스트용 프로젝트를 생성하셨을 때 기존 프로젝트와 같은 이름으로 만드셨다면 이 과정은 필요없겠죠.

 

 

 

그런 후 컴파일을 해보면 다음과 같이 UseFilledStateForNarrowWindow 속성을 찾을 수 없다고 알려줍니다. 과감하게 이 속성을 삭제합니다.  사실, SuspensionManager.cs만 추가된 것이 아니라 LayoutAwarePage.cs도 상당히 바뀌었거든요.

 

image_10.png

 

 

 

 

오~ 이 속성만 XAML에서 지워버리니 컴파일이 되네요~

우와~ 다 되었나보다~ 하는 마음에 실행을 해보지만…………. 화면에 피드 목록이 나오지를 않네요-.-;

 

image_12.png

 

 

 

 

컨슈머 프리뷰 버전에서 잘 돌아가던건데 왜 그럴까요?

바로 LayoutAwarePageDefaultViewModel의 처리 방식이 달라졌기 때문입니다.

 

ItemsPage.xaml.cs 를 보시면 다음과 같이 DefaultViewMode이라는 속성을 이용하고 있습니다.

 

this.DefaultViewModel["Items"] = _feedDataSource.Feeds;

 

 

 

Visual Studio 2012 RC에서는 LayoutAwarePage의 DefaultViewModel의 처리 방식이 달라져서 XAML에서 명시적으로 DataContext를 지정해줘야 작동합니다.

 

각 XAML 파일을 열고 맨 윗 부분에 다음과 같이 두 줄을 넣어줍니다. (두번 째 줄은 생략 가능합니다.)

DataContext="{Binding DefaultViewModel, RelativeSource={RelativeSource Self}}"

IsTabStop="false"

image_14.png

 

 

 

사실,  Visual Studio 11 베타에서는 LayoutAwarePage의 DefaultViewModel 사용법이 좀 이상했습니다. XAML에서 데이터바인딩을 사용하려면 어디엔가는 DataContext를 지정해줘야 하는데 그런게 안보였거든요. 그러던 것이 Visual Studio 2012 RC 템플릿에서는 좀더 XAML답게 템플릿이 바뀐 것이죠.

 

 

 

 

이제 앱을 다시 실행해보면 처리되지 않은 오류가 발생했다고 하면서 앱이 죽어버립니다^^;

상세 오류 내용은 다음과 같습니다.

Message = "Cannot find a Resource with the Name/Key ListViewItemOverlayBackgroundBrush [Line: 66 Position: 36]"

 

ItemsPage.xaml을 연 다음 Error 목록을

보니 다음과 같이 되어 있네요.

 

image_16.png

 

 

 

이 에러의 원흉은 StandardStyles.xaml입니다. Visual Studio 2012 RC로 넘어오면서 기본 컨트롤들의 모양과 구성이 상당히 바뀌었습니다. 그래서 기존 컨트롤의 디자인을 바꾸기 위해 ControlTemplate을 재정의한 경우에는 이처럼 리소스를 찾을 수 없다는 오류가 무진장 많이 뜹니다.

 

StandardStyles.xaml을 열어서 직접 살펴보거나 또는 새로 만든 프로젝트를 Blend로 열어서 기존 컨트롤의 ControlTemplate을 샘플로 하나 만들어보면  ListViewItemOverlayBackgroundBrushListViewItemOverlayBackgroundThemeBrush 로 바뀌었음을 아실 수 있습니다. 이처럼 주로 Brush 이름에 Theme가 추가된 경우가 대부분이니 열심히 노가다하셔서 잘 바꿔주시면 됩니다.^^;

 

참고로 디자인을 많이 뜯어고치셨을 수록 노가다의 고통이 심해집니다. 제가 만든 앱은 디자인을 상당히 바꿨기 때문에 이 작업에 시간이 좀 걸렸네요.

 

 

 

다시 실행해보면 다음과 같이 잘 뜹니다.

image_18.png

 

 

 

 

그런데, 이번에는 항목을 클릭하자마자 바로 에러가 나네요.

다음과 같이 LayoutAwarePage.cs에서 에러가 나는군요.

 

image_20.png

 

 

 

 

이 에러의 원흉은 LayoutAwarePage에서 페이지 네비게이션 처리 방식이 바뀌었기 때문입니다.

 

Visual Studio 11 베타에서는 다음과 같이 페이지가 네이게이션 될 때 OnNavigatedTo 메서드에서 처리했었는데

 

protected override async void OnNavigatedTo(NavigationEventArgs e)

 

 

Visual Studio 2012 RC의 템플릿에서는 _pageKey에 “Page-1” 과 같은 형식으로 각 페이지마다 내부적으로 키값을 만들어서 사용합니다. 그리고 템플릿으로 생성된 XAML 페이지를 열어보면 OnNavigatedTo 메서드 대신 LoadState 메서드로 처리하고 있음을 보실 수가 있죠.

protected override async void LoadState(Object navigationParameter, Dictionary<String, Object> pageState)

 

 

그리고, SaveState라는 메서드도 생겼습니다.

바로 LoadStateSaveState 메서드를 통해 페이지 네비게이션도 처리하고 절전 모드를 위한 상태 저장/복원 기능도 구현합니다.

 

 

따라서, 이 에러는 OnNavigatedTo 메서드를 LoadState로 바꾸면 해결이 됩니다. 물론 그에 맞게 이벤트 핸들러 파라미터 처리도 바꿔줘야겠죠.

 

예를 들면… SplitPage.xaml.cs는 다음과 같이 수정하면 됩니다.

//protected override void OnNavigatedTo(NavigationEventArgs e) - 기존 코드

protected override void LoadState(Object navigationParameter, Dictionary<String, Object> pageState)

{

     //FeedData feedData = e.Parameter as FeedData; - 기존 코드

     FeedData feedData = navigationParameter as FeedData;

 

모든 XAML 페이지를 다 수정해주고 실행해보면…

짜잔! 잘 돌아갑니다~

 

image_22.png

 

 

스냅뷰 상태는 수정하지 않아도 잘 돌아가는군요.

image_24.png

 

 

 

 

생각보다 몇 군데 수정하지 않았는데 Windows 8 릴리즈 프리뷰에서 작동하도록 잘 마이그레이션되었네요.

 

 

 

마지막으로, 스토어에 올리거나 다른 사람에게 배포하기 위해 App Package를 만들어봅니다.

그러면, 다음과 같이 또 에러 메시지가 뜰 겁니다.

 

image_26.png

 

 

 

 

 

이 에러는 현재 프로젝트 파일에 있는 인증용 임시 pfx 파일 (WindowsBlogReader_TemporaryKey.pfx)이 컨슈머 프리뷰에서 만들어져서 그런 겁니다. 같은 이름으로 프로젝트 파일을 만든 후 pfx 파일을 기존 프로젝트에 덮어쓰면 App Package가 잘 생성이 됩니다.

 

image_28.png

 

 

 

 

 

 

이렇게 해서 간단한 Windows 8 컨슈머 프리뷰용 RSS 리더 앱을 Windows 8 릴리즈 프리뷰로 마이그레이션 해봤습니다.

위 내용만 봐서는 몇 군데 수정안하고 금새 된 것 같죠? 하지만 그건 이 앱이 간단하기 때문입니다. 현실적인 앱에서는 아마 이보다 훨씬 복잡할 겁니다. 하지만 이 글에서 적은 것들과 마이크로소프트의 마이그레이션 가이드를 참고하시면 적어도 새로 만드는 것보다는 훨씬 빨리 마이그레이션 하실 수 있을 겁니다^^

 

사실, 이 외에도 몇 가지 더 발견한 이슈들이 있긴 합니다.

다음은 제가 발견한 마이그레션 이슈들 중 몇 가지 입니다.

 

  • 세컨더리 타일을 사용하실 때 컨슈머 프리뷰에서는 다음과 같이 로고 URL을 지정하는데 이 소스를 그대로 돌리면 Argument가 잘못되었다고 에러 메시지가 뜹니다.

var logo = new Uri("ms-resource:Assets/2ndlogo.png");

 

이 경우 다음과 같이 URL의 형식을 바꿔주면 문제가 해결됩니다. 이런 내용은 마이그레이션 문서에 안나오더군요^^;

Uri logo = new Uri("ms-appx:///Assets/2ndlogo.png");

 

 

  • Frame.GetNavigationState() 메서드를 이용하면 네이게이션 히스토리를 가져올 수 있는데, Visual Studio 2012 RC에서 Frame.Navigte 메서드를 호출할 때 기본 타입이 아닌 객체 타입을 인수로 넘겨주면 Frame.GetNavigationState() 메서드에서 Serializaion 에러가 납니다. 이 문제는 Visual Studio 2012 RC에서 네이게이션 처리 방식이 달라져서 생긴 문제인데 개발자 입장에서 본다면 버그라고 볼 수도 있죠. 무엇보다도 우리가 직접 네비게이션 히스토리 기능을 만들지 않는 이상 Frame.GetNavigationState()가 유일하게 히스토리를 가져올 수 있는 메서드라는 점에서 더욱 문제가 됩니다.

 

 

 

마지막으로, 이 글이 이전에 개발하셨던 앱을 Windows 8 릴리즈 프리뷰 용으로 마이그레이션하는데 도움이 되었으면 하며 컨슈머 프리뷰 버전과 릴리즈 프리뷰 버전의 소스 코드를 첨부합니다.

 

 





profile