XAP 사이즈, 압축하지 않겠는가?에서 얘기한 것 처럼 실버라이트 배포에 가장 중요한 점 중 하나는 바로 용량을 줄이는거죠. 그래서 배경화면이나 복잡한 디자인 등에 사용하는 이미지 파일은 프로젝트에 포함하지 않고 웹 서버쪽에 두는 것이 정석이에요. 그런데 이렇게 하면 개발자들이야 어차피 디자인을 보면서 작업하는 일이 많지 않아서 별로 문제가 안되지만, 디자이너들에겐 치명적인 문제가 되죠. 생각해보세요 배경화면을 보면서 디자인을 해야 하는데 이미지가 프로젝트에 없어서 보이지 않는다니!

요컨대, 다음과 같이 배경 이미지 한장을 보여주는 아주 간단한 샘플을 놓고 보죠.

image image

최초로 Images 폴더에 ducks.jpg를 추가하면 기본적으로 Build Action이 Resource가 되어 프로젝트를 빌드할 때 어셈블리에 리소스로 포함되고 이 이미지의 용량은 고스란히 XAP파일의 용량이 증가하는 결과로 이어지죠. 그렇다고 이미지를 삭제하고 웹서버에만 놓기엔 디자이너가 볼 수가 없어서 애매하죠.

이럴 때는 간단하게 해당 이미지 파일을 프로젝트에 그대로 놓은 상태에서 Build Action만 None으로 설정하세요.

image

이렇게 하면 비주얼 스튜디오의 디자인 뷰에는 나오지 않지만 블렌드로 열어보면…

image

잘 보이죠? 그러면서도 배포 사이즈는 이미지의 크기가 빠지게 되죠.

별거 없지만 첨부된 프로젝트를 보면서 참고하세요.


저작자 표시 동일 조건 변경 허락
신고
Posted by gongdo

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

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

우리는 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% 줄어드는 효과를 봤어요!

그러니…

저작자 표시 동일 조건 변경 허락
신고
Posted by gongdo

후우… 이건 뭐 챙피도 보통 챙피가 아니네요.
아무리 해봐도 퍼가기에서 애플리케이션이 동작을 안하길래 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이 있어야 해요. 물론 크로스 도메인 접근을 허용하지 않는다면 없어도 되겠죠.

참고 : http://timheuer.com/blog/archive/2008/04/06/silverlight-cross-domain-policy-file-snippet-intellisense.aspx
참고 : http://msdn.microsoft.com/en-us/library/cc197955(VS.95).aspx

 

크로스 도메인에서 실버라이트 실행시 스크립트 사용 허용

만약 실버라이트 애플리케이션이 크로스 도메인 영역에서 실행되고 있다면 기본적으로 스크립트 관련 기능이 사용 불가능 상태가 되는데요, 코드에 따라 다음의 설정들이 필요할 수 있어요.

  • AppManifest.xml에 설정 추가

모든 스크립트 관련 기능을 사용하려면 다음 그림과 같이 실버라이트 애플리케이션 프로젝트의 Properties 아이템을 확장해보면 AppManifest.xml 파일이 보이는데요, 여기에 아래의 설정을 추가해 줘야 해요.

 <Deployment xmlns="http://schemas.microsoft.com/client/2007/deployment"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    ExternalCallersFromCrossDomain="ScriptableOnly">
    <Deployment.Parts>
    </Deployment.Parts>
</Deployment>

  • enableHtmlAccess 설정

HtmlPage 클래스에서 호스트 HTML 페이지에 접근하려면 실버라이트 <object>태그의 <param>중에 다음의 설정을 추가해야 해요.

<param name="enableHtmlAccess" value="true" />

 

  • allowHtmlPopupWindow 설정

HtmlPage.PopupWindow 메서드를 사용하여 팝업을 할 필요가 있다면 실버라이트 <object>태그의 <param>중에 다음의 설정을 추가해야 해요.

<param name="allowHtmlPopupWindow" value="true" />

 

이런 설정들이 없을 때 나오는 증상은 대체로 화면이 허옇게 나오면서 아무것도 안나오거나, Alert이나 Popup이 안되거나, 휠 마우스가 안된다거나, Scriptable로 등록한 JavaScript 오브젝트와의 통신이 안된다거나 하는 현상이에요. 이런 현상을 겪더라도 쫄지마시고 순서대로 짚어 보세요.

저작자 표시 동일 조건 변경 허락
신고
Posted by gongdo

