유령회사 공도소프트 Gongdosoft the ghost company

어제 기습적으로(?) 실버라이트 3 업데이트가 나왔어요.

Visual Studio용 실버라이트 3툴은 아래 링크에서 다운로드 받으시고요, 한국어 지원도 추가되었으니까 한국어 버전을 사용하시는 분들은 언어를 선택해보세요^^

[Silverlight 3 Tools for Visual Studio 2008 SP1]

당연하겠지만, 실버라이트 3 런타임 자체도 버전업 했는데요, 이제 최종 버전은 3.0.40723.0이에요.

이 버전은 GDR(General Distribution Release)1으로 실버라이트 2때에도 비슷하게 RTW가 나오고 몇 주 있다가 GDR1이 나왔었죠.

업데이트는 오직 런타임에만 적용되기 때문에 Tools를 새로 깔아도 기본 템플릿은 여전히 3.0.40624를 가리키고 있죠. 뭐 거슬리는 분은 직접 수정하셔도 될 거에요.

업데이트 된 내용은 딱 하나에요.

• 미디어 재생 중 버퍼링을 너무 많이 하는 문제 수정(fix).

좀 더 빙잉(Bingingㅋㅋ)해 보니 정확히는 스트리밍을 사용하는 wmv에 스크립트 커맨드가 많을 때(어느 정도인지는 모르고요) 버퍼링이 잦아지는 문제가 생겼다는 군요.

여튼 대부분의 서비스에는 크게 영향을 주지 않을 것 같지만 혹시라도 wmv에 스크립트 커맨드를 대량으로 넣어서 서비스를 했다면 런타임을 업데이트 하도록 유도해야 겠죠.

최근에 VC-1 코덱을 사용하면 라이선스 비용때문에 도입을 못하겠다… 그래서 H.264를 선택했다…라는 얘기를 들었는데요, 저도 라이선스 관련은 제대로 모르지만 여튼 VC-1과 H.264모두 MPEG LA라는 곳에서 라이선스를 계약해야 하는 걸로 알고 있었거든요. 암튼 그간 실버라이트 하면서 VC-1과 H.264의 기술적 차이나 특성은 많이 봤지만 정작 중요한 라이선스 비용에 대한 정확한 얘기는 못 본 것 같아서 자료를 좀 찾아봤어요.

• MPEG LA 홈페이지 : http://www.mpegla.com/
• VC-1 코덱 라이선스 조항 요약본 : http://www.mpegla.com/vc1/vc1_TermsSummary.pdf
• AVC/H.264 코덱 라이선스 조항 요약본 : http://www.mpegla.com/avc/AVC_TermsSummary.pdf

▼VC-1 코덱 라이선스 발번역 보기

아오 빡세… 근데 원문을 봐도 번역문을 봐도 솔직히 복잡하긴 마찬가지에요. 그래서 진짜 초 간단하게 표로 요약해 봤고요, 대략적인 비용 계산은 이 표를 이용해도 될 것 같아요.

두둥~~

아니 어째 이렇게 정리가 되는 내용을 베베꼬아 놨대요 그래. 일단 표로 만들고 주석을 다는게 훨씬 보기 좋구만…

어쨌든, 우리의 관심사는 실버라이트로 미디어 서비스를 제공할 때 비용이 어떡게 되느냐…겠죠? 그리고 궁극적인 답은 공짜로 쓸 수 있느냐 없느냐고요. 결론적으로는 ‘제한적으로’ 가능하다 에요. 위의 표에 따라 VC-1 코덱을 사용한 미디어로 서비스 할 때 무료로 이용할 수 있는 조건은 다음과 같이 정리할 수 있겠네요.

• 사용자에게 한 건당 요금을 받지만 영상이 12분 이하일 때.
• 사용자에게 기간 한정 또는 개수 한정으로 요금을 받지만 서비스 가입자가 10만명 이하일 때.
• 사용자에게 직접적으로 요금을 받지 않는 인터넷 서비스일 때.
  (※단, 이 경우 광고 등의 수익 모델은 가능하며 2012년까지 한시적으로 적용됨)

네 사실 이 세 문장을 보기 위해 저런 캐삽질을 한 거죠.

그럼 H.264는 어떨까요? 이쪽도 해봐야 겠죠? 그.런.데. 진짜 하나하나 거의 다 똑같은 문구로 되어 있고 결정적으로 라이선스 비용도 완전히 동일해요. 제가 결코 귀찮아서 번역이랑 요약을 안하는게 아니고요. 핫핫!

한 가지 다른 점이 있다면 현재 VC-1의 라이선스 기간(주기)가 2012년까지인데 반해 H.264의 경우 2010년까지라는 거죠. 만약 인터넷으로 무료 서비스를 한다면 H.264의 경우 당장 내년 이후에는 라이선스 갱신을 고려해야 하고요, VC-1의 경우는 그럭저럭 2012년까지는 버틸 수 있다는 거죠. 물론 조항에 보면 ‘근거있는’ 조건으로 라이선스 조항이 변경될 가능성도 있지만요.

여튼 전적으로 제 해석에 따른 결론은 VC-1과 H.264의 ‘실제 서비스 비용’은 완전히 동일하다 이고요. 오류 지적은 웰컴 베리 쌩유~

마지막으로 번역한거 다운로드.

VC-1 코덱 라이선스 요약.docx

코덱 라이선스 비용 요약.xlsx

언제나처럼 버전업이 되면 MSDN에 마이그레이션에 관한 거의 완벽한 가이드가 나오죠. 이 글도 Ensuring That Your Silverlight 2 Applications Work with Silverlight 3를 번역한 거에요.

계속해서 추가적인 문제가 발견되면 Silverlight SDK 팀블로그여기에 올라오고 있는데 7월 25일 현재 올라온 것까지 합쳐서 번역했어요.

1. 소개

이 글은 실버라이트 2와 실버라이트 3간에 실버라이트 런타임 및 실버라이트 툴에 어떤 변화가 있었는지 소개합니다. 이 글에서 소개하는 변화는 기존의 실버라이트 기반 애플리케이션이 이제 실패하거나 오작동하는 원인이 될 가능성이 있는 것에 집중하였고, 단순히 이번 릴리즈에서 추가되거나 향상된 기능은 제외 했습니다. 이 글은 크게 세 가지 섹션을 다룹니다.

• 실버라이트 3 베타 이후의 Breaking Changes(※더 이상 지원되지 않아 빌드를 깨는 변화)
  ※실버라이트 3 베타 애플리케이션은 그리 많지 않으므로 이 섹션은 생략합니다.
• 실버라이트 2 이후의 Breaking Changes
• 업그레이드 Breaking Changes: 이 변경은 실버라이트 3로 재컴파일 하지 않는 한 문제를 일으키지 않을 것입니다.

2. 목차

