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 XAML do WPF existiam nos assemblies WindowsBase, PresentationCore e PresentationFramework. Da mesma forma, os tipos públicos que forneciam extensibilidade para o Windows Workflow Foundation XAML 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 problemas relacionados à 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 System.Windows.Markup namespace. A maioria desses tipos estava no assembly WindowsBase.

No .NET Framework 4, há um novo namespace e um novo System.Xaml 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 de disponibilizá-los para cenários mais gerais, os tipos são encaminhados do assembly WPF original para o assembly System.Xaml. Isso habilita 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 System.Windows.Markup namespace. Isso foi parcialmente para evitar a quebra de mapeamentos de namespace CLR em implementações existentes em uma base por arquivo. Como resultado, o System.Windows.Markup namespace 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 XAML do WPF (do WindowsBase e outros assemblies do WPF). Qualquer tipo que foi migrado para System.Xaml, mas existia anteriormente em um assembly WPF, tem suporte a encaminhamento de tipos 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 XAML e, em muitos casos, eles tinham nomes curtos idênticos a um equivalente WPF. Veja a seguir uma lista de 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 MarkupExtension classe para WPF estava no assembly WindowsBase. Uma classe paralela para o Windows Workflow Foundation, MarkupExtension, existia no assembly System.Workflow.ComponentModel. No .NET Framework 4, a MarkupExtension classe é migrada para o assembly System.Xaml. No .NET Framework 4, destina-se a qualquer cenário de extensibilidade XAML que use os Serviços XAML do .NET, MarkupExtension não apenas para aqueles 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 MarkupExtension classe para extensão XAML.

MarkupExtension Classes de serviço de suporte

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

Observação

Outro serviço do .NET Framework 3.5 que está relacionado a extensões de marcação é a IReceiveMarkupExtension interface. IReceiveMarkupExtension não foi migrado e está marcado [Obsolete] para .NET Framework 4. Os cenários usados IReceiveMarkupExtension anteriormente devem usar XamlSetMarkupExtensionAttribute retornos de chamada 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 PresentationFramework. Eles foram implementados como uma MarkupExtension subclasse para expor usos de extensão 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 acontece com os outros casos listados neste tópico, os tipos de suporte continuam a existir no namespace para evitar a quebra de System.Windows.Markup 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 Uso
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, é um atributo que é processado por leitores XAML e gravadores XAML de implementações System.Xaml, pode ser observado no fluxo de nó XAML, x:TypeArguments tem manipulação no contexto de esquema XAML padrão (baseado em CLR), tem uma representação de sistema de tipo 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 ValueSerializer classe oferece suporte à conversão de tipo em uma cadeia de caracteres, especialmente 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 no .NET Framework 3.0, o para WPF estava no ValueSerializer assembly WindowsBase. No .NET Framework 4, a classe está em System.Xaml e destina-se a ValueSerializer qualquer cenário de extensibilidade XAML, não apenas para aqueles 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 IComponentConnector interface 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 INameScope interface 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 seguintes classes existem nos assemblies WPF e System.Xaml no .NET Framework 4:

XamlReader

XamlWriter

XamlParseException

A implementação do WPF é encontrada no namespace e no System.Windows.Markup assembly PresentationFramework. A implementação System.Xaml é encontrada no System.Xaml namespace. Se você estiver usando tipos WPF ou estiver derivando de tipos WPF, você normalmente deve usar as implementações WPF de XamlReader e XamlWriter em vez das implementações System.Xaml. Para obter mais informações, consulte Comentários em 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 include instruções para namespaces System.Windows.Markup e System.Xaml , talvez seja necessário qualificar totalmente as chamadas para essas APIs para resolver os tipos sem ambiguidade.