Conjunto de correcções 2996568 para o .NET Framework 4.5, 4.5.1 e 4.5.2 na Vista SP2, Windows Server 2008 SP2, Windows 7 SP1 e Windows Server 2008 R2 SP1

Problema 1

Esta correcção resolve os seguintes problemas threads System.IO.Packaging dois quando utiliza a 4.5 do quadro de .NET, o .NET Framework 4.5.1 ou o .NET Framework 4.5.2.

• Um bloqueio pode ocorrer quando utiliza pacotes grandes em threads separados. System.IO.Packaging utiliza IsolatedStorage para pacotes que são maiores do que 10 megabytes (MB). Quando dois ou mais módulos utilizam embalagens grandes, um impasse pode ocorrer, mesmo se os pacotes são independentes. O bloqueio envolve dois threads. Um aguarda no IsolatedStorageFile.Lock enquanto outro está à espera de outro método da classe IsoloatedStorageFile . Este problema é corrigido através da adição de sincronização para System.IO.Packaging para evitar o problema no IsolatedStorageFile.

• Excepções podem ocorrer quando obtém PackageProperties de pacotes que são abertos no threads separados, mesmo que os pacotes são independentes. As pilhas de chamadas mais comuns que possam surgir deste são os 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()
  Este problema é causado por contenção num recurso partilhado interno e for resolvido, atribuindo a cada pacote de uma cópia do recurso.

Problema 2

Uma aplicação de apresentação de Windows Foundation (WPF) pode utilizar uma grande quantidade de memória quando recebe pedidos de muitos para o serviço UIAutomation . Pertence a memória para os objectos que são do espaço de nomes System. Threading . Isto inclui System.Threading.CancellationTokenSource, System.Threading.TimerQueueTimer, System.Threading.Timere várias outras classes relacionadas.

Estes são os objectos que estão atribuídos em nome de WPF quando WPF recebe um pedido para a actividade de UIAutomation . Eventualmente, estas são publicadas até que o prazo de tempo limite para pedido expira (normalmente, três minutos). Se os pedidos chegam rapidamente, a aplicação parece ser uma fuga de memória ou utilização de mais memória do que o que é razoável (como muito como 500 MB).

Este problema é resolvido lançando os objectos quando o pedido estiver concluído, em vez de aguardar o prazo de tempo limite.

Problema 3

Numa aplicação de WPF, quando introduz texto, utilizando o coreano IME Input Method Editor (), a propriedade de texto de uma caixa de combinação de editável não é alterada correctamente em alguns casos.

Este problema poderá apresentar sintomas diferentes e que depende da forma como a aplicação (ou o autor de controlo) configurou a caixa de combinação. Por exemplo:

• Depois de escrever e distância de tabulação (ou mover o foco para outro controlo), o texto apresentado de caixa de combinação reverte para a cadeia vazia ou para o valor que tinha antes do escrever.

• A funcionalidade TextSearch da caixa de combinação tem um comportamento incorrectamente. Não coincide com o prefixo que foi introduzido ou corresponde a um item independente.

Este problema é resolvido através de uma alteração lógica para acomodar a temporização do IME coreano que é ligeiramente diferente das outros IME.

Problema 4

Depois de utilizar um toque para efectuar uma operação de arrastar e largar numa aplicação de WPF, o gesto de toque seguinte será ignorado.

Este problema é resolvido, restaurando o estado interno do processador de introdução por toque, quando a operação de arrastar e largar é concluída. Desta forma,-calcula a posição do gesto toque seguinte correctamente.

Problema 5

Pode ser activada, opcionalmente, uma nova implementação de AuthenticationManager para obter desempenho significativos quando trabalha com personalizado IAuthenticationModules.

Nota Grandes riscos de segurança aparecem se o código não se destina a ser seguro para thread. A alteração de comportamento principal encontra-se sobre os métodos PreAuthenticate e autenticar . Anteriormente foi garantido que o código em execução em série (um bloqueio global foi retirado). Na nova implementação, sem bloqueio é retirado e o código do cliente deve garantir a segurança de thread.
Além disso, com a implementação de nova, o tamanho da cache PrefixLookup pode ser controlado através do registo.

As seguintes chaves de registo podem ser utilizadas para activar e configurar o comprimento 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 da aplicação 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
  

As definições globais têm prioridade sobre as definições da aplicação local. Definições de aplicações globais e locais podem ser misturadas. PrefixLookupMaxCount não será afectado se a definição de reversa aplicação globais ou locais estiver definida como DWORD 1.

Problema 6

Suponha que executa uma aplicação que se baseia a 4.5 do quadro de .NET, o .NET Framework 4.5.1 ou o .NET Framework 4.5.2. A aplicação lança uma excepção de um método gerido que foi chamado a partir de código nativo e foi transmitido uma interface COM por referência. Nesta situação, a aplicação poderá falhar.

Por exemplo: uma aplicação que está escrita VB6 chama uma DLL do c#. Se a aplicação e as DLL são compilados no modo de edição, quando é iniciada uma excepção no código do c#, ocorre uma violação de acesso e a aplicação falha.

Problema 7

Quando os projectos do fluxo de trabalho baseadas no XAML demoram mais tempo que o tempo de concessão predefinido (cinco minutos) dos objectos remotos que são definidos pelas tarefas para criar o XAML, recebe uma mensagem de erro semelhante à seguinte:

Depois de aplicar esta correcção, pode definir o seu próprio tempo de concessão (em minutos), definindo a variável de ambiente com o nome XamlBuildTaskRemotingLeaseLifetimeInMinutes.

Para definir a variável de ambiente num ficheiro de projecto para MSBuild, tem de incluir as seguintes informações no ficheiro de projecto:<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>
O nome da tarefa neste exemplo é MySetEnv. Pode ser definido para qualquer cadeia que é válida para nomes de tarefas. Este exemplo define o tempo de concessão para 1.440 minutos (um dia) antes da construção do projecto e define-lo para nulo posteriormente à construção. Se existirem vários projectos que necessita para expandir o tempo de concessão, cada projecto tem esta configuração.

Problema 8

Quando utiliza AJAX postback numa página, por vezes, a nova colocação é redireccionada para outro URL. Pode obter o RedirectLocation num HttpModule através de HttpContext.Items["System.Web.UI.PageRequestManager:AsyncPostBackRedirectLocation"].