실버라이트 2 베타 2에서 가장 중요한 업데이트는 바로 Visual State Manager(이하 VSM)의 지원이었죠. VSM은 실버라이트가 강조하는 개발자와 디자이너의 분리된 협업을 더욱 잘 지원하게 해주고 개발 생산성을 정말 엄청나게 향상시켰죠. 저 역시 베타 1때의 커스텀 컨트롤 만들었던 것과 지금을 비교하면 그저 눈물이 나올 뿐이에요.

그렇지만 아직 커스텀 컨트롤도 해결해야 할 문제가 몇 가지 있는데요, 그 중에서 실제 개발 할 때 가장 귀찮고 시간이 많이 걸리는 부분은 바로 코드에서 정의된 템플릿 파트나 Visual State Group 및 Visual State의 이름을 가지고 generic.xaml에 기본 템플릿을 정의해야 한다는 점이에요. 개발자와 디자이너가 '이름'이라는 수단으로 일종의 계약을 맺는거죠. 일단 개념 상으로는 굉장히 좋아요. 먼저 컨트롤이라는 부품의 역할과 필요한 요소를 먼저 정의한 후 그 정의에 부합하는 한에서 디자인을 마음대로 할 수 있으니까요.

그러나, 개발자의 입장에서 '이름' 즉, 문자열에 기반한 계약 관계란 귀찮고 불안하기 짝이 없는 물건이에요. 만약 프로젝트를 진행하다가 모종의 이유로 인해 이 이름을 바꿔야할 필요가 있다면? 특정 이름이 더 이상 사용되지 않는다거나 새로 추가 되었다면? 게다가 이런 일은 상당히 자주 발생하죠. 이런 상황에서는 대체로 개발자 해당 '문자열'을 수작업으로 검색해서 바꿔주는게 일반적이에요. 문제는 이것이 실수를 만들기 매우 쉬운 프로세스라는 것이에요. 코드만으로 구성된 프로그램에서는 이런 일이 발생하지 않죠. 왜냐면 만약 코드에서 어떤 변수의 이름을 바꾸거나 삭제했다면 컴파일러가 곧바로 그 사실을 알려주고 에러 메시지를 뿜어내니까요. 하지만 단순한 문자열은 그 내용을 바꿨는지 어쨌는지 아니 심지어 그 문자열이 무슨 뜻인지 조차 컴파일러는 알지 못하니까요.

이 문제는 과거 실버라이트 1.1의 사용자 컨트롤에서도 있었던 문제였어요. 요컨대 XAML에서 x:Name 어트리뷰트로 선언한 이름을 코드 비하인드에서 일일이 수작업으로 그 엘리먼트의 참조를 만들어야만 했었죠.

이 문제는 실버라이트 2 베타 1이 나오면서 해결되었어요. 바로 사용자 컨트롤을 생성하면 XAML 마크업과 코드 비하인드가 쌍으로 만들어지고 XAML에서 x:Name 어트리뷰트로 선언된 이름은 Xaml precompiler에 의해 자동으로 동일한 이름을 갖는 멤버 변수로 선언이 되죠.

[UserControl이란 사용자 컨트롤을 만들면 위와 같이 XAML 마크업과 코드 비하인드 외에 컴파일러가 자동으로 만들어주는 g.cs파일이 생성됩니다.]

이렇게 되어 사용자 컨트롤을 만들 때의 귀찮은 단순 노가다가 사라졌을 뿐만 아니라 디자이너가 자유롭게 XAML상의 x:Name어트리뷰트를 바꿔도 개발자는 그 사실을 빠르게 캐치 할 수 있게 되었죠.

불행하게도, 아직 커스텀 컨트롤에는 이러한 매커니즘이 적용되어 있지 않아요. 디자이너는 단지 generic.xaml에 컨트롤의 스타일을 XAML로 정의할 뿐이고 개발자는 단지 코드 비하인드에서 필요한 요소들을 수작업으로 참조하게 되죠. 마치 1.1에서 했던 그것처럼요!

휴... 사설이 길었죠? 네 바로 이런 이유로 Custom Control Helper를 만들어봤어요.

이 툴을 만들면서 굉장히 삽질을 많이 했는데요, generic.xaml과 커스텀 컨트롤의 DefaultStyle 적용 매커니즘은 굉장히 복잡하기 때문이죠. 그 옛날 사용자 컨트롤처럼 단순히 XAML 코드에서 x:Name으로 선언된 어트리뷰트를 가진 모든 엘리먼트를 멤버 변수로 1:1 매칭하기만 하는 코드와는 차원이 달랐어요.

