2996568 накопительный пакет исправлений для .NET Framework 4.5, 4.5.1 и 4.5.2 в Vista SP2, Windows Server 2008 SP2, Windows 7 с пакетом обновления 1 и Windows Server 2008 R2 с пакетом обновления 1

Проблема 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 . В конечном итоге они выпускаются до истечения срока ожидания для запроса (обычно трех минут). Если запросы поступают быстро, кажется, что приложение нехватку памяти или использовать больше памяти, чем то, что является разумным (сильнее, чем 500 МБ).

Эта проблема решена, выпустив объектов после завершения запроса, а не ожидать тайм-аута крайнего срока.

Проблема 3

В приложении WPF при вводе текста с помощью корейского ввода метода (IME), свойство Text элемента управления ComboBox редактируемый не изменяется правильно в некоторых случаях.

Проблемы возникают различные проблемы, и это зависит от того, как приложение (или автором элемента управления) настроил ComboBox. Например:

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

• Некорректное поведение функции TextSearch ComboBox . Не соответствует префикс, который был введен или он соответствует несвязанных элементов.

Данная проблема устранена в исправлении логики, в соответствии с временем, немного отличается от других редакторы методов ввода 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
  

Глобальные параметры имеют приоритет над параметрами локального приложения. Параметры глобальных и локальных приложений могут быть смешанными. Если параметр высокопроизводительную глобальные или локальные приложения установлено значение DWORD 1 PrefixLookupMaxCount не затрагиваются.

Проблема 6

Предполагается выполнение приложения на основе .NET Framework 4.5, платформа.NET Framework 4.5.1 или платформа.NET Framework 4.5.2. Приложение создает исключение в управляемый метод, была вызвана из машинного кода и COM-интерфейс был передан по ссылке. В этом случае приложение может аварийно завершить работу.

Например: приложения, написанного на VB6 вызывает библиотеку DLL C#. Если приложение и библиотека DLL компилируются в режиме выпуска при исключения в коде C#, происходит нарушение прав доступа и завершает работу приложения.

Проблема 7

При удаленных объектов, которые определяются задачи для создания XAML проектов рабочих процессов на основе XAML занять дольше, чем время аренды по умолчанию (5 минут), появляется сообщение об ошибке, подобное приведенному ниже:

После установки данного исправления можно определить собственное время аренды (в минутах) путем определения переменной среды с именем 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>
Имя задачи в данном примере — MySetEnv. Его можно задать любую строку, допустимую для названия задач. Этот пример задает время аренды 1440 минут (один день) перед построением проекта и задает для него значение null после построения. Если имеются несколько проектов, которые требуется расширить время аренды, каждый проект должен этой конфигурации.

Проблема 8

При использовании обратной передачи AJAX на странице иногда обратный запрос перенаправляется на другой URL-адрес. Можно получить RedirectLocation в HttpModule через HttpContext.Items["System.Web.UI.PageRequestManager:AsyncPostBackRedirectLocation"].