WPF 추가 기능 개요

아티클
05/04/2023

.NET Framework에는 개발자가 추가 기능 확장성을 지원하는 애플리케이션을 만드는 데 사용할 수 있는 추가 기능 모델이 포함되어 있습니다. 이 추가 기능 모델을 사용하면 애플리케이션 기능과 통합하고 이 기능을 확장하는 추가 기능을 만들 수 있습니다. 일부 시나리오에서 애플리케이션은 추가 기능을 통해 제공되는 사용자 인터페이스도 표시해야 합니다. 이 토픽에서는 WPF가 .NET Framework 추가 기능 모델을 보강하여 이러한 시나리오를 지원하는 방법, 그 뒤에 있는 아키텍처, 이점 및 제한 사항을 보여줍니다.

필수 구성 요소

.NET Framework 추가 기능 모델에 대해 잘 알고 있어야 합니다. 자세한 내용은 추가 기능 및 확장성을 참조하세요.

추가 기능 개요

애플리케이션에서는 새 기능을 통합하기 위해 애플리케이션을 다시 컴파일하여 배포하는 복잡한 작업을 방지하도록 확장성 메커니즘을 구현하여 개발자(자사 및 타사)가 새 기능을 통합하는 다른 애플리케이션을 만들 수 있도록 합니다. 이러한 형식의 확장성을 지원하는 가장 일반적인 방법은 추가 기능(“추가 기능” 및 “플러그 인”이라고도 함)을 사용하는 것입니다. 추가 기능으로 확장성을 노출하는 실제 애플리케이션의 예에는 다음이 있습니다.

Internet Explorer 추가 기능.
Windows Media Player 플러그 인.
Visual Studio 추가 기능.

예를 들어, Windows Media Player 추가 기능 모델을 사용하면 타사 개발자가 다양한 방식으로 Windows Media Player를 확장하는 “플러그 인”을 구현할 수 있습니다. 이러한 방식에는 Windows Media Player에서 기본적으로 지원하지 않는 미디어 형식(예: DVD, MP3)의 디코더와 인코더, 오디오 효과 및 스킨이 포함됩니다. 모든 추가 기능 모델에 공통인 동작과 엔터티가 여러 개 있지만, 각 추가 기능 모델은 애플리케이션에 고유한 기능을 노출하도록 빌드되어 있습니다.

일반적인 추가 기능 확장성 솔루션의 세 가지 기본 엔터티는 계약, 추가 기능 및 호스트 애플리케이션입니다. 계약은 추가 기능이 다음 두 방법으로 호스트 애플리케이션과 통합하는 방법을 정의합니다.

추가 기능은 호스트 애플리케이션으로 구현된 기능과 통합됩니다.
호스트 애플리케이션에서 추가 기능과 통합될 기능을 노출합니다.

추가 기능을 사용하려면 호스트 애플리케이션에서 해당 기능을 찾아 런타임 시 로드해야 합니다. 따라서 추가 기능을 지원하는 애플리케이션에서는 다음과 같은 추가 작업을 담당합니다.

검색: 호스트 애플리케이션에서 지원하는 계약을 준수하는 추가 기능 찾기.
활성화: 추가 기능과의 통신을 로드, 실행 및 설정.
격리: 애플리케이션 도메인 또는 프로세스를 사용하여 추가 기능의 잠재적인 보안 및 실행 문제로부터 애플리케이션을 보호하는 격리 경계 설정.
통신: 추가 기능과 호스트 애플리케이션을 통해 메서드를 호출하고 데이터를 전달하여 격리 경계를 넘어 서로 통신할 수 있도록 허용.
수명 관리: 예측 가능하고 정리된 방식으로 애플리케이션 도메인과 프로세스를 로드 및 언로드( 애플리케이션 도메인 참조).
버전 관리: 호스트 애플리케이션과 추가 기능 중 하나의 새 버전이 만들어진 경우에도 계속 통신 가능한지 확인.

근본적으로, 강력한 추가 기능 모델을 개발하는 것은 쉬운 작업이 아닙니다. 따라서 .NET Framework에서는 추가 기능 모델을 빌드하는 인프라를 제공합니다.

참고

추가 기능에 대한 자세한 내용은 추가 기능 및 확장성을 참조하세요.

.NET Framework 추가 기능 모델 개요