1. 소개
2. 목차
3. 실버라이트 3 베타 이후의 Breaking Changes(※생략)
4. 실버라이트 2 이후의 Breaking Changes
   1. System.Web.Silverlight.dll이 Silverlight SDK에서 제거됨.
   2. 실버라이트 애플리케이션은 브라우저 줌에 정상적으로 반응함.
   3. Popup 탭 키 변경
   4. ComboBox 팝업 클리핑 수정(fixed)
   5. 실버라이트가 Popup.RenderTransform이 변했을 때 항상 팝업을 새로 그림.
   6. ContentPresenter.Content = "string"이 더 이상 ContentTemplate 속성을 변경하지 않음.
   7. ContentControl이 빈 ContentTemplate을 사용할 때 Content를 무시함.
   8. ContentControl.Content를 설정하는 것이 불필요한 OnApplyTemplate 호출을 발생시키지 않음.
   9. ComboBox와 ContentControl은 ItemsSource가 TypeConverter가 붙은 enum으로 설정될 때 숫자가 아닌 문자를 표시함.
   10. 선택된 아이템이 없는 ComboBox에서는 추가적인 키 입력을 받아야 두 번째 아이템이 선택됨.
   11. HorizontalScrollBarVisibility와 VerticalScrollBarVisibility를 ComboBox와 ListBox용 스타일에서 설정할 수 있음.
   12. ListBoxItem.HorizontalContentAlignment가 정상적으로 적용됨.
   13. ListBoxItem.Style이 ListBox.ItemContainerStyle보다 우선시됨.
   14. ListBox안에서 탭을 하면 ListBox의 다음 아이템이 아닌 ListBox의 다음 컨트롤로 이동.
   15. PasswordBox/TextBox의 TemplatePart 정의를 제거.
   16. TextBox의 TextAlignment가 TextBox가 아닌 문서에 대하여 작용함.
   17. 읽기 전용 TextBox의 색상이 변경됨.
   18. ENTER키는 Button.ClickMode가 기본 값인 Release(KeyUp)일 때만 작동함.
   19. Slider 컨트롤의 히트 테스트 영역이 보이는 것과 일치함.
   20. 잘못된 URL 형식이 포함된 clientaccesspolicy.xml이 파일 전체에 영향을 주지 않고 그 URL만 무시함.
   21. Opacity 변경이 항상 새로 그려지지 않았던 버그 수정.
   22. DataBinding을 할 때 프로퍼티 세터(setter)가 반드시 public이어야 함.
   23. SetBinding()을 호출한 이후의 Binding.Path 변경은 허용되지 않음.
   24. Image.Source가 초기화 되지 않았을 때 null을 반환함.
   25. GetValue(ImageBrush.ImageSource)가 BitmapImage가 아닌 문자열을 반환함.
   26. 크로스 도메인의 .xap을 가져오는 <asp:Silverlight>가 JavaScript 에러를 냄.
   27. NotifyCollectionChangedEventHandler.Target이 이제 ItemsControl이 아닌 WeakCollectionChangedEventListener를 반환함.
5. 업그레이드 Breaking Changes
1. OpenFileDialog.ShowDialog()는 오직 사용자가 일으킨 이벤트에서만 열림.
2. 탭 동작 처리와 연관된 콜백이 비동기에서 동기로 변경됨.
3. Popup 안에서 일어난 마우스 이벤트가 전체 애플리케이션이 아닌 팝업 영역에 대한 위치를 제공함.
4. Popup이 하나의 부모만 갖게 됨.
5. Popup안의 네임스콥(Namescope)이 정확하게 동작함.
6. FindElementsInHostCoordinates가 Popup도 검색함.
7. ItemsControl안의 Item이 교체되는 것과 연관된 이벤트가 제거됨.
8. ScrollViewer가 스크롤바의 위치를 ScrollableWidth/ScrollableWidth까지 축소함.
9. Rectangle과 Ellipse의 Stretch가 설정되었고 Height 또는 Width가 설정되지 않으면 표시됨.
10. TextBlock, TextBox 및 PasswordBox의 Width가 올림 됨.
11. TextBlock.FontFamily=null은 ArgumentNullException을 던짐.
12. 템플릿에서 Run 엘리먼트 사이에 있는 공백이 더 이상 렌더링되지 않음.
13. RadioButton.GroupName은 템플릿 바깥쪽의 RadioButton을 검색.
14. ComboBox의 콘텐트에 IsHitTestVisible="False"가 먹힘.
15. TextBox에 Opacity 프로퍼티가 작동함.
16. FrameworkElementAutomationPeer 생성자에 null 파라미터를 주면 NullReferenceException을 던짐.
17. HyperlinkButton이 이제 실버라이트가 들어있는 전체 윈도가 아닌 IFRAME에 대해 내비게이션 동작함.
18. 실버라이트 2 이상의 애플리케이션이 XAP 파일 확장자를 갖지 않을 때 base URI 문제를 정정함.
19. Application.Current.Host.Source는 .xap URL이 쿼리 스트링을 포함할지라도 절대 URL을 반환함.
20. ResourceDictionary enum 버그가 수정됨.
21. ReadOnlyObservableCollection이 System.Windows.Controls.Data.dll에서 System.Windows.dll로 옮김.
22. DataGridEndingEditEventArgs가 Silverlight SDK에서 제거됨.
23. PollingDuplexHttpBinding 변경점.
24. 이벤트 핸들러를 제거할 때 버그 수정.
25. <Cursor>대신 <Cursors>를 허용하는 버그 수정.
26. XAML에서 커스텀 첨부 프로퍼티는 xmlns 접두사를 써야 함.
27. 서브클래스 컨트롤이 리소스를 잘못 로드할 수 있는 버그 수정.
28. 경로에 있는 자식 오브젝트가 null일 경우 ValueConverter가 호출되지 않는 버그 수정.
29. .xap의 바깥 쪽에 있는 리소스를 가리키던 상대 URL가 HTML page가 아닌 .xap 파일에 대해 작용함.
30. SetBinding() 이후에 Binding 속성을 설정하는 것은 더 이상 지원하지 않음.
31. ContentPresenter의 자식은 오직 하나의 부모를 가짐.
32. Thumb 컨트롤이 이제는 그 부모에 대해서가 아니라 절대 위치를 기준으로 드래그를 계산.
33. DataGrid가 이제는 첫 번째 아이템을 기본으로 선택하지 않음.
34. DataGrid에서 마지막 아이템이 HorizontalScrollBarVisibility="Auto"일 때 키보드를 사용할 수 없는 버그 수정.

3. 실버라이트 3 이후의 Breaking Changes(※생략)

4. 실버라이트 2 이후의 Breaking Changes

