Alterações de redirecionamento para a migração para o .NET Framework 4.5.x

Esse artigo lista os problemas de compatibilidade do aplicativo introduzidos no .NET Framework 4.5 ,4.5.1 e4.5.2 .

.NET Framework 4.5

ASP.NET

Os métodos MachineKey.Encode e MachineKey.Decode agora estão obsoletos

Detalhes

Esses métodos são agora obsoletos. A compilação de código que chama estes métodos gera um aviso do compilador.

Sugestão

As alternativas recomendadas são Protect(Byte[], String[]) e Unprotect(Byte[], String[]). Como alternativa, os avisos de compilação podem ser suprimidos ou evitados usando um compilador mais antigo. Ainda há suporte para as APIs.

Nome	Valor
Escopo	Secundária
Versão	4.5
Tipo	Redirecionando

APIs afetadas

• MachineKey.Encode(Byte[], MachineKeyProtection)
• MachineKey.Decode(String, MachineKeyProtection)

Espaçamento de Caixa de Texto do ASP.NET de várias linhas alterado ao usar AntiXSSEncoder

Detalhes

No .NET Framework 4.0, linhas extras eram inseridas entre as linhas de uma caixa de texto de várias linhas no postback, se usando o System.Web.Security.AntiXss.AntiXssEncoder. No .NET Framework 4.5, essas quebras de linhas extras não são incluídas, mas somente se o aplicativo Web for direcionado ao .NET 4.5

Sugestão

Lembre-se de que os aplicativos web 4.0 redirecionados para o .NET Framework 4.5 podem ter caixas de texto multilinha melhoradas para não inserir quebras de linha extras. Se isso não for desejável, o aplicativo poderá ter o comportamento antigo durante a execução no .NET Framework 4.5 visando o .NET Framework 4.0.

Nome	Valor
Escopo	Secundária
Versão	4.5
Tipo	Redirecionando

WebUtility.HtmlEncode e WebUtility.HtmlDecode vão e voltam corretamente ao BMP

Detalhes

Nos aplicativos destinados ao .NET Framework 4.5, os caracteres fora do BMP (Basic Multilingual Plane) vão e voltam corretamente quando são passados para os métodos HtmlDecode(String).

Sugestão

Essa alteração não deve afetar os aplicativos atuais, mas, para restaurar o comportamento original, defina o atributo targetFramework do elemento <httpRuntime> como uma cadeia de caracteres diferente de "4.5". Você também pode definir os atributos unicodeEncodingConformance e unicodeDecodingConformance do elemento de configuração <webUtility> para controlar esse comportamento independentemente da versão de destino do .NET Framework.

Nome	Valor
Escopo	Microsoft Edge
Versão	4.5
Tipo	Redirecionando

APIs afetadas

• WebUtility.HtmlEncode(String)
• WebUtility.HtmlEncode(String, TextWriter)

ClickOnce

Os aplicativos publicados com ClickOnce que usam um certificado de autenticação de código SHA-256 podem falhar no Windows 2003

Detalhes

O executável é assinado com SHA256. Antes, ele era assinado com SHA1, independentemente se o certificado de assinatura de código era SHA-1 ou SHA-256. Isso se aplica a:

• Todos os aplicativos compilados com o Visual Studio 2012 ou posterior.
• Os aplicativos compilados com o Visual Studio 2010 ou anteriores em sistemas com o .NET Framework 4.5. Além disso, se o .NET Framework 4.5 ou posterior estiver presente, o manifesto do ClickOnce também será assinado com certificados SHA-256 para SHA-256, independentemente da versão do .NET Framework na qual ele foi compilado.

Sugestão

A mudança na assinatura do executável do ClickOnce afeta apenas os sistemas Windows Server 2003; eles exigem a instalação do KB 938397. A alteração na assinatura do manifesto com SHA-256, mesmo quando um aplicativo destina-se ao .NET Framework 4.0 ou versões anteriores, introduz uma dependência de runtime no .NET Framework 4.5 ou uma versão posterior.

Nome	Valor
Escopo	Microsoft Edge
Versão	4.5
Tipo	Redirecionando

Núcleo

