Zmiany w .NET Framework 3.5 SP1

W tym dokumencie opisano zmiany projektu, które mogą być uwzględniane w aplikacji lub środowisku podczas uaktualniania z wersji .NET Framework w wersji 3.5 do .NET Framework w wersji 3.5 z dodatkiem Service Pack 1 (SP1).

Zmiany występują z kilku powodów, w tym poprawki problemów z produktem, zgodność ze standardami, opinie klientów i zabezpieczenia. W tym temacie opisano tylko istotne zmiany. Aby uzyskać informacje o nowych funkcjach, zobacz Co nowego w .NET Framework . Aby przekazać opinię, odwiedź Centrum opinii o produkcie MSDN.

W poniższych sekcjach opisano zmiany wprowadzone w .NET Framework wersji 3.5 SP1.

środowiska uruchomieniowe w trakcie wykonania

Ulepszenia wydajności Aplikacje używają teraz ochrony przed wykonywaniem danych, aby zapobiec próbom wstawiania i wykonywania kodu z lokalizacji pamięci nie wykonywalnej. Zabezpieczenia wykonywania kodu zarządzanego (w tym zestawy MSIL, obrazy NGen i kod niezarządzany) są wzmacniane przez losowe układy przestrzeni adresowej (ASLR). Zestawy o silnych nazwach, podpisane nie muszą już mieć sygnatur sprawdzanych w czasie ładowania, pod warunkiem że są w pełni zaufane i są ładowane do w pełni zaufanych domen aplikacji. Ta zmiana eliminuje nadmiarowe kontrole i poprawia wydajność uruchamiania aplikacji, które podpisały zestawy, ale nie są zainstalowane w globalnej pamięci podręcznej zestawów (GAC). Aplikacje uruchamiane z udziałów sieciowych mają takie samo zachowanie jak niezarządzane pliki wykonywalne i działają w pełnym zaufaniu, w przeciwieństwie do częściowego zaufania. Atrybut StringFreezingAttribute jest teraz ignorowany. Ten atrybut został użyty do tworzenia obrazów natywnych przy użyciu generatora obrazów natywnych (Ngen.exe). Inliner kompilatora just in time (JIT) został znacznie ulepszony w celu wygenerowania kodu o lepszej jakości. Jednak zmiana inlinera ma wpływ na aplikacje, które mają wystąpienia klas z konstruktorami używającymi wartości wyliczenia TypeAttributes.BeforeFieldInit. Statyczne inicjowanie tych typów jest gwarantowane naraz przed uzyskaniem dostępu do któregokolwiek z pól statycznych, ale nie przed wywołaniem metody statycznej lub konstruktora wystąpienia. Dokładny czas wywołania konstruktora klasy może być inny w .NET Framework w wersji 3.5 i 3.5 SP1. Inne zmiany kompilatora JIT obejmują zmiany błędów zaokrąglania zmiennoprzecinkowego i zmiany czasu finalizatorów. Nie są wymagane żadne modyfikacje.

ADO.NET

Metody CanConvertToString w klasach serializatora wartości Metody CanConvertToString klasy serializatora wartości w przestrzeni nazw System.Windows.Converters zgłaszają wyjątek ArgumentException zamiast zwracać wartość false. Metody System.Data.SqlClient.SQLDataReader.GetString i oth er Get zgłaszają wyjątek InvalidCastException , jeśli nie można rzutować danych do żądanego typu. Komunikaty zawierają teraz typy, takie jak: "Nie można rzutować obiektu typu System.Decimal", aby wpisać "System.String". Nie są wymagane żadne modyfikacje.

SQLDataReader.GetString w kolumnach UDT Wywołanie metody SQLDataReader.GetString w kolumnach Typu zdefiniowanego przez użytkownika (UDT) zgłasza teraz wyjątek InvalidCastException zamiast komunikatu o błędzie "Cast is not supported from Byte[] to String". Nie są wymagane żadne modyfikacje.

C#