이 섹션에서 설명하는 변경 사항은 실버라이트 2 애플리케이션의 동작을 망가뜨릴 수 있습니다. 이 중의 많은 사항은 사실 버그 수정입니다. 그렇다 하더라도, 실버라이트 2 애플리케이션이 이 버그를 피하기 위해 워크어라운드를 적용했다면, 애플리케이션이 올바로 동작되도록 이 워크어라운드를 제거해야 할 것입니다.

4.1 System.Web.Silverlight.dll이 Silverlight SDK에서 제거됨.

ASP.NET Silverlight 및 MediaPlayer 컨트롤이 Silverlight 3 SDK에서 제거되었습니다. 이들은 System.Web.Silverlight.dll이라는 이름의 서버 어셈블리에 포함되고 보통 테스트 웹 사이트의 Bin폴더에서 얻을 수 있습니다.

기존의 실버라이트 2 웹 사이트는 각 웹 애플리케이션의 Bin 폴더에서 Silverlight.Web.Silverlight 어셈블리를 가지고 있기 때문에(심지어 실버라이트 2 SDK가 언인스톨 되어도) 계속 동작 할 것입니다.

기존 프로젝트를 실버라이트 3로 업그레이드 할 때, 대부분의 경우 반드시 이 컨트롤을 동일한 역할을 하는 <object>태그로 교체해야 합니다. 예를 들어 <asp:Silverlight>는 다음과 같이 수정할 수 있습니다.

기존의 실버라이트 애플리케이션은 각 웹 애플리케이션의 Bin 폴더에서 System.Web.Silverlight 어셈블리를 얻으려고 할 것입니다. 때문에 실버라이트 3 SDK로 업그레이드 하여도 이 로컬 어셈블리를 제거하지 않을 것이며 애플리케이션은 동작할 것입니다. 개발자는 실버라이트 3용으로 적절한 버전 플래그를 설정할 것입니다.

• 클라이언트에서 기존의 fwlink가 실버라이트 3를 가리키도록 해야함.
• System.Web.Silverlight 어셈블리를 GAC에 등록한 개발자라면 GAC에서 수동으로 제거해야 함.

개발자가 새 애플리케이션을 만들 때는 최신의 object 태그 및 다른 마크업을 포함한 템플릿을 사용하길 바랄 것입니다.

• 개발자는 System.Web.Silverlight 어셈블리를 수동으로 추가하고 서버 컨트롤을 사용할 수도 있습니다. 그러나, 이 컨트롤은 최신의 설치 로직을 지원하지 않고, 실버라이트 히스토리 지원에 필요한 iframe 등을 렌더링 하지 않을 것입니다.

ASP.NET 서버 컨트롤을 실버라이트 3로 마이그레이션 하려면 ASP.NET Server Controls for Silverlight in the Silverlight SDK를 참고하세요.

4.2 실버라이트 애플리케이션은 브라우저 줌에 정상적으로 반응함.

실버라이트 애플리케이션(기존과 새 버전 모두)은 현재 상태에 따라 브라우저 줌에 대해 응답할 수 있는 기회를 가집니다. 실버라이트 애플리케이션은 애플리케이션이 Resized이벤트를 핸들링하지 않는다면 기본으로 줌을 할 것입니다. 줌은 루트 엘리먼트의 가상의 부모에 대해 RenderTransform = new ScaleTransform()을 적용한 것과 동일합니다.

애플리케이션은 다음의 새 API를 사용하여 이 동작을 변경할 수 있습니다.

• System.Windows.Interop.Content의 Zoomed 이벤트와 ZoomFactor 프로퍼티. (Content 클래스는 보통 App.Current.Host.Content로 사용)
• 실버라이트 플러그인의 EnableAutoZoom 파라미터.

4.3 Popup 탭 키 변경

실버라이트 2에서 포커스가 팝업 안에 있고 TAB 키를 눌렀다면, 포커스가 실버라이트 영역을 벗어나 브라우저로 갑니다. 다른 컨트롤이 팝업에 있어도 무시됩니다. 실버라이트 3에서는 탭 동작이 팝업 내부를 먼저 돕니다. 만약 이 전 동작대로 작동하길 바란다면 Popup의 루트에서 TabNavigation="Cycle"로 설정하면 됩니다.

4.4 ComboBox 팝업 클리핑 수정(fixed)

실버라이트 2에서 ComboBox 팝업 안에 수직 스크롤바가 있을 경우 팝업이 ComboBox 자신보다 더 넓었고, 팝업이 스크롤바의 너비에 따라 너무 좁았습니다.

이 실버라이트 2 버그를 워크어라운드를 써서 ComboBox 아이템의 크기를 늘려 해결하였다면, 실버라이트 3에서는 원치 않는 공간을 더 차지하게 될 것이고 아마도 기존의 워크어라운드를 제거하고 싶을 것입니다.

4.5 실버라이트가 Popup.RenderTransform이 변했을 때 항상 팝업을 새로 그림.

실버라이트 2에서 실버라이트는 Popup.RenderTransform이 변경되었을 때 항상 다시 그리지 않았습니다. 실버라이트 3에서 이 버그가 수정되었습니다.

4.6 ContentPresenter.Content = "string"이 더 이상 ContentTemplate 속성을 변경하지 않음.

전에는 ContentPresenter.Content를 문자열로 설정하면 호출된 ContentPresenter.ContentTemplate에서 null이 아닌 문자열 값을 보게 될 것입니다. 이제는 ContentPresenter.Content를 문자열로 설정하여도 더 이상 ContentTemplate 속성을 변경하지 않습니다. 이 변경이 완료되어 ContentPresenter.Content는 한 번 문자열로 설정한 다음 다시 설정할 수 없습니다.

이 동작은 ContentPresenter에 해당하는 것이지 ContentControl이 아님에 주의하세요. ContentPresenter는 일반적으로 다음 XAML처럼 오직 컨트롤 템플릿의 내부에서만 사용됩니다.

4.7 ContentControl이 빈 ContentTemplate을 사용할 때 Content를 무시함.

실버라이트 2에서 ContentControl(예를 들어 Button)에 빈 ContentTemplate을 설정하면 컨트롤은 템플릿을 무시하고 ContentPresenter를 사용하여 표시할 것입니다. 예를 들어 실버라이트 2에서 다음 코드는 "ABC"를 표시합니다.

이 문제는 실버라이트 3에서 수정되었고 이 코드는 이제 아무 내용도 표시하지 않습니다.

4.8 ContentControl.Content를 설정하는 것이 불필요한 OnApplyTemplate 호출을 발생시키지 않음.

실버라이트 2에서 ContentControl.Content를 세팅하면 OnApplyTemplate이 매번 호출되었습니다. 심지어 ContentControl.ControlTemplate이 설정되었어도 호출되었습니다. 실버라이트 3에서는 OnApplyTemplate은 ContentControl.ControlTemplate을 처음으로 설정될 때 한 번만 호출됩니다.

