Hotfixrollup 2996568 für.NET Framework 4.5 und 4.5.1, 4.5.2 auf Vista SP2, Windows Server 2008 SP2, Windows 7 SP1 und Windows Server 2008 R2 SP1

Problem 1

Dieser Hotfix behebt die folgenden zwei Threadingprobleme in System.IO.Packaging bei Verwendung von.NET Framework 4.5,.NET Framework 4.5.1 oder.NET Framework 4.5.2.

• Ein Deadlock kann auftreten, wenn Sie große Pakete in separaten Threads verwenden. System.IO.Packaging verwendet IsolatedStorage für Pakete, die größer als 10 Megabyte (MB). Wenn zwei oder mehr Threads große Pakete verwenden, kann ein Deadlock auftreten, auch wenn die Pakete unabhängig sind. Der Deadlock umfasst zwei Threads. Eine wartet IsolatedStorageFile.Lock während der andere in einer anderen Methode der IsoloatedStorageFile -Klasse wartet. Dieses Problem wurde behoben, System.IO.Packaging Problembehebung in IsolatedStorageFileSynchronisierung hinzu.

• Ausnahmen auftreten, wenn Sie PackageProperties von Paketen, die in separaten Threads geöffnet abrufen, auch wenn die Pakete unabhängig sind. Die am häufigsten verwendeten Aufruflisten in diesem Zusammenhang sind: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()
  Dieses Problem entsteht durch Konflikte auf eine freigegebene Ressource interne und indem jedem Paket eine Kopie der Ressource aufgelöst.

Problem 2

Windows Presentation Foundation (WPF)-Anwendung können viel Speicherplatz viele Anfragen für UIAutomation -Dienst empfängt. Der Speicher Objekte System.Threading -Namespace gehört. Dazu gehören System.Threading.CancellationTokenSource, System.Threading.TimerQueueTimer, System.Threading.Timerund verschiedene andere verwandten Klassen.

Dies sind Objekte, die für WPF WPF erhält eine Anforderung für die UIAutomation -Aktivität zugewiesen werden. Sie werden schließlich freigegeben, bis das Timeout für die Anforderung (in der Regel drei Minuten) Frist. Anfragen schnell ankommen, die Anwendung scheint Speicherverlustes oder mehr Arbeitsspeicher als ist angemessen (500 MB).

Dieses Problem wird behoben, durch die Objekte freigeben, nach Abschluss die Anforderung Frist Timeouts warten.

Problem 3

In einer WPF-Anwendung bei Texteingabe mit den koreanischen Eingabe-Editor (IME), wird die Text -Eigenschaft eines bearbeitbaren Kombinationsfeld nicht korrekt teilweise geändert.

Dieses Problem kann verschiedene Symptome auftreten und, die Anwendung (oder dem Steuerelemententwickler) ComboBoxKonfiguration hat abhängig. Beispiel:

• Nachdem Sie eingeben und entfernt Registerkarte (oder den Fokus auf ein anderes Steuerelement), wird der Anzeigetext ComboBox auf eine leere Zeichenfolge oder dem Wert vor der Eingabe.

• Funktion TextSearch ComboBox verhält falsch. Entspricht nicht das Präfix eingegeben wurde oder es unabhängige Element entspricht.

Dieses Problem wird behoben, durch eine Änderung der Logik für das Timing des koreanischen IME aufzunehmen, die leicht von anderen IMEs abweicht.

Problem 4

Nachdem eine Fingereingabe Drag und Drop-Operationen in einer WPF-Anwendung ausführen, wird die nächste Touch Bewegung ignoriert.

Dieses Problem wird behoben, durch den internen Zustand des Touch input Handler wiederherstellen, wenn Drag & Drop-Vorgang abgeschlossen ist. Auf diese Weise berechnet die Position des nächsten Touch Bewegung richtig.

Problem 5

Eine neue CustomTargetNameDictionary -Implementierung kann zu erheblichen Performance beim Arbeiten mit benutzerdefinierten IAuthenticationModulesoptional aktiviert werden.

Hinweis Wichtige Sicherheitsrisiken angezeigt, wenn der Code nicht threadsicher sein soll. Die wichtigsten verhaltensänderung befindet sich Methoden PreAuthenticate und authentifizieren . Zuvor wurde sichergestellt, dass der Code seriell ausgeführt wurde (eine globale Sperre stammt). Die neue Implementierung keine Sperre, und Kundencode muss die Threadsicherheit garantieren.
Darüber hinaus kann neue Implementierung die PrefixLookup Cachegröße Registrierung gesteuert werden.

Aktivieren und konfigurieren die maximale Länge des PrefixLookupkönnen die folgenden Registrierungsschlüssel verwendet werden:

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

• Lokale Konfiguration[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
  

Globale Einstellungen haben Vorrang vor lokalen Einstellungen. Globale und lokale Einstellungen können gemischt werden. PrefixLookupMaxCount nicht wirkt, wenn die globale oder lokale Anwendung leistungsstarker auf DWORD 1eingestellt ist.

Problem 6

Angenommen Sie, eine Anwendung auszuführen, die auf.NET Framework 4.5,.NET Framework 4.5.1 oder.NET Framework 4.5.2 basiert. Die Anwendung löst eine Ausnahme in einer verwalteten Methode, die von systemeigenem Code aufgerufen wurde und eine COM-Schnittstelle als Verweis übergeben wurde. In diesem Fall kann die Anwendung abstürzen.

Beispiel: eine Anwendung, die in VB6 geschrieben Ruft eine C# DLL. Die Anwendung und die DLL im Release-Modus kompiliert werden, wenn in der C#-Code eine Ausnahme ausgelöst wird, tritt eine und die Anwendung abstürzt.

Frage 7

Bei Workflow XAML-basierte Projekte länger als die standardmäßige Leasedauer (fünf Minuten) entfernte Objekte, die die Aufgaben zum Erstellen von XAML definiert sind, erhalten Sie eine Fehlermeldung, die der folgenden ähnelt:

Nach Installation dieses Hotfixes können Sie eigene Leasing-Zeit (in Minuten) definieren, definieren Sie die Umgebungsvariable mit dem Namen XamlBuildTaskRemotingLeaseLifetimeInMinutes.

Zum Festlegen von Umgebungsvariablen in einer Projektdatei MSBuild müssen Sie die folgende Informationen in der Projektdatei:<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>
Der TaskName in diesem Beispiel ist MySetEnv. Eine beliebige Zeichenfolge kann festgelegt werden, die für Aufgaben gültig ist. Dieses Beispiel legt die Leasing-Zeit auf 1.440 Minuten (1 Tag) vor dem Erstellen des Projekts und es auf null nach dem Bau. Wenn es mehrere Projekte, die Leasing-Zeit verlängern müssen, benötigt jedes Projekt dieser Konfiguration.

Problem 8

Bei Verwendung von AJAX-Postbacks auf einer Seite wird auch das Postback zu einem anderen URL umgeleitet. Erhalten Sie die RedirectLocation in ein HttpModule durch HttpContext.Items["System.Web.UI.PageRequestManager:AsyncPostBackRedirectLocation"].