Zapytania dotyczące kolekcji innych niż ogólne używają teraz standardowych semantyki rzutowania języka C#. W wyrażeniach zapytań LINQ dla kolekcji innych niż ogólne, takich jak System.Collections.ArrayList , klauzula from zapytania jest przepisana przez kompilator w celu uwzględnienia wywołania operatora Cast<T> . Rzutowanie<T> konwertuje wszystkie typy elementów na typ określony w klauzuli from w zapytaniu. Ponadto w oryginalnej wersji programu Visual C# 2008 operator Cast<T> wykonuje również konwersje typu wartości i konwersje zdefiniowane przez użytkownika. Jednak te konwersje są wykonywane przy użyciu klasy System.Convert zamiast standardowej semantyki języka C#. Te konwersje powodują również znaczne problemy z wydajnością w niektórych scenariuszach. W programie Visual C# 2008 SP1 operator Cast<T> został zmodyfikowany, aby zgłosić wyjątek InvalidCastException dla typu wartości liczbowej i konwersji zdefiniowanych przez użytkownika. Ta zmiana eliminuje zarówno nietypowe semantyka rzutowania języka C#, jak i problem z wydajnością. Ta zmiana jest pokazana w poniższym przykładzie. 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     } } Sugerowane modyfikacje: jeśli masz kod, który wykonuje zapytania LINQ w kolekcjach innych niż ogólne, a ten kod zgłasza teraz wyjątek, zmień typ wyrażenia zapytania, aby dopasować typ elementów w kolekcji, którą wykonujesz. Jeśli musisz wykonać konwersję typu wartości lub zdefiniowanej przez użytkownika na elementach, możesz to zrobić podczas wykonywania zapytania, jak pokazano w poniższym przykładzie: 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

Tryb zintegrowany usług IIS W trybie integracji dla usług Internet Information Services (IIS) 7.0 metoda HttpServerUtility.TransferRequest niepoprawnie używa metody HTTPResponse.End, aby zatrzymać żądanie nadrzędne. Spowoduje to zwrócenie elementu ThreadAbortException , co może mieć wpływ na wydajność zakończenia wykonywania odpowiedzi. W .NET Framework 3.5 SP1 metoda TransferRequest kończy teraz żądanie nadrzędne przy użyciu metody HttpApplication.CompleteRequest. Spowoduje to również bezproblemowe zakończenie bieżącego żądania przez przeniesienie kontrolki do procedury obsługi zdarzeń HttpApplication.EndRequest bez zgłaszania wyjątku. Sugerowane modyfikacje: jeśli masz kod obsługi błędów, który używa metody TransferRequest do określenia, czy został zgłoszony błąd ThreadAbortException , możesz usunąć ten kod z bloku catch. (Na koniec bloki będą nadal uruchamiane).

Zintegrowane uwierzytelnianie systemu Windows Zmiana zabezpieczeń wpływa na sposób obsługi zintegrowanego uwierzytelniania systemu Windows przez system.Net.HttpWebRequest , System.Net.HttpListener , System.Net.Security.NegotiateStream i powiązane klasy w przestrzeni nazw System.Net. Ta zmiana może mieć wpływ na serwery sieci Web i aplikacje klienckie skonfigurowane do korzystania ze zintegrowanego uwierzytelniania systemu Windows. Proces uwierzytelniania programu Microsoft Windows NT LAN Manager (NTLM) używany z zintegrowanym uwierzytelnianiem systemu Windows obejmuje wyzwanie wystawione przez komputer docelowy, który jest wysyłany z powrotem do komputera klienckiego. Gdy komputer otrzyma wyzwanie wygenerowane przez siebie, uwierzytelnianie zakończy się niepowodzeniem, chyba że połączenie jest połączeniem zwrotnym pętli (na przykład adres IPv4 127.0.0.1). Klasa HttpWebRequest domyślnie określa nazwę hosta używaną w adresie URL żądania w głównej nazwie usługi (SPN) używanej w procesie uwierzytelniania NTLM. Sugerowane modyfikacje: można podać niestandardową nazwę SPN do użycia podczas uwierzytelniania w słowniku ciągów indeksowanych przez identyfikator URI. Ten słownik jest uzyskiwany za pomocą właściwości System.Net.AuthenticationManager.CustomTargetNameDictionary. Możesz również dodać następujące ustawienie rejestru, aby mapować nazwy na połączenie z powrotem pętli: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\BackConnectionHostNames

CDOSYS Klasy w przestrzeni nazw System.Web.Mail opierają się na obiektach danych współpracy dla składników systemu Windows 2000, które nie będą dostępne w następnej wersji systemu Windows (Windows 7). W rezultacie użycie tych klas w systemie Windows 7 spowoduje zgłoszenie elementu PlatformNotSupportedException . Sugerowane modyfikacje: System.Web.Mail został przestarzały w .NET Framework w wersji 2.0. Zamiast tego użyj obsługi poczty w przestrzeni nazw System.Net.Mail.

