Visão Geral dos Suplementos do Windows Presentation Foundation

Artigo
08/25/2010

O .NET Framework inclui um modelo de suplementos que desenvolvedores podem utilizar para criar aplicativos que suportam extensibilidade a suplementos. Esse modelo de suplementos permite a criação de suplementos que integram e estendem a funcionalidade do aplicativo. Em alguns cenários, aplicativos também devem exibir UIs que são fornecidos por suplementos. Este tópico mostra como WPF aumenta o .NET Framework modelo de suplementos para habilitar estes cenários, a arquitetura por detrás, seus benefícios e suas limitações.

Este tópico contém as seguintes seções.

Pré-requisitos
Exemplos
Visão geral dos Suplementos
Visão Geral do Modelo de Suplementos do .NET Framework
Suplementos WPF
Suplemento retorna uma Interface de Usuário
Suplemento é uma Interface de Usuário
Retornando Múltiplas UIs de um Suplemento
Suplementos e Aplicativos de Navegação XAML.
Arquitetura de Suplemento WPF
Benefícios de suplementos WPF
Limitações de suplementos WPF
Otimização de Desempenho
Tópicos relacionados

Pré-requisitos

Familiaridade com o .NET Frameworkmodelo de suplementos é necessária. Para obter mais informações, consulte Adicionar-em Visão geral.

Exemplos

Este tópico utiliza as seguintes exemplos para demonstrar como WPF estende o .NET Framework modelo de suplementos.

Adicionar-Em retorna um exemplo de interface do usuário, que é abrangido noSuplemento retorna a interface de usuário seção deste tópico.
Adicionar-Em É um exemplo de interface do usuário, que é abrangido no Suplemento é uma Interface de Usuário seção deste tópico.
Adicionar-Com vários exemplo de interfaces de usuário, que é abrangido no Retornando múltiplas UIs de um suplemento seção deste tópico.
Adicionar-Com um XBAP como o exemplo de aplicativo de host, que é abrangido no Suplementos e Aplicativos de navegação XAML seção deste tópico.

Visão geral dos Suplementos

De modo a evitar as complexidades da recompilação e reimplantação de aplicativos para incorporar nova funcionalidade, os aplicativos implementam mecanismos de extensibilidade que permitem desenvolvedores (os próprios ou terceiros) criar outros aplicativos que os integrem. O modo mais comum de suporte a esse tipo de extensibilidade é através do uso de suplementos (também conhecidos como "complementos" e "plug-ins"). Exemplos de aplicativos reais que expõem extensibilidade com suplementos incluem:

Complementos do Internet Explorer.
Plug-ins do Windows Media Player.
Suplementos do Visual Studio.

Por exemplo, o modelo de suplementos do Windows Media Player permite que desenvolvedores secundários implementem "plug-ins" que estendam o Windows Media Player de várias maneiras, incluindo a criação de decodificadores e codificadores para formatos de mídia que não são suportados originalmente pelo Windows Media Player (por exemplo, DVD, MP3), efeitos de áudio e skins. Cada modelo de suplementos é construído para expor a funcionalidade que é exclusiva do aplicativo, embora haja várias entidades e comportamentos comuns a todos os modelos de suplementos.

As três principais entidades das típicas soluções de extensibilidade de suplementos são contratos, suplementos e aplicativos host. Contratos definem como os suplementos se integram com os aplicativos host de duas formas:

Os suplementos se integram com uma funcionalidade que é implementada por aplicativos host.
Os aplicativos host expõem funcionalidade para que os suplementos se integrem.

Para que os suplementos sejam usados, os aplicativos host precisam localizá-los e carregá-los em tempo de execução. Consequentemente, os aplicativos que dão suporte a suplementos possuem as seguintes responsabilidades adicionais:

Detecção: Localizando suplementos aderem aos contratos de suporte a aplicativos de host.
Ativação: Carregando, execução e estabelecer comunicação com os suplementos.
Isolamento: Usando um aplicativo domínios ou processos para estabelecer limites de isolamento que protegem aplicativo s de possíveis problemas de segurança e a execução de suplementos.
Comunicação: Permitindo que os suplementos e hospedar aplicativos se comuniquem entre si através de limites de isolamento chamando métodos e passagem de dados.
Gerenciamento de tempo de vida: Carregar e descarregar domínios de aplicativos e processos de forma limpa e previsível (consulte Visão Geral Sobre Domínios de Aplicativos).
Controle de versão: Garantir que aplicativos de host e os suplementos podem se ainda comunicar quando novas versões de um são criadas.

