ReverseStoryboardTest.zip

// 타겟 스토리보드를 가지고 새 인스턴스 생성
private ReverseStoryboard rs = new ReverseStoryboard(TargetStoryboard);
rs.BeginForward();  // 정방향으로 재생
// 또는...
rs.BeginReverse();  // 역방향으로 재생

실버라이트 애플리케이션을 배포하는 것에서 가장 중요한 원칙은 뭘까요? 밑줄 긋고 외웁시다.

배포 사이즈를 작게 더 작게!

우리는 XAP 파일이 표준 ZIP 압축 알고리즘을 쓰고 있다는 점을 알고 있죠. 그런데 Delay’s Blog의 포스팅에 의하면 실버라이트 2의 XAP 파일은 압축률이 일반적으로 사용되는 것보다 낮다고 해요. 7-Zip의 압축률을 기준으로 1~3 단계 정도면 용량도 더 줄어들면서 압축 시간은 거의 차이가 없는데 여튼 여기에 착안해서 XAP의 압축률을 변경하여 압축하는 것만으로도 약 20~22% 정도의 용량이 줄어드는 마법(!)같은 효과를 얻을 수 있다는 군요.

저도 예전에 실버라이트 1때에는 7-zip command line 툴을 이용해서 비스무레한 일을 했던 적이 있는데 아무래도 2에서는 XAP을 자동으로 만들어줘서 그러려니 했었죠.

여튼 WEB-SNIPPETS 블로그에서는 이 작업을 좀 더 쉽게 해주는 유틸리티를 공개했는데요, 간단하게 옮겨 보죠.

1. ReXapper를 다운로드
2. 받은 파일의 압축을 풀어 임의의 장소에 복사(예 : D:\Utils\ReXapper\ReXapper.exe)
3. 실버라이트 프로젝트의 Properties(속성)을 열어 Build Event탭의 Post-build event command line 박스를 찾아가서
4. 다음의 코드를 붙여 넣기
   D:\Utils\ReXapper\ReXapper.exe –xap "$(TargetDir)$(TargetName).xap"

일단 저도 하나만 테스트를 해 봤지만, 348,854 bytes가 268,154 bytes로 약 20% 줄어드는 효과를 봤어요!

그러니…

오늘은 땡스빌을 외치며 시작하죠. 그리고 코드 플렉스에도 감사를.

개발자를 지긋지긋하게 괴롭히는 것 중 하나는 문서 작업이죠. 어쩌겠습니까 뭐.

최근에 회사에서 라이브러리를 정리하면서 '위키로 라이브러리를 정리하자!'하고 막상 위키를 개설해 놨더니… 뭐 결과는 다 아시잖아요? 문서 만드는게 죽도록 귀찮은 일이라서…

이럴 시간에 한 줄이라도 더 쓰지 OTL…

음음.

그래서 한동안 잊고 있었던 샌드캐슬 프로젝트를 혹시나 하고 기웃거려 봤더니 코드플렉스로 죄다 이사를 갔더군요. 그리고 기대를 져버리지 않고 닷넷 3.5까지 잘 지원을 하고 있었어요. 앗싸~

여튼, 슬슬 이 글 쓰는 것도 귀찮아지고 있어서 아주 초간단하게 준비물과 해야 할 일을 주욱 늘어놓고 끝내도록 하죠.

준비물

[필수]

• Sandcastle 라이브러리 : http://www.codeplex.com/Sandcastle

[툴]

• 헬프 파일 작성 빌더 : http://www.codeplex.com/SHFB
• 헬프 파일 작성용 프로젝트 템플릿 및 빌드 툴 : http://www.codeplex.com/DocProject
• MS헬프 2.0 형식(.HxS 파일) 작성시 필수 : Visual Studio 2008 SDK 1.1
• MS헬프 2.0 형식(.HxS 파일) 등록 유틸리티 : http://www.codeplex.com/SandAssist

[옵션]

• 헬프 파일 스타일 : http://www.codeplex.com/SandcastleStyles