4.9 ComboBox와 ContentControl은 ItemsSource가 TypeConverter가 붙은 enum으로 설정될 때 숫자가 아닌 문자를 표시함.

실버라이트 2에서 ComboBox의 ItemsSource 속성에 Enum을 넣으면 ComboBox는 Enum의 이름이 아닌 수치 값을 표시합니다. 예를 들어,

이 코드는 "First"가 아니라 "1"을 표시합니다. 실버라이트 3에서는 수정되어 이제 문자열 값이 표시됩니다.

4.10 선택된 아이템이 없는 ComboBox에서는 추가적인 키 입력을 받아야 두 번째 아이템이 선택됨.

실버라이트 2에서 선택된 아이템이 없는 ComboBox를 열면 첫 번째 아이템이 선택되지도 않았으면서 포커스를 가집니다. 그래서 첫 번째 다운 키가 포커스와 선택을 두 번째 아이템으로 옮깁니다.

실버라이트 3에서는 ComboBox가 열렸을 때 첫 번째 아이템이 포커스를 갖지 않습니다. 첫 번째 키 입력은 첫 번째 아이템을 선택하고 포커스를 설정하며 두 번째 아이템은 두 번째 다운 키를 입력해야 포커스와 선택이 이동합니다.

4.11 HorizontalScrollBarVisibility와 VerticalScrollBarVisibility를 ComboBox와 ListBox용 스타일에서 설정할 수 있음.

실버라이트 2에서 이 프로퍼티는 생성자에서 내부적으로 설정되었으며 스타일의 값을 덮어 썼습니다. 이 문제가 수정되었습니다.

4.12 ListBoxItem.HorizontalContentAlignment가 정상적으로 적용됨.

실버라이트 2에서 ListBoxItem의 기본 템플릿을 사용할 때 HorizontalContentAlignment가 무시되었습니다. 이 문제가 수정되었습니다.

4.13 ListBoxItem.Style이 ListBox.ItemContainerStyle보다 우선시됨.

실버라이트 2에서 ListBoxItem.Style을 설정한 후 코드에서 ListBox.ItemContainerStyle을 설정하면 올바르지 않게 전에 설정한 ListBoxItem.Style을 덮어 씁니다. 이 문제가 수정되었습니다.

4.14 ListBox안에서 탭을 하면 ListBox의 다음 아이템이 아닌 ListBox의 다음 컨트롤로 이동.

실버라이트 2에서 ListBox안에서 TAB키를 누르면 다음 컨트롤이 아닌 다음 ListBox 아이템으로 이동했습니다. 이제 탭이 다른 플랫폼과 동일하게 동작합니다.

4.15 PasswordBox/TextBox의 TemplatePart 정의를 제거.

실버라이트 2에서 PasswordBox와 TextBox는 실제로는 가지고 있지 않은 많은 수의 [TemplatePart] 어트리뷰트로 컨트롤의 파트를 지정하였습니다. 이 어트리뷰트가 실버라이트 3에서는 제거되었습니다.

4.16 TextBox의 TextAlignment가 TextBox가 아닌 문서에 대하여 작용함.

실버라이트 2에서 TextBox의 텍스트는 문서에 기반하여 가운데 정렬하지 않고 TextBox의 Width 프로퍼티에 기반하여 가운데 정렬했습니다. 이것은 올바르지 않은 가운데 정렬이었습니다. 예를 들어 다음과 같이 가운데 정렬된 텍스트를 가정합시다.

실버라이트 2에서는 긴 텍스트를 타이핑하면 TextBox는 다음과 같이 표시됩니다.

실버라이트 3에서는 이 동작을 바로 잡았습니다. 올바른 동작은 "ABC"가 전체 문서의 가운데에 위치해야 하지 문서의 보이는 부분에 대해서 가운데 정렬되는 것이 아닙니다. 이 변경은 전체 텍스트의 크기에 영향을 주지는 않습니다. 그리고 사용자가 필요하다면 스크롤을 사용하여 뷰포인트를 가운데 정렬된 텍스트쪽으로 옮길 수 있습니다.

4.17 읽기 전용 TextBox의 색상이 변경됨.

실버라이트 2에서 읽기 전용 텍스트 박스는 수정 가능한 텍스트 박스와 별 차이가 없었습니다.

4.18 ENTER키는 Button.ClickMode가 기본 값인 Release(KeyUp)일 때만 작동함.

만약 애플리케이션이 ClickMode를 Press로 변경했다면 클릭 핸들러가 (클릭)재실행의 원인이 되는 코드를 실행하지 않습니다.

4.19 Slider 컨트롤의 히트 테스트 영역이 보이는 것과 일치함.

실버라이트 2에서 슬라이더를 길게 만들었다면 슬라이더의 파트가 아닌 것처럼 보이는 영역을 클릭할 수 있었습니다.

4.20 잘못된 URL 형식이 포함된 clientaccesspolicy.xml이 파일 전체에 영향을 주지 않고 그 URL만 무시함.

실버라이트 2에서 잘못된 URL은 나머지 clientaccesspolicy.xml을 무시하게 했습니다. 이 문제가 수정되었습니다.

4.21 Opacity 변경이 항상 새로 그려지지 않았던 버그 수정.

여러 사정으로 실버라이트 2에서 Opacity가 변경되었을 때 콘텐트를 다시 그리지 않았습니다. 이 문제가 수정되었습니다.

4.22 DataBinding을 할 때 프로퍼티 세터(setter)가 반드시 public이어야 함.

실버라이트 데이터 바인딩은 일반적으로 프로퍼티와 타입이 public이어야 합니다. 실버라이트 2에서는 public getter와 private setter를 가진 프로퍼티가 데이터 바인딩이 가능했습니다. 이 문제가 수정되었습니다.

4.23 SetBinding()을 호출한 이후의 Binding.Path 변경은 허용되지 않음.

실버라이트 2에서 SetBinding 호출이 끝났지만 DataContext가 설정되기 전이라면 Binding.Path를 설정할 수 있었습니다. 예를 들어,

실버라이트 3에서는 한번 SetBinding이 호출되면 Path 속성을 더 이상 수정할 수 없으며 위의 코드는 다음과 같이 수정되어야 합니다.

만약 Path가 SetBinding()이 호출된 후에 변경되면 실버라이트 3는 애플리케이션이 어떤 버전의 실버라이트에서 컴파일 되었냐에 따라 동작합니다. 실버라이트 3에서 컴파일되었다면 이 코드는 예외를 날리게 됩니다.

4.24 Image.Source가 초기화 되지 않았을 때 null을 반환함.

실버라이트 2에서 Image또는 ImageBrush.Source 프로퍼티가 설정되기 전에 접근하면 빈 BitmapImage를 생성하여 반환하였습니다. 실버라이트 3에서는 해당 프로퍼티가 설정되지 않았다면 null을 반환합니다.

