Pacote cumulativo de hotfixes 2996568 para o.NET Framework 4.5 e 4.5.1 4.5.2 no Vista SP2 e Windows Server 2008 R2 SP1, Windows 7 SP1 e Windows Server 2008 SP2

Problema 1

Esse hotfix resolve os seguintes problemas de threads dois em System.IO.Packaging quando você usar o.NET Framework 4.5, o.NET Framework 4.5.1 ou o.NET Framework 4.5.2.

• Um deadlock pode ocorrer quando você usar pacotes grandes em segmentos separados. System.IO.Packaging usa IsolatedStorage para pacotes maiores que 10 megabytes (MB). Quando dois ou mais threads usam pacotes grandes, um deadlock pode ocorrer mesmo que os pacotes são independentes. O deadlock envolve dois segmentos. Um está aguardando em IsolatedStorageFile.Lock , enquanto a outra está aguardando em outro método da classe IsoloatedStorageFile . Esse problema é corrigido pela adição de sincronização System.IO.Packaging para evitar o problema no IsolatedStorageFile.

• Exceções podem ocorrer quando você recupera PackageProperties de pacotes que são abertos em segmentos separados, mesmo que os pacotes são independentes. As pilhas de chamadas mais comuns que surgem com isso são as seguintes:System.Xml.XmlException: Unrecognized root element in Core Properties part. Line 2, position 2. atMS.Internal.IO.Packaging.PartBasedPackageProperties.ParseCorePropertyPart(PackagePart part) at
  System.IO.Packaging.Package.get_PackageProperties()
  System.ArgumentOutOfRangeException: Specified argument was out of the range of valid values. Parameter name: id atMS.Internal.IO.Packaging.PartBasedPackageProperties.ParseCorePropertyPart(PackagePart part) at
  System.IO.Packaging.Package.get_PackageProperties()
  Esse problema é causado pela contenção em um recurso compartilhado interno e resolvido, oferecendo uma cópia do recurso de cada pacote.

Problema 2

Um aplicativo Windows Presentation Foundation (WPF) pode usar uma grande quantidade de memória quando recebe muitas solicitações para o serviço de automação da IU . Pertence a memória para os objetos que estão no namespace System. Threading . Isso inclui System.Threading.CancellationTokenSource, System.Threading.TimerQueueTimer, System.Threading.Timere várias outras classes relacionadas.

Esses são os objetos que são alocados em nome do WPF ao WPF recebe uma solicitação para a atividade de automação da IU . Eventualmente forem lançadas até que o prazo de tempo limite da solicitação expire (geralmente de três minutos). Se as solicitações chegam rapidamente, o aplicativo parece estar causando um vazamento de memória ou usar mais memória do que o que é razoável (até 500 MB).

Este problema é resolvido, liberando os objetos quando a solicitação for concluída, em vez de aguardar o prazo de tempo limite.

Problema 3

Em um aplicativo do WPF, quando você inserir texto usando a entrada método Editor (IME) coreano, a propriedade Text de uma caixa de combinação editável não é alterada corretamente em alguns casos.

Esse problema pode apresentar outros sintomas diferentes e que depende de como o aplicativo (ou o autor do controle) configurou o ComboBox. Por exemplo:

• Depois que você digitar e guia imediatamente (ou move o foco para um outro controle), o texto exibido do ComboBox será revertido para a sequência de caracteres vazia ou o valor que tinha antes da digitação.

• O recurso de TextSearch do ComboBox se comporta incorretamente. Não coincide com o prefixo foi inserido ou corresponde a um item relacionado.

Este problema é resolvido pelo corrigindo lógica para acomodar a temporização do IME coreano um pouco diferente dos outros IMEs.

Problema 4

Depois que você usar um toque para executar uma operação de arrastar e soltar em um aplicativo WPF, o próximo gestos de toque é ignorado.

Este problema é resolvido restaurando o estado interno do manipulador de entrada de toque quando a operação de arrastar-e-soltar é concluída. Dessa maneira, ele calcula a posição do gesto de toque na próxima corretamente.

Problema 5

Uma nova implementação de AuthenticationManager pode ser opcionalmente ativada para obter significativos de desempenho quando você trabalha com personalizado IAuthenticationModules.