System.AddIn 네임스페이스에서 찾을 수 있는 .NET Framework 추가 기능 모델에는 추가 기능 확장성을 간편하게 개발할 수 있도록 설계된 형식 세트가 포함되어 있습니다. .NET Framework 추가 기능 모델의 기본 단위는 호스트 애플리케이션과 추가 기능이 서로 통신하는 방법을 정의하는 계약입니다. 계약은 계약의 호스트-애플리케이션별 보기를 사용하여 호스트 애플리케이션에 노출됩니다. 마찬가지로 계약의 추가 기능별 보기가 추가 기능에 노출됩니다. 호스트 애플리케이션과 추가 기능이 계약의 각 보기 간에 통신할 수 있도록 어댑터가 사용됩니다. 계약, 보기 및 어댑터를 세그먼트라고 하며, 관련 세그먼트 집합이 파이프라인을 구성합니다. 파이프라인은 .NET Framework 추가 기능 모델이 검색, 활성화, 보안 격리, 실행 격리(애플리케이션 도메인과 프로세스를 모두 사용), 통신, 수명 관리 및 버전 관리를 지원하는 기반입니다.

개발자는 이러한 지원을 모두 활용하여 호스트 애플리케이션의 기능과 통합하는 추가 기능을 빌드할 수 있습니다. 그러나 일부 시나리오에서는 추가 기능이 제공하는 사용자 인터페이스를 호스트 애플리케이션에 표시해야 합니다. .NET Framework의 프레젠테이션 기술마다 사용자 인터페이스를 구현하는 자체 모델이 있으므로 .NET Framework 추가 기능 모델은 특정 프레젠테이션 기술을 지원하지 않습니다. 대신 WPF는 추가 기능에 대한 UI를 지원하여 .NET Framework 추가 기능 모델을 확장합니다.

WPF 추가 기능

WPF는 .NET Framework 추가 기능 모델과 함께 호스트 애플리케이션이 추가 기능의 사용자 인터페이스를 표시해야 하는 다양한 시나리오를 처리할 수 있습니다. 특히 이러한 시나리오는 다음과 같은 두 가지 프로그래밍 모델을 사용하여 WPF에서 해결됩니다.

추가 기능이 UI를 반환함. 추가 기능에서 계약에 정의된 대로 메서드 호출을 통해 호스트 애플리케이션에 UI를 반환합니다. 이 시나리오는 다음과 같은 경우에 사용됩니다.
- 추가 기능에서 반환하는 UI의 모양은 동적으로 생성되는 보고서와 같이 런타임 시에만 존재하는 조건 또는 데이터에 따라 달라집니다.
- 추가 기능에서 제공하는 서비스의 UI는 추가 기능을 사용할 수 있는 호스트 애플리케이션의 UI와 다릅니다.
- 추가 기능은 주로 호스트 애플리케이션의 서비스를 수행하며, UI를 사용하여 호스트 애플리케이션에 상태를 보고합니다.
추가 기능이 UI임. 추가 기능은 계약에 정의된 UI입니다. 이 시나리오는 다음과 같은 경우에 사용됩니다.
- 추가 기능에서 광고와 같이 표시되고 있지 않은 서비스를 제공하지 않는 경우.
- 추가 기능에서 제공하는 서비스의 UI가 계산기 또는 색 선택과 같은 추가 기능을 사용할 수 있는 모든 호스트 애플리케이션에 공통적으로 나타나는 경우.

이러한 시나리오에서는 호스트 애플리케이션과 추가 기능 애플리케이션 도메인 간에 UI 개체를 전달할 수 있어야 합니다. .NET Framework 추가 기능 모델은 원격을 이용하여 애플리케이션 도메인 간에 통신하므로, 두 도메인 간에 전달되는 개체는 원격으로 사용 가능해야 합니다.

원격으로 사용 가능한 개체는 다음 중 하나 이상을 수행하는 클래스의 인스턴스입니다.

파생 되는 MarshalByRefObject 클래스입니다.
ISerializable 인터페이스를 구현합니다.
에 SerializableAttribute 특성을 적용 합니다.

참고

원격으로 사용 가능한 .NET Framework 개체 만들기에 대한 자세한 내용은 개체를 원격으로 사용 가능하도록 설정을 참조하세요.