Definitivamente, desenvolver um modelo de suplementos robusto não é uma tarefa trivial. Por essa razão, o .NET Framework fornece uma infraestrutura para a construção de modelos de suplementos.

Observação:
Para obter informações mais detalhadas sobre add-ins, consulte Adicionar-em Visão geral.

Visão Geral do Modelo de Suplementos do .NET Framework

O .NET Framework modelo de suplementos, encontrado no namespace do System.AddIn , contém um conjunto de tipos projetados para simplificar o desenvolvimento da extensibilidade de suplementos. A unidade fundamental do .NET Framework modelo de suplementos é o contrato, que define como um aplicativo host e um suplemento se comunicam. Um contrato é exposto a um aplicativo host utilizando uma exibição do contrato específica do aplicativo host. Da mesma forma, um específicos de add modo de exibição do contrato é exposta ao suplemento. An adaptador é usada para permitir que um host de aplicativo e um suplemento para se comunicar entre seus respectivos modos de exibição do contrato. Contratos, exibições e adaptadores são referidos como segmentos, e um conjunto de segmentos relacionados constitui uma pipeline. Pipelines são a base na qual o .NET Framework modelo de suplementos oferece suporte a descobertas, ativação, isolamento de segurança, isolamento de execução (usando tanto domínios de aplicativos quanto processos), comunicação, administração vitalícia e controle de versão.

A soma desses suportes permite que desenvolvedores construam suplementos que se integram com a funcionalidade de um aplicativo host. No entanto, alguns cenários exigem que os aplicativos host exibam UIs fornecidos pelos suplementos. Já que cada tecnologia de apresentação no .NET Framework possui seu modelo de implementação próprio UIs, o .NET Framework modelo de suplementos não oferece suporte a nenhuma tecnologia de apresentação específica. Ao invés disso, WPF estende o .NET Framework modelo de suplementos com UI suporte para suplementos.

Suplementos WPF

WPF, conjuntamente com o .NET Framework modelo de suplementos, permite o endereçamento de vários cenários que exigem que os aplicativos host exibam UIs de suplementos. Particularmente, estes cenários são endereçados pelo WPF com os dois seguintes modelos de programação:

O suplemento retorna uma UI. Um suplemento retorna uma UI ao aplicativo host via uma chamada de método, como definida pelo contrato. Este cenário é utilizado nos seguintes casos:
- A aparência de uma UI que é retornada por um suplemento é dependente de tanto dados como de condições que existem somente em tempo de execução, como relatórios gerados dinamicamente.
- O UI para serviços fornecidos por um suplemento difere do UI dos aplicativos host que podem usar o suplemento.
- O suplemento executa principalmente um serviço para o aplicativo host e relata o andamento ao aplicativo host com um UI.
O suplemento é uma UI. Um suplemento é uma UI, como definida pelo contrato. Este cenário é utilizado nos seguintes casos:
- Um suplemento não fornece serviços que não sejam de exibição, como um anúncio.
- O UI para serviços fornecidos por um suplemento é comum a todos os aplicativos host que podem utilizar esse suplemento, como uma calculadora ou um selecionador de cores.

Esses cenários exigem que objetos UI possam ser transmitidos entre aplicativos host e domínios de suplementos de aplicativos. Como o .NET Framework modelo de suplementos se baseia em arquitetura de comunicação remota para a comunicação entre domínios de aplicativos, os objetos transmitidos por eles devem ser remotos.

Um objeto remoto é um exemplo de classe que realiza um ou mais dos seguintes:

Deriva da classe MarshalByRefObject.
Implementa a interface ISerializable.
Possui o atributo SerializableAttribute aplicado.

Observação:
Para obter mais informações sobre a criação de remoto .NET Framework objetos, consulte Making Remotable Objetos. Para uma visão geral de arquitetura de comunicação remota, consulte Visão geral sobre a arquitetura de comunicação remota do .NET Framework.