Observação: Principais riscos de segurança são exibidos se o código não foi projetado para ser thread-safe. A alteração de comportamento principal está localizada nos métodos PreAuthenticate e autenticar . Anteriormente foi garantir que o código estava sendo executado em série (um bloqueio global foi obtido). Na nova implementação, nenhum bloqueio é utilizado e o código do cliente deve garantir a segurança de segmentos.
Além disso, com a nova implementação, o tamanho do cache de PrefixLookup pode ser controlado por meio do registro.

As seguintes chaves de registro podem ser usadas para habilitar e configurar o tamanho máximo de PrefixLookup:

• Configuração global[HKEY_LOCAL_MACHINE\SOFTWARE[\Wow6432Node]\Microsoft\.NETFramework\v4.0.30319]"System.Net.AuthenticationManager.HighPerformance"=dword:00000001
  "System.Net.AuthenticationManager.PrefixLookupMaxCount"=dword:00010000
  

• Configuração de aplicativo local[HKEY_LOCAL_MACHINE\SOFTWARE[\Wow6432Node]\Microsoft\.NETFramework\v4.0.30319\System.Net.AuthenticationManager.HighPerformance]"c:\myapp\myapp.exe"=dword:00000001
  [HKEY_LOCAL_MACHINE\SOFTWARE[\Wow6432Node]\Microsoft\.NETFramework\v4.0.30319\System.Net.AuthenticationManager.PrefixLookupMaxCount]
  "c:\myapp\myapp.exe"=dword:00010000
  

Configurações globais têm prioridade sobre as configurações do aplicativo local. Configurações de aplicativo global e local podem ser combinadas. PrefixLookupMaxCount não será afetado se a configuração de HighPerformance aplicativo global ou local está definida para DWORD 1.

Problema 6

Suponha que você execute um aplicativo que se baseia no.NET Framework 4.5, o.NET Framework 4.5.1 ou o.NET Framework 4.5.2. O aplicativo gera uma exceção em um método gerenciado que foi chamado a partir de código nativo e foi passado uma interface COM por referência. Nessa situação, o aplicativo pode falhar.

Por exemplo: um aplicativo que é escrito em VB6 chama uma DLL C#. Se o aplicativo e DLL são compilados no modo release, quando uma exceção é lançada no código C#, ocorre uma violação de acesso e o aplicativo falha.

Problema 7

Quando os projetos de fluxo de trabalho baseados em XAML levam mais tempo do que o tempo de concessão padrão (cinco minutos) dos objetos remotos são definidos pelas tarefas para a criação de XAML, você recebe uma mensagem de erro semelhante à seguinte:

Depois de aplicar esse hotfix, você pode definir seu próprio tempo de concessão (em minutos), definindo a variável de ambiente denominada XamlBuildTaskRemotingLeaseLifetimeInMinutes.

Para definir a variável de ambiente em um arquivo de projeto para MSBuild, você deve incluir as seguintes informações no seu arquivo de projeto:<Project ...> <UsingTask TaskName="MySetEnv" TaskFactory="CodeTaskFactory" AssemblyFile="$(MSBuildToolsPath)\Microsoft.Build.Tasks.v4.0.dll" >
<ParameterGroup>
<Name Required="true" />
<Value Required="false" />
</ParameterGroup>
<Task>
<Code Type="Fragment" Language="cs">System.Environment.SetEnvironmentVariable(Name, Value);</Code>
</Task>
</UsingTask>
...
...
<Target Name="BeforeBuild">
<MySetEnv Name="XamlBuildTaskRemotingLeaseLifetimeInMinutes" Value="1440" />
</Target>
<Target Name="AfterBuild">
<MySetEnv Name="XamlBuildTaskRemotingLeaseLifetimeInMinutes" Value="" />
</Target>
</Project>
TaskName neste exemplo é MySetEnv. Ela pode ser definida para qualquer sequência que é válida para nomes de tarefas. Este exemplo define o tempo de concessão para 1.440 minutos (um dia) antes da criação do projeto e define-a como nulo após a construção. Se houver vários projetos que necessita para estender o tempo de concessão, cada projeto deve essa configuração.

Problema 8

Quando você usa o postback AJAX em uma página, às vezes, a postagem é redirecionada para outra URL. Você pode obter o RedirectLocation em um HttpModule por meio de HttpContext.Items["System.Web.UI.PageRequestManager:AsyncPostBackRedirectLocation"].