A variável do iterador Foreach agora tem escopo na iteração, de modo que as semânticas de captura de fechamento são diferentes (no C#5)

Detalhes

A partir do C# 5 (Visual Studio 2012), as variáveis do iterador foreach têm escopo dentro da iteração. Isso poderá causar interrupções se o código anteriormente dependia das variáveis para não ser incluído no fechamento de foreach. O sintoma dessa alteração será que uma variável do iterador passada a um delegado será tratada com o valor que ela tinha no momento em que o delegado foi criado, e não com o valor que ela tinha no momento em que o delegado foi invocado.

Sugestão

De maneira ideal, o código deve ser atualizado para esperar o novo comportamento do compilador. Se as semânticas antigas forem necessárias, a variável do iterador poderá ser substituída por uma variável separada que seja explicitamente colocada fora do escopo do loop.

Nome	Valor
Escopo	Principal
Versão	4.5
Tipo	Redirecionando

A propriedade IAsyncResult.CompletedSynchronously deve estar correta para a tarefa resultante a ser concluída

Detalhes

Ao chamar TaskFactory.FromAsync, a implementação da propriedade CompletedSynchronously deve estar correta para a tarefa resultante a ser concluída. Isto é, a propriedade deverá retornar true se, e apenas se, a implementação for concluída de modo síncrono. Anteriormente, a propriedade não era verificada.

Sugestão

Se as implementações de System.IAsyncResult retornarem true corretamente para a propriedade System.IAsyncResult.CompletedSynchronously somente quando uma tarefa for concluída de modo síncrono, nenhuma interrupção será observada. Os usuários devem revisar as implementações de System.IAsyncResult que têm (se houver) para garantir que eles sejam avaliados corretamente se uma tarefa for concluída de modo síncrono ou não.

Nome	Valor
Escopo	Microsoft Edge
Versão	4.5
Tipo	Redirecionando

APIs afetadas

• TaskFactory.FromAsync(IAsyncResult, Action<IAsyncResult>)
• TaskFactory.FromAsync(IAsyncResult, Action<IAsyncResult>, TaskCreationOptions)
• TaskFactory.FromAsync(IAsyncResult, Action<IAsyncResult>, TaskCreationOptions, TaskScheduler)
• TaskFactory.FromAsync<TResult>(IAsyncResult, Func<IAsyncResult,TResult>)
• TaskFactory.FromAsync(Func<AsyncCallback,Object,IAsyncResult>, Action<IAsyncResult>, Object)
• TaskFactory.FromAsync(Func<AsyncCallback,Object,IAsyncResult>, Action<IAsyncResult>, Object, TaskCreationOptions)
• TaskFactory.FromAsync<TArg1>(Func<TArg1,AsyncCallback,Object,IAsyncResult>, Action<IAsyncResult>, TArg1, Object)
• TaskFactory.FromAsync<TArg1>(Func<TArg1,AsyncCallback,Object,IAsyncResult>, Action<IAsyncResult>, TArg1, Object, TaskCreationOptions)
• TaskFactory.FromAsync<TResult>(Func<AsyncCallback,Object,IAsyncResult>, Func<IAsyncResult,TResult>, Object)
• TaskFactory.FromAsync<TResult>(Func<AsyncCallback,Object,IAsyncResult>, Func<IAsyncResult,TResult>, Object, TaskCreationOptions)
• TaskFactory.FromAsync<TResult>(IAsyncResult, Func<IAsyncResult,TResult>, TaskCreationOptions)
• TaskFactory.FromAsync<TResult>(IAsyncResult, Func<IAsyncResult,TResult>, TaskCreationOptions, TaskScheduler)
• TaskFactory.FromAsync<TArg1,TArg2>(Func<TArg1,TArg2,AsyncCallback,Object,IAsyncResult>, Action<IAsyncResult>, TArg1, TArg2, Object)
• TaskFactory.FromAsync<TArg1,TArg2>(Func<TArg1,TArg2,AsyncCallback,Object,IAsyncResult>, Action<IAsyncResult>, TArg1, TArg2, Object, TaskCreationOptions)
• TaskFactory.FromAsync<TArg1,TResult>(Func<TArg1,AsyncCallback,Object,IAsyncResult>, Func<IAsyncResult,TResult>, TArg1, Object)
• TaskFactory.FromAsync<TArg1,TResult>(Func<TArg1,AsyncCallback,Object,IAsyncResult>, Func<IAsyncResult,TResult>, TArg1, Object, TaskCreationOptions)
• TaskFactory.FromAsync<TArg1,TArg2,TResult>(Func<TArg1,TArg2,AsyncCallback,Object,IAsyncResult>, Func<IAsyncResult,TResult>, TArg1, TArg2, Object)
• TaskFactory.FromAsync<TArg1,TArg2,TArg3>(Func<TArg1,TArg2,TArg3,AsyncCallback,Object,IAsyncResult>, Action<IAsyncResult>, TArg1, TArg2, TArg3, Object)
• TaskFactory.FromAsync<TArg1,TArg2,TArg3>(Func<TArg1,TArg2,TArg3,AsyncCallback,Object,IAsyncResult>, Action<IAsyncResult>, TArg1, TArg2, TArg3, Object, TaskCreationOptions)
• TaskFactory.FromAsync<TArg1,TArg2,TResult>(Func<TArg1,TArg2,AsyncCallback,Object,IAsyncResult>, Func<IAsyncResult,TResult>, TArg1, TArg2, Object, TaskCreationOptions)
• TaskFactory.FromAsync<TArg1,TArg2,TArg3,TResult>(Func<TArg1,TArg2,TArg3,AsyncCallback,Object,IAsyncResult>, Func<IAsyncResult,TResult>, TArg1, TArg2, TArg3, Object)
• TaskFactory.FromAsync<TArg1,TArg2,TArg3,TResult>(Func<TArg1,TArg2,TArg3,AsyncCallback,Object,IAsyncResult>, Func<IAsyncResult,TResult>, TArg1, TArg2, TArg3, Object, TaskCreationOptions)

List<T>.ForEach agora gera exceção durante a modificação de item de lista

Detalhes

Começando no .NET Framework 4.5, um enumerador ForEach(Action<T>) gerará uma exceção System.InvalidOperationException se um elemento na coleção de chamada for modificado. Anteriormente, isso não geraria uma exceção, mas podia levar a condições de corrida.

Sugestão

De modo ideal, o código deve ser corrigido para não modificar listas durante a enumeração de seus elementos, pois essa nunca é uma operação segura. Porém, para reverter para o comportamento anterior, um aplicativo pode ser direcionado ao .NET Framework 4.0.

Nome	Valor
Escopo	Microsoft Edge
Versão	4.5
Tipo	Redirecionando

APIs afetadas

• List<T>.ForEach(Action<T>)

Análise de System.Uri adere à RFC 3987

Detalhes

A análise de URI foi alterada de várias maneiras no .NET Framework 4.5. No entanto, observe que essas alterações afetam somente o código direcionado ao .NET Framework 4.5. Se um binário for direcionado ao .NET Framework 4.0, o comportamento antigo será observado. As alterações na análise de URI no .NET Framework 4.5 incluem:

• A análise de URI executará a normalização e a verificação de caracteres de acordo com as regras mais recentes de URI na RFC 3987.
• O formulário C de normalização Unicode só será executado na parte de host do URI.
• Agora, os URIs mailto: inválidos gerarão uma exceção.
• Os pontos à direita no fim de um segmento de linha agora são preservados.
• Os URIs file:// não escapam o caractere ?.
• Os caracteres de controle Unicode U+0080 a U+009F não são compatíveis.
• Os caracteres de vírgula , ou %2c não fogem ao escape automaticamente.

Sugestão

Se a semântica de análise de URI antiga do .NET Framework 4.0 for necessária (geralmente não é), ela poderá ser usada direcionando ao .NET Framework 4.0. Isso pode ser feito usando um System.Runtime.Versioning.TargetFrameworkAttribute no assembly ou pela interface do usuário do sistema do projeto no Visual Studio, na página "propriedades do projeto".

Nome	Valor
Escopo	Principal
Versão	4.5
Tipo	Redirecionando

APIs afetadas

• Uri(String)
• Uri(String, Boolean)
• Uri(String, UriKind)
• Uri(Uri, String)
• Uri.TryCreate(String, UriKind, Uri)
• Uri.TryCreate(Uri, String, Uri)
• Uri.TryCreate(Uri, Uri, Uri)

Método System.Uri.IsWellFormedUriString retorna false para URIs com dois-pontos no primeiro segmento

Detalhes

A partir do .NET Framework 4.5, IsWellFormedUriString(String, UriKind) tratará URIs relativos com um : no primeiro segmento como malformados. Essa é uma alteração do comportamento de System.Uri.IsWellFormedUriString(String, UriKind) no .NET Framework 4.0, realizada para manter a conformidade com a RFC3986.

Sugestão

Essa alteração (assim como várias outras alterações de URI) afetará somente os aplicativos do .NET Framework 4.5 ou versões posteriores. Para continuar usando o comportamento antigo, direcione o aplicativo para o .NET Framework 4.0. Como alternativa, verifique se há caracteres : no URI que você deseja remover para fins de validação antes de chamar System.Uri.IsWellFormedUriString(String, UriKind) se quiser usar o comportamento antigo.

Nome	Valor
Escopo	Secundária
Versão	4.5
Tipo	Redirecionando

APIs afetadas

• Uri.IsWellFormedUriString(String, UriKind)

Entity Framework

A versão do Entity Framework deve corresponder à versão do .NET Framework

Detalhes

A versão do EF (Entity Framework) deve corresponder à versão do .NET Framework. O Entity Framework 5 é recomendado para o .NET Framework 4.5. Há alguns problemas conhecidos com o EF 4.x em um projeto do .NET Framework 4.5 em relação a System.ComponentModel.DataAnnotations. No .NET Framework 4.5, eles foram movidos para um assembly diferente, portanto, há problemas para determinar quais anotações usar.

Sugestão

Atualização para o Entity Framework 5 do .NET Framework 4.5

Nome	Valor
Escopo	Principal
Versão	4.5
Tipo	Redirecionando

Windows Forms

O construtor EncoderParameter está obsoleto

Detalhes

O construtor EncoderParameter(Encoder, Int32, Int32, Int32, Int32) agora está obsoleto e introduzirá novos avisos de compilação se for usado.

Sugestão

Embora o construtor EncoderParameter(Encoder, Int32, Int32, Int32, Int32) continue funcionando, o seguinte construtor deverá ser usado em seu lugar para evitar o aviso de build obsoleto durante a recompilação de código com ferramentas do .NET Framework 4.5: EncoderParameter(Encoder, Int32, EncoderParameterValueType, IntPtr).

Nome	Valor
Escopo	Secundária
Versão	4.5
Tipo	Redirecionando

APIs afetadas

• EncoderParameter(Encoder, Int32, Int32, Int32, Int32)

Windows Communication Foundation (WCF)

Gravando a saída binária usando o BodyWriter

Detalhes

Se você estiver derivando da classe System.ServiceModel.Channels.BodyWriter e usando a implementação de OnWriteBodyContents(XmlDictionaryWriter writer) para gravar a saída binária, talvez seja necessário fazer algumas alterações ao redirecionar para o .NET Framework 4.5. Verifique o estado da gravação e, se for WriterState.Start, emita o elemento XML de cobertura Binary, conforme mostrado no trecho de código a seguir.

protected override void OnWriteBodyContents(XmlDictionaryWriter writer)
{
    bool wroteStartElement = false;
    if (writer.WriteState == WriteState.Start)
    {
        writer.WriteStartElement("Binary", string.Empty);
        wroteStartElement = true;
    }
    writer.WriteBase64(buffer, offset, count);
    if (wroteStartElement)
    {
        writer.WriteEndElement();
    }
}

Além disso, se você estiver derivando da classe System.ServiceModel.Channels.StreamBodyWriter e tiver substituído o método OnWriteBodyContents(XmlDictionaryWriter writer), algumas alterações poderão ser necessárias. Ao direcionar o .NET Framework 4.0, era necessário escrever explicitamente o elemento Binary ao substituir esse método. Isso não é mais necessário quando você tem como alvo o .NET Framework 4.5, e isso faz com que o corpo não seja gravado.

Windows Presentation Foundation (WPF)

O TextBox.Text do WPF pode estar fora de sincronia com a associação de dados

Detalhes

Em alguns casos, a propriedade Text reflete um valor anterior do valor da propriedade vinculada se a propriedade é modificada durante uma operação de escrita de vinculação de dados.

Sugestão

Isso não deve ter nenhum impacto negativo. No entanto, é possível restaurar o comportamento anterior ao definir a propriedade KeepTextBoxDisplaySynchronizedWithTextProperty como false.

	Valor
Escopo	Microsoft Edge
Versão	4.5
Tipo	Redirecionando

APIs afetadas

• TextBox.Text

Windows Workflow Foundation (WF)

Sobrecargas novas (ambíguas) do Dispatcher.Invoke podem resultar em comportamento diferente

Detalhes

O .NET Framework 4.5 adiciona novas sobrecargas ao Dispatcher.Invoke que incluem um parâmetro do tipo Action. Quando um código existente é recompilado, os compiladores podem resolver as chamadas aos métodos Dispatcher.Invoke que têm um parâmetro Delegate como chamadas aos métodos Dispatcher.Invoke com um parâmetro Action. Se uma chamada à sobrecarga do Dispatcher.Invoke com um parâmetro Delegate for resolvida como chamada à sobrecarga do Dispatcher.Invoke com um parâmetro Action, poderão ocorrer as seguintes diferenças de comportamento:

• Se ocorrer uma exceção, os eventos UnhandledExceptionFilter e UnhandledException não serão gerados. Em vez disso, as exceções são tratadas pelo evento System.Threading.Tasks.TaskScheduler.UnobservedTaskException.
• Chamadas para alguns membros, como Result, são bloqueadas até que a operação seja concluída.

Sugestão

Para evitar ambiguidade (e possíveis diferenças no tratamento de exceções ou nos comportamentos de bloqueio), o código que chama o Dispatcher.Invoke pode passar um object[] vazio como um segundo parâmetro à chamada de Invoke para garantir a resolução da sobrecarga do método no .NET Framework 4.0.

Nome	Valor
Escopo	Secundária
Versão	4.5
Tipo	Redirecionando

APIs afetadas

• Dispatcher.Invoke(Delegate, Object[])
• Dispatcher.Invoke(Delegate, TimeSpan, Object[])
• Dispatcher.Invoke(Delegate, TimeSpan, DispatcherPriority, Object[])
• Dispatcher.Invoke(Delegate, DispatcherPriority, Object[])

Algumas APIs arrastar e soltar do Fluxo de Trabalho estão obsoletas

Detalhes

A API Arrastar/Soltar do Fluxo de Trabalho está obsoleta e vai gerar avisos do compilador se o aplicativo for recompilado na versão 4.5.

Sugestão

No lugar, devem ser usadas as novas APIs System.Activities.Presentation.DragDropHelper compatíveis com operações com vários objetos. Como alternativa, os avisos de compilação podem ser suprimidos ou evitados usando um compilador mais antigo. Ainda há suporte para as APIs.

Nome	Valor
Escopo	Secundária
Versão	4.5
Tipo	Redirecionando

APIs afetadas

• DragDropHelper.DoDragMove(WorkflowViewElement, Point)
• DragDropHelper.GetCompositeView(DragEventArgs)
• DragDropHelper.GetDraggedModelItem(DragEventArgs)
• DragDropHelper.GetDroppedObject(DependencyObject, DragEventArgs, EditingContext)

Os tipos do WorkFlow 3.0 estão obsoletos

Detalhes

As APIs (aquelas do namespace System.Workflow) do WWF (Windows Workflow Foundation) 3.0 agora estão obsoletas.

Sugestão

Agora devem ser usadas as novas APIs (em System.Activities) do WWF 4.0. Um exemplo de como usar as novas APIs pode ser encontrado aqui, e outras diretrizes estão disponíveis aqui. Como alternativa, uma vez que as APIs do WWF 3.0 ainda têm suporte, elas poderão ser usadas, e o aviso de hora da compilação deve ser evitado suprimindo-o ou usando um compilador mais antigo.

Nome	Valor
Escopo	Principal
Versão	4.5
Tipo	Redirecionando

WorkflowDesigner.Load não remove a propriedade de símbolo

Detalhes

Ao destinar para o .NET Framework 4.5 no designer de fluxo de trabalho e carregar um fluxo de trabalho 3.5 hospedado novamente com o método Load(), uma System.Xaml.XamlDuplicateMemberException é gerada durante o salvamento do fluxo de trabalho.

Sugestão

Esse bug se manifesta somente no direcionamento do .NET Framework 4.5 no designer de fluxo de trabalho, de modo que a solução alternativa é definir o WorkflowDesigner.Context.Services.GetService<DesignerConfigurationService>().TargetFrameworkName para o .NET Framework 4.0.

Como alternativa, é possível evitar o problema usando o método Load(String) para carregar o fluxo de trabalho, em vez de Load().

Nome	Valor
Escopo	Principal
Versão	4.5
Tipo	Redirecionando

APIs afetadas

• WorkflowDesigner.Load()

XML, XSLT

A validação do esquema XML está mais rigorosa

Detalhes

No .NET Framework 4.5, a validação do esquema XML está mais rigorosa. Se você usar xsd:anyURI para validar um URI como um protocolo mailto, a validação falhará se houver espaços no URI. Nas versões anteriores do .NET Framework, a validação foi bem-sucedida. A alteração afeta somente aplicativos destinados ao .NET Framework 4.5.

Sugestão

Se for necessária uma validação menos rigorosa do .NET Framework 4.0, o aplicativo de validação poderá se destinar à versão 4.0 do .NET Framework. No entanto, ao direcionar ao .NET Framework 4.5, é necessário revisar o código para verificar se URIs inválidos (com espaços) não são esperados como valores de atributo com o tipo de dados anyURI.

Nome	Valor
Escopo	Secundária
Versão	4.5
Tipo	Redirecionando

.NET Framework 4.5.1

ADO.NET

DbParameter.Precision e DbParameter.Scale agora são membros virtuais públicos

Detalhes

Precision e Scale são implementados como propriedades virtuais públicas. Elas substituem as implementações de interface explícitas correspondentes, IDbDataParameter.Precision e IDbDataParameter.Scale.

Sugestão

Ao recompilar um provedor de banco de dados ADO.NET, essas diferenças exigirão que a palavra-chave "override" seja aplicada às propriedades Precision e Scale. Isso é necessário somente na recompilação dos componentes; binários existentes continuarão funcionando.

Nome	Valor
Escopo	Secundária
Versão	4.5.1
Tipo	Redirecionando

APIs afetadas

• DbParameter.Precision
• DbParameter.Scale

Núcleo

ObsoleteAttribute exporta ObsoleteAttribute e DeprecatedAttribute em cenários WinMD

Detalhes

Quando você cria uma biblioteca de Metadados do Windows (arquivo .winmd), o atributo System.ObsoleteAttribute é exportado como System.ObsoleteAttribute e Windows.Foundation.DeprecatedAttribute.

Sugestão

A recompilação do código-fonte existente que usa o atributo System.ObsoleteAttribute pode gerar avisos durante o consumo desse código do C++/CX ou JavaScript. Não é recomendável aplicar System.ObsoleteAttribute e Windows.Foundation.DeprecatedAttribute ao código em assemblies gerenciados, isso pode gerar avisos de compilação.

Nome	Valor
Escopo	Microsoft Edge
Versão	4.5.1
Tipo	Redirecionando

Entity Framework

A compilação de um edmx do Entity Framework com o Visual Studio 2013 pode falhar com o erro MSB4062 se estiver usando as tarefas EntityDeploySplit ou EntityClean

Detalhes

As ferramentas do MSBuild 12.0 (incluídas no Visual Studio 2013) alteraram os locais do arquivo MSBuild, fazendo com que arquivos de destino do Entity Framework sejam inválidos. O resultado é que as tarefas EntityDeploySplit e EntityClean falham porque não conseguem localizar Microsoft.Data.Entity.Build.Tasks.dll. Observe que essa interrupção se deve a uma alteração no conjunto de ferramentas (MSBuild/VS), e não por uma mudança no .NET Framework. Ela ocorrerá apenas no upgrade das ferramentas do desenvolvedor, não simplesmente no upgrade do .NET Framework.

Sugestão

Os arquivos de destino do Entity Framework foram corrigidos para trabalhar com o novo layout do MSBuild a partir do .NET Framework 4.6. O upgrade para essa versão do Framework corrigirá esse problema. Como alternativa, esta solução alternativa pode ser usada para aplicar patches diretamente aos arquivos de destino.

Nome	Valor
Escopo	Principal
Versão	4.5.1
Tipo	Redirecionando

MSBuild

A tarefa ResolveAssemblyReference agora avisa sobre dependências com arquitetura incorreta

Detalhes

A tarefa emite um aviso, MSB3270, que indica que uma referência ou qualquer uma de suas dependências não corresponde à arquitetura do aplicativo. Por exemplo, isso ocorrerá se um aplicativo que tenha sido compilado com a opção AnyCPU incluir uma referência x86. Esse cenário pode resultar em uma falha do aplicativo no tempo de execução (nesse caso, se o aplicativo for implantado como um processo x64).

Sugestão

Há duas áreas de impacto:

• A recompilação gerencia os avisos que não foram exibidos quando o aplicativo foi compilado com uma versão anterior do MSBuild. Entretanto, como o aviso identifica uma possível fonte de falha no runtime, ele deve ser investigado e resolvido.
• Se os avisos forem tratados como erros, o aplicativo não será compilado.

Nome	Valor
Escopo	Secundária
Versão	4.5.1
Tipo	Redirecionando

Windows Presentation Foundation (WPF)

Não há suporte para a associação de dados bidirecionais para uma propriedade com um setter não público

Detalhes

A tentativa de associar dados a uma propriedade sem um setter público nunca foi um cenário com suporte. A partir do .NET Framework 4.5.1, esse cenário vai gerar uma System.InvalidOperationException. Observe que essa nova exceção será gerada somente para aplicativos destinados especificamente ao .NET Framework 4.5.1. Se um aplicativo for destinado ao .NET Framework 4.5, a chamada será permitida. Se o aplicativo não for destinado a uma versão específica do .NET Framework, a associação será tratada como unidirecional.

Sugestão

O aplicativo deve ser atualizado para usar a associação unidirecional ou expor publicamente o setter da propriedade. Como alternativa, o direcionamento ao .NET Framework 4.5 fará com que o aplicativo demonstre o comportamento antigo.

Nome	Valor
Escopo	Secundária
Versão	4.5.1
Tipo	Redirecionando

APIs afetadas

• BindingMode.TwoWay

.NET Framework 4.5.2

Visual Basic .NET

VB.NET não é mais compatível com a qualificação do namespace parcial para APIs System.Windows

Detalhes

Começando com o .NET Framework 4.5.2, os projetos VB.NET não podem especificar APIs System.Windows com namespaces parcialmente qualificados. Por exemplo, fazer referência a Windows.Forms.DialogResult falhará. Em vez disso, o código deve fazer referência ao nome totalmente qualificado (DialogResult) ou importar o namespace específico e simplesmente fazer referência a System.Windows.Forms.DialogResult.

Sugestão

O código deve ser atualizado para fazer referência as APIs System.Windows com nomes simples (e importando o namespace relevante) ou com nomes totalmente qualificados.

Nome	Valor
Escopo	Secundária
Versão	4.5.2
Tipo	Redirecionando

Windows Forms

DataObject.GetData agora recupera dados como UTF-8

Detalhes

Para aplicativos destinados ao .NET Framework 4 ou que são executados no .NET Framework 4.5.1 ou em versões mais recentes, DataObject.GetData recupera dados formatados em HTML como uma cadeia de caracteres ASCII. Como resultado, caracteres não ASCII (caracteres cujos códigos ASCII são maiores que 0x7F) são representados por dois caracteres aleatórios.

Para aplicativos direcionados ao .NET Framework 4.5 ou posteriores e executados no .NET Framework 4.5.2, o DataObject.GetData recupera dados formatados em HTML como UTF-8, que representam caracteres maiores que 0x7F corretamente.

Sugestão

Se você implementou uma solução alternativa para o problema de codificação com cadeias de caracteres formatadas em HTML (por exemplo, codificando explicitamente a cadeia de caracteres HTML recuperada da área de transferência enviando-a para System.Text.UTF8Encoding.GetString(Byte[], Int32, Int32)) e estiver redirecionando seu aplicativo da versão 4 para a versão 4.5, essa solução deverá ser removida. Se o comportamento antigo for necessário por algum motivo, o aplicativo poderá ser destinado ao .NET Framework 4.0 para obtê-lo.

Nome	Valor
Escopo	Microsoft Edge
Versão	4.5.2
Tipo	Redirecionando

APIs afetadas

• DataObject.GetData(String)
• DataObject.GetData(Type)
• DataObject.GetData(String, Boolean)

Windows Workflow Foundation (WF)

WorkflowDesigner.Load não remove a propriedade de símbolo

Detalhes

Ao destinar para o .NET Framework 4.5 no designer de fluxo de trabalho e carregar um fluxo de trabalho 3.5 hospedado novamente com o método Load(), uma System.Xaml.XamlDuplicateMemberException é gerada durante o salvamento do fluxo de trabalho.

Sugestão

Esse bug se manifesta somente no direcionamento do .NET Framework 4.5 no designer de fluxo de trabalho, de modo que a solução alternativa é definir o WorkflowDesigner.Context.Services.GetService<DesignerConfigurationService>().TargetFrameworkName para o .NET Framework 4.0.

Como alternativa, é possível evitar o problema usando o método Load(String) para carregar o fluxo de trabalho, em vez de Load().

Nome	Valor
Escopo	Principal
Versão	4.5
Tipo	Redirecionando

APIs afetadas

• WorkflowDesigner.Load()