The WPF UI types are not remotable. To solve the problem, WPF extends the .NET Framework add-in model to enable WPF UI created by add-ins to be displayed from host applications. Esse suporte é fornecido por WPF por dois tipos: the INativeHandleContract interface e dois métodos estático implementados pela FrameworkElementAdapters classe: ContractToViewAdapter e ViewToContractAdapter. Num alto nível, esses tipos e métodos são utilizados da seguinte maneira:

WPF exige que UIs fornecido pelos suplementos sejam classes que derivem direta ou indiretamente de FrameworkElement, como formas, controles, controles de usuários, painéis de layout e páginas.
Aonde o contrato declarar que uma UI será transmitida entre o suplemento e o aplicativo host, isso deve ser declarado como um INativeHandleContract (não um FrameworkElement); INativeHandleContract é uma representação remota do suplemento UI que pode ser transmitido por limites de isolamento.
Antes de ser transmitido do domínio de aplicativo do suplemento, um FrameworkElement é empacotado como um INativeHandleContract chamando ViewToContractAdapter.
Após ser transmitido ao domínio de aplicativo do aplicativo host, o INativeHandleContract deve ser reempacotado como um FrameworkElement chamandoContractToViewAdapter.

Como INativeHandleContract, ContractToViewAdapter e ViewToContractAdapter são usados dependendo do cenário específico. As seções seguintes fornecem detalhes para cada modelo de programação.

Suplemento retorna uma Interface de Usuário

Para um suplemento retornar uma UI para um aplicativo host, o seguinte é exigido:

The host application, add-in, and pipeline must be created, as described by the .NET Framework Adicionar-ins e extensibilidade documentation.
O contrato deve implementar IContract e, para retornar um UI, o contrato deve declarar um método com um valor de retorno do tipo INativeHandleContract.
O UI que é transmitido entre o suplemento e o aplicativo host deve direta ou indiretamente vir do FrameworkElement.
O UI que é retornado pelo suplemento deve ser convertido de um FrameworkElement para um INativeHandleContract antes de cruzar o limite de isolamento.
O UI que é retornado pelo suplemento deve ser convertido de um INativeHandleContract para um FrameworkElement antes de cruzar o limite de isolamento.
O aplicativo host exibe o FrameworkElement retornado.

Para obter um exemplo que demonstra como implementar um suplemento que retorna um UI, consulte Como: Criar um suplemento que retorna uma interface do usuário. Para obter um exemplo completo, consulte Adicionar-Em retorna um exemplo de interface do usuário.

Suplemento é uma Interface de Usuário

Quando um suplemento é um UI, exige-se o seguinte:

The host application, add-in, and pipeline must be created, as described by the .NET Framework Adicionar-ins e extensibilidade documentation.
A interface do contrato para o suplemento deve implementar INativeHandleContract.
O suplemento que é transmitido ao aplicativo host deve direta ou indiretamente vir do FrameworkElement.
O suplemento deve ser convertido de um FrameworkElement para um INativeHandleContract antes de cruzar o limite de isolamento.
O suplemento deve ser convertido de um INativeHandleContract para um FrameworkElement antes de cruzar o limite de isolamento.
O aplicativo host exibe o FrameworkElement retornado.

Retornando Múltiplas UIs de um Suplemento

Add-ins geralmente fornecem vários UIs para aplicativos de host exibir. Por exemplo, considere um suplemento que é um UI que também fornece informações de status ao aplicativo host, também como um UI. Um suplemento como esse pode ser implementado usando uma combinação de técnicas do Suplemento retorna uma interface de usuário and Suplemento está uma interface de usuário modelos.

Para obter um exemplo completo que ilustra isso, consulte Adicionar-Com vários exemplo de interfaces de usuário.

Suplementos e Aplicativos de Navegação XAML.

Nos exemplos até agora, o aplicativo host têm sido um aplicativo autônomo instalado. Contudo aplicativos de navegador XAML (XBAPs) também pode hospedar suplementos, embora com os seguintes requisitos adicionais de implementação e compilação.

O manifesto de aplicativo XBAP deve ser configurado especialmente para baixar a pipeline (pastas e assemblies) e assembly do suplemento ao cache de aplicativos ClickOnce no cliente, na mesma pasta do XBAP.
O código XBAP para descobrir e carregar suplementos deve usar o aplicativo cache ClickOnce para o XBAP como a localização da pipeline e do suplemento.
O XBAP deve carregar o suplemento em um contexto de segurança especial se o suplemento se referir a arquivos soltos localizados no site de origem; quando hospedados por XBAPs, suplementos somente podem se referir a arquivos soltos localizados no site de origem do aplicativo host.

