Zmiany w programie .NET Framework 3.5 SP1

W tym dokumencie opisano zmiany projektu, które mogą być uwzględniane w aplikacji lub środowisku podczas uaktualniania z programu .NET Framework w wersji 3.5 do programu .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 programie .NET Framework . Aby przekazać opinię, odwiedź Centrum opinii o produktach MSDN.

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

Środowisko uruchomieniowe języka wspólnego

ulepszenia wydajności Aplikacje używają teraz zapobiegania wykonywaniu 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 losowość układu przestrzeni adresowej (ASLR). Zestawy podpisane o silnej nazwie 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 mają podpisane 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 inliner ma wpływ na aplikacje, które mają wystąpienia klas z konstruktorami używającymi TypeAttributes.BeforeFieldInit wartość wyliczenia. Statyczne inicjowanie tych typów jest gwarantowane naraz przed uzyskaniem dostępu do dowolnego pola statycznego, ale nie przed wywołaniem metody statycznej lub konstruktora wystąpienia. Dokładny czas wywołania konstruktora klasy może być inny w programie .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 w klasach serializatora wartości w przestrzeni nazw System.Windows.Converters zgłaszają ArgumentException zamiast zwracać false. Metody System.Data.SqlClient.SQLDataReader.GetString i oth er Get zgłaszają 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 InvalidCastException zamiast komunikatu o błędzie "Rzutowanie nie jest obsługiwane z bajtu[] do ciągu". Nie są wymagane żadne modyfikacje.

C#

Zapytania dotyczące kolekcji innych niż ogólne używają teraz standardowej 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 Rzutowanie<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> jest modyfikowany w celu wyrzucenia elementu InvalidCastException dla typu wartości liczbowej i konwersji zdefiniowanych przez użytkownika. Ta zmiana eliminuje zarówno nietypową semantykę 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 nad kolekcjami niegeneryjnymi, a ten kod zgłasza teraz wyjątek, zmień typ wyrażenia zapytania, aby dopasować typ elementów w kolekcji, do której wykonujesz zapytanie. 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

trybu zintegrowanego 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 ThreadAbortException, co może mieć wpływ na wydajność zakończenia wykonywania odpowiedzi. W programie .NET Framework 3.5 SP1 metoda TransferRequest kończy żądanie nadrzędne przy użyciu metody HttpApplication.CompleteRequest. Spowoduje to również bezproblemowe zakończenie bieżącego żądania przez przeniesienie kontroli do HttpApplication.EndRequest obsługi zdarzeń bez zgłaszania wyjątku. Sugerowane modyfikacje: jeśli masz kod obsługi błędów, który używa metody TransferRequest w celu ustalenia, czy ThreadAbortException został zgłoszony, możesz usunąć ten kod z bloku catch. (Na koniec bloki będą nadal działać).

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 ze 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 samodzielnie, 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 teraz 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żesz 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 System.Web.Mail przestrzeni nazw polegają 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 PlatformNotSupportedException . Sugerowane modyfikacje: System.Web.Mail została uznana za przestarzałą w programie .NET Framework w wersji 2.0. Zamiast tego użyj obsługi poczty w przestrzeni nazw System.Net.Mail.

ASP.NET weryfikacje żądań ASP.NET sprawdzanie poprawności żądania obejmuje teraz sprawdzanie 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 został uwzględniony w ciągu zapytania zmiennej cookie.

sprawdzanie poprawności adresu 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 system.Web.SessionState.SessionStateStoreProviderBase klasy, w tym metoda CreateUninitializedItem. Jednak ta metoda została 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ć createUninitializedItem w dostawcy niestandardowym. Po wydaniu programu .NET Framework 3.5 SP1 CreateUninitializedItem można teraz również wywołać metodę w pewnych okolicznościach, gdy jest używany stan sesji cookie. Sugerowane modyfikacje: Zaimplementuj 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 dla 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 kontrolnych 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 było możliwe użycie. Teraz zgłasza wyjątek PlatformNotSupported. Sugerowane modyfikacje: zmień konfigurację aplikacji, aby działała prawidłowo w trybie zintegrowanym.

Server i formatowanie numerów klienta Zachowanie formatowania funkcji Number.localeFormat (uruchamianej na kliencie) jest teraz zgodne z metodą String.Format (uruchom na serwerze). Na przykład następujący kod zwraca 1000.00% : String.Format("{0:p2}", 10) Przed programem .NET Framework 3.5 SP1 następujący kod zwróci 10.00% : String.localeFormat("{0:p2}", 10) Teraz ustawienia regionalneFormat zwraca wartość 1000.00% . Nie są wymagane żadne modyfikacje.

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

Windows Presentation Foundation (WPF)

klasy BitmapEffect są przestarzałe Klasa System.Windows.Media.Effects.BitmapEffect, i jego klasy pochodne (BevelBitmapEffect, BitmapEffectGroup, BlurBitmapEffect, DropShadowBitmapEffect, EmbossBitmapEffecti OuterGlowBitmapEffect), są teraz przestarzałe. Sugerowane modyfikacje: Przestań używać starszych klas BitmapEffect i pochodnych, a zamiast tego użyj nowych klas pochodnych uzyskanych z Effect:BlurEffect, DropShadowEffecti ShaderEffect.  Możesz również utworzyć własne efekty, wyprowadzając z 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łącza Jeśli wartość właściwości Hiperłącze.NavigateUri zmienia się między czasem, gdy użytkownik umieści kursor myszy na hiperlinku, a czasem 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.

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 alertu DHTML () funkcji i kontrolek ActiveX hostowanych w kodzie HTML są blokowane, a nie wyświetlane. Ponadto, gdy kontrolka WebBrowser lub Frame kontrolka 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 klas serializatora wartości w System.Windows.Media.Converters i System.Windows.Media.Media3D.Converters przestrzeni nazw zgłaszają ArgumentException zamiast zwracać false. Nie są wymagane żadne modyfikacje.

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

dopasowywanie schematu Schemat dopasowania schematu używany przez UriTemplate i klas UriTemplateTable 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ę szablonów końcowych ukośników i wartości domyślnych. Nie są wymagane żadne modyfikacje.

Ulepszenia zabezpieczeń uwierzytelniania Gdy usługa jest uruchomiona na koncie użytkownika z zabezpieczeniami w trybie mieszanym, 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 niestandardowy kod do obsługi weryfikacji odcisku palca.

Częściowa obsługa zaufania na potrzeby rejestrowania zdarzeń Zaufanie częściowe obsługuje teraz ograniczone rejestrowanie zdarzeń. Do dziennika zdarzeń są rejestrowane tylko błędy aktywacji usługi, błędy śledzenia i błędy rejestrowania. 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ści 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 wykonywania odbierania jednokierunkowego). Nie są wymagane żadne modyfikacje.

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

Zobacz też

informacje o wersji programu .NET Framework i zestawie