Änderungen in .NET Framework 3.5 SP1

Dieses Dokument beschreibt Entwurfsänderungen, die möglicherweise in Ihrer Anwendung oder Umgebung berücksichtigt werden müssen, wenn Sie ein Upgrade von .NET Framework, Version 3.5 auf .NET Framework, Version 3.5 Service Pack 1 (SP1) durchführen.

Änderungen treten aus mehreren Gründen auf, einschließlich Korrekturen für Produktprobleme, Standards compliance, Kundenfeedback und Sicherheit. In diesem Thema werden nur wichtige Änderungen beschrieben. Informationen zu neuen Features finden Sie unter Neuerungen in .NET Framework. Um Feedback zu geben, besuchen Sie bitte das MSDN Product Feedback Center.

In den folgenden Abschnitten werden die Änderungen beschrieben, die in .NET Framework, Version 3.5 SP1 vorgenommen wurden.

Common Language Runtime

Leistungsverbesserungen Anwendungen verwenden jetzt die Datenausführungsverhinderung, um zu verhindern, dass Versucht wird, Code von nicht ausführbaren Speicherspeicherorten einzufügen und auszuführen. Die Sicherheit für die Ausführung von verwaltetem Code (einschließlich MSIL-Assemblys, NGen-Images und nicht verwaltetem Code) wird durch die Randomisierung des Adressraumlayouts (ASLR) gestärkt. Stark benannte signierte Assemblys müssen ihre Signaturen nicht mehr zum Ladezeitpunkt überprüft haben, sofern sie vollständig vertrauenswürdig sind und in voll vertrauenswürdige Anwendungsdomänen geladen werden. Diese Änderung beseitigt redundante Prüfungen und verbessert die Startleistung von Anwendungen mit signierten Assemblys, die jedoch nicht im globalen Assemblycache (GAC) installiert sind. Anwendungen, die von Netzwerkfreigaben gestartet werden, weisen dasselbe Verhalten wie nicht verwaltete ausführbare Dateien auf und funktionieren im Gegensatz zu teilweiser Vertrauensstellung voll vertrauenswürdig. Das StringFreezingAttribute-attribut wird jetzt ignoriert. Dieses Attribut wurde zum Erstellen nativer Bilder mit dem nativen Bildgenerator (Ngen.exe) verwendet. Der Just-in-Time-Compiler (JIT)-Compiler wurde erheblich verbessert, um besseren Qualitätscode zu generieren. Das Ändern des Inliners wirkt sich jedoch auf Anwendungen aus, die Klassen mit Konstruktoren instanziiert haben, die den TypeAttributes.BeforeFieldInit Enumerationswert verwenden. Die statische Initialisierung dieser Typen wird garantiert gleichzeitig ausgeführt, bevor auf statische Felder zugegriffen wird, jedoch nicht vor dem Aufrufen einer statischen Methode oder eines Instanzkonstruktors. Die genaue Uhrzeit, zu der der Klassenkonstruktor aufgerufen wird, kann in .NET Framework, Version 3.5 und 3.5 SP1, unterschiedlich sein. Andere JIT-Compileränderungen umfassen Änderungen an Gleitkommarundenfehlern und Änderungen an der Anzeigedauer von Finalizern. Es sind keine Änderungen erforderlich.

ADO.NET

CanConvertToString-Methoden für Value Serializer-Klassen Die CanConvertToString- Methoden für die Wert serialisiererklassen in der System.Windows.Converters Namespace lösen eine ArgumentException- aus, anstatt falsezurückzugeben. Die System.Data.SqlClient.SQLDataReader.GetString und oth er Get Methoden auslösen eine InvalidCastException-, wenn die Daten nicht in den angeforderten Typ umgewandelt werden können. Nachrichten enthalten nun die Typen, z. B. "Das Objekt vom Typ 'System.Decimal' kann nicht in den Typ 'System.String' umwandeln". Es sind keine Änderungen erforderlich.