Essas tarefas são descritas em detalhes nas subseções seguintes.

Observação:
Para uma implementação completa de um XBAP que hospeda um suplemento, consulte Adicionar-Com um XBAP como o exemplo de aplicativo de host.

Configurando a Pipeline e o Suplemento para a Implantação do ClickOnce

XBAPs são baixados para uma pasta segura e nela executados no cache de implantação ClickOnce. Para que um XBAP hospede um suplemento, a pipeline e o assembly do suplemento também devem ser baixados à pasta segura. Para alcançar isso, configure o manifesto do aplicativo para incluir tanto a pipeline quanto o assembly do suplemento para download. Isso é facilmente realizado em Visual Studio, embora a pipeline e o assembly do suplemento precisem estar no host XBAP da pasta raiz do projeto de modo que o Visual Studio detecte os assemblies da pipeline.

Consequentemente, o primeiro passo é construir a pipeline e o assembly do suplemento à raiz do projeto XBAP, definindo a saída da compilação de cada assembly da pipeline e dos projetos assembly do suplemento. A tabela a seguir mostra os caminhos de saída da compilação para os projetos de assembly da pipeline e projetos de assembly do suplemento que estão na mesmas solução e pasta raiz do projeto XBAP host.

Tabela 1: Criar caminhos de saída para os conjuntos de módulos de pipeline que são hospedados por um XBAP

Projeto de Assembly da Pipeline	Compilar Caminho de Saída
Contrato	.. \HostXBAP\Contracts\
Exibição do Suplemento	.. \HostXBAP\AddInViews\
Adaptador no lado do Suplemento	.. \HostXBAP\AddInSideAdapters\
Adaptador do lado do Host	.. \HostXBAP\HostSideAdapters\
Suplemento	.. \HostXBAP\AddIns\WPFAddIn1

O próximo passo é especificar as assemblies da pipeline e assembly do suplemento como arquivos de conteúdo XBAPs em Visual Studio, realizando o seguinte:

Incluindo a pipeline e o assembly do suplemento no projeto clicando com o botão direito em cada pasta de pipeline no Gerenciador de Soluções e escolhendo Incluir no Projeto.
Definindo o Ação de Compilação de cada assembly de pipeline e de suplemento ao Conteúdoa partir da janela Propriedades.

O último passo é configurar o manifesto do aplicativo para incluir os arquivos de assembly da pipeline e do suplemento para download. Os arquivos devem estar localizados nas raízes das pastas no cache ClickOnce que o aplicativo XBAP ocupa. A configuração pode ser alcançada em Visual Studio realizando o seguinte:

Clique com o botão direito no projeto XBAP, clique em Propriedades, clique em Publicar e então clique no botão Arquivos do Aplicativo.
Na caixa de diálogo Arquivos do Aplicativo, defina o Status da Publicação de cada pipeline e DLL do suplemento ao Incluir (Auto), e defina o Grupo de Downloads para cada pipeline e DLL do suplemento ao (Requerido).

Usando a Pipeline e o Suplemento a partir da Base do Aplicativo

Quando a pipeline e o suplemento estiverem configurados para a implantação do ClickOnce, eles são baixados para a mesma pasta cache ClickOnce que o XBAP. Para usar a pipeline e o suplemento a partir do XBAP, o código do XBAP deve obtê-los da base do aplicativo. Os vários tipos de membros do modelo de suplemento .NET Framework para usar pipelines e suplementos fornecem suporte especial para esse cenário. Primeiramente, o caminho é identificado pelo valor de enumeração ApplicationBase. Use esse valor com sobrecargas de membros pertinentes do suplemento para usar pipelines que incluem o seguinte:

Acessando o Site de Origem do Host

Para garantir que o suplemento possa fazer referência a arquivos do site de origem, o suplemento deve ser carregado com isolamento de segurança equivalente à do aplicativo host. O nível de segurança é identificado pelo valor de enumeração AddInSecurityLevel.Host, e passado ao método Activate quando o suplemento é ativado.

Arquitetura de Suplemento WPF

