CLR: Designing Managed AddIns For Reliability, Security, And Versioning

CLR: Designing Managed AddIns For Reliability, Security, And Versioning Jim Miller, Architect, CLRThomas Quinn, Architect, VSTA FUN309 Microsoft Corporation

Agenda • AddIn Models • Object-Oriented AddIn Models • Demo (hand-built) • Visual Studio Tools for Applications (VSTA) • Demo (VSTA) • Prescriptive Guidance

Terminology • “Components” • Hosts and their components are tested together • Testing is against known versions, and later “mix and match” is not permitted • Components may (or may not) be dynamically discovered and loaded • “AddIns” • New versions of a host need not test against all existing addins (example: Microsoft Word) • New versions of an addin need nottest against all existing hosts (example: Windows Media Player) • AddIns are always dynamically discovered and loaded

AddIns: The Problems Host Object AddIn Object • Deploying the addin • Discovering the addin and its implementation code • Qualifyingthe addin to ensure it meets the constraints • Activating an instance of the addin object • Creating the instance in the appropriate environment • Building the communication path • Calling methods, throwing exceptions, calling callbacks, raising events, etc. A complete addin model, like COM, supplies a solution to all four of these problems

AddIns: Tightly Coupled Host App Domain Host Object AddIn Object • Problems: • Can’t unload the addin • Same CLR and Framework for host and addin • Same security domain for host and addin • If host is updated, addin must be recompiled to avoid type mismatches (and vice-versa)

AddIns: Isolation Boundary AddIn App Domain Host App Domain Host Object AddIn Object • Problems: • Can’t unload the addin • Same CLR and Framework for host and addin • Same security domain for host and addin • If host is updated, addin must be recompiled to avoid type mismatches (and vice-versa) • New Problems: • Requires serialization or marshal-by-ref objects • Performance penalty

AddIns: Version-Resilient AddIn App Domain Host App Domain Host Object AddIn Object Stable Contract Proxy Adaptor • Problems: • Can’t unload the addin • Same CLR and Framework for host and addin • Same security domain for host and addin • If host is updated, addin must be recompiled to avoid type mismatches (and vice-versa) • New Problems: • Requires serialization or marshal-by-ref objects • Performance penalty • Design of a stable contract • Implementation of Proxy and Adaptor

, but can’t use process- local resources AddIns: Cross-Process AddIn Process Host Process Host Object AddIn Object Stable Contract Proxy Adaptor • Problems: • Can’t unload the addin • Same CLR and Framework for host and addin • Same security domain for host and addin • If host is updated, addin must be recompiled to avoid type mismatches (and vice-versa) • New Problems: • Requires serialization or marshal-by-ref objects • Performance penalty • Design of a stable contract • Implementation of Proxy and Adaptor • Threading and re-entrancy • Hosting of addin process and lifetime issues even higher

Microsoft Recommendation • Tightly Coupled Model • For components (“tested together”) • Some dynamic language scenarios (eg. SmallTalk environment) • Isolated Model is for components only • Version-Resilient Model in-process • Best model for most addins • Cross-Process Model • When addin might require a later version of the CLR or Framework • When OS isolation is required (addin calls unsafe code) • To avoid process resource exhaustion (32-bit address space) • Cross-Machine (not supported by addin model) • Use Service-Oriented architecture, not Object-Oriented model

Status (Office 12 Timeframe) • COM provides a complete solution • You know its advantages and its limitations • One limitation is the lack of an object-oriented model • Another limitation is that in-process COM activation isn’t isolated • VSTA provides a more secure solution • Provides an object-oriented model, for both managed and unmanaged code • Provides isolation via an App Domain or a process • System.AddIn and System.AddIn.Contract will become part of the platform, shipping first in VSTA • Deployment, discovery, and qualification fundamentals are included in V1 • Future direction • We intend to integrate VSTA (for addins) and WCF (for services) • Deployment, discovery, and qualification will be more fully addressed after Windows Vista/Office-12

Version-Resilient ArchitectureThe Communication Pipeline • Host defines an object model it will use to call methods in the addin • The host addin view (HAV), an interface or abstract class • AddIn implements an object model • The addin base, typically an abstract base class • A stable contract connects the two object models • The stable contract is an interface which never versions • The host calls a host-to-contract adaptor (HCA) that maps the host’s object model to the stable contract • The contract is implemented by a contract-to-addin adaptor (CAA) that maps the stable contract to the addin’s object model • If the addin needs to call methods on the host, a reverse pipeline is required

Sample: Host Creates AddIn Calls infrastructure tocreate AD, construct pipeline, load addin, and activate it Host AddIn View (HAV) from HostSDK MenuAddIn MyAddIn = MenuAddIn.Load(manifest); MyAddIn.Show(); Specifies assemblyand type name HAV: Host AddIn View HCA: Host-to-Contract Adaptor CAA: Contract-to-AddIn Adaptor