SQLDataReader.GetString für UDT-Spalten Durch Aufrufen der SQLDataReader.GetString--Methode für BENUTZERdefinierte Typspalten (USER Defined Type, UDT) wird nun eine InvalidCastException- anstelle der Fehlermeldung "Cast wird von Byte[] in String nicht unterstützt" ausgelöst. Es sind keine Änderungen erforderlich.

C#

Abfragen über nicht generische Auflistungen verwenden jetzt standardmäßige C#-Castsemantik. In LINQ-Abfrageausdrücken über nicht generische Auflistungen wie System.Collections.ArrayList wird die From-Klausel der Abfrage vom Compiler umgeschrieben, um einen Aufruf des Cast<T> Operator einzuschließen. Cast<T> konvertiert alle Elementtypen in den typ, der in der From-Klausel in der Abfrage angegeben ist. Darüber hinaus führt der Cast<T> Operator in der ursprünglichen Version von Visual C# 2008 auch einige Werttypkonvertierungen und benutzerdefinierte Konvertierungen durch. Diese Konvertierungen werden jedoch mithilfe der System.Convert Klasse anstelle der C#-Standardsemantik ausgeführt. Diese Konvertierungen verursachen auch erhebliche Leistungsprobleme in bestimmten Szenarien. In Visual C# 2008 SP1 wird der Operator "Cast<T>" geändert, um eine InvalidCastException für numerischen Werttyp und benutzerdefinierte Konvertierungen auszuwerfen. Diese Änderung beseitigt sowohl die nicht standardmäßige C#-Umwandlungsemantik als auch das Leistungsproblem. Diese Änderung wird im folgenden Beispiel veranschaulicht. using System; using System.Linq; class Program {     public struct S { }     static void Main()     {         var floats = new float[] { 2.7f, 3.1f, 4.5f };         var ints = from int i in floats                    select i;         // Visual C# 2008 SP1 throws InvalidCastException.         foreach (var v in ints)             Console.Write("{0} ", v.ToString());         // The original release version of Visual C# 2008         // compiles and outputs 3 3 4     } } Vorgeschlagene Änderungen: Wenn Sie Code haben, der LINQ-Abfragen über nicht generische Auflistungen ausführt und dieser Code jetzt eine Ausnahme auslöst, ändern Sie den Typ des Abfrageausdrucks so, dass er dem Typ der Elemente in der Auflistung entspricht, die Sie abfragen. Wenn Sie eine Werttyp- oder benutzerdefinierte Konvertierung für die Elemente ausführen müssen, können Sie dies tun, wie im folgenden Beispiel gezeigt: using System; using System.Linq; class Program {     static void Main(string[] args)     {         ArrayList floats = new ArrayList();         floats.Add(2.7f);         floats.Add(3.1f);         floats.Add(4.5f);         var query = from float f in floats                     where f > 3.0f                     select f;         foreach (int i in floats)         {             // Perform the conversion as you             // execute the query.             int num = Convert.ToInt32(i);             Console.Write("{0} ", num.ToString());         }         Console.ReadLine(); // output is 3 4     } }

ASP.NET, IIS

integrierten IIS-Modus Im Integrationsmodus für Internetinformationsdienste (IIS) 7.0 verwendet die HttpServerUtility.TransferRequest--Methode die HTTPResponse.End Methode, um die übergeordnete Anforderung zu beenden. Dies führt dazu, dass ein ThreadAbortException- ausgelöst wird, was sich auf die Leistung beim Beenden der Ausführung einer Antwort auswirken kann. In .NET Framework 3.5 SP1 beendet die TransferRequest--Methode nun die übergeordnete Anforderung mithilfe der HttpApplication.CompleteRequest-Methode. Dadurch wird auch die aktuelle Anforderung ordnungsgemäß beendet, indem die Steuerung an die HttpApplication.EndRequest Ereignishandler übertragen wird, ohne eine Ausnahme auszulösen. Vorgeschlagene Änderungen: Wenn Sie Fehlerbehandlungscode haben, der die TransferRequest Methode verwendet, um zu bestimmen, ob die ThreadAbortEx ception ausgelöst wurde, können Sie diesen Code aus dem Catch-Block entfernen. (Schließlich werden Blöcke weiterhin ausgeführt.)