No nível mais alto, como visto, WPF permite que suplementos .NET Framework implementem UIs (que derivam direta ou indiretamente do FrameworkElement) usando INativeHandleContract, ViewToContractAdapter e ContractToViewAdapter. O resultado é que ao aplicativo host é retornado uma FrameworkElement que é exibida a partir do UI no aplicativo host.

Para cenários de suplementos UI simples, isso são todos os detalhes de que o desenvolvedor necessita. Para cenários mais complexos, particularmente os que tentam utilizar serviços WPF adicionais como layout, recursos e associação de dados, mais conhecimentos detalhados de como WPF estende o modelo de suplemento .NET Framework com suporte UI é necessário para entender seus benefícios e limitações.

Fundamentalmente, WPF não passa uma UI de um suplemento a um aplicativo host; ao invés disso, WPF passa o identificador de janela Win32 ao UI usando interoperabilidade WPF. De mesmo modo, quando um UI de um suplemento é passado ao aplicativo host, o seguinte ocorre:

No lado do suplemento, WPF adquire um identificador de janela para o UI que será exibido no aplicativo host. O identificador de janela é encapsulado por uma classe WPF interna que deriva de um HwndSource e implementa INativeHandleContract. Um exemplo dessa classe é retornado por ViewToContractAdapter e é empacotada do domínio do aplicativo do suplemento ao domínio de aplicativo do aplicativo host.
No lado do aplicativo host, WPF reempacota o HwndSource como uma classe WPF interna que deriva de HwndHost e consome INativeHandleContract. Um exemplo dessa classe é retornado pelo ContractToViewAdapter ao aplicativo host.

HwndHost existe para exibir UIs, reconhecido por identificadores de janelas, do WPF UIs. Para obter mais informações, consulte Visão geral sobre interoperabilidade entre WPF e Win32.

Em resumo, INativeHandleContract, ViewToContractAdapter e ContractToViewAdapter existem para permitir que o identificador de janelas de um WPF UI seja passado de um suplemento a um aplicativo host, aonde é encapsulado por um HwndHost e exibido o UI do aplicativo host.

Observação:
Porque o aplicativo host recebe um HwndHost, o aplicativo host não é possível converter o objeto retornado pelo ContractToViewAdapter o tipo é implementado sistema autônomo pelo suplemento (por exemplo, um UserControl).

Por sua natureza, HwndHost possui certas limitações que afetam como aplicativos host podem utilizá-los. No entanto, WPF estende HwndHost com vários recursos para cenários de suplementos. Esses benefícios e limitações são descritas a seguir.

Benefícios de suplementos WPF

Because WPF add-in UIs are displayed from host applications using an internal class that derives from HwndHost, those UIs are constrained by the capabilities of HwndHost with respect to WPF UI services such as layout, rendering, data binding, styles, templates, and resources. No entanto, WPF aumenta sua subclasse HwndHost interna com recursos adicionais que incluem o seguinte:

Tabulações entre um UI do aplicativo host e um UI do suplemento. Observe que o modelo de programação "suplemento é um UI" requer que o adaptador do lado do suplemento substitua QueryContract para ativar tabulações, se o suplemento é totalmente confiável ou parcialmente confiável.
Respeitando requisitos de acessibilidade para UIs de suplementos que são exibidos de UIs do aplicativo host.
Ativando aplicativos WPF para que sejam executados com segurança em vários cenários de aplicativos de domínio.
Impedindo acesso ilegal a identificadores de janela UI do suplemento ao executar os suplementos com isolamento de segurança (ou seja, uma área de segurança de confiança parcial). Chamando ViewToContractAdapter garante essa segurança:
- Para o modelo de programação "Suplemento retorna um UI", a única maneira para passar o identificador da janela para um UI de suplemento pelo limite de isolamento é chamar ViewToContractAdapter.
- Para o modelo de programação "suplemento é um UI", substituindo QueryContract no adaptador no lado do suplemento e chamando ViewToContractAdapter (conforme mostrado nos exemplos anteriores) é necessária, como é chamar o adaptador no lado do suplemento do QueryContract implementação a partir do adaptador no lado do host.
Fornecendo várias proteções de execução de domínios de aplicativos. Devido a limitações com domínios de aplicativos, exceções sem-tratamento que são geradas em um domínio de aplicativo do suplemento faz com que o todo aplicativo falhe, mesmo que o limite de isolamento exista. No entanto, WPF e o modelo de suplemento .NET Framework oferecem uma forma simples para solucionar esse problema e melhorar a estabilidade do aplicativo. Um suplemento WPF que exibe um UI cria um Dispatcher para o encadeamento em que o domínio de aplicativo é executado, se o aplicativo host é um aplicativoWPF. Todas as exceções sem-tratamento que ocorrem no domínio do aplicativo podem ser detectadas ao manipular o evento UnhandledException do WPF Dispatcher do suplemento. Pode-se obter o Dispatcher a partir da propriedade CurrentDispatcher.

