אוסף תיקונים חמים 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 כאשר תשתמש 4.5 Framework של .NET, .NET Framework 4.5.1 או .NET Framework 4.5.2.

• קיפאון עלולה להתרחש בעת שימוש בחבילות גדולות על הליכי משנה נפרדת. System.IO.Packaging משתמש IsolatedStorage עבור חבילות הגדולים מ- 10 מגה-בתים (MB). כאשר הליכי משנה של שניים או יותר להשתמש בחבילות גדולות, עלולה להתרחש קיפאון, גם אם החבילות עצמאיות. מבוי סתום כוללת שני תהליכים. אחד ממתין ב- 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 Foundation (WPF) עשויים להשתמש כמות גדולה של זיכרון כאשר הוא מקבל בקשות רבות עבור שירות UIAutomation . הזיכרון שייך האובייקטים הנמצאים ממרחב השמות System.Threading . זה כולל System.Threading.CancellationTokenSource, System.Threading.TimerQueueTimer, System.Threading.Timerומספר מחלקות אחרות הקשורות.

אלה הם אובייקטים המוקצות בשם WPF WPF מקבל בקשה עבור פעילות UIAutomation . בסופו של דבר פרסומם עד תאריך יעד של הזמן הקצוב לבקשה פג (בדרך כלל שלוש דקות). אם הבקשות מגיעות במהירות, נראה כי היישום כדי להיות יש דליפת זיכרון, או באמצעות זיכרון מאשר מה סבירים (עד כמה 500 MB).

בעיה זו נפתרת על-ידי שחרור האובייקטים כאשר להשלים את הבקשה, במקום ממתין תאריך היעד של זמן קצוב.

בעיה 3

ביישום WPF, בעת הזנת טקסט באמצעות את קוריאנית עורך שיטות קלט (IME), המאפיין Text של ניתנים לעריכה תיבה משולבת אינו משתנה כראוי במקרים מסוימים.

בעיה זו עשויה שהפגינו סימפטומים שונים ולאחר תלוי כיצד הגדיר את היישום (או המחבר פקד) תיבה משולבת. לדוגמה:

• לאחר הקלד בכרטיסיה במרחק (או להעביר את המוקד לפקד אחר), הטקסט המוצג של תיבה משולבת תחזור למחרוזת ריקה, או על הערך בו היתה לפני הקלדת.

• התכונה TextSearch של תיבה משולבת מתנהגת באופן שגוי. שהיא אינה תואמת לקידומת הוזן, או שהוא תואם פריט לא קשורים.

בעיה זו נפתרת על-ידי amending הלוגיקה כדי להתאים את התזמון של ה-IME לקוריאנית השונה מעט עורכי שיטות קלט אחרים.

בעיה 4

לאחר שימוש של מגע כדי לבצע פעולת גרירה ושחרור ביישום WPF, המערכת תתעלם מחוות מגע הבא.

בעיה זו נפתרת על-ידי שחזור מצבו הפנימי של המטפל קלט מגע בעת השלמת פעולת גרירה ושחרור. באופן זה, היא מחשבת את המיקום של מחוות מגע הבא כראוי.

בעיה 5

ניתן לאפשר הטמעה AuthenticationManager חדשה באופן אופציונלי כדי לקבל ביצועים משמעותיים בעת עבודה עם מותאם אישית IAuthenticationModules.

הערה סיכוני אבטחה ראשיות מופיעות אם הקוד לא נועד להיות בטוח משנה (thread). שינוי התנהגות ראשית ממוקם על שיטות 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 לא יושפעו אם ההגדרה HighPerformance יישום כללי או מקומי מוגדר כ- DWORD 1.

בעיה 6

נניח כי אתה מפעיל יישום המבוסס על 4.5 Framework של .NET, .NET Framework 4.5.1 או .NET Framework 4.5.2. היישום מתריע על חריג בשיטת מנוהל נקראה מקוד טבעי אשר הועבר ממשק COM על-ידי הפניה. במצב זה, היישום עלול לקרוס.

לדוגמה: יישום שנכתב ב- VB6 הקורא DLL C#. אם היישום ואת קובץ DLL מבוצע הידור במצב שחרור, כאשר התרעה על חריגה בקוד 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 דקות (יום אחד) לפני הבניין של הפרוייקט, ומגדיר אותו null לאחר הבניין. אם קיימים מספר פרוייקטים הדורשת כדי להאריך את משך ההחכרה, לכל פרוייקט יש תצורה זו.

בעיה 8

כאשר אתה משתמש ב- AJAX ל- postback בעמוד, לעתים ל- postback מנותבת מחדש ל- URL אחר. באפשרותך להשיג את RedirectLocation ב- HttpModule עד HttpContext.Items["System.Web.UI.PageRequestManager:AsyncPostBackRedirectLocation"].