integrierte Windows-Authentifizierung Eine Sicherheitsänderung wirkt sich auf die Verarbeitung der integrierten Windows-Authentifizierung durch die System.Net.HttpWebRequest , System.Net.HttpListener , System.Net.Security.NegotiateStream und zugehörige Klassen im System.Net Namespace aus. Diese Änderung kann sich auf Webserver und Clientanwendungen auswirken, die für die Verwendung der integrierten Windows-Authentifizierung konfiguriert sind. Der mit der integrierten Windows-Authentifizierung verwendete Microsoft Windows NT LAN Manager (NTLM)-Authentifizierungsprozess enthält eine Herausforderung, die vom Zielcomputer ausgegeben wird, der an den Clientcomputer zurückgesendet wird. Wenn ein Computer eine Abfrage erhält, die er selbst generiert hat, schlägt die Authentifizierung fehl, es sei denn, die Verbindung ist eine Loopbackverbindung (z. B. IPv4-Adresse 127.0.0.1). Die HttpWebRequest Klasse gibt nun standardmäßig den Hostnamen an, der in der Anforderungs-URL im dienstprinzipalnamen (SPN) verwendet wird, der im NTLM-Authentifizierungsprozess verwendet wird. Vorgeschlagene Änderungen: Sie können einen benutzerdefinierten SPN bereitstellen, der während der Authentifizierung für ein Wörterbuch mit Zeichenfolgen verwendet werden kann, die vom URI indiziert werden. Dieses Wörterbuch wird mit der System.Net.AuthenticationManager.CustomTargetNameDictionary-Eigenschaft abgerufen. Sie können auch die folgende Registrierungseinstellung hinzufügen, um namen der LoopBack-Verbindung zuzuordnen: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\BackConnectionHostNames

CDOSYS- Die Klassen im System.Web.Mail Namespace basieren auf Datenobjekten für die Zusammenarbeit für Windows 2000-Komponenten, die in der nächsten Version von Windows (Windows 7) nicht verfügbar sind. Daher löst die Verwendung dieser Klassen in Windows 7 eine PlatformNotSupportedException- aus. Vorgeschlagene Änderungen: System.Web.Mail- wurde in .NET Framework, Version 2.0, veraltet. Verwenden Sie stattdessen die E-Mail-Unterstützung im System.Net.Mail Namespace.

ASP.NET Anforderungsüberprüfungen ASP.NET Anforderungsüberprüfung umfasst jetzt die Überprüfung auf die linke winkelige Klammer und die Fragezeichenfolge: <? Sugested Modifications: Die Auswirkungen dieser Änderung sollten minimal sein, da es in der Regel keinen Grund gibt, dass ein XML-Kommentar in die Abfragezeichenfolge der Cookievariable einbezogen werden soll.

URL-Überprüfungen ASP.NET überprüft nun Teile der URL, wenn auf eine ASP.NET Seite zugegriffen wird. Wenn die URL-Umschreibung verwendet wird, ist es jedoch möglich, auf die alte Version der URL auf der Seite mit der Request.RawUrl--Eigenschaft zuzugreifen. Vorgeschlagene Änderungen: Deaktivieren Sie die Überprüfung auf einer Seite, falls erforderlich.

Sitzungsstatus Sitzungsstatusanbieter werden alle Elemente implementieren, die in der System.Web.SessionState.SessionStateStoreProviderBase Klasse definiert sind, einschließlich der CreateUninitializedItem--Methode. Diese Methode wurde jedoch nur aufgerufen, wenn ein cookieloser Sitzungszustand von der Website verwendet wurde. Entwickler, die keinen cookielosen Sitzungsstatus verwendet haben, mussten nicht CreateUninitializedItem- in einem benutzerdefinierten Anbieter implementieren. Mit der Veröffentlichung von .NET Framework 3.5 SP1 kann die CreateUninitializedItem--Methode jetzt auch unter bestimmten Umständen aufgerufen werden, wenn ein Cookie-Sitzungsstatus verwendet wird. Vorgeschlagene Änderungen: Implementieren sie CreateUninitializedItem- in benutzerdefinierten Anbietern. Bestimmen Sie, ob für die angegebene Sitzungs-ID bereits ein "live"-Element vorhanden ist. Wenn kein Element vorhanden ist, sollten die Anbieter ein Element für die Sitzungs-ID erstellen.