4.25 GetValue(ImageBrush.ImageSource)가 문자열이 아닌 BitmapImage를 반환함.

실버라이트 2에서 다음 코드는 문자열을 반환했습니다.

실버라이트 3에서는 정상적으로 BitmapImage 오브젝트를 반환합니다.

4.26 크로스 도메인의 .xap을 가져오는 <asp:Silverlight>가 JavaScript 에러를 냄.

※생략

4.27 NotifyCollectionChangedEventHandler.Target이 이제 ItemsControl이 아닌 WeakCollectionChangedEventListener를 반환함.

실버라이트 2에서 NotifyCollectionChangedEventHandler.Target이 ItemsControl을 반환했지만 실버라이트 3에서는 WeakCollectionChangedEventListener를 반환합니다.

5. 업그레이드 Breaking Changes

실버라이트 팀은 실버라이트 2에 있던 많은 버그를 실버라이트 3에서는 고치고 싶었습니다. 그러나, 몇몇 버그를 수정함으로써 기존의 실버라이트 2의 일부가 동작하지 않을 가능성이 있습니다. 이 문제를 넘어가려면, 실버라이트 개발자는 잠재적인 문제점이 있는 변경 사항을 “변칙 모드(quirk mode) 변경”으로 정할 수 있습니다. 변칙 모드 변경은 애플리케이션이 실버라이트 2용으로 디자인되었다고 감지했을 때에는 실버라이트 3 런타임이 강제되지 않는다는 것을 의미합니다. 이 때 실버라이트 3는 실버라이트 2 애플리케이션이 실행될 때 실버라이트 2의 “버그 호환”이 되도록 합니다. 어쨌든 이 섹션에서 설명하는 변경은 기존의 애플리케이션을 실버라이트 3용으로 재컴파일 했을 때만 적용될 것입니다.

다음 그림처럼 만약 애플리케이션의 RuntimeVersion이 실버라이트 2를 가리킨다면, 런타임은 “변칙 모드”가 됩니다. 변칙 모드일 때 런타임은 변칙 모드 변경 사항과 관련된 동작을 실버라이트 2에 맞출 것입니다.

위의 그림에서 실버라이트 3 런타임은 애플리케이션이 실버라이트 2용으로 디자인 되었는지 여부를 RuntimeVersion을 사용하여 알아냅니다. RuntimeVersion은 .xap 파일 안에 있는 AppManifest.xaml 파일의 어트리뷰트로 설정됩니다.

RuntimeVersion은 애플리케이션을 컴파일한 개발자의 컴퓨터에 있었던 실버라이트의 버전을 말합니다.

5.1 OpenFileDialog.ShowDialog()는 오직 사용자가 일으킨 이벤트에서만 열림.

보안상의 이유로 OpenFileDialog.ShowDialog()는 사용자가 일으킨 이벤트(MouseLeftButtonDown/Up이나 KeyDown/Up)를 처리하는 동안에만 호출할 수 있습니다. 혹은 버튼을 클릭하거나 체크 박스를 클릭할 때 발생하는 이벤트에서 파생될 때에도 가능합니다. 이제 실버라이트는 다른 대부분의 브라우저나 플러그 인과 같은 동작을 합니다.

5.2 탭 동작 처리와 연관된 콜백이 비동기에서 동기로 변경됨.

실버라이트 2에서 페이지에 있는 마지막 컨트롤위에서 탭을 할 때 버그가 있었습니다. 이 버그를 수정하면서 생긴 부작용은 탭 처리와 관련된 GotFocus 이벤트와 같은 콜백이 비동기에서 동기로 변경되었다는 점입니다. (“비동기”란 사실은 PostMessage를 말합니다. 이는 현재 메시지가 처리된 직후 같은 스레드에서 동작합니다.) 이것은 Breaking change입니다. 왜냐하면 실버라이트에서 비동기 이벤트를 처리하는 중에는 HTML DOM으로 호출할 수 없기 때문입니다. 이 동작은 WPF에 있는 재진입(reentrancy) 제한의 실버라이트 버전입니다. 변칙 모드에서는 애플리케이션이 비동기 탭 처리를 할 것이며 이는 페이지의 가장 마지막 컨트롤에서 잘 동작하지 않을 것입니다.

5.3 Popup 안에서 일어난 마우스 이벤트가 전체 애플리케이션이 아닌 팝업 영역에 대한 위치를 제공함.

Popup 안에 있는 엘리먼트가 마우스 이벤트를 수신한다고 가정해 봅시다.

실버라이트 2에서 MouseButtonEventArgs.GetPosition()으로 얻은 좌표는 해당 실버라이트 플러그인에 대한 상대 좌표가 됩니다. 심지어 애플리케이션이 해당 엘리먼트에 대한 상대 좌표를 요청하더라도 그렇게 됩니다. 이 문제가 실버라이트 3에서는 수정되었습니다.

5.4 Popup이 하나의 부모만 갖게 됨.

실버라이트 2에서 여러가지 이유로 한 Popup이 두 개의 부모를 가질 수도 있었습니다. 실버라이트 3는 Popup에 오직 하나의 부모만을 허용합니다.

5.5 Popup안의 네임스콥(Namescope)이 올바로 동작함.

실버라이트 2는 Popup안에 있는 이름붙은 아이템이 Popup 되었을 때 잘못된 네임스콥을 설정하는 버그가 있었습니다. 자식이 자기 자신의 네임스콥을 가졌습니다 (예를 들어 자식이 XamlReader.Load로 생성됨). 이는 FindName()과 Storyboard.TargetName으로 찾아야 할 엘리먼트를 찾을 수 없거나 찾으면 안될 엘리먼트를 찾게 되었습니다 (실버라이트가 잘못된 네임스콥을 검색하므로). 어떤 경우 FindName()이 트리에서 제거된 엘리먼트를 찾았습니다. 이 문제가 실버라이트 3에서 수정되었습니다. 올바른 네임스콥 동작은 팝업이 트리에 실제로 올라왔고 팝업 되었을 때, 자식은 네임스콥의 오너가 아니며, 팝업의 자식들은 팝업 부모의 네임스콥에 일부가 됩니다. 그렇지 않은 경우 팝업의 자식들은 Popup.Child에 붙은 네임스콥에 들어있어야 합니다.

5.6 FindElementsInHostCoordinates가 Popup도 검색함.

실버라이트 2에서 FindElementInHostCoordinates가 Popup안은 검색하지 않았습니다. 이 문제가 수정되었습니다.

5.7 ItemsControl안의 Item이 교체되는 것과 연관된 이벤트가 제거됨.

실버라이트 2에서 ItemsControl에 있는 아이템을 교체하면 세 개의 이벤트-Remove, Add, Replace-를 만듭니다. 이 동작은 WPF와 호환되지 않고 이에 대해 코딩하기도 어렵습니다. Remove와 Add 이벤트를 받았을 때 이것이 잔짜로 교체하여 진행되는 것인지 알 수 없습니다. 실버라이트 3에서는 오직 Replace 이벤트만 발생합니다.

