.NET Framework 4 geçiş sorunları

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ızda herhangi bir programlama değişikliği 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)

Ö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 iPhone 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, tarayıcı tanım dosyaları tarafından yönlendirilir ve sayfanın `Request.Browse` özelliği tarafından erişilebilir kılınır. 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 ASP.NET 4 Önemli Değişiklikler belgesinde yer alan "ASP.NET 2.0 veya ASP.NET 3.5 Uygulamalarının Altında Çalışan ASP.NET 4 Alt Uygulamalar 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'in önceki sürümlerinde varsayılan davranış, `AutoIDclientIDMode` ayarıyla 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 yeni `legacyCasModel` özniteliğini kullanarak kısmi güven ASP.NET 4 uygulamalarını ASP.NET 1.1 ve 2.0'ın davranışları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ı), uygulama Web.config dosyalarında bulunan ortak yapılandırma bilgilerinin çoğunu ASP.NET 3.5'te 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 kombinasyonları ve belirli kombinasyonlarla ilgili sorunların nasıl çözüleceği hakkında bilgi için, ASP.NET Web sitesindeki ASP.NET 4 Değişikliklere Yol Açan Unsurlar belgesinde "Yeni ASP.NET 4 Kök Yapılandırmasıyla İlgili Yapılandırma Hataları" bölümüne bakın.
Görselleştirmeyi denetleme	ASP.NET'in önceki sürümlerinde, bazı denetimler devre dışı bırakamadığınız işaretleme oluşturuyordu. 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. * `HtmlForm` kontrolü bir `name` özniteliği render etmez. * Denetim `Table` artık bir `border="0"` özniteliği oluşturmaz. Kullanıcı girişi için tasarlanmamış denetimler (örneğin, `Label` denetimi), `disabled="disabled"` özellikleri `Enabled` olarak ayarlanmışsa (veya bu ayarı kapsayıcı denetimden devralmışlarsa), `false` özniteliğini artık görüntülemez.	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 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'in önceki sürümlerinde, bir istek `http://contoso.com`'e yapıldığında, Default.aspx'e yönlendirilirdi. Bu belgede, açılış `form` etiketi aşağıdaki örnekte olduğu gibi işlenecektir. `<form action="Default.aspx" />` ASP.NET 4'te, bir `http://contoso.com` isteği yine Default.aspx isteğiyle sonuçlanır, ancak ASP.NET, HTML açılış `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: * `form` öğesinin `action` özniteliği "" olarak ayarlanmış bir .aspx sayfası tarayıcıya gönderilir. * Bu form ASP.NET'e geri gönderiliyor. * Yönetilen bir HTTP modülü, varlık gövdesinin `Request.Form` veya `Request.Params` gibi 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önderilecek bir varlık gövdesi bulunmamaktadır. * 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 sorunları aşmanın yolları hakkında bilgi almak için, ASP.NET Web sitesindeki ASP.NET 4 Önemli Değişiklikler belgesindeki "IIS 7 veya IIS 7.5 Tümleşik Modunda Varsayılan Bir Belgede Olay İşleyicileri Tetiklenmeyebilir" konusuna bakın.
Hash 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, çerezler ve görüntüleme durumu üzerindeki karma işlemleri için HMACSHA256 algoritmasını 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'i 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 `UrlEncode` ve HttpUtility HttpServerUtility yöntemleri, tek tırnak işareti karakterini (') aşağıdaki gibi kodlayarak güncelleştirildi: * Bu `HtmlEncode` yöntemi, tek tırnak işaretinin örneklerini `'` olarak kodlar. * Bu `UrlEncode` yöntemi, tek tırnak işaretinin örneklerini `%27` olarak kodlar.	ve `HtmlEncode` yöntemlerini kullandığınız `UrlEncode` 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 2.0 Uygulamaları eurl.axd'ye Başvuran HttpException Hataları Oluşturabilir" bölümüne ASP.NET Web sitesindeki ASP.NET 4'teki Bozulma Değişiklikleri belgesinde bakın.
Üyelik türleri	ASP.NET üyelikte kullanılan bazı türler (örneğin, MembershipProvider) System.Web.dll derlemesinden 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, sınıf kitaplığı projesine System.Web.ApplicationServices.dlliçin bir referans ekleyin.
Menü denetimi değişiklikleri	Denetimde yapılan Menu değişiklikler aşağıdaki davranışla sonuçlanır: * MenuRenderingMode`List` olarak ayarlandıysa, veya MenuRenderingMode`Default` olarak ve ControlRenderingCompatibilityVersion`4.0` veya daha sonra olarak ayarlandıysa, PopOutImageUrl özelliğinin hiçbir etkisi yoktur. Eğer StaticPopOutImageUrl ve DynamicPopOutImageUrl özelliklerinde ayarlanan yol ters eğik çizgi (\) içeriyorsa, görüntüler gösterilmez. (ASP.NET önceki sürümlerinde yol ters eğik çizgi içerebilir.)	* Tek tek menü öğeleri için PopOutImageUrl özelliğini ayarlamak yerine, ebeveyn StaticPopOutImageUrl denetiminin DynamicPopOutImageUrl veya Menu özelliğini ayarlayın. -veya- MenuRenderingMode öğesini `Table` olarak ayarlayın veya MenuRenderingMode öğesini `Default` olarak ve ControlRenderingCompatibilityVersion öğesini `3.5` olarak ayarlayın. Bu ayarlar, denetimin Menu önceki ASP.NET sürümlerinde kullandığı HTML tablo tabanlı düzeni kullanmasına neden olur. * Eğer StaticPopOutImageUrl veya DynamicPopOutImageUrl özelliğindeki yol ters eğik çizgi (\) içeriyorsa, eğik çizgi (/) ile değiştirin.
Web.config dosyasında mobil derleme	ASP.NET'ın önceki sürümlerinde, altındaki `assembliessystem.web`/bölümündeki kök Web.config dosyasına System.Web.Mobile.dll derlemesine `compilation` 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 eklenir, ancak kullanım dışıdır.	Bu derlemedeki türleri kullanmak istiyorsanız, kök Web.config dosyasında veya uygulama Web.config dosyasında derlemeye bir başvuru ekleyin.
Çıktı önbelleğe alma	ASP.NET 1.0'daki bir hata, çıkış önbelleği ayarı olarak `Location="ServerAndClient"` belirtilen önbelleğe alınmış sayfaların yanıtta `Vary:` HTTP üst bilgisi göndermesine 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 bilgisini engellemek için çağrılabilen `Vary:` 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" %>` Artık SetOmitVaryStar üst bilgisinin bastırılması için `Vary:` yöntemi 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 `Vary:` yayması gerekiyorsa, aşağıdaki örnekte gösterildiği gibi AppendHeader yöntemini çağırın. `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, System.Web.Security içindeki Passport ile ilgili türler artık `ObsoleteAttribute` özniteliğiyle 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 `PathInfo`, FilePath ve AppRelativeCurrentExecutionFilePath gibi özelliklerden dönen değerlere CurrentExecutionFilePath değerini eklemez. Bunun yerine, `PathInfo` bilgileri PathInfo içinde bulunabilir. Ö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 amacıyla, ASP.NET istek doğrulama işlemi istek yaşam döngüsünün daha erken bir aşamasında başlatı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 yollar üzerinden bir HTTP 404 hatası döndürülüyor. 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 özniteliğini "/" olarak değiştirin `Virtual Path` . -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, `<system.Web>` öğesinin içindeki 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.

Çekirdek