와우, 죄다 코드 플렉스로 이사갔네요. 요즘은 마이크로소프트랑 관계된 오픈 소스 프로젝트는 거의 대부분 코드 플렉스에 있는 것 같아요.

간단하게 설명하자면 Sandcastle은 일종의 라이브러리이고 Sandcastle을 사용하여 여러 가지 프로젝트들이 각기 다른 방법으로 문서화나 빌드를 하는 툴 혹은 프로젝트를 진행하고 있죠.

실제로 사용할 툴은 Sandcastle Help File Builder(SHFB) 또는 DocProject에서 진행하고 있는 건데요 서로 다른 특성을 가지고 있어요.

SHFB는 GUI 툴로 프로젝트 파일을 추가하고 연관된 어셈블리 들을 넣어주면 헬프 파일을 만들어주는데 단점은 의존성 있는 어셈블리를 일일이 추가해 줘야 한다는 것과 편집 옵션이 전체 헬프 파일 서머리와 네임스페이스 별 서머리만을 지원하고 나머지는 그냥 기본이라는 점. (이 외에 다른 방법이 있는 것 같은데 귀찮습니다. … ㅠ.ㅜ)

이에 반해 DocProject는 의존성 있는 어셈블리를 별도로 지정할 수 있어서 간편하고 좀 더 편리한 편집 툴도 제공해서 더 좋은 것 같아요. 하지만 C# 프로젝트 형식이라서 별도의 솔루션을 만드는 것이 좋고 해서 스탠드얼론 방식을 좋아하는 분에게는 별로겠죠.

여튼 선택은 자유…이지만 설명은 DocProject만 할께요.

헬프 파일 스타일은 헬프 파일의 디자인의 몇몇 템플릿인데요, MSDN말고도 다른 스타일로 할 수 있죠. 이건 뭐 말 그대로 옵션.

마지막으로 MS 헬프 2.0 형식의 파일(.HsX)는 CHM과는 다르게 곧바로 볼 수 없고 별도의 등록 과정을 거쳐야만 Document Explorer에서 볼 수 있죠. 근데 이게 또 만만치가 않아요. =_=;

설치 과정

사용 방법

DocProject를 기준으로, 기본적으로 릴리즈 노트에 잘 설명이 되어 있으니,

…라고 하고 싶습니다만, 실버라이트용 프로젝트에서는 약간 더 손대야 할 부분이 있어서 그 부분만 언급하고 넘어갈께요;; 길어서 접어둡니다.

더보기

Source 먼저 x:Name 어트리뷰트가 "Output"으로 설정된 TextBlock만을 가진 MyUserControl이라는 유저 컨트롤의 코드 비하인드에 다음의 코드를 입력하고 다른 유저 컨트롤(Page)에 MyUserControl을 추가 했어요.

using System;
using System.Windows.Controls;
using System.IO.IsolatedStorage;

namespace IsolatedStorageCrashInBlend
{
    public partial class MyUserControl : UserControl
    {
        public MyUserControl()
        {
            InitializeComponent();

            // 디자인 모드가 아닐 경우에만 처리
            // 설정을 읽어 Output에 출력
            if (IsolatedStorageSettings.ApplicationSettings.Contains("LastGuid"))
            {
                Output.Text = IsolatedStorageSettings.ApplicationSettings["LastGuid"].ToString();
            }
            else
            {   // 설정이 없으면 새 값을 저장
                IsolatedStorageSettings.ApplicationSettings["LastGuid"] = Guid.NewGuid().ToString();
            }
        }
    }
}

Incorrect IsolatedStorage와 관련된 코드를 포함하는 컨트롤 자체는 블렌드에서 디자인이 잘 보여요. 이유는 이 전에 포스팅 했고요.

Correct 그러나 IsolatedStorage와 관련된 코드를 포함하는 컨트롤을 다른 컨트롤의 XAML에서 추가했을 때 블렌드에서 디자인이 안보이면서 복장터지는 에러 메시지만 내뿜죠.