URL-Codierung ASP.NET erweitert jetzt die URL-Codierung ausgehender HTTP-Header, um das Löschzeichen (7F) und alle ASCII-Steuerelementzeichen (mit Ausnahme der horizontalen Registerkarte) einzuschließen. Vorgeschlagene Änderungen: Bei Bedarf können Sie das Standardverhalten der Headercodierung wie folgt deaktivieren: <httpRuntime enableHeaderChecking="true|false" />

DefaultHTTPHandler für IIS- Obwohl die System.Web.DefaultHTTPHandler Klasse für Anwendungen im integrierten Modus zu einem veralteten Modul in IIS 7.0 wurde, war es dennoch möglich, es zu verwenden. Es löst jetzt eine PlatformNotSupported Ausnahme aus. Vorgeschlagene Änderungen: Ändern Sie die Anwendungskonfiguration so, dass sie ordnungsgemäß im integrierten Modus funktioniert.

Server- und Clientnummernformatierung besteht aus Das Formatierungsverhalten der Number.localeFormat--Funktion (auf dem Client ausgeführt) entspricht nun der String.Format-Methode (auf dem Server ausgeführt). Der folgende Code gibt z. B. 1000.00% zurück: String.Format("{0:p2}", 10) Vor .NET Framework 3.5 SP1 würde der folgende Code 10.00% zurückgeben: String.localeFormat("{0:p2}", 10) Jetzt gibt localeFormat- 1000.00% zurück. Es sind keine Änderungen erforderlich.

ASP.NET ausgeblendeten Felder Ausgeblendete ASP.NET Felder, z. B. VIEWSTATE-, werden jetzt vor dem Rendern von Steuerelementen am oberen Rand der <form /> gerendert. Vorgeschlagene Änderungen: Ich f erforderlich, sie können dieses Verhalten deaktivieren, indem Sie das neue renderAllHiddenFieldsAtTopOfForm- attribut auf "false" festlegen:   <pages renderAllHiddenFieldsAtTopOfForm="false" /> Der Standardwert ist true.

Windows Presentation Foundation (WPF)

BitmapEffect-Klassen sind veraltet Die System.Windows.Media.Effects.BitmapEffect Klasse, und die abgeleiteten Klassen (BevelBitmapEffect, BitmapEffectGroup, BlurBitmapEffect, DropShadowBitmapEffect, EmbossBitmapEffect, und OuterGlowBitmapEffect) sind jetzt veraltet. Vorgeschlagene Änderungen: Beenden Sie die Verwendung der Legacy-BitmapEffect- und abgeleiteten Klassen und verwenden Sie stattdessen die neuen Klassen, die von Effectabgeleitet wurden:BlurEffect, DropShadowEffectund ShaderEffect.  Sie können auch eigene Effekte erstellen, indem Sie von ShaderEffectableiten.

Ändern des Assemblynamens Die Assembly, die die Kernrenderingebene von WPF enthält, wurde von milcore.dll in wpfgfx_v0300.dllumbenannt. Diese Assembly hat nie öffentliche APIs. Es sind keine Änderungen erforderlich.

Hyperlinkverhalten Wenn sich der Wert der Hyperlink.NavigateUri Eigenschaft zwischen dem Zeitpunkt ändert, zu dem der Benutzer den Mauszeiger über einen Hyperlink bewegt, und der Zeitpunkt, zu dem der Benutzer auf diesen Link klickt, erfolgt die Navigation mithilfe des URI, der beim Daraufzeigen des Cursors über den Hyperlink abgerufen wurde. Es sind keine Änderungen erforderlich.