WPF UI 형식은 원격으로 사용할 수 없습니다. 문제점을 해결하기 위해 WPF에서는 .NET Framework 추가 기능 모델을 확장하여 추가 기능을 통해 만들어진 WPF UI를 호스트 애플리케이션에서 표시할 수 있게 합니다. 이 지원은 WPF에서 INativeHandleContract 인터페이스와 FrameworkElementAdapters 클래스에서 구현되는 두 가지 정적 메서드 ContractToViewAdapter 및 ViewToContractAdapter를 통해 제공됩니다. 상위 수준에서는 대략적으로 이러한 형식과 메서드가 다음과 같은 방식으로 사용됩니다.

WPF에서는 추가 기능에서 제공한 사용자 인터페이스가 셰이프, 컨트롤, 사용자 컨트롤, 레이아웃 패널 및 페이지 등의 FrameworkElement에서 직간접적으로 파생된 클래스여야 합니다.
계약에서 UI가 추가 기능과 호스트 애플리케이션 간에 전달된다고 선언할 때는 항상 FrameworkElement가 아닌 INativeHandleContract로 UI를 선언해야 합니다. INativeHandleContract는 추가 기능 UI의 원격으로 사용 가능한 표현이며 격리 경계 간에 전달할 수 있습니다.
FrameworkElement는 추가 기능의 애플리케이션 도메인에서 전달되기 전에 ViewToContractAdapter를 호출하여 INativeHandleContract로 패키징됩니다.
호스트 애플리케이션의 애플리케이션 도메인에 전달된 후에는 ContractToViewAdapter를 호출하여 INativeHandleContract를 FrameworkElement로 다시 패키징해야 합니다.

INativeHandleContract, ContractToViewAdapter 및 ViewToContractAdapter 사용 방법은 시나리오에 따라 달라집니다. 다음 섹션에서는 각 프로그래밍 모델의 자세한 내용을 제공합니다.

추가 기능이 사용자 인터페이스를 반환함

추가 기능이 호스트 애플리케이션에 UI를 반환하려면 다음이 필요합니다.

.NET Framework 추가 기능 및 확장성 문서에 설명된 대로 호스트 애플리케이션, 추가 기능 및 파이프라인을 만들어야 합니다.
계약에서 IContract를 구현해야 하며, UI를 반환하려면 계약에서 반환 값 형식이 INativeHandleContract인 메서드를 선언해야 합니다.
추가 기능과 호스트 애플리케이션 간에 전달되는 UI는 FrameworkElement에서 직간접적으로 파생되어야 합니다.
추가 기능에서 반환되는 UI는 격리 경계를 통과하기 전에 FrameworkElement에서 INativeHandleContract로 변환되어야 합니다.
반환되는 UI는 격리 경계를 통과한 후에 INativeHandleContract에서 FrameworkElement로 변환되어야 합니다.
호스트 애플리케이션은 반환된 FrameworkElement를 표시합니다.

UI를 반환하는 추가 기능을 구현하는 방법을 설명하는 예는 UI를 반환하는 추가 기능 만들기를 참조하세요.

추가 기능이 사용자 인터페이스임

추가 기능이 UI이면 다음이 필요합니다.

.NET Framework 추가 기능 및 확장성 문서에 설명된 대로 호스트 애플리케이션, 추가 기능 및 파이프라인을 만들어야 합니다.
추가 기능에 대한 계약 인터페이스에서 INativeHandleContract를 구현해야 합니다.
호스트 애플리케이션에 전달되는 추가 기능은 FrameworkElement에서 직간접적으로 파생되어야 합니다.
추가 기능은 격리 경계를 통과하기 전에 FrameworkElement에서 INativeHandleContract로 변환되어야 합니다.
추가 기능은 격리 경계를 통과한 후에 INativeHandleContract에서 FrameworkElement로 변환되어야 합니다.
호스트 애플리케이션은 반환된 FrameworkElement를 표시합니다.

UI인 추가 기능을 구현하는 방법을 설명하는 예는 UI인 추가 기능 만들기를 참조하세요.

추가 기능에서 여러 UI 반환

