.NET Framework 4 geçiş sorunları

Makale
10/04/2023

Bu makalede düzeltmeler, standartlara uyumluluk ve güvenlik değişiklikleri ve müşteri geri bildirimlerine dayalı değişiklikler de dahil olmak üzere .NET Framework sürüm 3.5 Service Pack 1 ile .NET Framework sürüm 4 arasındaki geçiş sorunları açıklanmaktadır. Bu değişikliklerin çoğu uygulamalarınızdaki programlamalarda herhangi bir değişiklik gerektirmez. Değişiklik içerebilecek olanlar için tablonun Önerilen değişiklikler sütununa bakın. Önemli değişiklikler, ASP.NET ve Windows Presentation Foundation (WPF) gibi alanlara göre ayrılmıştır.

Bu makaledeki sorunlara daha üst düzey bir genel bakış için bkz . .NET Framework 4'e Geçiş Kılavuzu.

Yeni özellikler hakkında bilgi için bkz . .NET Framework 4'teki Yenilikler.

ASP.NET ve Web

Ad Alanları: System.Web, System.Web.Mobile, System.Web.Security, System.Web.UI.WebControls

Derleme: System.Web (System.Web.dll içinde)

Özellik	3.5 SP1 ile arasındaki farklar	Önerilen değişiklikler
Tarayıcı tanım dosyaları	Tarayıcı tanım dosyaları, yeni ve güncelleştirilmiş tarayıcılar ve cihazlar hakkında bilgi içerecek şekilde güncelleştirildi. Netscape Navigator gibi eski tarayıcılar ve cihazlar kaldırıldı ve Google Chrome ve Apple i Telefon gibi daha yeni tarayıcılar ve cihazlar eklendi. Uygulamanız kaldırılan tarayıcı tanımlarından birinden devralınan özel tarayıcı tanımları içeriyorsa bir hata görürsünüz. HttpBrowserCapabilities Nesne (sayfanın `Request.Browse` özelliği tarafından kullanıma sunulur) tarayıcı tanım dosyaları tarafından yönlendirilir. Bu nedenle, ASP.NET 4'te bu nesnenin bir özelliğine erişilerek döndürülen bilgiler, ASP.NET önceki bir sürümünde döndürülen bilgilerden farklı olabilir.	Uygulamanız eski tarayıcı tanım dosyalarını kullanıyorsa, bunları aşağıdaki klasörden kopyalayabilirsiniz: Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers Dosyaları ASP.NET 4 için karşılık gelen \CONFIG\Browsers klasörüne kopyalayın. Dosyaları kopyaladıktan sonra Aspnet_regbrowsers.exe komut satırı aracını çalıştırın. Daha fazla bilgi için web sitesine bakın https://www.asp.net/mobile .
ASP.NET'nin karma sürümleri altında çalışan alt uygulamalar	ASP.NET ASP.NET önceki sürümlerini çalıştıran uygulamaların alt öğeleri olarak yapılandırılan 4 uygulama, yapılandırma veya derleme hataları nedeniyle başlatılamıyor olabilir. Oluşan hata, uygulamanın IIS 6.0 veya IIS 7 veya IIS 7.5 altında çalışıp çalışmadığına bağlıdır.	Yapılandırma sisteminin ASP.NET 4 uygulamasını doğru şekilde tanıması için etkilenen uygulamaların yapılandırma dosyalarında değişiklik yapabilirsiniz. Yapmanız gereken değişiklikler hakkında bilgi için, ASP.NET Web sitesindeki 4 Hataya Neden Olan Değişiklikler ASP.NET belgedeki "ASP.NET 4 Alt Uygulama ASP.NET 2.0 veya ASP.NET 3.5 Uygulamalarında Başlatılamıyor" bölümüne bakın.
ClientID değişiklikleri	ASP.NET 4'teki yeni `clientIDMode` ayar, ASP.NET'nin HTML öğeleri için özniteliği nasıl oluşturacağını belirtmenize `id` olanak tanır. ASP.NET'ın önceki sürümlerinde varsayılan davranış ayarıyla `AutoIDclientIDMode`eşdeğerdi. Varsayılan ayar şudur: `Predictable`. Daha fazla bilgi için bkz . ASP.NET Web Sunucusu Denetim Kimliği.	Uygulamanızı ASP.NET 2.0 veya ASP.NET 3.5'ten yükseltmek için Visual Studio kullanıyorsanız, araç Web.config dosyasına .NET Framework'ün önceki sürümlerinin davranışını koruyan bir ayarı otomatik olarak ekler. Ancak, IIS'deki uygulama havuzunu .NET Framework 4'e hedef olarak değiştirerek bir uygulamayı yükseltirseniz, ASP.NET varsayılan olarak yeni modu kullanır. Yeni istemci kimliği modunu devre dışı bırakmak için Web.config dosyasına aşağıdaki ayarı ekleyin: `<pages clientIDMode="AutoID" />`
Kod erişim güvenliği (CAS)	ASP.NET 3.5'e eklenen ASP.NET 2.0 NET özellikleri.NET Framework 1.1 ve .NET Framework 2.0 kod erişim güvenliği (CAS) modelini kullanır. Ancak, ASP.NET 4'te CAS'nin uygulanması önemli ölçüde elden geçirilmiştir. Sonuç olarak, genel derleme önbelleğinde çalışan güvenilen kodu kullanan kısmi güven ASP.NET uygulamaları çeşitli güvenlik özel durumları ile başarısız olabilir. Makine CAS ilkesinde kapsamlı değişikliklere dayanan kısmi güven uygulamaları da başarısız olabilir ve güvenlik özel durumları oluşturabilir.	Aşağıdaki örnekte gösterildiği gibi yapılandırma öğesindeki `trust` yeni `legacyCasModel` özniteliği kullanarak kısmi güven ASP.NET 4 uygulaması ASP.NET 1.1 ve 2.0 davranışına geri döndürebilirsiniz: `<trust level= "Medium" legacyCasModel="true" />` Önemli: Eski CAS modeline geri dönmek azaltılmış güvenliği temsil edebilir. Yeni ASP.NET 4 kod erişimi güvenlik modeli hakkında daha fazla bilgi için bkz . ASP.NET 4 Uygulamalarında Kod Erişim Güvenliği.
Yapılandırma dosyaları	.NET Framework ve ASP.NET 4 için kök yapılandırma dosyaları (machine.config dosyası ve kök Web.config dosyası), ASP.NET 3.5'teki uygulama Web.config dosyalarında bulunan ortak yapılandırma bilgilerinin çoğunu içerecek şekilde güncelleştirildi. Yönetilen IIS 7 ve IIS 7.5 yapılandırma sistemlerinin karmaşıklığı nedeniyle, ASP.NET 4 altında ve IIS 7 ve IIS 7.5 altında ASP.NET 3.5 uygulamalarını çalıştırmak ASP.NET hatalara veya IIS hatalarıyla sonuçlanabilir.	Visual Studio'daki proje yükseltme araçlarını kullanarak ASP.NET 3.5 uygulamalarını ASP.NET 4'e yükseltin. Visual Studio 2010, ASP.NET 3.5 uygulamasının Web.config dosyasını ASP.NET 4 için uygun ayarları içerecek şekilde otomatik olarak değiştirir. Ancak, yeniden derleme olmadan .NET Framework 4 kullanarak ASP.NET 3.5 uygulamalarını çalıştırabilirsiniz. Bu durumda, uygulamayı .NET Framework 4 ve IIS 7 veya IIS 7.5 altında çalıştırmadan önce uygulamanın Web.config dosyasını el ile değiştirmeniz gerekebilir. Yapmanız gereken belirli değişiklik, Hizmet Paketi (SP) sürümleri de dahil olmak üzere üzerinde çalıştığınız yazılımın birleşimine bağlıdır. Bu değişiklikten etkilenen olası yazılım birleşimleri ve belirli birleşimlerle ilgili sorunları çözme hakkında bilgi için, ASP.NET Web sitesindeki 4 Hataya Neden Olan Değişiklikler ASP.NET belgedeki "Yeni ASP.NET 4 Kök Yapılandırmasıyla İlgili Yapılandırma Hataları" bölümüne bakın.
İşlemeyi denetleme	ASP.NET'ın önceki sürümlerinde, bazı denetimler devre dışı bırakamadığınız işaretlemeler yaymıştı. Varsayılan olarak, bu işaretleme türü artık ASP.NET 4'te oluşturulmaz. İşleme değişiklikleri aşağıdaki denetimleri etkiler: `Image`* ve `ImageButton` denetimleri artık bir `border="0"` özniteliği işlemez. * Bundan `BaseValidator` türetilen sınıf ve doğrulama denetimleri artık varsayılan olarak kırmızı metin işlemez. * Denetim `HtmlForm` bir `name` özniteliği işlemez. * Denetim `Table` artık bir `border="0"` özniteliği işlemez. Kullanıcı girişi (örneğin, denetim) için tasarlanmamış denetimler, `Label` özellikleri olarak ayarlanmışsa `Enabledfalse` (veya bu ayarı kapsayıcı denetiminden devralıyorsa) özniteliğini işlemez`disabled="disabled"`.	Uygulamanızı ASP.NET 2.0 veya ASP.NET 3.5'ten yükseltmek için Visual Studio kullanırsanız, araç Web.config dosyasına eski işlemeyi koruyan bir ayarı otomatik olarak ekler. Ancak, IIS'deki uygulama havuzunu .NET Framework 4'e hedef olarak değiştirerek bir uygulamayı yükseltirseniz, ASP.NET varsayılan olarak yeni işleme modunu kullanır. Yeni işleme modunu devre dışı bırakmak için Web.config dosyasına aşağıdaki ayarı ekleyin: `<pages controlRenderingCompatibilityVersion="3.5" />`
Varsayılan belgelerde olay işleyicileri	ASP.NET 4, html öğesinin `formaction` öznitelik değerini, varsayılan bir belgenin eşlendiği uzantısız bir URL'ye istekte bulunulduğunda boş bir dize olarak işler. ASP.NET'ın önceki sürümlerinde, bir isteğin `http://contoso.com` Default.aspx isteğine neden olması gerekir. Bu belgede, açma `form` etiketi aşağıdaki örnekte olduğu gibi işlenir: `<form action="Default.aspx" />` ASP.NET 4'te, bir isteğin `http://contoso.com` de Default.aspx isteğiyle sonuçlandığı halde ASP.NET html açma `form` etiketini aşağıdaki örnekte olduğu gibi işler: `<form action="" />` `action` Öznitelik boş bir dize olduğunda, IIS `DefaultDocumentModule` nesnesi Default.aspx için bir alt istek oluşturur. Çoğu koşulda, bu alt istek uygulama kodu için saydamdır ve Default.aspx sayfası normal şekilde çalışır. Ancak, yönetilen kod ile IIS 7 veya IIS 7.5 Tümleşik modu arasındaki olası bir etkileşim, yönetilen .aspx sayfalarının alt istek sırasında düzgün çalışmamasına neden olabilir. Aşağıdaki koşullar oluşursa, varsayılan bir .aspx belgesine yönelik alt istek bir hataya veya beklenmeyen davranışa neden olur: * Öğenin `action` özniteliği "" olarak ayarlanmış bir .aspx sayfası tarayıcıya `form` gönderilir. * Form ASP.NET geri gönderiliyor. * Yönetilen BIR HTTP modülü, varlık gövdesinin veya `Request.Params`gibi `Request.Form` bir bölümünü okur. Bu, POST isteğinin varlık gövdesinin yönetilen belleğe okunmasını sağlar. Sonuç olarak, varlık gövdesi artık IIS 7 veya IIS 7.5 Tümleşik modunda çalışan yerel kod modülleri tarafından kullanılamaz. * IIS `DefaultDocumentModule` nesnesi sonunda çalışır ve Default.aspx belgesine bir alt istek oluşturur. Ancak, varlık gövdesi bir yönetilen kod parçası tarafından zaten okunduğu için alt isteğe gönderilebilecek varlık gövdesi yoktur. * HTTP işlem hattı alt istek için çalıştırıldığında, .aspx dosyalarının işleyicisi işleyici yürütme aşamasında çalışır. Varlık gövdesi olmadığından, form değişkeni ve görünüm durumu yoktur. Bu nedenle, .aspx sayfa işleyicisi için hangi olayın (varsa) tetiklenmesi gerektiğini belirlemek için kullanılabilir bilgi yoktur. Sonuç olarak, etkilenen .aspx sayfası için geri gönderme olay işleyicilerinin hiçbiri çalışmaz.	Bu değişiklik sonucunda ortaya çıkabilecek sorunlara geçici çözüm yolları hakkında bilgi için, ASP.NET Web sitesindeki 4 Hataya Neden Olan Değişiklikler ASP.NET belgenin "IIS 7 veya IIS 7.5 Tümleşik Modunda Varsayılan Belgede Olay İşleyicileri Tetiklenmeyebilir" konusuna bakın.
Karma algoritması	ASP.NET, form kimlik doğrulaması tanımlama bilgileri ve görüntüleme durumu gibi verilerin güvenliğini sağlamaya yardımcı olmak için hem şifreleme hem de karma algoritmaları kullanır. Varsayılan olarak ASP.NET 4, tanımlama bilgileri ve görüntüleme durumu üzerindeki karma işlemleri için algoritmayı HMACSHA256 kullanır. ASP.NET'ın önceki sürümleri eski HMACSHA1 algoritmayı kullanıyordu.	Form kimlik doğrulama tanımlama bilgileri gibi verilerin .NET Framework sürümlerinde çalışması gereken ASP.NET 2.0 ve ASP.NET 4'leri karıştıran uygulamalar çalıştırıyorsanız, Web.config dosyasına aşağıdaki ayarı ekleyerek ASP.NET 4 Web uygulamasını eski HMACSHA1 algoritmayı kullanacak şekilde yapılandırın: `<machineKey validation="SHA1" />`
Internet Explorer'da barındırma denetimleri	Web'de denetimleri barındırmak için daha iyi çözümler olduğundan, Artık Windows Forms denetimlerini Internet Explorer'da barındıramamalısınız. Bu nedenle, IEHost.dll ve IEExec.exe derlemeleri .NET Framework'ten kaldırılmıştır.	Web uygulamalarında özel denetim geliştirme için aşağıdaki teknolojileri kullanabilirsiniz: * Bir Silverlight uygulaması oluşturabilir ve tarayıcı dışında çalışacak şekilde yapılandırabilirsiniz. Daha fazla bilgi için bkz . Tarayıcı Dışı Destek. * WPF özelliklerinden yararlanmak için bir XAML tarayıcı uygulaması (XBAP) oluşturabilirsiniz (istemci makinelerinde .NET Framework gerektirir). Daha fazla bilgi için bkz . WPF XAML Tarayıcı Uygulamalarına Genel Bakış.
HtmlEncode ve UrlEncode yöntemleri	`HtmlEncode` ve sınıflarının HttpUtility ve `UrlEncode`HttpServerUtility yöntemleri, tek tırnak işareti karakterini (') aşağıdaki gibi kodlayarak güncelleştirildi: * yöntemi tek `HtmlEncode` tırnak işaretinin örneklerini şu şekilde kodlar: `'` * yöntemi tek `UrlEncode` tırnak işaretinin örneklerini şu şekilde kodlar: `%27`	ve `UrlEncode` yöntemlerini kullandığınız `HtmlEncode` yerler için kodunuzu inceleyin ve kodlamadaki değişikliğin uygulamanızı etkileyebilecek bir değişiklikle sonuçlanmadığından emin olun.
ASP.NET 2.0 uygulamalarında HttpException hataları	IIS 6'da ASP.NET 4 etkinleştirildikten sonra, IIS 6 üzerinde çalışan ASP.NET 2.0 uygulamaları (Windows Server 2003 veya Windows Server 2003 R2'de) aşağıdaki gibi hatalar oluşturabilir: `System.Web.HttpException: Path '/[yourApplicationRoot]/eurl.axd/[Value]' was not found.`	* Web sitesini çalıştırmak için ASP.NET 4 gerekli değilse, siteyi ASP.NET 2.0 kullanacak şekilde yeniden eşle. -veya- * Web sitesini çalıştırmak için ASP.NET 4 gerekiyorsa, alt ASP.NET 2.0 sanal dizinlerini ASP.NET 2.0 ile eşlenen farklı bir Web sitesine taşıyın. -veya- * Uzantısız URL'leri devre dışı bırakın. Daha fazla bilgi için, ASP.NET Web sitesindeki 4 Hataya Neden Olan Değişiklikler ASP.NET belgedeki "ASP.NET 2.0 Uygulamaları eurl.axd'ye Başvuran HttpException Hataları Oluşturabilir" bölümüne bakın.
Üyelik türleri	ASP.NET üyelikte kullanılan bazı türler (örneğin, MembershipProvider) System.Web.dll System.Web.ApplicationServices.dll derlemesine taşındı. Türler, istemcideki ve genişletilmiş .NET Framework SKU'larındaki türler arasındaki mimari katmanlama bağımlılıklarını çözümlemek için taşındı.	ASP.NET'nin önceki sürümlerinden yükseltilen ve taşınan üyelik türlerini kullanan sınıf kitaplıkları, ASP.NET 4 projesinde kullanıldığında derlenemiyor olabilir. Öyleyse, System.Web.ApplicationServices.dll için sınıf kitaplığı projesine bir başvuru ekleyin.
Menü denetimi değişiklikleri	Denetimde yapılan Menu değişiklikler aşağıdaki davranışla sonuçlanır: * olarak ayarlandıysa MenuRenderingMode`List`veya olarak ve ControlRenderingCompatibilityVersion`Default` veya daha sonra olarak ayarlandıysa MenuRenderingMode`4.0`, özelliğin PopOutImageUrl hiçbir etkisi yoktur. * ve DynamicPopOutImageUrl özelliklerinde StaticPopOutImageUrl ayarlanan yol ters eğik çizgi (\) içeriyorsa, görüntüler işlenmez. (ASP.NET önceki sürümlerinde yol ters eğik çizgi içerebilir.)	* Tek tek menü öğeleri için özelliğini ayarlamak PopOutImageUrl yerine, veya DynamicPopOutImageUrl üst Menu denetimini ayarlayınStaticPopOutImageUrl. -veya- olarak `Table`ayarlayın MenuRenderingMode veya olarak ayarlayın MenuRenderingMode`Default` ve olarak `3.5`ayarlayınControlRenderingCompatibilityVersion. Bu ayarlar, denetimin Menu önceki ASP.NET sürümlerinde kullandığı HTML tablo tabanlı düzeni kullanmasına neden olur. * or DynamicPopOutImageUrl özelliğindeki StaticPopOutImageUrl yol ters eğik çizgi (\) içeriyorsa, eğik çizgi karakterini (/) kullanın.
Web.config dosyasında mobil derleme	ASP.NET'in önceki sürümlerinde, altındaki `system.web`/`compilation`bölümündeki kök Web.config dosyasına System.Web.Mobile.dll derlemesine `assemblies` bir başvuru eklenmiştir. Performansı geliştirmek için bu derlemeye başvuru kaldırıldı. Not: System.Web.Mobile.dll derlemesi ve ASP.NET mobil denetimleri ASP.NET 4'e dahil edilir, ancak kullanım dışıdır.	Bu derlemedeki türleri kullanmak istiyorsanız, derlemeye kök Web.config dosyasında veya bir uygulama Web.config dosyasında başvuru ekleyin.
Çıktı önbelleğe alma	ASP.NET 1.0'da bir hata, yanıtta http üst bilgisi yaymak `Vary:` için output€"cache ayarı olarak belirtilen `Location="ServerAndClient"` önbelleğe alınmış sayfalara neden oldu. Bu, istemci tarayıcılarına sayfayı hiçbir zaman yerel olarak önbelleğe almamalarını söylemenin etkisi oldu. ASP.NET 1.1'de, SetOmitVaryStar üst bilgiyi engellemek `Vary:` için çağrılabilen yöntemi eklendi. Ancak, hata raporları geliştiricilerin mevcut `SetOmitVaryStar` davranışın farkında olmadığını gösterir. ASP.NET 4'te HTTP `Vary:` üst bilgisi artık aşağıdaki yönergeyi belirten yanıtlardan dışarı aktarilmez: `<%@ OutputCache Location="ServerAndClient" %>` Sonuç olarak, üst bilginin gizlenmesi SetOmitVaryStar`Vary:` için yöntemi artık gerekli değildir. özniteliği için `Location` "ServerAndClient" belirten uygulamalarda, çağırmanıza SetOmitVaryStargerek kalmadan sayfalar tarayıcıda önbelleğe alınabilecektir.	Uygulamadaki sayfaların yayması `Vary:`gerekiyorsa, aşağıdaki örnekte gösterildiği gibi yöntemini çağırın AppendHeader : `System.Web.HttpResponse.AppendHeader("Vary","");` Alternatif olarak, çıkış önbelleğe `Location` alma özniteliğinin değerini "Sunucu" olarak değiştirebilirsiniz.
Sayfa ayrıştırma	ASP.NET Web sayfaları (.aspx dosyaları) ve kullanıcı denetimleri (.ascx dosyaları) için sayfa ayrıştırıcısı, ASP.NET 4'teki sayfa ayrıştırıcısı, ASP.NET önceki sürümlerindekinden daha katıdır ve önceki sürümlerden daha fazla işaretlemeyi geçersiz olarak işaretler.	Sayfa çalıştırıldığında oluşturulan hata iletilerini inceleyin ve geçersiz işaretlemeden kaynaklanan hataları düzeltin.
Pasaport türleri	ASP.NET 2.0'da yerleşik olan Passport desteği kullanımdan kaldırılmış ve Passport'taki değişiklikler (şimdi Live ID SDK'sı) nedeniyle desteklenmiyor. Sonuç olarak, içindeki System.Web.Security Passport ile ilgili türler artık özniteliğiyle `ObsoleteAttribute` işaretlenir.	Ad alanında System.Web.Security Passport türlerini (örneğin, PassportIdentity) kullanan tüm kodları Windows Live ID SDK'sını kullanacak şekilde değiştirin.
FilePath özelliğindeki PathInfo bilgileri	ASP.NET 4 artık , AppRelativeCurrentExecutionFilePathve CurrentExecutionFilePathgibi FilePathözelliklerden döndürülen değerlere değer eklemez`PathInfo`. Bunun yerine, `PathInfo` bilgiler içinde PathInfokullanılabilir. Örneğin, aşağıdaki URL parçasını düşünün: `/testapp/Action.mvc/SomeAction` ASP.NET'nin HttpRequest önceki sürümlerinde özellikler aşağıdaki değerlere sahiptir: * FilePath: `/testapp/Action.mvc/SomeAction` * PathInfo: (boş) ASP.NET 4'te, HttpRequest özellikler bunun yerine aşağıdaki değerlere sahiptir: * FilePath: `/testapp/Action.mvc` * PathInfo: `SomeAction`	Yol bilgilerini döndürmek için sınıfın HttpRequest özelliklerine güvendiğiniz yerler için kodunuzu inceleyin; kodu yol bilgilerinin döndürülmesiyle ilgili değişiklikleri yansıtacak şekilde değiştirin.
İstek doğrulama	İstek doğrulamasını geliştirmek için, istek ASP.NET doğrulama, istek yaşam döngüsünün başlarında çağrılır. Sonuç olarak, web hizmeti çağrıları ve özel işleyiciler gibi .aspx dosyaları için olmayan istekler için istek doğrulama çalıştırılır. İstek işleme işlem hattında özel HTTP modülleri çalıştırıldığında da istek doğrulama etkin olur. Bu değişikliğin sonucunda, .aspx dosyalar dışındaki kaynaklara yönelik istekler istek doğrulama hataları verebilir. İstek işlem hattında çalışan özel kod (örneğin, özel HTTP modülleri) istek doğrulama hataları da verebilir.	Gerekirse, Web yapılandırma dosyasında aşağıdaki ayarı kullanarak yalnızca .aspx sayfaların istek doğrulamasını tetiklemesi eski davranışına geri dönebilirsiniz: `<httpRuntime requestValidationMode="2.0" />` Uyarı: Eski davranışa geri dönerseniz, mevcut işleyicilerdeki, modüllerdeki ve diğer özel kodlardaki tüm kodların XSS saldırı vektörleri olabilecek güvenli olmayabilecek HTTP girişleri için denetimler gerçekleştirdiğinden emin olun.
Yönlendirme	Visual Studio 2010'da bir dosya sistemi Web sitesi oluşturursanız ve Web sitesi klasör adında nokta (.) bulunan bir klasördeyse, URL yönlendirme güvenilir bir şekilde çalışmaz. Bazı sanal yollardan BIR HTTP 404 hatası döndürülür. Bunun nedeni, Visual Studio 2010'un kök sanal dizin için yanlış bir yol kullanarak Visual Studio Geliştirme Sunucusu'nu başlatmasıdır.	* Dosya tabanlı Web sitesinin Özellikler sayfasında Sanal Yol özniteliğini "/" olarak değiştirin. -veya- * Web sitesi projesi yerine bir Web uygulaması projesi oluşturun. Web uygulaması projelerinde bu sorun yoktur ve proje klasörünün adında bir nokta olsa bile URL yönlendirmesi çalışır. -veya- * IIS'de barındırılan HTTP tabanlı bir Web sitesi oluşturun. IIS tarafından barındırılan Web siteleri hem sanal yolda hem de proje dosyası klasöründe noktalar içerebilir.
SharePoint siteleri	adlı `WSS_Minimal`özel bir kısmi güven düzeyi içeren bir SharePoint Web sitesinin alt öğesi olarak dağıtılan ASP.NET 4 Web sitesini çalıştırmayı denerseniz aşağıdaki hatayı görürsünüz: `Could not find permission set named 'ASP.Net'.`	Şu anda SharePoint'in hiçbir sürümü ASP.NET ile uyumlu değildir. Sonuç olarak, ASP.NET 4 Web sitesini SharePoint Web sitesinin alt öğesi olarak çalıştırmayı denememelisiniz.
XHTML 1.1 standartları	Yeni Web sitelerinde XHTML 1.1 uyumluluğunu etkinleştirmek için.NET Framework 4'teki ASP.NET denetimleri XHTML 1.1 uyumlu HTML oluşturur. Bu işleme, öğesinin içindeki `<system.Web>` Web.config dosyasında aşağıdaki seçenek kullanılarak etkinleştirilir: `<pages controlRenderingCompatibilityVersion="4.0"/>` Bu seçenek varsayılan olarak 4.0 olarak ayarlanır. Visual Studio 2008'den yükseltilen web projelerinde uyumluluk için 3.5 ayarı etkindir.	Yok.

Temel

Genel özellikler

Özellik	3.5 SP1 ile arasındaki farklar	Önerilen değişiklikler
Cardspace	Windows CardSpace artık .NET Framework'e dahil değildir; ayrı olarak sağlanır.	Microsoft İndirme Merkezi'nden Windows CardSpace'i indirin.
Yapılandırma dosyaları	.NET Framework'ün uygulama yapılandırma dosyalarına nasıl eriştiğinde düzeltmeler yapılmıştır.	Uygulama yapılandırma dosyanızın adı application-name.config ise, dosyayı application-name.exe.config olarak yeniden adlandırın. Örneğin, MyApp.config öğesini MyApp.exe.config olarak yeniden adlandırın.
C# kod derleyicisi	`Compiler`Ad alanında Microsoft.CSharp bulunan , `CompilerError`ve `ErrorLevel` sınıfları artık kullanılamaz ve derlemeleri (cscompmgd.dll) artık .NET Framework'e dahil değildir.	sınıfını CodeDomProvider ve ad alanında System.CodeDom.Compiler diğer sınıfları kullanın. Daha fazla bilgi için bkz . CodeDOM kullanma.
Barındırma (yönetilmeyen API)	Barındırma özelliklerini geliştirmek için bazı barındırma etkinleştirme API'leri kullanım dışı bırakılmıştır. İşlem içi yan yana yürütme özellikleri, bir uygulamanın aynı işlemde .NET Framework'ün birden çok sürümünü yüklemesine ve başlatmasına olanak tanır. Örneğin, .NET Framework 2.0 SP1'i temel alan eklentileri (veya bileşenleri) yükleyen uygulamaları ve .NET Framework 4'e dayalı eklentileri aynı işlemde çalıştırabilirsiniz. Eski bileşenler eski .NET Framework sürümünü kullanmaya devam eder ve yeni bileşenler yeni .NET Framework sürümünü kullanır.	İşlem İçi Yan Yana Yürütme bölümünde açıklanan yapılandırmaları kullanın.
Yeni güvenlik modeli	Kod erişim güvenliği (CAS) ilkesi kapatılmış ve .NET Framework 4'teki Güvenlik Değişiklikleri'nde açıklandığı gibi basitleştirilmiş bir modelle değiştirilmiştir.	Uygulamalarınızda CAS'ye bağlıysanız değişiklikler gerekebilir. Daha fazla bilgi için bkz . Kod Erişimi Güvenlik İlkesi Uyumluluğu ve Geçişi.

Tarih ve saat

Ad Alanı: System

Derleme: mscorlib (mscorlib.dll)

Özellik	3.5 SP1 ile arasındaki farklar	Önerilen değişiklikler
Gün ışığından yararlanma	Sistem saatiyle tutarlı olmak için saat özellikleri (ve gibi Local Now) artık yaz saati işlemleri için diğer .NET Framework verileri yerine işletim sistemi kurallarını kullanıyor.	Yok.
Dizeleri biçimlendirme	Kültüre duyarlı biçimlendirmeyi TimeSpan desteklemek için yapı, yeni ve `TryParseExact` yöntemlerine `ToString`ek olarak , `Parse`ve `TryParse` yöntemlerinin yeni `ParseExact` aşırı yüklemelerini içerir.	Yok.

Globalleştirme

Yeni nötr ve belirli kültürlerin listesi için bkz . Genelleştirme ve Yerelleştirmedeki Yenilikler.

Ad Alanı: System.Globalization

Derleme: mscorlib (mscorlib.dll)

Özellik	3.5 SP1 ile arasındaki farklar	Önerilen değişiklikler
Kültür adları	Aşağıdaki ad değişiklikleri Almanca, Divehi ve Afrika kültürlerini etkiler: * CurrencyEnglishName: Alman (İsviçre) (ch) kültürünün para birimi adı "sFr." olan "Fr." olarak değiştirildi. * LongDatePattern: Divehi (Maldivler) (dv-MV) kültürü için uzun tarih deseni "dd/MMMM/yyyy" olan "dd/AA/y" olarak değiştirildi. * PMDesignator: Afrikaan (Güney Afrika) (af-ZA) kültürünün P.M. belirleyicisi "nm" yerine "PM" olarak değiştirildi.	Not kültürü adı değişiklikleri.
LCID parametresi	Otomasyon sunucusu ayarlarında beklenen davranışla tutarlı olmak için CLR artık parametresinin `LCID` geçerli kültürünü yönetilmeyen COM tabanlı uygulamalara geçiremez. Bunun yerine, kültür için 1033 (en-us) geçirir.	Belirtilen bir kültür gerektiren yerel uygulamalar dışında hiçbir değişiklik gerekmez.
Eski kültür türleri	CultureTypes ve CultureTypes kültür türleri artık kullanımdan kaldırıldı. Geriye dönük uyumluluk için, CultureTypes şimdi önceki .NET Framework'e dahil edilen nötr ve belirli kültürleri döndürür ve CultureTypes şimdi boş bir liste döndürür.	Numaralandırmanın CultureTypes diğer değerlerini kullanın.
Kültür alınıyor	.NET Framework 4, Windows 7'den başlayarak verilerin kendisini depolamak yerine işletim sisteminden kültür bilgilerini alır. Buna ek olarak, .NET Framework verileri sıralamak ve büyük/küçük harfe ayırmak için Windows ile eşitlenir.	Yok.
Unicode 5.1 standartları	.NET Framework artık yaklaşık 1400 karakterden oluşan tüm Unicode 5.1 karakterlerini destekliyor. Ek karakterler arasında yeni simgeler, oklar, aksan işaretleri, noktalama işaretleri, matematiksel simgeler, CJK vuruşları ve ideograflar, ek Malayalam ve Telugu sayısal karakterleri ve çeşitli Myanmar, Latin, Arapça, Yunanca, Moğolca ve Kiril karakterleri bulunur. Aşağıdaki yeni betikler Unicode 5.1 ile desteklenir: Sundanese, Lepcha, Ol Chiki, Vai, Saurashtra, Kayah Li, Rejang, Gurmukhi, Odia, Tamil, Telugu ve Malayalam karakterleri ve Cham.	Yok.

Özel durumlar

Ad Alanları: System, System.Runtime.ExceptionServices

Derleme: mscorlib (mscorlib.dll)

Özellik	3.5 SP1 ile arasındaki farklar	Önerilen değişiklikler
Bozuk işlem durumu için özel durumlar	CLR artık yönetilen koddaki özel durum işleyicilerine bozuk işlem durumu için özel durumlar sunmaz.	Bu özel durumlar, bir işlemin durumunun bozuk olduğunu gösterir. Uygulamanızı bu durumda çalıştırmanızı önermeyiz. Daha fazla bilgi için MSDN dergisindeki HandleProcessCorruptedStateExceptionsAttribute Bozuk Durum Özel Durumlarını İşleme bölümüne bakın.
Yürütme altyapısı özel durumları	ExecutionEngineException artık kullanımdan kaldırıldı çünkü yakalanabilir bir özel durum, kararsız bir işlemin çalışmaya devam etmesi için izin verir. Bu değişiklik çalışma zamanında öngörülebilirliği ve güvenilirliği artırır.	Koşula işaret etmek için bir InvalidOperationException kullanın.

Yansıma

Ad Alanı: System.Reflection

Derleme: mscorlib (mscorlib.dll)

Özellik	3.5 SP1 ile arasındaki farklar	Önerilen değişiklikler
Derleme karma algoritmaları	Derleme HashAlgorithm yüklenmediğinde çalışma zamanı başvuruda bulunılan derlemenin karma algoritmasını bilmediğinden özelliği artık döndürür AssemblyHashAlgorithm. (Bu, yöntemi tarafından döndürülen gibi başvuruda bulunılan bir derlemede GetReferencedAssemblies özelliğini kullanmayı ifade eder.)	Yok.
Derleme yükleme	Derlemelerin yedekli yüklenmesini önlemek ve sanal adres alanından tasarruf etmek için CLR artık yalnızca Win32 `MapViewOfFile` işlevini kullanarak derlemeleri yükler. Artık işlevini çağırmaz `LoadLibrary` . Bu değişiklik tanılama uygulamalarını aşağıdaki yollarla etkiler: * A ProcessModuleCollection artık çağrısından elde edilen `Process.GetCurrentProcess().Modules`bir sınıf kitaplığından (.dll dosyası) modül içermez. * İşlevi `EnumProcessModules` kullanan Win32 uygulamaları, listelenen tüm yönetilen modülleri görmez.	Yok.
Tür bildiriyor	Türün DeclaringType bildirim türü olmadığında özelliği artık null değerini doğru bir şekilde döndürür.	Yok.
Temsilciler	Temsilci artık, temsilcinin oluşturucusunun ArgumentNullException NullReferenceException null değeri geçirildiğinde yerine bir atar.	Özel durum işleme işlemlerinin öğesini yakaladığına ArgumentNullExceptionemin olun.
Genel bütünleştirilmiş kod önbelleği konum değişikliği	.NET Framework 4 derlemeleri için, genel derleme önbelleği Windows dizininden (%WINDIR%) Microsoft.Net alt dizinine (%WINDIR%\Microsoft.Net) taşındı. Önceki sürümlerdeki derlemeler eski dizinde kalır. Yönetilmeyen ASM_CACHE_FLAGS numaralandırması yeni `ASM_CACHE_ROOT_EX` bayrağı içerir. Bu bayrak, GetCachePath işlevi tarafından alınabilen .NET Framework 4 derlemeleri için önbellek konumunu alır.	Hiçbiri, uygulamaların derlemeler için açık yollar kullanmadığını varsayarsak, bu önerilen bir uygulama değildir.
Genel bütünleştirilmiş kod önbellek aracı	Gacutil.exe (Genel Bütünleştirilmiş Kod Önbellek Aracı) artık kabuk eklentisi görüntüleyicisini desteklemez.	Yok.

Birlikte çalışabilirlik

Ad Alanı: System.Runtime.InteropServices

Derleme: mscorlib (mscorlib.dll)

Özellik	3.5 SP1 ile arasındaki farklar	Önerilen değişiklikler
Arabellek uzunluğu (yönetilmeyen API)	Belleği kaydetmek için`pBufferLengthOffset`, ICorProfilerInfo2::GetStringLayout yönteminin parametresinin işlevselliği parametresiyle `pStringLengthOffset` eşleşecek şekilde değiştirildi. Her iki parametre de artık dize uzunluğunun uzaklık konumuna işaret eder. Arabellek uzunluğu dize sınıfının gösteriminden kaldırıldı.	Arabellek uzunluğu üzerindeki tüm bağımlılıkları kaldırın.
JIT hata ayıklama	Tam zamanında (JIT) hata ayıklama için kaydı basitleştirmek için .NET Framework hata ayıklayıcısı artık yerel kod için JIT hata ayıklama davranışını denetleyen yalnızca AeDebug kayıt defteri anahtarını kullanıyor. Bu değişiklik aşağıdakilere neden olur: * Yönetilen ve yerel kod için artık iki farklı hata ayıklayıcı kaydedemezsiniz. * Artık etkileşimli olmayan bir işlem için hata ayıklayıcıyı otomatik olarak başlatasınız, ancak kullanıcıdan etkileşimli bir işlem isteyebilirsiniz. * Artık hata ayıklayıcı başlatılamıyorsa veya başlatılması gereken kayıtlı bir hata ayıklayıcı olmadığında size bildirilmiyor. * Uygulamanın etkileşimini temel alan otomatik başlatma ilkeleri artık desteklenmiyor.	Hata ayıklama işlemlerini gerektiği gibi ayarlayın.
Platform çağırma	Yönetilmeyen kodla birlikte çalışabilirlik performansını artırmak için, bir platformdaki yanlış çağırma kuralları artık uygulamanın başarısız olmasına neden oluyor. Önceki sürümlerde, sıralama katmanı yığındaki bu hataları çözdü.	Microsoft Visual Studio'da uygulamalarınızda hata ayıklamak, bu hataları düzeltebilmeniz için sizi uyarır. Güncelleştirilemeyen ikili dosyalarınız varsa, çağırma hatalarının <önceki sürümlerde olduğu gibi yığının çözülmesini sağlamak için uygulamanızın yapılandırma dosyasına NetFx40_PInvokeStackResilience> öğesini ekleyebilirsiniz. Ancak bu durum uygulamanızın performansını etkileyebilir.
Arabirimler kaldırıldı (yönetilmeyen API)	Geliştirici karışıklığını önlemek için, aşağıdaki arabirimler yararlı çalışma zamanı senaryoları sağlamadığından ve CLR herhangi bir uygulama sağlamadığından veya kabul etmediğinden kaldırıldı: * INativeImageINativeImageDependency * INativeImageInstallInfo * INativeImageEvaluate * INativeImageConverter * ICorModule * IMetaDataConverter	Yok.

Veri

Bu bölümde veri kümeleri ve SQL istemcileri, Entity Framework, LINQ to SQL ve WCF Veri Sunucularını (eski adıyla ADO.NET Veri Hizmetleri) kullanmaya yönelik geçiş sorunları açıklanmaktadır.