אוסף תיקונים חמים 3035814 (המתקין במצב לא מקוון) עבור .NET Framework 4.5, 4.5.1 ו- 4.5.2 ב- Windows Vista SP2, Windows 7 SP1, Windows 8, Windows 8.1, Windows Server 2008 SP2, Windows Server 2008 R2 SP1, 2012 שרת Windows ו- Windows Server 2012 R2

מאמר זה מתאר אוסף תיקונים חמים 3035814 הזמינים עבור Microsoft .NET Framework 4.5.2, .NET Framework 4.5.1 ו- 4.5 Framework של .NET. לקבלת מידע נוסף אודות הבעיות הפותר אוסף תיקונים חמים, עיין בסעיף "בעיות הפותר אוסף תיקונים חמים זה".

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

פתרון

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

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

מידע נוסף

דרישות מוקדמות

כדי להחיל תיקון חם זה, עליך .NET Framework 4.5.2, .NET Framework 4.5.1 או 4.5 מסגרת .NET מותקן.

דרישת הפעלה מחדש

עליך להפעיל מחדש את המחשב לאחר החלת תיקון חם זה, אם נעשה שימוש בכל הקבצים המושפעים. מומלץ לסגור את כל היישומים מבוססי .NET Framework לפני החלת תיקון חם זה.

מידע על החלפת התיקון החם

חבילת תיקון חם זה אינו מחליף את חבילת תיקון חם שפורסם בעבר.

מזהה את התיקונים החמים שהותקנו

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

גירסת התיקון החם של סיכוםהערך של מהדורת ה-DWORD
אוסף תיקונים חמים 3035814 עבור .NET Framework 4.5 וגירסאות מאוחרות יותר379970

לקבלת מידע נוסף אודות אופן הסימון מותקנות גירסאות של .NET Framework, עיין במאמר MSDN הבא:


אוסף תיקונים חמים זה פותר הבעיות

בעיה 1

נניח שיש לך יישום מצגת Windows Foundation (WPF) של 32 סיביות במערכת הפעלה של 64 סיביות. כאשר היישום קורא שוב ושוב את שיטת PrintQueue.GetPrintCapabilities (או שיטות הדפסה קשורים אחרים, כגון PrintQueue.Dispose), מתרחשת דליפת זיכרון בתהליך נפרד בו פועל dllhost.exe.

הערה בעיה זו מתרחשת בדרך כלל כאשר הקף את האובייקט תור ההדפסה בבלוק "שימוש" הבאים:
using (var printQueue = new PrintQueue(printServer, printerName)){ ... use printQueue ... }

בעיה 2

כאשר תפעיל את הווירטואליזציה ממשק משתמש עבור פקד רשימה כגון תיבת רשימה, DataGrid, ListView או TreeView ביישום WPF, תיתקל בבעיות הבאות:
  • NullReferenceException או ArgumentException
  • גלילה למיקום לא צפויה
  • לולאה אינסופית, או תלויה
  • חריגה StackOverflow
  • כשל בעת גלילה האחרון דף
Cause

לעתים קרובות, בעיות אלה מתרחשות כאשר מחלקה VirtualizingStackPanel מגלה כי אחד או יותר של הצאצאים שלו השתנה גובה, במועד כלשהו מלבד במהלך הבקשה המידה הראשונה מאתר האב שלו. לנוחיותכם, אנו מתייחסים מצב זה כ- "שינוי גובה התחתון כלפי מעלה". מצב זה כולל את הדוגמאות הבאות:
  • הרחבה או כיווץ היררכית צאצא (TreeViewItem או GroupItem)
  • המיחזור צאצא כאשר הנתונים החדשים מניב גובה שונה מאשר הנתונים הישנים (כאשר VirtualizingMode = "מיחזור" מוגדר)
  • השתמש של UserControl שתוכנם תלוי בנתונים מחוץ לפקד
  • הפעלת המטפלים להצהיר על-ידי היישום עבור אירועים הקשורים לפריסה, כגון Loaded או LayoutUpdated
  • איגוד נתונים לנתונים מחוץ הצאצא (עבור שימוש לדוגמה AncestorType או ElementName באיגוד)
המחלקה VirtualizingStackPanel אין אפשרות לטפל תמיד מצב זה כהלכה, הדבר עלול לגרום לבעיות שתואר לפני כן.

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

נניח שהחלת עדכון ינואר. במצב זה, degradations ביצועים ויציבות מתרחשת במערכות המסתמכים על רקע איסוף פסולת. בעיה זו מתרחשת מאחר אוסף האשפה עודכן כדי להפוך את "הזיכרון לכתוב צפייה" התכונה (MEM_WRITE_WATCH) נדרש במקום אופציונלי. עדכון זה מאפשר מחדש את התכונה MEM_WRITE_WATCH כאופציונליים.

בעיה 4

נניח שיש לך של IIS המתארחים שירות WCF פועל .NET Framework 4.5.1 או 4.5.2. השירות מוגדרת לדרוש אישור לקוח הגדרות IIS. עם זאת, של האיגוד HttpsTransportBindingElement.RequireClientCertificate מוגדר כ- false.

במצב זה, WCF לא מכבד את הגדרות IIS ולאחר כראוי לא יאמת את אישור הלקוח. הוא אפשרי על מנת לעקוף בעיה זו באמצעות איגוד מותאם אישית והגדרת המאפיין HttpsTransportBindingElement.RequireClientCertificate ל- true.

בעיה 5

נניח שיש לך שירות WCF שעושה שימוש אבטחת תעבורה. השירות כולל איגוד עם SecurityBindingElement.SecurityHeaderLayout שאינו מוגדר לערך שונה מברירת המחדל של מחמיר.

במצב זה, WCF מתעלם מאפיין זה, כך לקוחות WCF היתה אפשרות לקיים תקשורת עם השירות גם כאשר באמצעות פריסה הנכון. בסדר עבור WCF לכבד זאת כראוי, תצטרך להוסיף את השורה הבאה כדי appSettings בקובץ התצורה שלך:
<appSettings><add key="wcf:useConfiguredTransportSecurityHeaderLayout" value="true" />
</appSettings>

מאפיינים:

מזהה פריט: 3035814 - סקירה אחרונה: 25 בינו׳ 2017 - תיקון: 1

Microsoft .NET Framework 4.5.2, Microsoft .NET Framework 4.5.1, Microsoft .NET Framework 4.5

משוב