추가 기능에서 표시할 호스트 애플리케이션을 위해 여러 사용자 인터페이스를 제공하는 경우가 많습니다. 예를 들어 UI인 추가 기능이 호스트 애플리케이션에 상태 정보도 UI로 제공하는 경우가 있습니다. 이와 같은 추가 기능은 추가 기능이 사용자 인터페이스를 반환함 및 추가 기능이 사용자 인터페이스임 모델의 기술을 조합하여 구현할 수 있습니다.

추가 기능 및 XAML 브라우저 애플리케이션

지금까지의 예에서는 호스트 애플리케이션이 독립형 애플리케이션으로 설치되었습니다. 다음과 같은 추가 빌드 및 구현 요구 사항이 있긴 하지만 XBAP(XAML 브라우저 애플리케이션)에서도 추가 기능을 호스트할 수 있습니다.

클라이언트 컴퓨터에서 XBAP와 동일한 폴더의 ClickOnce 애플리케이션 캐시에 파이프라인(폴더 및 어셈블리) 및 추가 기능 어셈블리를 다운로드하도록 XBAP 애플리케이션 매니페스트를 특별히 구성해야 합니다.
추가 기능을 검색하고 로드하는 XBAP 코드가 XBAP의 ClickOnce 애플리케이션 캐시를 파이프라인과 추가 기능 위치로 사용해야 합니다.
추가 기능이 원본 사이트에 있는 느슨한 파일을 참조하는 경우 XBAP는 특수 보안 컨텍스트에 추가 기능을 로드해야 합니다. 추가 기능이 XBAP에 호스트된 경우 이러한 추가 기능은 호스트 애플리케이션의 원본 사이트에 있는 느슨한 파일만 참조할 수 있습니다.

이러한 작업은 다음 하위 섹션에 자세히 설명되어 있습니다.

ClickOnce 배포를 위한 파이프라인 및 추가 기능 구성

XBAP는 ClickOnce 배포 캐시의 안전한 폴더로 다운로드되고 이 폴더에서 실행됩니다. XBAP가 추가 기능을 호스트하려면 파이프라인과 추가 기능 어셈블리도 안전한 폴더에 다운로드해야 합니다. 이 작업을 수행하려면 다운로드할 파이프라인과 추가 기능 어셈블리를 모두 포함하도록 애플리케이션 매니페스트를 구성해야 합니다. Visual Studio에서 파이프라인 어셈블리를 탐지하려면 파이프라인과 추가 기능 어셈블리가 호스트 XBAP 프로젝트의 루트 폴더에 있어야 하지만, 이 작업은 Visual Studio에서 가장 쉽게 수행됩니다.

결과적으로 첫 번째 단계에서는 각 파이프라인 어셈블리의 빌드 출력과 추가 기능 어셈블리 프로젝트를 설정하여 XBAP 프로젝트의 루트에 파이프라인 및 추가 기능 어셈블리를 빌드합니다. 다음 표에서는 호스트 XBAP 프로젝트와 동일한 솔루션 및 루트 폴더에 있는 파이프라인 어셈블리 프로젝트와 추가 기능 어셈블리 프로젝트의 빌드 출력 경로를 보여줍니다.

표 1: XBAP로 호스팅되는 파이프라인 어셈블리의 출력 경로 빌드

