Кумулативен спешна корекция 2996568 за .NET Framework 4.5 и 4.5.1, 4.5.2 Vista SP2, Windows Server 2008 SP2, Windows 7 SP1 и Windows Server 2008 R2 SP1

Проблем 1

Тази актуална корекция решава следните две резби проблеми в System.IO.Packaging , когато използвате .NET Framework 4.5, .NET Framework 4.5.1 или .NET Framework 4.5.2.

• Блокиране може да възникне, когато използвате големи пакети на отделни теми. System.IO.Packaging използва IsolatedStorage пакети, които са по-големи от 10 мегабайта (МБ). Когато две или повече нишки използват големи пакети, блокиране може да възникне дори ако пакетите са независими. Блокиране включва две теми. Един чака в IsolatedStorageFile.Lock а другата очаква друг метод на класа IsoloatedStorageFile . Този проблем е разрешен чрез добавяне на синхронизация System.IO.Packaging за избягване на проблема в IsolatedStorageFile.

• Изключения може да възникне, когато извличате PackageProperties от пакети, които са отворени на отделни теми, дори ако пакетите са независими. Най-често срещаните повикване стека, възникващи от това са както следва: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()
  Този проблем се причинява от спор на вътрешен споделен ресурс и е разрешен чрез пакет за всеки екземпляр от ресурса.

Проблем 2

Приложение на Windows Presentation Foundation (WPF) могат да използват голям обем памет, когато получава много заявки за UIAutomation услуга. Паметта принадлежи към обекти от System.Threading имена. Това включва System.Threading.CancellationTokenSource, System.Threading.TimerQueueTimer, System.Threading.Timerи няколко други свързани класове.

Това са обекти, които са разпределени от името на WPF при WPF получава искане за UIAutomation дейност. Накрая са пуснати до времето за изчакване на заявката изтече (обикновено 3 минути). Ако исканията пристигат бързо, приложението изглежда е изтичане на памет или използва повече памет от това, което е разумно (колкото е 500 MB).

Този проблем е разрешен чрез освобождаване на обекти, когато искането, вместо да чакате за изчакване срок.

Проблем 3

В WPF приложение когато въвеждате текст с помощта на корейски въвеждане редактор (IME), свойството текст може да се редактира разгъващ се списък не се променя правилно в някои случаи.

Този проблем може да имат различни симптоми и това зависи от приложението (или автор) е конфигурацията на разгъващ се списък. Например:

• След като въведете и раздела далеч (или преместите фокуса към друг контрол), текст на разгъващ се списък се връща празен низ или стойност, която е имала преди въвеждането.

• Функцията TextSearch на разгъващ се списък на неправилно поведение. Не съвпада префикс, който е въведен или тя съпоставя несвързани елемент.

Този проблем е решен чрез изменение на логиката за времето на корейски, различен от други IME IME.

Проблем 4

След като използвате връзка за операция плъзгане и пускане в WPF приложение, следващото докосване жест се игнорира.

Този проблем е разрешен чрез вътрешно състояние на манипулатор на въвеждане докосване при операцията за плъзгане и пускане. По този начин тя изчислява позицията на следващия докосване жест правилно.

Проблем 5

Ново AuthenticationManager изпълнение може да бъде разрешен по желание да получат значителни производителността при работа с потребителски IAuthenticationModules.

Забележка: Основните рискове за сигурността се появи, ако кодът не е проектиран да бъде съвместими. Промяната на основните поведение се намира на PreAuthenticate и удостоверяване методи. Преди това е гарантира, че кода е последователно изпълнение (заключване на глобалния бе). В новия изпълнение заключване не се приема и код на клиента трябва да гарантира сигурността нишка.
Освен това с ново изпълнение, размера на кеш паметта PrefixLookup може да се контролира чрез системния регистър.

Следните ключове на системния регистър може да се използва за разрешаване и конфигуриране на максималната дължина на PrefixLookup:

• Общо конфигуриране[HKEY_LOCAL_MACHINE\SOFTWARE[\Wow6432Node]\Microsoft\.NETFramework\v4.0.30319]"System.Net.AuthenticationManager.HighPerformance"=dword:00000001
  "System.Net.AuthenticationManager.PrefixLookupMaxCount"=dword:00010000
  

• Конфигуриране на локални приложения[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
  

Глобални настройки имат приоритет пред настройките за локално приложение. Настройки на глобални и локални приложения могат да бъдат смесени. PrefixLookupMaxCount няма да бъдат засегнати, ако настройката на високоефективна глобално или локално приложение е DWORD 1.

Въпрос 6

Да предположим, че изпълнявате приложение, което се основава на .NET Framework 4.5, .NET Framework 4.5.1 или .NET Framework 4.5.2. Приложението води до възникване на изключение в управлявана метод, който е наречен от основните код и е преминал интерфейс COM с препратка. В тази ситуация може да блокира приложението.

Например: приложение, което се записва в VB6 извиква C# DLL. Ако приложението и DLL се събират в release режим, когато хвърлено в C# код, възниква нарушаване на достъпа и приложението се срива.

Брой 7

Когато проекти поток XAML отнеме повече време от времето по подразбиране лизинг (пет минути) на отдалечени обекти, които са дефинирани от задачи за изграждане на XAML, получавате съобщение за грешка, подобно на следното:

След като приложите тази актуална корекция, можете да зададете собствен лизинг време (в минути) чрез задаване на променливата на средата, която се нарича XamlBuildTaskRemotingLeaseLifetimeInMinutes.

За да зададете променливата на средата във файла на проекта за MSBuild, трябва да съдържа следната информация във вашия файл с проект:<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 в този пример е MySetEnv. Това може да се настрои произволен низ, който е валиден за имената на задачите. Този пример задава лизинг време 1,440 минути (един ден) преди изграждането на проекта и се определя на нула след building. Ако има няколко проекти, която изисква да се удължи времето на лизинг, всеки проект се нуждае от тази конфигурация.

Брой 8

Когато използвате AJAX обратното публикуване в страница, понякога обратното публикуване е пренасочване към друг URL. Можете да получите RedirectLocation в HttpModule чрез HttpContext.Items["System.Web.UI.PageRequestManager:AsyncPostBackRedirectLocation"].