Partilhar via

Tipos migrados do WPF para System.Xaml

  • Artigo

No .NET Framework 3.5 e no .NET Framework 3.0, o Windows Presentation Foundation (WPF) e o Windows Workflow Foundation incluíam uma implementação de linguagem XAML. Muitos dos tipos públicos que forneciam extensibilidade para a implementação WPF XAML existiam nos assemblies WindowsBase, PresentationCore e PresentationFramework. Da mesma forma, os tipos públicos que forneciam extensibilidade para o XAML do Windows Workflow Foundation existiam no assembly System.Workflow.ComponentModel. No .NET Framework 4, alguns dos tipos relacionados a XAML foram migrados para o assembly System.Xaml. Uma implementação comum do .NET Framework de serviços de linguagem XAML permite muitos cenários de extensibilidade XAML que foram originalmente definidos pela implementação XAML de uma estrutura específica, mas agora fazem parte do suporte geral à linguagem XAML do .NET Framework 4. Este artigo lista os tipos que foram migrados e discute questões relacionadas à migração.

Assemblies e namespaces

No .NET Framework 3.5 e no .NET Framework 3.0, os tipos que o WPF implementou para dar suporte a XAML geralmente estavam no namespace System.Windows.Markup. A maioria desses tipos estava na assemblagem WindowsBase.

No .NET Framework 4, há um novo namespace System.Xaml e um novo assembly System.Xaml. Muitos dos tipos que foram originalmente implementados para WPF XAML agora são fornecidos como pontos de extensibilidade ou serviços para qualquer implementação de XAML. Como parte da disponibilização para cenários mais gerais, os tipos são reencaminhados da biblioteca WPF original para a biblioteca System.Xaml. Isso permite cenários de extensibilidade XAML sem precisar incluir os assemblies de outras estruturas (como WPF e Windows Workflow Foundation).

Para tipos migrados, a maioria dos tipos permanece no namespace System.Windows.Markup. Isso foi parcialmente para evitar a quebra de mapeamentos de namespace CLR em implementações existentes por arquivo. Como resultado, o namespace System.Windows.Markup no .NET Framework 4 contém uma mistura de tipos gerais de suporte à linguagem XAML (do assembly System.Xaml) e tipos específicos para a implementação WPF XAML (do WindowsBase e outros assemblies WPF). Qualquer tipo que foi migrado para System.Xaml, mas existia anteriormente num assembly WPF, tem suporte a reencaminhamento de tipo na versão 4 do assembly WPF.

Tipos de suporte XAML de fluxo de trabalho

O Windows Workflow Foundation também fornecia tipos de suporte a XAML e, em muitos casos, eles tinham nomes curtos idênticos a um equivalente WPF. Segue-se uma lista dos tipos de suporte XAML do Windows Workflow Foundation:

Esses tipos de suporte ainda existem nos assemblies do Windows Workflow Foundation para .NET Framework 4 e ainda podem ser usados para aplicativos específicos do Windows Workflow Foundation; no entanto, eles não devem ser referenciados por aplicativos ou estruturas que não usam o Windows Workflow Foundation.

MarkupExtension

No .NET Framework 3.5 e .NET Framework 3.0, a classe MarkupExtension para WPF estava no assembly WindowsBase. Uma classe paralela para o Windows Workflow Foundation, MarkupExtension, existia na assemblagem System.Workflow.ComponentModel. No .NET Framework 4, a classe MarkupExtension é migrada para o assembly System.Xaml. No .NET Framework 4, MarkupExtension destina-se a qualquer cenário de extensibilidade XAML que use os Serviços XAML do .NET, não apenas àqueles que se baseiam em estruturas específicas. Quando possível, estruturas específicas ou código de usuário na estrutura também devem se basear na classe MarkupExtension para extensão XAML.

Classes de Serviço de Suporte a MarkupExtension

O .NET Framework 3.5 e o .NET Framework 3.0 para WPF forneceram vários serviços que estavam disponíveis para implementadores de MarkupExtension e implementações TypeConverter para dar suporte ao uso de tipo/propriedade em XAML. Estes serviços são os seguintes:

Observação