Solution 이 문제는 이 전 포스팅에서 얘기했듯이 DesignerProperties를 사용하여 피해갈 수 있어요.

using System;
using System.Windows.Controls;
using System.IO.IsolatedStorage;
using System.ComponentModel;

namespace IsolatedStorageCrashInBlend
{
    public partial class MyUserControl : UserControl
    {
        public MyUserControl()
        {
            InitializeComponent();

            // 디자인 모드일 때에는 임의의 값 출력
            if (DesignerProperties.GetIsInDesignMode(this) == true)
            {
                Output.Text = Guid.NewGuid().ToString();
            }
            else
            {
                // 디자인 모드가 아닐 경우에만 처리
                // 설정을 읽어 Output에 출력
                if (IsolatedStorageSettings.ApplicationSettings.Contains("LastGuid"))
                {
                    Output.Text = IsolatedStorageSettings.ApplicationSettings["LastGuid"].ToString();
                }
                else
                {   // 설정이 없으면 새 값을 저장
                    IsolatedStorageSettings.ApplicationSettings["LastGuid"] = Guid.NewGuid().ToString();
                }
            }
        }
    }
}

잘 나오죠? 하지만 위의 코드는 좋은 패턴이 아니에요. 약간만 리팩터링을 해보죠.

using System;
using System.Windows.Controls;
using System.IO.IsolatedStorage;
using System.ComponentModel;

namespace IsolatedStorageCrashInBlend
{
    public partial class MyUserControl : UserControl
    {
        public MyUserControl()
        {
            InitializeComponent();

            // 디자인 모드일 때에는 임의의 값 출력
            if (DesignerProperties.GetIsInDesignMode(this) == true)
            {
                Output.Text = Guid.NewGuid().ToString();
            }
            else
            {
                // 디자인 모드가 아닐 경우에만 처리
                InitializeApplicationData();
            }
        }

        private void InitializeApplicationData()
        {
            // 설정을 읽어 Output에 출력
            if (IsolatedStorageSettings.ApplicationSettings.Contains("LastGuid"))
            {
                Output.Text = IsolatedStorageSettings.ApplicationSettings["LastGuid"].ToString();
            }
            else
            {   // 설정이 없으면 새 값을 저장
                IsolatedStorageSettings.ApplicationSettings["LastGuid"] = Guid.NewGuid().ToString();
            }
        }
    }
}

네, 다른 모든 코드도 마찬가지지만 특히 IsolatedStorage와 관련된 코드는 별도의 코드 블럭으로 빼주는 것이 좋아요.
아니, 반드시 그렇게 해야 해요.
이 외에도 블렌드에서만 발생하는 문제가 가끔 있는데요, 그 문제가 코드와 연관된 것이라면 DesiginerProperties를 사용하여 회피할 수 있어요.

샘플을 첨부했으니 한 번 이렇게 저렇게 테스트 해 보세요.

IsolatedStorageCrashInBlend.zip

컴퍼넌트 및 컨트롤 개발자/디자이너에게 반드시 필요한 기능이죠. 보통 우리가 컨트롤을 디자인 할 때에는 특히, 데이터 바인딩을 사용하는 컨트롤의 경우에는 실제 데이터가 표시될 자리에는 아직 아무런 데이터가 들어가지 않았기 때문에 디자이너들이 그 곳에 임의의 값이 어떤 형태로 들어갈지 알 수 없다는 문제점이 있죠. 바로 이럴 때 System.ComponentModel.DesignerProperties 클래스를 유용하게 사용할 수 있어요.

우선 샘플 프로젝트부터 받아 보시죠.

DesignPropertiesSample.zip

먼저 간단하게 유저 컨트롤을 하나 만들어서 테스트 해 보죠. 컨트롤의 이름은 MyUserControl이라고 하고 크기는 100x100으로 아무것도 없는 컨트롤이에요. 그리고 코드 비하인드에 다음과 같이 간단한 코드를 넣어보죠.