먼저 일반적인 Custom Control을 만들 때 가장 필수적인 요소들을 뽑아 보죠.

  • Custom Control은 DefaultStyle로 자기 자신의 Type을 사용합니다. 즉, generic.xaml에 선언된 Style중 TargetType이 자기 자신의 Type과 일치하는 스타일을 선택합니다.
  • Custom Control에 포함될 VisualStateGroup과 VisualState의 이름을 internal 멤버로 선언합니다. 이 때 Custom Control이 이미 부모 Custom Control로부터 상속받았을 가능성도 있으므로 부모 Custom Control이 해당 멤버를 이미 가지고 있을 경우는 제외합니다.
  • Custom Control에 포함될 Template Part를 리스트업 합니다. 일반적으로 Template Part의 대상으로는 Custom Control의 RootElement의 Resources에 포함된 Storyboard, 그리고 RootElement를 포함한 모든 하위 엘리먼트 중에서 x:Name 어트리뷰트를 선언한 엘리먼트를 의미하며 그 하위 엘리먼트들은 자기 자신의 Style 정의를 따로 갖을 수도 있으므로 이런 부분은 제외합니다. 마찬가지로 Template Part는 부모 Custom Control로부터 상속이 가능하므로 이미 선언 되었다면 제외합니다.
  • Custom Control을 위한 partial class 문자열을 생성합니다. 이 때 해당 클래스에 포함된 모든 Template Part들의 Type을 사용할 수 있도록 적절히 using 문도 넣어줘야 합니다.
  • Custom Control의 partial class는 InintializeTemplate이라는 멤버 메서드를 정의하고 그 메서드 내에서 스타일이 정의하고 있는 Tempalte Part들을 멤버 변수로 참조합니다. 이 때 해당 Template Part가 null이 아닌데 Type이 일치하지 않는 경우는 Assertion을 발생시키는 코드도 넣습니다.
  • Template Part 참조시의 Assertion 코드는 단순히 똑같은 코드를 반복할 수도 있고 클래스의 멤버 메서드로 묶어서 쓸 수도 있고 혹은 해당 클래스의 부모 클래스에서 이미 상속했을 수도 있습니다.
  • 컨트롤의 템플릿을 정의하는 XAML은 단순히 이름만 정의했을 뿐 실제로 코드에서 굳이 참조하여 사용할 필요가 없는 경우가 더 많습니다. 따라서 이름을 가지고 있는 엘리먼트 중에서 Template Part로 등록할 엘리먼트를 선택할 수 있어야 합니다.

...만들다 보니 진짜 복잡하네요...
여튼 이런 조건을 만족시키기 위해서는 XAML 만 분석해서는 답이 안나와요. 그래서 차선으로 선택한 것은 아예 컴파일 되어 있는 XAP 패키지를 직접 다운로드하고 그 안에 들어있는 어셈블리들을 동적으로 로드한 후 정확한 Type 분석 및 상속 관계를 파악하여 작업해야 했어요.

완벽한 형태가 되려면 Visual Studio 플러그 인으로 개발하면 더 좋겠지만 더 이상은 귀찮아서 손대기가 싫어요 -_-;

사용법은 간단하게 [Browse]를 클릭하여 XAP파일을 선택하세요. 주소창에 http://...처럼 웹에서 직접 선택하는 것도 가능해요.

선택된 XAP 파일내에 어셈블리들을 로드하고 각 어셈블리에 generic.xaml이 있을 경우만 리스트업하죠.

분석할 어셈블리를 선택하면 generic.xaml에서 스타일이 정의되어 있는 커스텀 컨트롤의 목록이 나오고 Options에서 Template Part를 참조하는 방법을 선택할 수 있으며 Required template parts에서 Template Part로 등록할 엘리먼트의 이름을 체크하면 돼요.

왼쪽 아래의 TextBox는 원본 generic.xaml 코드이고 오른쪽 TextBox는 현재 선택된 커스텀 컨트롤에 대한 partial class 코드에요. 이 코드를 복사해서 프로젝트에 새 파일로 추가하고 해당 클래스의 선언을 partial 로 변경해준 후 OnApplyTemplate 오버라이드 구현에서 InitializeTemplate()을 호출하면 돼요.

사실 이 샘플은 그냥 제가 쓸려고 만든거라 아마 별 도움은 안되겠지만, 혹시 XAP 파일에서 어셈블리를 얻어와서 분석하는데 관심이 있다면 소스코드가 도움이 될 거에요.


없을 걸 알지만 피드백 기대합니다. :)

신고
Posted by gongdo