AddIn-Side Objects contract HAV AddInBase AddIn HCA CAA Infrastructure created AddIn Model (supplied by host or addin) Abstract base class/interface Reference passed to constructor HostAddIn Communication Host-Side Objects Host HAV: Host AddIn View HCA: Host-to-Contract Adaptor CAA: Contract-to-AddIn Adaptor

contract AddInBase AddIn CAA Infrastructure created contract HAV CAA HCA Bidirectional Communication Host-Side Objects AddIn-Side Objects Host HAV HCA HAV: Host AddIn View HCA: Host-to-Contract Adaptor CAA: Contract-to-AddIn Adaptor Abstract base class/interface Reference passed to constructor

Host V1.0 HAVV1.0 HCAV1.0 Versioning In Action: V1 Host-Side Objects AddIn-Side Objects AddInBaseV1.0 AddInV1.0 contract CAA V1.0 Infrastructure created HAV: Host AddIn View HCA: Host-to-Contract Adaptor CAA: Contract-to-AddIn Adaptor

contract Host V1.0 Host V2.0 HAVV2.0 HAVV1.0 CAA V1.0 V2 Versioning In Action: V1 Host-Side Objects AddIn-Side Objects AddInBaseV1.0 AddInV1.0 HCAV1.0 HCAV2.0 Infrastructure created HAV: Host AddIn View HCA: Host-to-Contract Adaptor CAA: Contract-to-AddIn Adaptor

contract AddInBase AddIn CAA Infrastructure created HAV: MenuAddIn HCA: MenuContractAdapator Contract: IMenuItemContract CAA: MenuBase Demo Code as AddIn Model Host-Side Objects AddIn-Side Objects Host HAV HCA Host-to-AddIn Pipeline HAV: Host AddIn View HCA: Host-to-Contract Adaptor CAA: Contract-to-AddIn Adaptor

Host AD AddIn AD Passed to constructor for Dance Created and called on demand AddIn calls V2 Demo Explanation GetMenuItems, GetName, etc. WinFormsControl Host Code MenuAddIn addin (a Dance.v1) HostShape addin (a RemotelyControlledShape) GetBackColor, GetLabel, etc.

Host-Side Objects AddIn-Side Objects Host HAV HCA contract AddInBase AddIn CAA contract HAV Infrastructure created CAA HCA HAV: MenuAddIn HCA: MenuContractAdapator Contract: IMenuItemContract CAA: MenuBase Demo Code As AddIn Model Host-to-AddIn Pipeline AddIn-to-Host Pipeline Contract: IShapeContract CAA: RemotelyControlledShape HCA: ShapeContractAdaptor HAV: HostShape

Visual Studio Tools For Applications: SDK • ProxyGen • Tool to generate proxy classes from metadata or COM TypeLib • Generates source code and XML “tweak” file • Uses built-in late-binding contracts – no new contracts necessary • However, allows iteration on code, and custom contracts • Samples • Projects and Wizards • Full Documentation

Design It Right From V1 • Think in terms of a host, an SDK, and an addin • A very useful design discipline even for components • Design the contract(s) you need carefully • This isn’t a place to skimp! • These interfaces “live forever, unchanged” • All types used are either contracts or base types (integers, string, etc.) • Strongly consider deriving from IContract • Keep it clean: separate the five parts • Separating the HCA and CAA may seem like wasted effort in V1, but without them you can’t move on to V2! • Host should never reference a contract, HCA, or CAA directly (just the HAV) • AddIn should never reference a contract, HAV, or HCA directly (just implement the CAA)

DiscoveryFinding AddIns for this Host What Makes a Complete AddIn Model • Host specifies the addin view (HAV) • System locates all candidate addins • System searches all possible pipelines • Each addin has a name, description and constraints What’s Needed to Implement It • Registration of the contracts and adaptors What To Do Today • Discovery based on directory location: host specifies a directory where addins must be stored • Use a manifest to allow the actual code file to be stored in the GAC (for shared components) or the application-specific directory as needed

QualificationNegotiating Constraints What Makes a Complete AddIn Model • Attributes on the addin and the HAV specify restrictions on use (isolation boundary, security, etc.) • System chooses settings acceptable to both host and addin What’s Needed to Implement It • Standard attributes and constraints • Registration of addins and their adaptors What To Do Today • AddIn manifest specifies constraints • Host manually inspects manifest, validates it, and rejects it if unacceptable

ActivationCreating an Instance of the AddIn What Makes a Complete AddIn Model • System activates addin in an environment that satisfies the constraints of both the host and the addin What’s Needed to Implement It • Process hosting infrastructure • Lifetime management What To Do Today • Use VSTA loader and tools

CLR: Designing Managed AddIns For Reliability, Security, And Versioning