public MyUserControl()
{
    InitializeComponent();
    TextBlock tb = new TextBlock();

    if (DesignerProperties.GetIsInDesignMode(this) == true)
    {
        // Design-time
        LayoutRoot.Background = new SolidColorBrush(Colors.Blue);
        tb.Text = "in Design";
    }
    else
    {
        // Run-time
        LayoutRoot.Background = new SolidColorBrush(Colors.Green);
        tb.Text = "in Runtime";
    }

    LayoutRoot.Children.Add(tb);
}

DesignerProperties.GetIsInDesignMode() 메서드는 주어진 UIElement가 현재 디자인 모드에서 렌더링 되고 있는지 여부를 반환해요. 해당 UIElement가 디자인 모드 즉, Blend에서 렌더링 되고 있다면 true를, 웹브라우저 등에서 렌더링 되고 있다면 false를 반환하는거죠.

위의 코드는 컨트롤이 인스턴스화 될 때 디자인 모드에서는 파란색으로 컨트롤을 채우고 "in Design"이란 문자열을 출력하고 런타임에서는 녹색으로 컨트롤을 채우고 "in Runtime"이란 문자열을 출력하도록 작성되었어요.

비주얼 스튜디오에서 MyUserControl을 볼까요?

아무것도 안나오죠? 이것은 비주얼 스튜디오의 XAML 뷰어(코드명 사이더)는 해당 UserControl을 새로 생성하는 것이 아니라 단지 XAML을 분석하여 보여준다는 것을 알 수 있죠.

블렌드의 경우도 마찬가지에요.

자, 다음으로 MyUserControl을 XAML에서 추가하여 사용하는 Page.xaml을 한번 볼까요?

비주얼 스튜디오의 XAML 뷰어에서는 디자인 모드가 아닌 런타임으로 판단하는군요. 이것은 아마도 버그내지는 잘못된 판단이 아닐까 싶어요. 아무리 사이더에서 실제로 디자인 하는게 불가능하더라도 엄연히 이 시점은 '디자인'상태니까요.

반면, 블렌드에서는 디자인 모드를 정상적으로 인식하는 것을 볼 수 있죠.

그렇다면 브라우저에서는? 당연히 런타임으로 나오겠죠?

DesignerProperties 클래스가 유용하게 쓰이는 경우는 앞에서 말했던 것처럼 동적으로 변경되는 값의 샘플 값을 디자이너에게 보여주고 싶을 때인데요 이 외에도 이 클래스를 반드시 써야 하는 경우도 있어요. 바로 몇몇 코드는 블렌드에서 처리할 수 없어서 에러를 발생시키는 원인이 되기도 해요.

이렇게 말이죠. 이게 당해보면 진짜 환장할 노릇이거든요. 왜냐면 유저 컨트롤 그 자체에서는 잘 보이는데 그 컨트롤을 사용한 다른 컨트롤의 디자인에서만 안보이니까요.

어떤 경우에 위와 같은 에러가 나오는지 완전히 정리되지는 않았지만 한가지 확실한 것은 IsolatedStorage가 사용되었을 때에요. IsolatedStorage를 쓸 때의 주의점과 해결 방법은 다음 포스팅에서 설명할께요.

한창 PDC2008에서 소식이 쏟아져 나오고 있는데요, 관심 있는 주제들은 많은데 둘러 볼 시간이 없네요. 저는 한창 프로젝트 막바지에 이르러서요… 그래도 실버라이트 관련해서 그냥 지나칠 수 없는 소식이 있어요.

전에 실버라이트 2를 공식으로 발표한 컨퍼런스 콜에서도 나왔던 얘기지만 코드 플렉스를 통해 실버라이트 툴킷이 공개되었어요.

이번에 공개된 툴 킷에는 12개의 컨트롤과 6개의 테마를 포함하고 있으며 모두다 유닛 테스트와 문서화가 완벽하게 이루어져 있어요. 여느 오픈 소스와는 질적으로 다른 게 바로 유닛 테스트와 문서화라고 생각해요.

 
MSDN 스타일의 표준화된 문서화야 말로 마이크로소프트 기술의 강점중 하나!

 
진짜 프로젝트를 이 정도로만 깔끔하게 만들면 하산해도 될거에요. 앞으로 실버라이트 컴포넌트를 만들 때의 교과서가 될 듯. 저도 이번 프로젝트 끝내고 빨리 공부해보고 싶군요.