항상 새로운 기술을 접할 때에는 그 기술에 대한 전반적인 아키텍처와 구성, 특히 Overview를 읽어보는 것이 많은 도움이 되는 것 같아요. 저도 오랫만에 WPF스타일을 접해서 많은 혼란을 겪고 있어서 생각도 정리할 겸 MSDN 토픽 하나를 날림 번역해봤어요.

원본 글 : http://msdn2.microsoft.com/en-us/library/cc221365(vs.95).aspx

실버라이트는 애플리케이션 개발자에게 브라우저에서 실행되는 웹 애플리케이션을 개발하고 배포할 수 있게 하는 기술입니다. 이 토픽은 실버라이트 애플리케이션의 개발, 실버라이트 애플리케이션 및 라이브러리 어셈블리의 구현, 리소스 파일의 조직, 애플리케이션 서비스의 사용, 그리고 실버라이트가 제공하는 유연한 패키징 옵션을 다양한 개발 시나리오에 공급하는 것에 대한 개요를 제공합니다. 이 토픽은 클라이언트 측 캐싱에 관한 간단한 논의로 마무리합니다.

이 토픽은 다음과 같은 섹션을 포함합니다.

  • 애플리케이션 클래스, 어셈블리 및 패키지
  • 라이브러리 어셈블리
  • 리소스 파일
  • 패키지에 포함 vs 필요할 때 요청
  • 애플리케이션 서비스
  • 실버라이트 애플리케이션
  • 관련 토픽

실버라이트 애플리케이션에 관련된 정보는 Deployment (Silverlight 2)를 보세요.


애플리케이션 클래스, 어셈블리 및 패키지

각 실버라이트 애플리케이션은 반드시 실버라이트 플러그인 컨트롤에 의해 다운로드 된 이후 구동start up시키기 위한 최소한의 기능이라도 구현해야만 합니다. 만약 각 실버라이트 애플리케이션이 구동 기능을 각자의 방법으로 구현했다면 실버라이트 플러그인 컨트롤이 가능한 모든 구현을 공급하는 것은 불가능할 것입니다. 실버라이트 플러그인 컨트롤은 각 실버라이트 애플리케이션이 엔트리 포인트entry point라고 하는 잘 알려진 방법을 명시적으로 구동 기능을 구현하기를 기대합니다. 실버라이트 애플리케이션에서 엔트리 포인트는 다음의 항목들의 조합이 됩니다.

  • 애플리케이션 클래스application class라고 하는 Application에서 파생된 클래스.
  • 애플리케이션 어셈블리application assembly라고 하는 이 클래스를 구현하는 어셈블리.
  • 애플리케이션 클래스와 엔트리 포인트를 이루는 애플리케이션 어셈블리를 식별하는 메타 데이터.

최소한의 실행 가능한 실버라이트 애플리케이션은 애플리케이션 어셈블리(애플리케이션 클래스를 가지는)와 엔트리 포인트 메타데이터 모두를 포함하는 .xap 파일 확장자로 압축된 ZIP 파일입니다. .xap 파일은 애플리케이션 패키지로 알려져 있고 실버라이트 플러그인 컨트롤이 다운로드하고 실행하는 파일입니다.

애플리케이션 클래스와 애플리케이션 어셈블리를 어떻게 구현하고 패키지에 대한 자세한 정보는 Developing a Silverlight Application Assembly를 보세요.


라이브러리 어셈블리

애플리케이션 어셈블리가 일반적으로 실버라이트 애플리케이션의 메인 UI와 기능을 이루고 통합하는 반면, 라이브러리 어셈블리library assembly는 추가적인 애플리케이션 UI와 기능을 캡슐화할 수 있습니다. 라이브러리 어셈블리들은 애플리케이션을 더 쪼개진 요소로 분해하여 복잡도를 낮추고 다수의 애플리케이션에 걸쳐 UI와 기능을 공유하는 등의 다양한 이유로 사용됩니다.

실버라이트 라이브러리 어셈블리에 대한 자세한 정보는 Developing a Silverlight Library Assembly를 보세요.


리소스 파일

애플리케이션과 라이브러리 어셈블리가 실버라이트 애플리케이션의 실행가능한 형태를 캡슐화하는 한편, 실버라이트 애플리케이션은 오디오, 비디오, 이미지, XML 및 XAML 파일과 같은 비실행 데이터를 포함할 수도 있습니다. 이런 유형의 파일들은 집합적인 리소스 파일로 알려져 있고 다양한 방법으로 패키징될 수 있습니다.

리소스 파일의 작동에 대한 자세한 정보는 Application Services를 보세요.


패키지에 포함 vs 필요할 때 요청