5.8 ScrollViewer가 스크롤바의 위치를 ScrollableWidth/ScrollableWidth까지 축소함.

이 결과, ScrollViewer에 있는 컨텐트의 너비와 높이는 레이아웃 계산 작업이 완료될 때까지 0이 됩니다.

5.9 Rectangle과 Ellipse의 Stretch가 설정되었고 Height 또는 Width가 설정되지 않으면 표시됨.

실버라이트 2에서 Stretch!=UniformToFill이고 너비나 높이가 설정되지 않은 Rectangle이나 Ellipse가 ContentControl에 있으면 오브젝트가 렌더링되지 않았습니다. 실버라이트 3에서는 Rectangle이나 Ellipse의 Stretch가 None이 아닐 경우 렌더링됩니다.

5.10 TextBlock, TextBox 및 PasswordBox의 Width가 올림 됨.

실버라이트 2에서 PasswordBox, TextBlock 및 TextBox의 크기가 자동으로 조절되게 하면 마지막 문자의 일부가 잘리는 현상이 있었습니다. 텍스트의 실제 길이가 정수가 아니고 소수 부분이 .5보다 작을 경우 그렇습니다. 예를 들어, 텍스트 길이가 96.34로 측정되면 96.00으로 내림 처리하고 TextBlock은 이 텍스트를 표시할 충분한 공간을 확보하지 않았습니다. 이제는 올림을 하기 때문에 애플리케이션의 레이아웃에 영향을 줍니다.

5.11 TextBlock.FontFamily=null은 ArgumentNullException을 던짐.

이제는 ArgumentNullException을 던집니다.

5.12 템플릿에서 Run 엘리먼트 사이에 있는 공백이 더 이상 렌더링되지 않음.

템플릿내에서 실버라이트 2는 암시적으로 엘리먼트 간에 공백을 삽입했기 때문에 <TextBlock><Run Text="Hel"/><Run Text="lo"/></TextBlock>이 "Hel_lo"(_는 공백)가 됩니다. 실버라이트 3에서는 이 공백을 렌더링하지 않습니다.

5.13 RadioButton.GroupName은 템플릿 바깥쪽의 RadioButton을 검색.

실버라이트 2에서 RadioButton.GroupName을 템플릿 안에서 사용한다면 실버라이트는 다른 RadioButton을 해당 템플릿 안에서만 검색합니다. 이 동작은 WPF와 다르고 다른 많은 유용한 시나리오를 어렵게 만듭니다. 실버라이트 3에서는 RadioButton이 템플릿 바깥쪽도 잘 검색합니다.

5.14 ComboBox의 콘텐트에 IsHitTestVisible="False"가 먹힘.

실버라이트 2에서 ComboBox안에서 선택된 아이템이 마우스 이벤트를 받았습니다. 이 동작은 ComboBox가 마우스 오버 상태에서 비주얼을 올바로 표시하는데 방해가 되었습니다. ComboBox는 이제 컨트롤 템플릿 내부적으로 ContentPresenter를 IsHitTestVisible="False"로 설정합니다. ComboBox자신은 여전히 마우스 이벤트를 받습니다.

5.15 TextBox에 Opacity 프로퍼티가 작동함.

실버라이트 2에서 Opacity 프로퍼티가 무시되었습니다 (항상 1로 처리됨). 이 문제가 수정되었습니다.

5.16 FrameworkElementAutomationPeer 생성자에 null 파라미터를 주면 NullReferenceException을 던짐.

이제는 ArgumentNullException을 던집니다.

5.17 HyperlinkButton이 이제 실버라이트가 들어있는 전체 윈도가 아닌 IFRAME에 대해 내비게이션 동작함.

실버라이트 2에서 HyperlinkButton이 브라우저 사이를 고려하지 않고 동작했습니다. Internet Explorer에서 HyperlinkButton은 현재 IFrame이 아닌 항상 전체 브라우저에 대해 내비게이션하였습니다.

다른 브라우저에서 HyperlinkButton은 오직 현재 IFrame에 대해서만 내비게이션 했습니다. 이 동작이 HTML 특성을 고려한 것입니다. 실버라이트 3에서는 Internet Explorer에서의 동작이 다른 브라우저와 맞도록 변경되었습니다.

5.18 실버라이트 2 이상의 애플리케이션이 XAP 파일 확장자를 갖지 않을 때 base URI 문제를 정정함.

실버라이트 2 플러그인에서 .xap 파일의 확장자를 다르게 준다면, 실버라이트는 이 애플리케이션이 실버라이트 1을 위해서 디자인 되었다고 오해하고 실버라이트 1 호환 모드로 동작했습니다. 한 예로 베이스 URI가 .xap 파일이 아닌 HTML page로 인식되었고 다른 예로 기본 폰트가 .xap과 달랐습니다. 이 문제가 수정되었습니다.

5.19 Application.Current.Host.Source는 .xap URL이 쿼리 스트링을 포함할지라도 절대 URL을 반환함.

실버라이트 2에서 .xap 파일의 URL이 쿼리스트링을 포함하면 Application.Current.Host.Source가 상대 URL을 반환했습니다. 실버라이트 3에서는 이 문제가 수정되어 Application.Current.Host.Source는 항상 절대 URL을 반환합니다. .xap파일의 URL은 보통 <object>태그 안에서 <param>으로 지정하며 다음은 쿼리 스트링을 포함하는 .xap 파일의 URL 예제입니다.

5.20 ResourceDictionary enum 버그가 수정됨.

실버라이트 2에서 ResourceDictionary에 enum을 넣고 다시 가져오면 enum 타입이 아닌 Integer32 타입의 object를 받았습니다. 이 문제가 실버라이트 3에서 수정되었습니다.

5.21 ReadOnlyObservableCollection이 System.Windows.Controls.Data.dll에서 System.Windows.dll로 옮김.

또한 다운로드 크기를 줄이기 위해 잘 사용되지 않는 메서드가 제거되었습니다.

이 수정은 실버라이트 2에서 컴파일된 애플리케이션에는 적용되지 않습니다. 실버라이트 2에서 ReadOnlyObservableCollection를 사용하였다면 .xap 파일에는 System.Windows.Controls.Data.dll이 들어있을 것입니다. 실버라이트 3가 .xap을 실행하면 .xap에 들어있는 System.Windows.Controls.Data.dll 버전의 ReadOnlyObservableCollection을 사용하지 실버라이트 3에서 제공하는 System.Windows.dll 버전을 사용하지 않습니다.

5.22 DataGridEndingEditEventArgs가 Silverlight SDK에서 제거됨.