Internet Explorer im geschützten Modus unter Windows Vista Wenn Sich Internet Explorer im geschützten Modus unter Windows Vista befindet, werden modale Dialogfelder aus der DHTML-Warnung () Funktion und in HTML gehostete ActiveX-Steuerelemente blockiert und nicht angezeigt. Wenn das WebBrowser-Steuerelement oder Frame- Steuerelement, das den HTML-Code hosten, in einer XMAL-Browseranwendung (XBAP) befindet und die XBAP domänenübergreifend auf einer HTML-Seite geladen wird, wird eine Ausnahme ausgelöst. Es sind keine Änderungen erforderlich.

CanConvertToString-Methoden für Value Serializer-Klassen Die CanConvertToString- Methoden für die Wert serialisiererklassen in den System.Windows.Media.Converters und System.Windows.Media.Media3D.Converters Namespaces lösen eine ArgumentException- aus, anstatt falsezurückzugeben. Es sind keine Änderungen erforderlich.

Windows Communication Foundation (WCF) und Windows Workflow Foundation (WF)

Schemaabgleich Das Schemaabgleichsschema, das von der UriTemplate- und UriTemplateTable- Klassen verwendet wird, wurde entspannt, Basisadressen mit anderen Schemas als HTTP zu akzeptieren. Jetzt verwendet keiner dieser Klassen das Schema oder die Portnummer, wenn Kandidaten-URIs mit Vorlagen übereinstimmen. Die Vorlagenunterstützung für nachfolgende Schrägstriche und Standardwerte wurde hinzugefügt. Es sind keine Änderungen erforderlich.

Sicherheitsverbesserungen für die Authentifizierung Wenn ein Dienst unter einem Benutzerkonto mit Sicherheit im gemischten Modus ausgeführt wird, muss eine EndPointIdentity- über eine Benutzerprinzipalnamenidentität (UPN) verfügen. Dies war bei früheren Versionen von WCF nicht erforderlich. Vorgeschlagene Änderungen: Wenn ein Client für die Verwendung der Einstellung SecurityMode.TransportWithMessageCredential (mithilfe der Windows-Authentifizierung, UPN-Authentifizierung oder Fingerabdruckauthentifizierung) festgelegt ist, erstellen Sie eine Instanz der EndPointAddress Klasse mit einer UPN-Identität und stellen benutzerdefinierten Code bereit, um eine Fingerabdrucküberprüfung zu verarbeiten.

Teilweise vertrauenswürdige Unterstützung für die Ereignisprotokollierung Partielle Vertrauensstellung unterstützt jetzt die eingeschränkte Ereignisprotokollierung. Nur Dienstaktivierungsfehler, Ablaufverfolgungsfehler und Protokollierungsfehler werden im Ereignisprotokoll protokolliert. Um übermäßige Nachrichten in das Ereignisprotokoll zu vermeiden, beträgt die maximale Anzahl von Ereignissen, die von einem Prozess protokolliert werden können, 5. Es sind keine Änderungen erforderlich.

RemoteEndpointMessageProperty-Verfügbarkeit Der Zugriff auf eine Instanz der RemoteEndpointMessageProperty Klasse bei Verwendung von HTTP, die in IIS gehostet wird, hängt davon ab, dass eine derzeit aktive Anforderung vorhanden ist.  Daher kann sie nicht abgerufen werden, nachdem die Anforderung abgeschlossen wurde (z. B. beim Ausführen eines unidirektionalen Empfangs). Es sind keine Änderungen erforderlich.

Hinweis: Um probleme zu beheben, die für einige Anwendungen von entscheidender Bedeutung waren, plant Microsoft, ein Update für das NET Framework 3.5 SP1 bereitzustellen, das in einem wichtigen Windows Update enthalten sein kann. Weitere Informationen zu diesem Update finden Sie auf der .NET Framework 3.5 SP1 Downloadseite im Microsoft Download Center.

Siehe auch

.NET Framework-Versions- und Assemblyinformationen