sprawdzanie poprawności żądań ASP.NET ASP.NET walidacja żądania obejmuje teraz sprawdzanie dla lewego nawiasu kątowego i sekwencji znaków znaku zapytania: <? Modyfikacje su ggested: Wpływ tej zmiany powinien być minimalny, ponieważ zwykle nie ma powodu, aby komentarz XML był uwzględniany w ciągu zapytania zmiennej cookie.

Walidacje adresów URL ASP.NET teraz weryfikuje fragmenty adresu URL po korzystaniu ze strony ASP.NET. Jednak w przypadku ponownego zapisywania adresów URL można uzyskać dostęp do starej wersji adresu URL na stronie za pomocą właściwości Request.RawUrl. Sugerowane modyfikacje: wyłącz walidację na stronie, jeśli jest to konieczne.

Stany sesji Oczekuje się, że dostawcy stanu sesji zaimplementują wszystkie elementy członkowskie zdefiniowane w klasie System.Web.SessionStateStoreProviderBase, w tym metodę CreateUninitializedItem. Ta metoda została jednak wywołana tylko wtedy, gdy stan sesji bez plików cookie był używany przez witrynę. Deweloperzy, którzy nie używali stanu sesji bez plików cookie, nie musieli implementować metody CreateUninitializedItem u dostawcy niestandardowego. Po wydaniu .NET Framework 3.5 SP1 metoda CreateUninitializedItem może być teraz również wywoływana w pewnych okolicznościach, gdy jest używany stan sesji cookie. Sugerowane modyfikacje: zaimplementuj metodę CreateUninitializedItem u dostawców niestandardowych. Ustal, czy element "live" już istnieje dla określonego identyfikatora sesji. Jeśli element nie istnieje, dostawcy powinni utworzyć element identyfikatora sesji.

Kodowanie adresów URL ASP.NET teraz rozszerza kodowanie adresów URL wychodzących nagłówków HTTP w celu uwzględnienia znaku usuwania (7F) i wszystkich znaków kontrolki ASCII (z wyjątkiem karty poziomej). Sugerowane modyfikacje: w razie potrzeby można wyłączyć domyślne zachowanie kodowania nagłówka w następujący sposób: <httpRuntime enableHeaderChecking="true|false" />

DefaultHTTPHandler w usługach IIS Mimo że klasa System.Web.DefaultHTTPHandler dla aplikacji w trybie zintegrowanym została utworzona przestarzałym modułem w usługach IIS 7.0, nadal można było go użyć. Teraz zgłasza wyjątek PlatformNotSupported . Sugerowane modyfikacje: zmień konfigurację aplikacji, aby działała prawidłowo w trybie zintegrowanym.

Składowe formatowania numerów serwera i klienta Zachowanie formatowania funkcji Number.localeFormat (uruchamiane na kliencie) jest teraz zgodne z metodą String.Format (uruchom na serwerze). Na przykład następujący kod zwraca wartość 1000.00% : String.Format("{0:p2}", 10) Przed .NET Framework 3.5 z dodatkiem SP1 zwracany będzie 10.00% następujący kod: String.localeFormat("{0:p2}", 10) Teraz funkcja localeFormat zwraca wartość 1000.00% . Nie są wymagane żadne modyfikacje.

ASP.NET ukrytych pól Ukryte ASP.NET pola, takie jak VIEWSTATE, są teraz renderowane w górnej części kontrolki <form /> przed renderowaniem wszystkich kontrolek. Sugerowane modyfikacje: Muszę wyłączyć to zachowanie, ustawiając nowy atrybut renderAllHiddenFieldsAtTopOfForm na wartość false:   <pages renderAllHiddenFieldsAtTopOfForm="false" /> Wartością domyślną jest true.

Windows Presentation Foundation (WPF)

Klasy BitmapEffect są przestarzałe Klasa System.Windows.Media.Effects.BitmapEffect i jej klasy pochodne (BevelBitmapEffect, BitmapEffectGroup, BlurBitmapEffect, DropShadowBitmapEffect, EmbossBitmapEffect i OuterGlowBitmapEffect) są teraz przestarzałe. Sugerowane modyfikacje: przestań używać starszych klas BitmapEffect i pochodnych, a zamiast tego użyj nowych klas pochodnych od Effect:BlurEffect, DropShadowEffect i ShaderEffect.  Możesz również utworzyć własne efekty, korzystając z funkcji ShaderEffect.