이 EventArgs를 반환하는 곳이 없어서 제거되었습니다. DataGridCellEditEndingEventArgs, DataGridCellEditEndedEventArgs, DataGridRowEditEndingEventArgs, DataGridRowEditEndedEventArgs가 실버라이트 3에 추가되었습니다.

5.23 PollingDuplexHttpBinding 변경점.

PollingDuplexHttpBinding이 이제 BasicHttpBinding이 아닌 HttpBinding에서 파생됩니다. PollingDuplexHttpBinding은 이제 SOAP 1.1 대신 1.2 버전을 사용하며, 이로써 실버라이트 3 PollingDuplexHttpBinding은 실버라이트 2버전의 System.ServiceModel.PollingDuplex.dll을 실행하는 ASP.NET 서버와 동작하지 않을 것입니다.

5.24 이벤트 핸들러를 제거할 때 버그 수정.

보통 이벤트 수신자를 제거(-= 오퍼레이션)하면, 부분적인 이벤트의 부분적인 딜리게이트만 제거합니다. 실버라이트 2는 이벤트 파트를 무시했습니다. 예를 들어, “object.SomeEvent –= SomeMethod”는 SomeEvent뿐만 아니라 다른 모든 이벤트에서 SomeMethod 메서드에 묶인 모든 이벤트 수신자를 제거했습니다. 이 문제가 실버라이트 3에서 수정되었습니다.

5.25 <Cursor>대신 <Cursors>를 허용하는 버그 수정.

실버라이트 2에서는 요컨대 다음과 같은 XAML을 허용했습니다.

이 코드는 잘못되었습니다. 실버라이트 3는 오직 <Cursor>만 허용합니다.

5.26 XAML에서 커스텀 첨부 프로퍼티는 xmlns 접두사를 써야 함.

실버라이트 2에서 다음과 같은 잘못된 XAML을 허용했습니다.

실버라이트 3에서는 첨부 프로퍼티에 정확하게 XML 접두사를 써줘야 합니다.

5.27 서브클래스 컨트롤이 리소스를 잘못 로드할 수 있는 버그 수정.

실버라이트 2에서 클래스 A가 한 사용자 어셈블리에 정의되어 있고 마크업이 다른 사용자 코드 어셈블리안에 있는 클래스 B를 상속하였을 때, Application.LoadComponent(A)가 A의 어셈블리가 아닌 B의 어셈블리에서 XAML을 로드하려고 할 것입니다. 이 문제가 수정되었습니다.(※A어셈블리의 XAML을 로드)

5.28 경로에 있는 자식 오브젝트가 null일 경우 ValueConverter가 호출되지 않는 버그 수정.

실버라이트 2 데이터 바인딩은 null에 대해 어떡게 처리할지 고려하지 않았습니다. Path=a.b.c.d로 설정하고 a, b 또는 c가 null이면 실버라이트 2는 ValueConverter를 호출합니다. 그러나 만약 Source=null로 설정하면 이 코드는 ValueConverter를 호출하지 않습니다. 실버라이트 3는 항상 ValueConverter를 호출합니다.

5.29 .xap의 바깥 쪽에 있는 리소스를 가리키던 상대 URL가 HTML page가 아닌 .xap 파일에 대해 작용함.