실버라이트 애플리케이션은 하나의 애플리케이션 어셈블리, 0개 혹은 한개 이상의 라이브러리 어셈블리 및 0개 혹은 한개 이상의 리소스 파일의 덩어리입니다. 이 다양한 파일들이 어떻게 패키지되느냐는 가장 짧은 시간 동안 유저에게 올바른 기능을 제공하는 것의 평가에 달려있습니다.

앞서 얘기한 것처럼, 실버라이트 애플리케이션은 반드시 애플리케이션 클래스를 구현하는 애플리케이션 어셈블리를 가진 애플리케이션 패키지를 포함해야 합니다. 추가적으로 애플리케이션 패키지는 라이브러리 어셈블리와 리소스 파일을 포함할 수 있습니다. 애플리케이션 패키지는 실버라이트 애플리케이션을 시작하기 위해 실버라이트 플러그인 컨트롤이 다운로드하기 때문에 애플리케이션 패키지는 가급적 빠르게 다운로드 될 수 있도록 가능한 작아야 합니다. 따라서 애플리케이션의 UI와 기능을 구성하여 그것 없이는 애플리케이션의 실행이 불가능한 파일들만이 포함되어야 합니다. 예를 들어, 스프레드시트 애플리케이션과 같이 데이터를 입력하고 보여주는 기능만을 요구하는 애플리케이션을 생각해 봅시다. 애플리케이션 패키지에 포함되어 있는, 애플리케이션 어셈블리와 라이브러리 어셈블리와 리소스 파일을 포함하는 파일들이 바로 패키지에 포함된in-package 파일을 말합니다.

스프레드시트 애플리케이션은 또한 바 차트나 파이 차트처럼 언제나 사용되지는 않는 다른 데이터 뷰를 제공할 것입니다. 실버라이트 애플리케이션의 관점에 의하면, 애플리케이션의 선택적인 UI와 기능을 구성하는 파일들은 필요할 때 다운로드 될 수 있고 이것이 필요할 때 요청on-demand되는 파일입니다.

올바르게 구성된 스프레드는 사용자들이 애플리케이션 UI와 기능에 필요한 최소한의 초기 다운로드 비용이 들도록 하고 그들이 선택적인 기능을 원할 때만 추가적인 다운로드 비용이 들도록 합니다.

패키지에 포함하거나 필요할 때 요청되는 라이브러리 어셈블리를 어떻게 배포하는지에 대한 자세한 정보는 Developing a Silverlight Library Assembly를 보세요. 리소스 파일의 경우는 Application Services를 보세요.


애플리케이션 서비스

Application은 또한 일반적으로 애플리케이션에서 요구하는 몇 가지 애플리케이션 서비스를 제공합니다. 가장 중요한 서비스는 애플리케이션이 시작될 때 보여줄 사용자 인터페이스(UI)를 지정하는 기능입니다. 추가적인 서비스는 라이프타임 관리, 애플리케이션 스코프 리소스와 속성, 초기화 파라미터에 접근하기 및 처리되지 않은 예외 검출과 응답입니다.

Application 클래스에 의해 제공되는 서비스에 대한 자세한 정보는 Application Services를 보세요.


실버라이트 애플리케이션

지금까지 애플리케이션 클래스, 애플리케이션 어셈블리, 애플리케이션 패키지, 애플리케이션 서비스, 라이브러리 어셈블리 및 리소스 파일의 개요를 살펴봤습니다. 또한 실버라이트가 유연한 패키징과 배포를 위해 어떻게 in-package와 on-demand 파일을 지원하는지도 살펴봤습니다. 각 실버라이트 애플리케이션은 다음과 같은 방법으로 표현되는 하나 혹은 모든 것들의 조합입니다.

  • [필수] - 애플리케이션 어셈블리로 구현되고 애플리케이션 패키지에 포함된 애플리케이션 클래스와 서비스.
  • [선택] - 필수적인 애플리케이션 UI와 기능을 캡슐화하고 애플리케이션 패키지에 포함되는 in-package 라이브러리 어셈블리와 리소스 파일.
  • [선택] - 선택적인 UI와 기능을 캡슐화하고 애플리케이션 패키지와 나란히 포함되는 on-demand 라이브러리 어셈블리와 리소스 파일.

실버라이트 애플리케이션의 가능한 조합은 다음 그림에서 설명하고 있습니다.


관련 토픽

컨셉
Developing a Silverlight Application Assembly
Developing a Silverlight Library Assembly
Resource Files
Application Services
Deployment (Silverlight 2)

참조
Application 클래스

신고
Posted by gongdo


티스토리 툴바