Outro serviço do .NET Framework 3.5 relacionado a extensões de marcação é a interface IReceiveMarkupExtension. IReceiveMarkupExtension não foi migrado e está marcado como [Obsolete] para .NET Framework 4. Os cenários que usavam anteriormente IReceiveMarkupExtension devem, em vez disso, usar retornos de chamada XamlSetMarkupExtensionAttribute atribuídos. AcceptedMarkupExtensionExpressionTypeAttribute também está marcado [Obsolete].

Recursos de linguagem XAML

Vários recursos e componentes de linguagem XAML para WPF existiam anteriormente no assembly do PresentationFramework. Eles foram implementados como uma subclasse MarkupExtension para expor utilizações de extensões de marcação na marcação XAML. No .NET Framework 4, eles existem no assembly System.Xaml para que os projetos que não incluem assemblies WPF possam usar esses recursos de nível de linguagem XAML. O WPF usa essas mesmas implementações para aplicativos do .NET Framework 4. Assim como nos outros casos listados neste tópico, os tipos de suporte continuam a existir no namespace System.Windows.Markup para evitar a quebra de referências anteriores.

A tabela a seguir contém uma lista das classes de suporte a recursos XAML definidas em System.Xaml.

Recurso de linguagem XAML Utilização
ArrayExtension <x:Array ...>
NullExtension {x:Null}
StaticExtension {x:Static ...}
TypeExtension {x:Type ...}

Embora System.Xaml possa não ter classes de suporte específicas, a lógica geral para processar recursos de linguagem para a linguagem XAML agora reside em System.Xaml e seus leitores XAML implementados e gravadores XAML. Por exemplo, x:TypeArguments é um atributo que é processado por leitores e escritores XAML de implementações do System.Xaml; ele pode ser observado no fluxo de nós XAML, tem tratamento no contexto de esquema XAML padrão (baseado em CLR), tem uma representação no sistema de tipos XAML, e assim por diante. Para obter mais informações sobre a documentação de referência para XAML, consulte Serviços XAML.

ValueSerializer e classes de suporte

A classe ValueSerializer oferece suporte à conversão de tipo em uma cadeia de caracteres, particularmente para casos de serialização XAML em que a serialização pode exigir vários modos ou nós na saída. No .NET Framework 3.5 e .NET Framework 3.0, o ValueSerializer para WPF estava na biblioteca WindowsBase. No .NET Framework 4, a classe ValueSerializer está em System.Xaml e destina-se a qualquer cenário de extensibilidade XAML, não apenas àqueles que se baseiam no WPF. IValueSerializerContext (um serviço de suporte) e DateTimeValueSerializer (uma subclasse específica) também são migrados para System.Xaml.

O WPF XAML incluiu vários atributos que podem ser aplicados a tipos CLR para indicar algo sobre seu comportamento XAML. A seguir está uma lista dos atributos que existiam em assemblies WPF no .NET Framework 3.5 e .NET Framework 3.0. Esses atributos são migrados para System.Xaml no .NET Framework 4.

Classes Diversas

A interface IComponentConnector existia no WindowsBase no .NET Framework 3.5 e no .NET Framework 3.0, mas existe no System.Xaml no .NET Framework 4. IComponentConnector destina-se principalmente ao suporte a ferramentas e compiladores de marcação XAML.

A interface INameScope existia no WindowsBase no .NET Framework 3.5 e no .NET Framework 3.0, mas existe no System.Xaml no .NET Framework 4. INameScope define operações básicas para um namescope XAML.

As classes seguintes existem nos assemblies WPF e no assembly System.Xaml no .NET Framework 4:

XamlReader

XamlWriter

XamlParseException

A implementação do WPF é encontrada no namespace System.Windows.Markup e no assembly do PresentationFramework. A implementação System.Xaml é encontrada no namespace System.Xaml. Se você estiver usando tipos WPF ou derivar de tipos WPF, normalmente deve usar as implementações WPF de XamlReader e XamlWriter em vez das implementações System.Xaml. Para obter mais informações, consulte Observações no System.Windows.Markup.XamlReader e System.Windows.Markup.XamlWriter.

Se você estiver incluindo referências a assemblies WPF e System.Xaml e também estiver usando instruções include para os namespaces System.Windows.Markup e System.Xaml, talvez seja necessário qualificar totalmente as chamadas para essas APIs para resolver os tipos sem ambiguidade.