HTML 페이지와 xap 파일이 서로 다른 디렉토리에 있다고 가정해 봅시다. (예를 들어, http://example.com/과 http://contoso.com/ClientBin/) 그리고 xap 파일에 포함되어 있지 않은 상대 URL로 접근하는 리소스가 있다고 합시다. (예를 들어 images/myImage.jpg) 실버라이트 2는 이 URL을 HTML 페이지의 위치에 대해 상대적으로 해석했습니다. (http://contoso.com/images/myImage.jpg) 실버라이트 애플리케이션을 다른 위치로 쉽게 옮길 수 있게 하려고 실버라이트 3는 이 URL을 .xap 파일의 위치에 대해 상대적으로 해석합니다. (http://contoso.com/ClientBin/images/myImages.jpg)

5.30 SetBinding() 이후에 Binding 속성을 설정하는 것은 더 이상 지원하지 않음.

실버라이트 2에서 DataContext가 설정되기 전에 SetBinding()이 호출한 경우 이 둘 사이에서 Binding의 프로퍼티를 수정할수 있었습니다.

각 프로퍼티가 다른 동작을 했습니다.

• Converter, ConverterParameter, ConverterCulture, NotifyOnValidationError 및 ValidatesOnExceptions 프로퍼티는 SetBinding()으로 초기화된 바인딩에 소급하여 적용됩니다.
• Mode와 Source 프로퍼티는 무시됩니다.

실버라이트 3는 SetBinding()이 호출된 후에 이 프로퍼티를 변경하면 예외를 던집니다. (실버라이트 2도 DataContext가 설정된 후에 이 프로퍼티를 변경할 경우 비슷하게 예외를 던집니다)

5.31 ContentPresenter의 자식은 오직 하나의 부모를 가짐.

실버라이트 2에서 여러가지 이유로 ContentPresenter안의 콘텐트(자식 엘리먼트)가 두 개의 부모를 가질 수 있습니다. 콘텐트가 첫 번째 ContentPresenter에서 제거되지 않은 상태에서 두 번째 ContentPresenter에 추가될 경우입니다. 실버라이트 3는 엘리먼트가 첫 번째 부모에서 제거되지 않은 상태에서 두 번째 부모에 추가되면 예외를 던집니다.

5.32 Thumb 컨트롤이 이제는 그 부모에 대해서가 아니라 절대 위치를 기준으로 드래그를 계산.

이 문제는 드래그의 결과로 부모 엘리먼트가 이동할 때 두드러집니다.

5.33 DataGrid가 이제는 첫 번째 아이템을 기본으로 선택하지 않음.

5.34 DataGrid에서 마지막 아이템이 HorizontalScrollBarVisibility="Auto"일 때 키보드를 사용할 수 없는 버그 수정.

HorizontalScrollBarVisibility가 Auto로 설정되어 있고 수평 스크롤바가 있다면 DataGrid ScrollIntoView API가 마지막 아이템에서 올바로 작동하지 않습니다. 이 경우 마지막 아이템은 수평 스크롤바에 덮힐 것입니다. 다운 키를 눌러 이 API를 사용하여 마지막 아이템까지 내비게이션할 경우에도 같은 동작을 합니다. 워크어라운드는 HorizontalScrollBarVisibility를 Visible로 설정하는 것입니다. 수직 스크롤바는 해당하지 않습니다.

실버라이트 3가 웹을 통해 정식(RTW)으로 런칭되었어요. 그에 맞춰 See the Light라는 사이트가 열렸는데요, 한 번 들어가보세요^^

http://vepexp.microsoft.com/seethelight

See the Light는 일종의 온라인 컨퍼런스인데요, 작년에 DevDays 2008이 온라인에서 열린 것과 마찬가지 맥락이죠.

 
오프라인 컨퍼런스 분위기로 꾸며놓은 사이트…

 
뭐, 파트너사나 고객, 에이전시 별로 따로 ‘부스’가 마련 되어 있기도 하고요.

전체적으로 오프라인 느낌을 주려고 만들긴 했는데. 뭐랄까 2009년에 이 정도 디자인이라면 뭐어… 딱히 감흥이 있지는 않네요.^^;
그렇지만 키노트나 세션 동영상은 나름 볼만 하니 영어 울렁증을 참고 보는 것도…후우…

그나저나... 아오 이거 볼려고 퇴근도 안하고 있었는데 별 거 없었어 oTL
트위터 낚시주의 ㅠ.ㅜ

+ 보너스
silverlight.net도 실버라이트 3 출시에 맞춰 삼삼하게 변경되었네요.
어차피 메인 페이지가 중요한 사이트는 아니라...(음음)

그 외에도 전반적으로 꽤 파격적으로 변했는데요, 바뀌어서 그런건지 몰라도 썩 편리하지는 않네요.
설치 관련해서는 Microsoft Web Platform Installer란 넘으로 한 방에 설치를 해결한다!...인데 저도 아직 써보진 않았어요 -_-;
MIX09에서 본 Web Platform Installer는 꽤 멋졌던 것 같긴 하지만요.

여튼! See the Light!

드디어 드디어 맑은 고딕 말고도 굴림이나 돋움체를 깔끔하게 볼 수 있어요 ㅠ.ㅜ
백문이 불여일견.

위에서부터 각각 굴림체, 돋움체, 맑은 고딕체로 FontSize="6", 7,8,9,10,11,12,13,14,15,16,20,30 으로 설정한 화면을 캡쳐했어요.

아쉽게도 FontSource 속성은 여전히 설정하고 싶은 모든 Text에 각각 세팅해야 하는 불편이 있지만 혹시 폰트가 없더라도 기본 폰트가 충분한 품질을 뽑아주니 이제 폰트 배포 문제를 덜 고민해도 되겠어요 >_<
우와와와왕ㅋ구우우우우웃ㅋ!!

http://www.sharpgis.net/post/2009/07/09/Silverlight-3-Released.aspx 여기에 잘 포스팅 되어 있고, 저도 해봤어요.

1. MouseWheel이 드디어 지원되네요 :D
중요한 사실을 빼먹었네요. 이 MouseWheel 이벤트는 FullScreen에서도 지원된다는 사실! 우오오오옷!

2. 구동 환경이 Windows 7일 경우 멀티터치를 지원!! 우오오오옷!!!!!
근데 난 터치디바이스가 없을 뿐이고 ㅠ.ㅜ

3. 8bit 투명 PNG 지원. 아쉽게도 1,2,4bit는 지원 안한다는군요. ㅠ.ㅜ

4. Out-of-browser 기능을 프로젝트 속성에서 GUI로 조절 가능.

5. 기본 Behavior가 제공됨.
진짜 뭘 하든 꼭 필요한 것들만 모아둔 것 같아요!

사소한거지만 메인 페이지의 XAML에서 기본 배경색상이 투명으로 바뀌었고 블렌드를 위한 xmlns가 기본으로 정의 되었네요.

우와왕ㅋ굳ㅋ!!! 으아아아아 빨리 쓰고 싶다 >_<

드디어 나왔어요! 아직 공식 사이트인 silverlight.net에는 올라오지 않았지만 마이크로소프트 이반젤리스트 블로그를 중심으로 링크가 공개되었네요. 사족이지만 RTW란 Release To Web의 약자로 정식 버전이 맞아요^^
설치는 전과 마찬가지로 기존에 설치된 모든 실버라이트 관련 설치를 제거하고 다음 링크에서 새로 설치하면 돼요.

[개발자 필수]

• Silverlight 3 Tools for Visual Studio 2008 SP1

[디자이너 필수 + 개발자도 어지간하면 설치]

• Expression Blend 3 with SketchFlow

[End-user용 실버라이트 3]

• Silverlight 3

참고로 Blend 3 with SketchFlow는 일종의 RC버전으로 Final은 2주 정도 후에 나온다고 '유력한' 소식통이 전해왔어요.
자세한 리뷰는 나중에 하기로 하고 인증샷들만….

RTW 버전은 3.0.40624.0 즉, 6월 24일에 이미 최종 버전의 빌드가 되었다는 것을 알 수 있죠.

블렌드 3 설치 화면. 와~우 깔끔해졌어요~

블렌드 3 + 스케치플로우! 근데 저기서 춤 추는지 뭐 하는지 포즈 잡는 사람들은 뭔가…=_=

블렌드 3의 새 아이콘. 음… 판단 유보.

새 프로젝트 만들기. 좀 더 많은 종류의 프로젝트를 지원하면서 창도 늘어났네요. 당연한 얘기지만 실버라이트 2는 지원하지 않아요.

변경된 블렌드 3의 화면. Asset을 좀 더 빠르게 접근할 수 있도록 구성했군요. 그런데 모니터 해상도가 높아야 좋을 것 같네요. 해상도 작으면 오밀조밀해서 답답할 듯. 노트북 유저들 안습 ㅠ.ㅜ

드디어 공개된 스케치 플로우!! 우와아아앙 빨리 써보고 싶다아아아아 >_<

제가 또 일 끝까지 안하고 새로 일 벌리는 걸 좋아하죠. (…후우…)

MSDN POPCON에 ‘공도의 실버라이트 하기 좋은 날’이란 동영상 시리즈를 연재하기로 했어요. 매주 목요일날 업데이트 예정이고요, 내용은 그야말로 자유. 피드백 많이 주세요 :D

그 대망의 시리즈 제 1편: http://blogs.msdn.com/popcon/archive/2009/07/02/s-1.aspx

소개가 참 간드러지게 나왔는데요, 제가 원래 그 모양이니 모…ㅎㅎ

아래는 기각당한 초안이에요. 사실 이쪽이 더 마음에 들어서 남겨놉니다.^^

한 몇 개월 전부터 실버라이튼지 뭔지 하는 게 자꾸 사람들이 얘기는 하는데,
그까이꺼 대애애~충 훑어보니 뭐 별 어려워 보이는 것도 없고 해서 한 번 해 보는데,
팀장님이 '너 뭐하냐?' 물어보니 나름 깝쭉대 보지만?
아뿔사! 이건 뭐 내가 뭘 하는 지 설명을 못하겠네...
하는 당신을 위한 초고농도압축액기스추출 동영상!
액기스만 모았습니다. 짧습니다. 효과 (아마도)확실합니다!
(※부작용 발생 시 가까운 개발자나 디자이너에게 하소연하시기 바랍니다.)

P.S. 
손발은 오글오글.

[+ 동영상 다운로드]