Zmiana nazwy zestawu Nazwa zestawu zawierającego podstawową warstwę renderowania WPF została zmieniona z milcore.dll na wpfgfx_v0300.dll. Ten zestaw nigdy nie miał żadnych publicznych interfejsów API. Nie są wymagane żadne modyfikacje.

Zachowanie hiperłączy Jeśli wartość właściwości Hiperłącze.NavigateUri zmienia się między czasem, gdy użytkownik umieści kursor myszy na hiperlinku i czas kliknięcia tego hiperłącza przez użytkownika, nawigacja nastąpi przy użyciu identyfikatora URI uzyskanego po umieszczeniu kursora na hiperłączu. Nie są wymagane żadne modyfikacje.

Program Internet Explorer w trybie chronionym w systemie Windows Vista Gdy program Internet Explorer jest w trybie chronionym w systemie Windows Vista, modalne okna dialogowe z funkcji alertu DHTML () i kontrolek ActiveX hostowanych w języku HTML są blokowane, a nie wyświetlane. Ponadto, gdy kontrolka WebBrowser lub kontrolka Ramka hostująca kod HTML znajduje się w aplikacji przeglądarki XMAL (XBAP), a XBAP jest ładowana między domenami na stronie HTML, zgłaszany jest wyjątek. Nie są wymagane żadne modyfikacje.

Metody CanConvertToString w klasach serializatora wartości Metody CanConvertToString klasy serializatora wartości w przestrzeni nazw System.Windows.Media.Converters i System.Media.Media3D.Converters zgłaszają argumentException zamiast zwracać fałsz. Nie są wymagane żadne modyfikacje.

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

Dopasowywanie schematu Schemat dopasowania schematu używany przez klasy UriTemplate iUriTemplateTable został złagodzony do akceptowania adresów bazowych z schematami innymi niż HTTP. Teraz żadna z tych klas nie używa schematu lub numeru portu podczas dopasowywania identyfikatorów URI kandydata do szablonów. Dodano obsługę końcowych ukośników i wartości domyślnych. Nie są wymagane żadne modyfikacje.

Ulepszenia zabezpieczeń uwierzytelniania Gdy usługa jest uruchomiona w ramach konta użytkownika z zabezpieczeniami w trybie mieszanym, tożsamość endPointIdentity musi mieć tożsamość głównej nazwy użytkownika (UPN). Nie było to konieczne we wcześniejszych wersjach programu WCF. Sugerowane modyfikacje: jeśli klient ma używać ustawienia SecurityMode.TransportWithMessageCredential (przy użyciu uwierzytelniania systemu Windows, uwierzytelniania nazwy UPN lub uwierzytelniania odciskiem palca), utwórz wystąpienie klasy EndPointAddress z tożsamością UPN i podaj kod niestandardowy do obsługi weryfikacji odcisku palca.

Obsługa częściowo zaufania na potrzeby rejestrowania zdarzeń Zaufanie częściowe obsługuje teraz ograniczone rejestrowanie zdarzeń. Tylko błędy aktywacji usługi, śledzenie błędów i błędów rejestrowania są rejestrowane w dzienniku zdarzeń. Aby uniknąć zapisywania nadmiernych komunikatów w dzienniku zdarzeń, maksymalna liczba zdarzeń, które mogą być rejestrowane przez proces, wynosi 5. Nie są wymagane żadne modyfikacje.

Dostępność remoteEndpointMessageProperty Uzyskiwanie dostępu do wystąpienia klasy RemoteEndpointMessageProperty w przypadku korzystania z protokołu HTTP hostowanego w usługach IIS zależy od aktualnie aktywnego żądania.  W związku z tym nie można go uzyskać po zakończeniu żądania (na przykład podczas odbierania jednokierunkowego). Nie są wymagane żadne modyfikacje.

Uwaga: Aby rozwiązać problemy dotyczące późnych problemów, które były krytyczne dla niektórych aplikacji, firma Microsoft planuje udostępnić aktualizację programu NET Framework 3.5 SP1, która może być uwzględniona w ważnym Windows Update. Więcej informacji o tej aktualizacji będzie dostępnych na stronie pobierania .NET Framework 3.5 SP1 w Centrum pobierania Microsoft.

Zobacz też

informacje o wersji i zestawie .NET Framework