실버라이트 툴킷 프로젝트에서는 컨트롤을 4개의 퀄러티 대역으로 구분하고 있네요.

• Experimental ; 실험적이고 평가를 위해 작성된 컨트롤.
• Preview ; 기본적인 사용 시나리오를 미리 보기 위한 퀄러티로 피드백에 따라 많은 수정이 있을 수 있음.
• Stable ; 90% 이상의 완성도로 이 후 브레이킹 체인지는 거의 없는 퀄러티.
• Mature ; 풀 릴리즈를 위해 준비된 퀄러티.

이번에 공개된 컨트롤은 다음과 같아요.

Preview 퀄러티

• AutoCompleteBox
• NumericUpDown
• ViewBox
• Expander
• ImplicitStyleManager
• Charting

Stable 퀄러티

• TreeView
• DockPanel
• WrapPanel
• Label
• HeaderedContentControl
• HeaderedItemsControl

네, WPF를 하셨던 분이라면 익숙한 몇몇 컨트롤도 있고 새로 추가된 컨트롤도 있네요. 특히 썩 아름답지는 않지만 쓸만한 차트가 포함된 것도 고무적이고요.

또 특이한 점으로는 기존 컨트롤에 쉽게 테마를 입힐 수 있도록 준비된 ImplicityStyleManager인데요, 자세한 사항은 Theming에서 확인해 보세요. 간단하게 눈으로만 봐도 무슨 내용인지 파악할 수 있을 거에요.

아우아우… 바빠 죽겠는데 새로운 것들은 쏟아져 나오고… 진짜 정신 없네요!

후우… 이건 뭐 챙피도 보통 챙피가 아니네요.
아무리 해봐도 퍼가기에서 애플리케이션이 동작을 안하길래 1시간 동안 별 쌩쑈를 다 했는데… 결국 서버에 해줘야 할 가장 기본적인 설정을 안해줘서 생긴 문제였어요.

이 기회에 실버라이트 서비스를 위해 필요한 서버측의 준비 사항을 정리해봅니다.

[필수]

올바른 MIME-TYPE 등록과 Content-type 응답

먼저 서버에는 반드시 다음과 같이 XAP에 대한 MIME-TYPE이 등록되어 있어야 해요.

확장자 : XAP
MIME-TYPE : application/x-silverlight-app

IIS6의 경우 MIME-TYPE이 없을 경우 애초에 다운로드부터 실패하므로 비교적 원인을 빨리 찾을 수 있는데요,
Tomcat 등으로 돌린 호스트는 MIME-TYPE을 등록하지 않더라도 기본적으로 다운로드를 허용하죠. 그래서 웹 디버깅 툴로 HTTP 200 떨어지는 걸 보고는 MIME-TYPE 문제는 아닐 것이다…라고 안심하고 다른 곳에서 삽질한거죠.

또한 실버라이트 2에서는 서버가 XAP에 응답할 때에는 반드시 올바른 Content-Type을 헤더에 포함하고 있어야 해요.

예)
HTTP/1.1 200 OK
Content-Length: 321175
Content-Type: application/x-silverlight-app
…생략…

자 외쳐봅시다!

프로젝트 시작하면 MIME-TYPE 등록!
다운되는 XAP도 다시 보자!

(참고로 고맙게도 IIS7에서는 XAP에 대한 올바른 MIME-TYPE이 처음부터 등록되어 있어요)

[크로스 도메인에 따른 옵션]

크로스 도메인에 대한 리소스 접근 허용시 clientaccesspolicy.xml 등록

만약 실버라이트 애플리케이션이 크로스 도메인을 넘어 서버에 리소스를 요청할 때에는 반드시 해당 도메인의 최상위 경로에 clientaccesspolicy.xml이 있어야 해요. 물론 크