Limitações de suplementos WPF

Além de benefícios que WPF adiciona os comportamentos padrão fornecidos pelo HwndSource,HwndHost e identificadores de janela, há também limitações para UIs de suplementos que são exibidos a partir de aplicativos host:

UIs do suplemento exibido de um aplicativo host não respeitam o comportamento de recorte do aplicativo host.
O conceito de airspace em cenários de interoperabilidade também se aplica a suplementos (consulte Interoperação do WPF: Visão geral de regiões de janela e "Airspace").
Serviços UI do aplicativo host, como a herança de recursos, associação de dados e controle, não estão automaticamente disponíveis para UIs do suplemento. Para fornecer esses serviços para o suplemento, deve-se atualizar o pipeline.
Um UI do suplemento não pode ser girado, dimensionado, inclinado ou do contrário é afetado por uma transformação (consulte Visão Geral sobre Transformações).
Conteúdo dentro do UIs do suplemento que é renderizado por operações de desenho a partir do namespace System.Drawing pode incluir combinação alfa. No entanto, tanto um UI do suplemento quanto o UI do aplicativo host que o contém devem ser 100% opaco; em outras palavras, a propriedade Opacity nos dois deve ser definida como 1.
Se a propriedade AllowsTransparency de uma janela no aplicativo host que contém um UI do suplemento é definida como true, o suplemento está invisível. Isso é verdadeiro mesmo se o UI do suplemento está 100% opaco (ou seja, a propriedade Opacity tem um valor de 1).
Um UI do suplemento deve aparecer na parte superior dos outros elementos WPF na mesma janela de nível superior.
Nenhuma parte do UI do suplemento pode ser renderizado usando um VisualBrush. Em vez disso, o suplemento pode tirar um instantâneo do UI gerado para criar um bitmap que pode ser passado para o aplicativo host usando métodos definidos pelo contrato.
Arquivos de mídia não podem ser executados de um MediaElement em um UI do suplemento.
Eventos do mouse gerados para o UI do suplemento não são recebidos nem gerados pelo aplicativo host, e a propriedade IsMouseOver para o aplicativo host UI possui um valor de false.
Quando o foco alterna entre os controles em um UI do suplemento, os eventos GotFocus e LostFocus não são recebidos nem gerados pelo aplicativo host.
A parte de um aplicativo host que contém um UI de suplemento aparece em branco quando impresso.
Todos os distribuidores (consulte Dispatcher) criados pelo UI do suplemento devem ser desativados manualmente antes do suplemento proprietário ser descarregado se o aplicativo host continua a execução. O contrato pode implementar métodos que permitem que o aplicativo host sinalize o suplemento antes do suplemento ser descarregado, permitindo assim que o UI do suplemento desligue seus distribuidores.
Se um UI do suplemento for um InkCanvas ou contiver um InkCanvas, não é possível descarregar o suplemento.

Otimização de Desempenho

Por padrão, quando vários domínios de aplicativo são usados, os vários Conjuntos de Módulos (Assemblies) .NET Framework exigidos por cada aplicativo são todos carregados no domínio do aplicativo. Como resultado, o tempo necessário para criar novos domínios de aplicativo e iniciar aplicativos neles pode afetar o desempenho. No entanto, o .NET Framework fornece uma maneira para se reduzir horas de inicialização instruindo os aplicativos a compartilhar conjuntos de módulos (assemblies) nos domínios de aplicativo se eles já estiverem carregados. Isso é feito usando o atributo LoaderOptimizationAttribute, que deve ser aplicado ao método do ponto de entrada (Main). Nesse caso, use somente o código para implementar sua definição de aplicativo (consulte Visão Geral do Gerenciamento de Aplicativo).

Os exemplos a seguir, discutidos anteriormente, demonstram o uso do LoaderOptimizationAttribute:

Consulte também

Share via