파이프라인 어셈블리 프로젝트	빌드 출력 경로
계약	`..\HostXBAP\Contracts\`
추가 기능 뷰	`..\HostXBAP\AddInViews\`
추가 기능측 어댑터	`..\HostXBAP\AddInSideAdapters\`
호스트측 어댑터	`..\HostXBAP\HostSideAdapters\`
추가 기능	`..\HostXBAP\AddIns\WPFAddIn1`

다음 단계에서는 다음을 수행하여 파이프라인 어셈블리와 추가 기능 어셈블리를 Visual Studio의 XBAP 콘텐츠 파일로 지정합니다.

솔루션 탐색기에서 각 파이프라인 폴더를 마우스 오른쪽 단추로 클릭하고 프로젝트에 포함을 선택하여 프로젝트에 파이프라인 및 추가 기능 어셈블리 포함.
속성 창에서 각 파이프라인 어셈블리 및 추가 기능 어셈블리의 빌드 작업을 콘텐츠로 설정.

마지막 단계에서는 다운로드할 파이프라인 어셈블리 파일과 추가 기능 어셈블리 파일을 포함하도록 애플리케이션 매니페스트를 구성합니다. 파일은 XBAP 애플리케이션이 차지하는 ClickOnce 캐시의 폴더 루트에 있는 폴더에 있어야 합니다. 구성은 Visual Studio에서 다음을 수행하여 구현할 수 있습니다.

XBAP 프로젝트를 마우스 오른쪽 단추로 클릭하고, 속성, 게시를 순서대로 클릭한 다음, 애플리케이션 파일 단추를 클릭합니다.
애플리케이션 파일 대화 상자에서 각 파이프라인과 추가 기능 DLL의 게시 상태를 포함(자동)으로 설정하고 각 파이프라인과 추가 기능 DLL에 대해 그룹 다운로드을 (필수)로 설정합니다.

애플리케이션 기준 위치에서 파이프라인과 추가 기능 사용

파이프라인 및 추가 기능이 ClickOnce 배포용으로 구성되면 XBAP와 동일한 ClickOnce 캐시 폴더에 다운로드됩니다. XBAP의 파이프라인과 추가 기능을 사용하려면 XBAP 코드를 통해 애플리케이션 기준 위치에서 가져와야 합니다. 파이프라인과 추가 기능을 사용하기 위한 .NET Framework 추가 기능 모델의 다양한 형식과 멤버에서 이 시나리오를 위한 특수 지원을 제공합니다. 먼저 ApplicationBase 열거형 값을 통해 경로가 식별됩니다. 다음을 포함하는 파이프라인을 사용하기 위해 관련 추가 기능 멤버의 오버로드와 함께 이 값을 사용합니다.

호스트의 원본 사이트에 액세스

추가 기능이 원본 사이트의 파일을 참조할 수 있도록 호스트 애플리케이션과 동일한 수준의 보안 격리로 추가 기능을 로드해야 합니다. 이 보안 수준은 AddInSecurityLevel.Host 열거형 값을 통해 식별되며, 추가 기능이 활성화되면 Activate 메서드에 전달됩니다.

WPF 추가 기능 아키텍처

앞에서 살펴본 것처럼 WPF를 사용하면 .NET Framework 추가 기능에서 INativeHandleContract, ViewToContractAdapter 및 ContractToViewAdapter를 사용하여 사용자 인터페이스(FrameworkElement에서 직간접적으로 파생됨)를 구현할 수 있습니다. 그러면 호스트 애플리케이션은 호스트 애플리케이션의 UI에 표시되는 FrameworkElement를 반환됩니다.

간단한 UI 추가 기능 시나리오의 경우 개발자는 이 내용만 알면 충분합니다. 더 복잡한 시나리오의 경우, 특히 레이아웃, 리소스 및 데이터 바인딩과 같이 추가 WPF 서비스를 활용하려는 시나리오에서는 WPF가 UI를 지원하는 .NET Framework 추가 기능 모델을 확장하는 방법에 대해 자세히 알아야 이 방법의 이점과 한계를 이해할 수 있습니다.

근본적으로 WPF는 추가 기능에서 호스트 애플리케이션으로 UI를 전달하지 않습니다. 대신 WPF가 WPF 상호 운용성을 사용하여 UI에 대한 Win32 창 핸들을 전달합니다. 이와 같이 추가 기능의 UI가 호스트 애플리케이션에 전달되면 다음이 발생합니다.

추가 기능 쪽에서 WPF가 호스트 애플리케이션이 표시할 UI의 창 핸들을 획득합니다. 창 핸들은 HwndSource에서 파생되어 INativeHandleContract를 구현하는 내부 WPF 클래스를 통해 캡슐화됩니다. 이 클래스의 인스턴스는 ViewToContractAdapter를 통해 반환되며, 추가 기능의 애플리케이션 도메인에서 호스트 애플리케이션의 애플리케이션 도메인으로 마샬링됩니다.
호스트 애플리케이션 쪽에서 WPF는 HwndSource를 HwndHost에서 파생되어 INativeHandleContract를 사용하는 내부 WPF 클래스로 다시 패키징합니다. 이 클래스의 인스턴스는 ContractToViewAdapter를 통해 호스트 애플리케이션에 반환됩니다.

HwndHost는 창 핸들이 WPF 사용자 인터페이스에서 식별한 사용자 인터페이스를 표시하기 위해 존재합니다. 자세한 내용은 WPF 및 Win32 상호 운용성을 참조하세요.

요약하자면, INativeHandleContract, ViewToContractAdapter 및 ContractToViewAdapter는 WPF UI에 대한 창 핸들을 추가 기능에서 호스트 애플리케이션으로 전달하기 위해 존재하며, 창 핸들은 HwndHost를 통해 캡슐화되고 호스트 애플리케이션의 UI에 표시됩니다.

참고

호스트 애플리케이션이 HwndHost를 얻기 때문에, 호스트 애플리케이션은 ContractToViewAdapter에서 반환된 개체를 추가 기능을 통해 구현되는 형식(예: UserControl)으로 변환할 수 없습니다.

기본적으로 HwndHost에는 호스트 애플리케이션의 사용 방법에 영향을 미치는 제한이 있습니다. 그러나 WPF는 추가 기능 시나리오에 대한 여러 기능으로 HwndHost를 확장합니다. 이러한 이점과 한계는 아래에 설명되어 있습니다.

WPF 추가 기능의 이점

WPF 추가 기능 사용자 인터페이스는 HwndHost에서 파생되는 내부 클래스를 사용하여 호스트 애플리케이션에서 표시되므로, 이러한 사용자 인터페이스는 레이아웃, 렌더링, 데이터 바인딩, 스타일, 템플릿 및 리소스 등의 WPF UI 서비스에 관한 HwndHost의 기능에 의해 제한됩니다. 그러나 WPF는 다음을 포함하는 추가 기능으로 내부 HwndHost 하위 클래스를 보강합니다.

호스트 애플리케이션의 UI와 추가 기능의 UI 간 탭 이동. "추가 기능이 UI임" 프로그래밍 모델에서는 추가 기능 쪽 어댑터가 QueryContract를 재정의하여 추가 기능을 완전히 신뢰하는지 아니면 부분적으로 신뢰하는지에 상관없이 탭 이동을 사용하도록 설정해야 합니다.
호스트 애플리케이션 사용자 인터페이스에서 표시된 추가 기능 사용자 인터페이스의 접근성 요구 사항 준수.
여러 애플리케이션 도메인 시나리오에서 안전하게 실행되도록 WPF 애플리케이션 사용.
추가 기능이 보안 격리(즉, 부분 신뢰 보안 샌드박스) 상태에서 실행되는 경우 추가 기능 UI 창 핸들에 대한 무단 액세스 방지. ViewToContractAdapter를 호출하면 다음과 같은 보안이 보장됩니다.
- "추가 기능이 UI를 반환함" 프로그래밍 모델의 경우 격리 경계 간에 추가 기능 UI의 창 핸들을 전달하는 유일한 방법은 ViewToContractAdapter를 호출하는 것입니다.
- "추가 기능이 UI임" 프로그래밍 모델의 경우 호스트 쪽 어댑터에서 추가 기능 쪽 어댑터의 QueryContract 구현을 호출하는 것처럼, 추가 기능 쪽 어댑터에서 QueryContract를 재정의하고 ViewToContractAdapter를 호출해야 합니다(이전 예에서 설명한 대로).
여러 애플리케이션 도메인 실행 보호 제공. 애플리케이션 도메인의 한계로 인해 추가 기능 애플리케이션 도메인에서 throw된 처리되지 않은 예외가 발생하면 격리 경계가 있는 경우에도 전체 애플리케이션이 중단됩니다. 그러나 WPF와 .NET Framework 추가 기능 모델은 이 문제에 대한 간단한 해결 방법을 제공하고 애플리케이션 안정성을 향상시킵니다. 호스트 애플리케이션이 WPF 애플리케이션인 경우 UI를 표시하는 WPF 추가 기능은 애플리케이션 도메인이 실행되는 스레드의 Dispatcher를 만듭니다. WPF 추가 기능 Dispatcher의 UnhandledException 이벤트를 처리하여 애플리케이션 도메인에서 발생하는 처리되지 않은 모든 예외를 탐지할 수 있습니다. CurrentDispatcher 속성에서 Dispatcher를 가져올 수 있습니다.

WPF 추가 기능 한계

WPF가 HwndSource, HwndHost 및 창 핸들을 통해 기본 동작 외에 추가로 제공하는 이점도 있지만, 호스트 애플리케이션에서 표시되는 추가 기능의 한계도 있습니다.

호스트 애플리케이션에서 표시되는 추가 기능 사용자 인터페이스는 호스트 애플리케이션의 클리핑 동작을 준수하지 않습니다.
상호 운용성 시나리오의 에어스페이스 개념도 추가 기능에 적용됩니다(기술 영역 개요 참조).
리소스 상속, 데이터 바인딩 및 명령과 같은 호스트 애플리케이션의 UI 서비스를 추가 기능 사용자 인터페이스에서 자동으로 사용할 수 있는 것은 아닙니다. 추가 기능에 이러한 서비스를 제공하려면 파이프라인을 업데이트해야 합니다.
추가 기능 UI는 회전하거나, 배율을 조정하거나 기울일 수 없으며 변환을 통해 달리 변경할 수 없습니다(변환 개요 참조).
System.Drawing 네임스페이스에서 그리기 작업을 통해 렌더링된 추가 기능 사용자 인터페이스 내의 콘텐츠는 알파 혼합을 포함할 수 있습니다. 그러나 추가 기능 UI와 이를 포함하는 호스트 애플리케이션 UI는 모두 100% 불투명한 상태여야 합니다. 즉, 두 가지 모두 Opacity 속성이 1로 설정되어야 합니다.
추가 기능 UI를 포함하는 호스트 애플리케이션에 있는 창의 AllowsTransparency 속성이 true로 설정되어 있으면 추가 기능이 표시되지 않습니다. 이는 추가 기능 UI가 100% 불투명한 경우(즉, Opacity 속성의 값이 1임)에도 마찬가지입니다.
추가 기능 UI는 동일한 최상위 창의 다른 WPF 요소 위에 표시되어야 합니다.
추가 기능 UI의 어떤 부분도 VisualBrush를 사용하여 렌더링할 수 없습니다. 대신 추가 기능은 생성된 UI의 스냅샷을 사용하여 계약에 정의된 메서드를 통해 호스트 애플리케이션에 전달할 수 있는 비트맵을 만들 수 있습니다.
미디어 파일은 추가 기능 UI의 MediaElement에서 재생할 수 없습니다.
추가 기능 UI용으로 생성된 마우스 이벤트는 호스트 애플리케이션에서 수신되거나 발생되지 않으며, 호스트 애플리케이션 UI의 IsMouseOver 속성 값은 false입니다.
추가 기능 UI의 컨트롤 간에 포커스가 이동할 때 호스트 애플리케이션에서 GotFocus 및 LostFocus 이벤트를 수신하거나 발생시키지 않습니다.
호스트 애플리케이션에서 추가 기능 UI가 있는 부분은 인쇄 시 흰색으로 표시됩니다.
호스트 애플리케이션이 계속 실행되면 소유자 추가 기능을 언로드하기 전에 추가 기능 UI에서 만든 모든 디스패처(Dispatcher 참조)를 수동으로 종료해야 합니다. 계약에서 추가 기능이 언로드되기 전에 호스트 애플리케이션에서 추가 기능에 신호를 보낼 수 있도록 하는 메서드를 구현할 수 있으므로 이를 통해 추가 기능 UI가 디스패처를 종료할 수 있습니다.
추가 기능 UI가 InkCanvas이거나 InkCanvas를 포함하는 경우 추가 기능을 언로드할 수 없습니다.

성능 최적화

기본적으로 여러 애플리케이션 도메인을 사용할 경우 각 애플리케이션에 필요한 다양한 .NET Framework 어셈블리가 애플리케이션의 도메인에 모두 로드됩니다. 결과적으로 새 애플리케이션 도메인을 만들고 이 도메인의 애플리케이션을 시작하는 데 필요한 시간이 성능에 영향을 미칠 수 있습니다. 그러나 .NET Framework에서는 애플리케이션이 이미 로드된 경우 애플리케이션 도메인 전체에서 어셈블리를 공유하도록 애플리케이션에 지시하여 시작 시간을 줄이는 방법을 제공합니다. 진입점 메서드(Main)에 적용되어야 하는 LoaderOptimizationAttribute 특성을 사용하여 이 작업을 수행합니다. 이 경우, 애플리케이션 정의를 구현하는 코드만 사용해야 합니다(애플리케이션 관리 개요 참조).