Set de remedieri rapide 2996568 pentru .NET Framework 4.5, 4.5.1 și 4.5.2 pe Vista SP2, Windows Server 2008 SP2, Windows 7 SP1 și Windows Server 2008 R2 SP1

Problema 1

Această remediere rapidă rezolvă următoarele două probleme threading în System.IO.Packaging atunci când utilizați .NET Framework 4.5, .NET Framework 4.5.1 sau .NET Framework 4.5.2.

• O blocare poate apărea atunci când utilizați mare pachetelor pe fire separate. System.IO.Packaging utilizează IsolatedStorage pentru pachetele care sunt mai mult de 10 megaocteți (MO). Când două sau mai multe fire utilizați pachete mari, o blocare poate apărea chiar dacă pachetele sunt independente. Blocare fatală implică două fire. Una este în aşteptare în IsolatedStorageFile.Lock în timp ce alte așteaptă în altă metodă de a clasei IsoloatedStorageFile . Această problemă este rezolvată prin adăugarea sincronizare la System.IO.Packaging pentru a evita problema în IsolatedStorageFile.

• Excepții se poate produce atunci când regăsiți PackageProperties la pachetele care sunt deschise pe fire separată, chiar dacă pachetele sunt independente. Cele mai frecvente apel stive care apar din această sunt după cum urmează: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()
  Această problemă este cauzată de probleme privind împărțirea pe o resursă partajată interne și s-a rezolvat oferindu-o copie a resurselor că fiecare pachet.

Problema 2

O aplicație Windows Presentation Foundation (WPF) poate utiliza o cantitate mare de memorie când se primește multe cereri de serviciul UIAutomation . Memoria aparține obiectele care sunt de System.Threading de nume. Aceasta include System.Threading.CancellationTokenSource, System.Threading.TimerQueueTimer, System.Threading.Timerși mai multe alte clase asociate.

Acestea sunt obiecte care sunt alocate în numele WPF când WPF primește o solicitare de activitate UIAutomation . Acestea sunt lansate în cele din urmă până la expirare pentru solicitarea termenului (de obicei trei minute). Dacă solicitările ajunge rapid, aplicația pare să fie scurgeri de memorie sau folosind mai multă memorie decât ceea ce este rezonabil (cât 500 MB).

Această problemă este rezolvată prin eliberarea obiectele când solicitarea este terminată, în loc de aşteptare pentru termenul de expirare.

Problema 3

Într-o aplicație de WPF, când Introduceți textul utilizând coreeană Input Method Editor (IME), proprietatea Text de un editabile casetă combo nu se modifică corect în unele cazuri.

Această problemă poate prezenta simptome diferite, şi care depinde de modul aplicație (sau autor de control) a configurat casetă combo. De exemplu:

• După ce tastați și fila departe (sau mutați focalizarea la alt control), textul afișat de casetă combo revine la șir vid, sau la valoarea pe care a avut înainte de tastare.

• Caracteristica TextSearch de casetă combo care se comportă incorect. Nu corespunde prefixul care a fost introdusă sau se potriveşte cu un element de legătură.

Această problemă este rezolvată prin modificarea logica pentru a gestiona momentul IME coreeană care diferă ușor de alte IME.

Problema 4

După ce utilizați o notă pentru a efectua o operațiune de glisare și fixare într-o aplicație de WPF, următorul gest de atingere este ignorat.

Această problemă este rezolvată prin restabilirea stării intern de atingere intrare rutina de tratare, când se termină operațiunea de glisare și fixare. În acest mod, se calculează poziția următorul gest de atingeri corect.

Problema 5

Implementarea unui nou AuthenticationManager pot fi activate opțional pentru a obține performanța semnificativ atunci când lucrați cu particularizate IAuthenticationModules.

Notă Mari riscuri de securitate apar dacă codul nu este proiectat pentru a fi sigur fir. Modificare de comportament majoră se află pe metodele PreAuthenticate și autentificare . Anterior acesta a fost garantează că codul se executa serial (o blocare globală a fost luată). În noua implementare, nu se face nici o blocare și codul de client trebuie să garanteze siguranța fir.
În plus, cu noua implementare, dimensiunea memoriei cache a PrefixLookup poate fi controlată prin registry.

Următoarele chei de registry poate fi utilizat pentru activarea și configurarea lungimea maximă a PrefixLookup:

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

• Configurare aplicaţie 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
  

Setări globale au prioritate asupra Setări aplicație locală. Setări globale şi locale aplicații poate fi amestecat. PrefixLookupMaxCount nu vor fi afectate dacă setarea HighPerformance aplicație global sau local este setat la DWORD 1.

Problema 6

Să presupunem că executați o aplicație care se bazează pe .NET Framework 4.5, .NET Framework 4.5.1 sau .NET Framework 4.5.2. Aplicația lansează o excepţie într-o metodă gestionate care a fost apelat de cod nativ și s-a introdus o interfață COM de trimitere. În această situație, aplicația se poate bloca.

De exemplu: O aplicație care sunt scrise în VB6 apelează DLL C#. Dacă aplicația și DLL sunt compilate în modul de lansare, atunci când o excepție este lansată în codul C#, o violare de acces și aplicația se blochează.

Problema 7

Când flux de lucru bazate pe XAML proiecte dura mai mult timp decât implicit creditare time (cinci minute) de la distanță obiectele care sunt definite de activități pentru a construi XAML, primiți un mesaj de eroare asemănător cu următorul:

După aplicarea acestei remedieri rapide, aveți posibilitatea să definiți propriul creditare timpul (în minute) definind variabila de mediu care este denumit XamlBuildTaskRemotingLeaseLifetimeInMinutes.

Pentru a seta MSBuild variabila de mediu într-un fișier de proiect, trebuie să includeți următoarele informații în fișierul de proiect:<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 în acest exemplu este MySetEnv. Poate fi setată la orice șir de caractere care este valid pentru numele de activitate. Acest exemplu stabilește data de creditare la 1,440 minute (o zi) înainte de construirea de proiect şi se setează la nul după construirea. Dacă există mai multe proiecte care necesită timp de creditare, fiecare proiect are nevoie de această configurație.

Problema 8

Atunci când utilizaţi AJAX postback într-o pagină, uneori postback este Redirecționat către un alt URL. Aveți posibilitatea să obțineți RedirectLocation într-o HttpModule prin HttpContext.Items["System.Web.UI.PageRequestManager:AsyncPostBackRedirectLocation"].