ASP.NET 4 Yeni Değişiklik

Bu belgede, .NET Framework sürüm 4 sürümü için yapılan ve ASP.NET 4 Beta 1 ve Beta 2 sürümleri de dahil olmak üzere önceki sürümler kullanılarak oluşturulmuş uygulamaları etkileyebilecek değişiklikler açıklanmaktadır.

Bu Teknik İncelemeyi İndir

İçeriği

Web.config Dosyasında ControlRenderingCompatibilityVersion Ayarı
ClientIDMode Değişiklikleri
HtmlEncode ve UrlEncode Artık Tek Tırnak İşaretlerini de Kodluyor
ASP.NET Sayfası (.aspx) Ayrıştırıcısı Daha Katı
Tarayıcı Tanım Dosyaları Güncelleştirildi
web yapılandırma dosyasından System.Web.Mobile.dll kaldırıldı
ASP.NET İstek Doğrulaması
Varsayılan Karma Algoritması artık HMACSHA256
Yeni ASP.NET 4 Kök Yapılandırmasıyla İlgili Yapılandırma Hataları
ASP.NET 4 Alt Uygulama, ASP.NET 2.0 veya ASP.NET 3.5 Uygulamalarında Başlatılamıyor
ASP.NET 4 Web Sitesi SharePoint'in Yüklü Olduğu Bilgisayarlarda Başlatılamıyor
HttpRequest.FilePath Özelliği artık PathInfo Değerlerini içermiyor
ASP.NET 2.0 Uygulamaları eurl.axd'ye Başvuran HttpException Hataları Oluşturabilir
IIS 7 veya IIS 7.5 Tümleşik Modunda Varsayılan Bir Belgede Olay İşleyicileri Kaldırılmayabilir
ASP.NET Kod Erişim Güvenliği (CAS) Uygulamasında yapılan değişiklikler
System.Web.Security Ad Alanı'ndaki MembershipUser ve Diğer Türler Taşındı
Vary * HTTP Üst Bilgisi İle İlgili Çıkış Önbellekleme Değişiklikleri
Passport için System.Web.Security Türleri Kullanımdan Kaldırıldı
MenuItem.PopOutImageUrl Özelliği ASP.NET 4'te Görüntü İşlenemiyor
Menu.StaticPopOutImageUrl ve Menu.DynamicPopOutImageUrl, Yollar Ters Eğik Çizgi İçerdiğinde Görüntü İşlemede Başarısız Oldu
Reddi

Web.config Dosyasında ControlRenderingCompatibilityVersion Ayarı

ASP.NET denetimleri, işaretlemeyi nasıl işlediklerini daha net bir şekilde belirtmenize olanak sağlamak için .NET Framework sürüm 4'te değiştirilmiştir. .NET Framework'ün önceki sürümlerinde bazı denetimler, devre dışı bırakmanın hiçbir yolunun olmadığı işaretlemeler yaymıştı. Varsayılan olarak, ASP.NET 4 bu tür işaretleme artık oluşturulmaz.

Uygulamanızı ASP.NET 2.0 veya ASP.NET 3.5'ten yükseltmek için Visual Studio 2010 kullanıyorsanız, araç dosyaya otomatik olarak eski işlemeyi Web.config koruyan bir ayar ekler. Ancak, IIS'deki uygulama havuzunu .NET Framework 4'e hedef olacak şekilde 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 dosyaya aşağıdaki ayarı Web.config ekleyin:

<pages controlRenderingCompatibilityVersion="3.5" />

Yeni davranışın getirdiği önemli işleme değişiklikleri aşağıdaki gibidir:

• Image ve ImageButton denetimleri artık bir border="0" özniteliği işlemez.
• Bundan türetilen BaseValidator sınıfı ve doğrulama denetimleri artık varsayılan olarak kırmızı metin işlemez.
• HtmlForm denetimi bir ad özniteliğini işlemez.
• Tablo denetimi artık bir border="0" özniteliği oluşturmaz.
• Kullanıcı girişi için tasarlanmayan denetimler (örneğin, Etiket denetimi), disabled="disabled" özellikleri false olarak ayarlandığında (veya bu ayarı bir kapsayıcı denetimden devraldıklarında) artık özniteliğini oluşturmaz.

ClientIDMode Değişiklikleri

ASP.NET 4'teki ClientIDMode ayarı, ASP.NET HTML öğeleri için kimlik özniteliğini nasıl oluşturacağını belirtmenize olanak tanır. ASP.NET önceki sürümlerinde varsayılan davranış ClientIDMode'un AutoID ayarına eşdeğerdi. Ancak varsayılan ayar artık Tahmin Edilebilir'dir.

Uygulamanızı ASP.NET 2.0 veya ASP.NET 3.5'ten yükseltmek için Visual Studio 2010 kullanıyorsanız, araç dosyaya Web.config otomatik olarak .NET Framework'ün önceki sürümlerinin davranışını koruyan bir ayar 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 dosyaya Web.config aşağıdaki ayarı ekleyin:

<pages clientIDMode="AutoID" />

HtmlEncode ve UrlEncode Artık Tek Tırnak İşaretlerini Kodluyor

ASP.NET 4'te, HttpUtility ve HttpServerUtility sınıflarının HtmlEncode ve UrlEncode yöntemleri, tek tırnak işareti karakterini (') aşağıdaki gibi kodlayarak güncelleştirilmiştir:

• HtmlEncode yöntemi, tek tırnak işaretinin örneklerini ' olarak kodlar.
• UrlEncode yöntemi, tek tırnak işaretinin örneklerini %27olarak kodlar.

ASP.NET Sayfası (.aspx) Ayrıştırıcısı Daha Katı

ASP.NET sayfaları (.aspx dosyalar) ve kullanıcı denetimleri (.ascx dosyalar) için sayfa ayrıştırıcısı ASP.NET 4'te daha katıdır ve daha fazla geçersiz işaretleme örneğini reddeder. Örneğin, aşağıdaki iki kod parçacığı önceki ASP.NET sürümlerinde başarıyla ayrıştırılır, ancak şimdi ASP.NET 4'te ayrıştırıcı hataları oluşturur.

<asp:HiddenField runat="server" ID="SomeControl" Value="sampleValue"  ; />

HiddenField etiketinin sonundaki geçersiz noktalı virgüle dikkat edin.

<asp:LinkButton runat="server" ID="SomeControl" onclick="someControlClicked"
      style="display:inline;  CssClass="searchLink"  />

Kapatılmamış style özniteliğinin CssClass özniteliğine doğru devam ettiğine dikkat edin.

Tarayıcı Tanım Dosyaları Güncelleştirildi

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. Örneğin, App_Browsers klasör IE2 tarayıcı tanımından devralan bir tarayıcı tanımı içeriyorsa, aşağıdaki yapılandırma hata iletisini alırsınız:

• 'IE2' kimliğine sahip tarayıcı veya ağ geçidi öğesi bulunamıyor.

Uyarı

HttpBrowserCapabilities nesnesi (sayfanın Request.Browser ö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.

Tarayıcı tanım dosyalarını aşağıdaki klasörden kopyalayarak eski tarayıcı tanım dosyalarına geri dönebilirsiniz:

Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers

Dosyaları ASP.NET 4 için ilgili \CONFIG\Browsers klasöre kopyalayın. Dosyaları kopyaladıktan sonra Aspnet_regbrowsers.exe komut satırı aracını çalıştırın.

System.Web.Mobile.dll Kök Web Yapılandırma Dosyasından Kaldırıldı

ASP.NET'in önceki sürümlerinde, System.Web.Mobile.dll derlemesine yapılan başvuru, derlemeler bölümündeki kök Web.config dosyasına dahil edildi. Performansı geliştirmek için bu derlemeye başvuru kaldırıldı.

System.Web.Mobile.dll derlemesi ASP.NET 4'e dahil edilir, ancak kullanım dışıdır. System.Web.Mobile.dll derlemesinden türleri kullanmak istiyorsanız, bu derlemeye kök Web.config dosyaya veya uygulama Web.config dosyasına bir başvuru ekleyin. Örneğin, (kullanım dışı) ASP.NET mobil denetimlerinden herhangi birini kullanmak istiyorsanız, Web.config dosyasına System.Web.Mobile.dll derlemesine bir başvuru eklemeniz gerekir.

ASP.NET İsteği Doğrulama

ASP.NET'daki istek doğrulama özelliği, siteler arası betik (XSS) saldırılarına karşı belirli bir varsayılan koruma düzeyi sağlar. ASP.NET önceki sürümlerinde istek doğrulama varsayılan olarak etkinleştirilmiştir. Ancak, yalnızca ASP.NET sayfalara (.aspx dosyalar ve sınıf dosyaları) ve yalnızca bu sayfalar yürütülürken uygulanır.

ASP.NET 4'te, http isteğinin BeginRequest aşamasından önce etkinleştirildiğinden, varsayılan olarak tüm istekler için istek doğrulaması etkinleştirilir. Sonuç olarak, istek doğrulaması yalnızca .aspx sayfa istekleri için değil, tüm ASP.NET kaynakları için istekler için geçerlidir. Bu, Web hizmeti çağrıları ve özel HTTP işleyicileri gibi istekleri içerir. Özel HTTP modülleri bir HTTP isteğinin içeriğini okurken istek doğrulama da etkindir.

Sonuç olarak, daha önce hata tetiklemeyen istekler için istek doğrulama hataları oluşabilir. ASP.NET 2.0 istek doğrulama özelliğinin davranışına geri dönmek için dosyaya Web.config aşağıdaki ayarı ekleyin:

<httpRuntime requestValidationMode="2.0" />

Ancak, mevcut işleyicilerin, modüllerin veya diğer özel kodların XSS saldırı vektörleri olabilecek güvenli olmayan HTTP girişlerine erişip erişmeyeceğini belirlemek için istek doğrulama hatalarını analiz etmenizi öneririz.

Varsayılan Karma Algoritması şimdi HMACSHA256 olarak belirlendi.

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 HMACSHA256 algoritmasını kullanır. ASP.NET'ın önceki sürümleri eski HMACSHA1 algoritmasını kullanıyordu.

.NET Framework sürümleri arasında uyum göstermesi gereken form kimlik doğrulama çerezleri gibi verilerin bulunduğu karma ASP.NET 2.0/ASP.NET 4 ortamlarını çalıştırırsanız, uygulamalarınız etkilenebilir. ASP.NET 4 Web uygulamasını eski HMACSHA1 algoritmasını kullanacak şekilde yapılandırmak için dosyaya Web.config aşağıdaki ayarı ekleyin:

<machineKey validation="SHA1" />

Yeni ASP.NET 4 Kök Yapılandırmasıyla İlgili Yapılandırma Hataları

.NET Framework 4 (ve dolayısıyla ASP.NET 4) için kök yapılandırma dosyaları (machine.config dosyası ve kök Web.config dosyası), ASP.NET 3.5'te uygulama Web.config dosyalarında bulunan çoğu ortak yapılandırma bilgisini içerecek şekilde güncellendi. Yönetilen IIS 7 ve IIS 7.5 yapılandırma sistemlerinin karmaşıklığı nedeniyle, ASP.NET 4 ve IIS 7 ve IIS 7.5 altında ASP.NET 3.5 uygulamalarını çalıştırmak ASP.NET veya IIS yapılandırma hatalarıyla sonuçlanabilir.

Pratikse Visual Studio 2010'daki proje yükseltme araçlarını kullanarak ASP.NET 3.5 uygulamalarını ASP.NET 4'e yükseltmenizi öneririz. 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, .NET Framework 4 kullanarak yeniden derleme olmadan ASP.NET 3.5 uygulamalarını çalıştırmak desteklenen bir senaryodur. Bu durumda, uygulamayı Web.config .NET Framework 4 ve IIS 7 veya IIS 7.5 altında çalıştırmadan önce uygulamanın dosyasını el ile değiştirmeniz gerekebilir.

Sonraki iki bölümde, farklı yazılım bileşimleri için yapmanız gerekebilecek değişiklikler açıklanmaktadır.

Ne düzeltme KB958854 ne de SP2'nin yüklü olmadığı Windows Vista SP1 veya Windows Server 2008 SP1. Bu yapılandırmada IIS 7 yapılandırma sistemi, uygulama düzeyi Web.config dosyasını ASP.NET 2.0 machine.config dosyalarıyla karşılaştırarak uygulamanın yönetilen yapılandırmasını yanlış bir şekilde birleştirir. Bu nedenle, IIS 7 doğrulama hatasına neden olmaması için .NET Framework 3.5 veya sonraki sürümlerdeki uygulama düzeyi Web.config dosyaların system.web.extensions yapılandırma bölüm tanımına (öğesi) sahip olması gerekir.

Ancak, Visual Studio 2008 ile sunulan özgün ortak yapılandırma bölümü tanımlarıyla tam olarak eşleşmeyen el ile değiştirilen uygulama düzeyi Web.config dosya girişleri ASP.NET yapılandırma hatalarına neden olur. (Visual Studio 2008 tarafından oluşturulan varsayılan yapılandırma girdileri düzgün çalışır.) Sık karşılaşılan bir sorun, el ile değiştirilen Web.config dosyaların çeşitli yapılandırma bölümü tanımlarında bulunan allowDefinition ve requirePermission yapılandırma özniteliklerini dışarıda bırakmasıdır. Bu, uygulama düzeyi Web.config dosyalarındaki kısaltılmış yapılandırma bölümü ile ASP.NET 4 machine.config dosyasındaki tam tanım arasında uyuşmazlık olmasına neden olur. Sonuç olarak, çalışma zamanında ASP.NET 4 yapılandırma sistemi bir yapılandırma hatası oluşturur.

Windows Vista SP2, Windows Server 2008 SP2, Windows 7, Windows Server 2008 R2 ve ayrıca düzeltme KB958854 yüklü olduğu Windows Vista SP1 ve Windows Server 2008 SP1.

Bu senaryoda, IIS 7 ve IIS 7.5 yerel yapılandırma sistemi, yönetilen yapılandırma bölümü işleyicisi için tanımlanan tür özniteliğinde metin karşılaştırması gerçekleştirdiğinden bir yapılandırma hatası döndürür. Visual Studio 2008 ve Visual Studio 2008 SP1 tarafından oluşturulan tüm Web.config dosyaların system.web.extensions (ve ilgili) yapılandırma bölümü işleyicileri için tür dizesinde "3.5" olduğundan, ve ASP.NET 4 machine.config dosyasının aynı yapılandırma bölümü işleyicileri için tür özniteliğinde "4.0" olduğundan, Visual Studio 2008 veya Visual Studio 2008 SP1'de oluşturulan uygulamalar IIS 7 ve IIS 7.5'te yapılandırma doğrulamasında her zaman başarısız olur.

Bu Sorunları Çözme

İlk senaryo için geçici çözüm, Visual Studio 2008 tarafından otomatik olarak oluşturulan bir Web.config dosyadan ortak yapılandırma metnini ekleyerek uygulama düzeyinde Web.config dosyayı güncelleştirmektir.

İlk senaryo için alternatif bir geçici çözüm, IIS yapılandırma sisteminin yanlış yapılandırma birleştirme davranışını düzeltmek üzere Bilgisayarınıza Vista veya Windows Server 2008 için Service Pack 2'yi yüklemektir. Ancak, bu eylemlerden birini gerçekleştirdikten sonra uygulamanız büyük olasılıkla ikinci senaryo için açıklanan sorun nedeniyle bir yapılandırma hatasıyla karşılaşır.

İkinci senaryo için geçici çözüm, tüm system.web.extensions yapılandırma bölümü tanımlarını ve yapılandırma bölümü grup tanımlarını uygulama düzeyi Web.config dosyasından silmek veya açıklama satırı yapmaktır. Bu tanımlar genellikle uygulama düzeyi Web.config dosyasının en üstünde yer alır ve configSections öğesi ve alt öğeleri tarafından tanımlanabilir.

Her iki senaryoda da system.codedom bölümünü el ile silmeniz önerilir, ancak bu gerekli değildir.

ASP.NET 4 Alt Uygulamaları, ASP.NET 2.0 veya ASP.NET 3.5 uygulamaları altında başlatılamıyorlar.

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. Aşağıdaki örnekte, etkilenen bir uygulamanın dizin yapısı gösterilmektedir.

/parentwebapp (ASP.NET 2.0 veya ASP.NET 3.5 kullanacak şekilde yapılandırılmış)
/childwebapp (ASP.NET 4 kullanacak şekilde yapılandırılmış)

Klasördeki childwebapp uygulama IIS 7 veya IIS 7.5'te başlatılamaz ve bir yapılandırma hatası bildirir. Hata metni aşağıdakine benzer bir ileti içerir:

• The requested page cannot be accessed because the related configuration data for the page is invalid.

• The configuration section 'configSections' cannot be read because it is missing a section declaration.

IIS 6'da, klasördeki childwebapp uygulama da başlatılamaz, ancak farklı bir hata bildirecektir. Örneğin, hata metni aşağıdakileri gösterebilir:

• The value for the 'compilerVersion' attribute in the provider options must be 'v4.0' or later if you are compiling for version 4.0 or later of the .NET Framework. To compile this Web application for version 3.5 or earlier of the .NET Framework, remove the 'targetFramework' attribute from the element of the Web.config file

Bu senaryolar, klasördeki üst uygulamadan gelen yapılandırma bilgilerinin, klasördeki parentwebapp alt web uygulaması tarafından kullanılan son birleştirilmiş yapılandırma ayarlarını belirleyen yapılandırma bilgileri hiyerarşisinin childwebapp bir parçası olması nedeniyle oluşur. ASP.NET 4 Web uygulamasının IIS 7 (veya IIS 7.5) veya IIS 6 üzerinde çalışıp çalışmadığına bağlı olarak, IIS yapılandırma sistemi veya ASP.NET 4 derleme sistemi bir hata döndürür.

Bu sorunu çözmek ve alt ASP.NET 4 uygulamasının çalışmasını sağlamak için izlemeniz gereken adımlar, ASP.NET 4 uygulamasının IIS 6'da mı yoksa IIS 7'de mi (veya IIS 7.5'te) çalıştığına bağlıdır.

1. Adım (yalnızca IIS 7 veya IIS 7.5)

Bu adım yalnızca Windows Vista, Windows Server 2008, Windows 7 ve Windows Server 2008 R2 içeren IIS 7 veya IIS 7.5 çalıştıran işletim sistemlerinde gereklidir.

Üst uygulamanın (ASP.NET 2.0 veya ASP.NET 3.5 çalıştıran uygulama) dosyasındaki Web.config tanımını the.NET Framework 2.0 için kök Web.config dosyasına taşıyın. IIS 7 ve IIS 7.5 yerel yapılandırma sistemi, yapılandırma dosyalarının hiyerarşisini birleştirdiğinde configSections öğesini tarar. configSections tanımını üst Web uygulamasının Web.config dosyasından kök Web.config dosyaya taşımak, öğeyi alt ASP.NET 4 uygulaması için gerçekleşen yapılandırma birleştirme işleminden etkili bir şekilde gizler.

32 bit işletim sisteminde veya 32 bit uygulama havuzlarında, ASP.NET 2.0 ve ASP.NET 3.5 kök Web.config dosyası normalde aşağıdaki klasörde bulunur:

C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG

64 bit işletim sisteminde veya 64 bit uygulama havuzları için ASP.NET 2.0 ve ASP.NET 3.5 kök Web.config dosyası normalde aşağıdaki klasörde bulunur:

C:\Windows\Microsoft.NET\Framework64\v2.0.50727\CONFIG

64 bit bilgisayarda hem 32 bit hem de 64 bit Web uygulamaları çalıştırıyorsanız, configSections öğesini hem 32 bit hem de 64 bit sistemler için kök Web.config dosyalara taşımanız gerekir.

configSections öğesini kök Web.config dosyaya yerleştirdiğinizde, bölümü yapılandırma öğesinin hemen arkasına yapıştırın. Aşağıdaki örnek, öğeleri taşımayı bitirdiğinizde kök Web.config dosyanın üst kısmının nasıl görünmesi gerektiğini gösterir.

Uyarı

Aşağıdaki örnekte satırlar okunabilirlik için sarmalanmıştır.

<?xml version="1.0" encoding="utf-8"?>
<!-- The root web configuration file -->
<configuration>
  <configSections>
    <sectionGroup name="system.web.extensions"
        type="System.Web.Configuration.SystemWebExtensionsSectionGroup, 
      System.Web.Extensions, Version=3.5.0.0, Culture=neutral,  
      PublicKeyToken=31BF3856AD364E35">

      <sectionGroup name="scripting"
        type="System.Web.Configuration.ScriptingSectionGroup, 
        System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
        PublicKeyToken=31BF3856AD364E35">

        <section name="scriptResourceHandler"
          type="System.Web.Configuration.ScriptingScriptResourceHandlerSection, 
          System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
          PublicKeyToken=31BF3856AD364E35" requirePermission="false"
          allowDefinition="MachineToApplication" />

        <sectionGroup name="webServices"
          type="System.Web.Configuration.ScriptingWebServicesSectionGroup,
          System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
          PublicKeyToken=31BF3856AD364E35">

          <section name="jsonSerialization"
            type="System.Web.Configuration.ScriptingJsonSerializationSection, 
            System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
            PublicKeyToken=31BF3856AD364E35" requirePermission="false"
            allowDefinition="Everywhere" />

          <section name="profileService"
            type="System.Web.Configuration.ScriptingProfileServiceSection, 
            System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
            PublicKeyToken=31BF3856AD364E35" requirePermission="false"
            allowDefinition="MachineToApplication" />
          <section name="authenticationService"
            type="System.Web.Configuration.ScriptingAuthenticationServiceSection, 
          System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
          PublicKeyToken=31BF3856AD364E35" requirePermission="false"
            allowDefinition="MachineToApplication" />

          <section name="roleService"
            type="System.Web.Configuration.ScriptingRoleServiceSection, 
          System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
          PublicKeyToken=31BF3856AD364E35" requirePermission="false"
            allowDefinition="MachineToApplication" />

        </sectionGroup>
      </sectionGroup>
    </sectionGroup>
  </configSections>

2. Adım (IIS'nin tüm sürümleri)

bu adım, ASP.NET 4 alt Web uygulamasının IIS 6'da mı yoksa IIS 7'de mi (veya IIS 7.5'te) çalıştığında gereklidir.

Web.config ASP.NET 2 veya ASP.NET 3.5 çalıştıran üst Web uygulamasının dosyasına, yapılandırma girişlerinin yalnızca üst Web uygulaması için geçerli olduğunu açıkça belirten bir konum etiketi ekleyin (hem IIS hem de ASP.NET yapılandırma sistemleri için). Aşağıdaki örnek, eklenecek konum öğesinin söz dizimini gösterir:

<location path="" inheritInChildApplications="false" >
  <!-- Additional settings -->
</location>

Aşağıdaki örnekte, appSettings bölümünden başlayıp system.webServer bölümüyle biten tüm yapılandırma bölümlerini sarmak için konum etiketinin nasıl kullanıldığı gösterilmektedir.

<location path="" inheritInChildApplications="false" >
  <appSettings />
  <connectionStrings />
  <system.web>
    <!-- Removed for brevity -->
  </system.web>
  <system.codedom>
    <!-- Removed for brevity -->
  </system.codedom>
  <system.webServer>
    <!-- Removed for brevity -->
</system.webServer>
</location>

1. ve 2. adımları tamamladığınızda alt ASP.NET 4 Web uygulamaları hatasız başlar.

ASP.NET 4 Web Sitesi SharePoint'in Yüklü Olduğu Bilgisayarlarda Başlatılamıyor

SharePoint çalıştıran web sunucuları, SharePoint Web sitesinin kök dizininde (örneğin, Varsayılan Web Sitesi gibi) dağıtılan bir Web.config dosyasına sahiptir. Bu Web.config dosyada SharePoint, WSS_Minimal adlı özel bir kısmi güven düzeyi ayarlar.

Bu tür bir SharePoint Web sitesinin alt öğesi olarak dağıtılan bir ASP.NET 4 Web sitesi çalıştırmayı denerseniz aşağıdaki hatayı görürsünüz:

Could not find permission set named 'ASP.NET'.

bu hatanın nedeni, ASP.NET 4 kod erişim güvenliği (CAS) altyapısının ASP.NET adlı bir izin kümesi aramasıdır. Ancak, WSS_Minimal tarafından başvurulan kısmi güven yapılandırma dosyası bu ada sahip herhangi bir izin kümesi içermez.

Şu anda ASP.NET ile uyumlu bir SharePoint sürümü yoktur. Sonuç olarak, ASP.NET 4 Web sitesini SharePoint Web siteleri altında alt site olarak çalıştırmayı denememelisiniz.

HttpRequest.FilePath Özelliği artık PathInfo Değerlerini içermiyor

önceki ASP.NET sürümleri, HttpRequest.FilePath, HttpRequest.AppRelativeCurrentExecutionFilePath ve HttpRequest.CurrentExecutionFilePath gibi dosya yolu ile ilgili çeşitli özelliklerden döndürülen değere bir PathInfo değeri eklemıştı. ASP.NET 4 artık bu özelliklerden dönüş değerlerine PathInfo değerini içermiyor. Bunun yerine PathInfo bilgisi HttpRequest.PathInfo içinde mevcuttur. Örneğin, aşağıdaki URL parçasını düşünün:

/testapp/Action.mvc/SomeAction

ASP.NET'nin önceki sürümlerinde HttpRequest özellikleri aşağıdaki değerlere sahiptir:

HttpRequest.FilePath: /testapp/Action.mvc/SomeAction

HttpRequest.PathInfo: (boş)

ASP.NET 4'te HttpRequest özellikleri bunun yerine aşağıdaki değerlere sahiptir:

HttpRequest.FilePath: /testapp/Action.mvc

HttpRequest.PathInfo: SomeAction

ASP.NET 2.0 Uygulamaları, eurl.axd'ye Başvuran HttpException Hataları Oluşturabilir

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.

Bu hatanın nedeni, ASP.NET bir Web sitesinin ASP.NET 4 kullanacak şekilde yapılandırıldığını algıladığında, ASP.NET 4'ün yerel bileşeni daha fazla işlem için ASP.NET yönetilen bölümüne uzantısız bir URL geçirmesi nedeniyle oluşur. Ancak, ASP.NET 4 Web sitesinin altındaki sanal dizinler ASP.NET 2.0 kullanacak şekilde yapılandırılmışsa, uzantısız URL'nin bu şekilde işlenmesi "eurl.axd" dizesini içeren değiştirilmiş bir URL ile sonuçlanır. Bu değiştirilen URL daha sonra ASP.NET 2.0 uygulamasına gönderilir. ASP.NET 2.0, "eurl.axd" biçimini tanıyamaz. Bu nedenle, ASP.NET 2.0 adlı eurl.axd bir dosyayı bulmaya ve yürütmeye çalışır. Böyle bir dosya olmadığından, istek httpexception özel durumuyla başarısız olur.

Aşağıdaki seçeneklerden birini kullanarak bu sorunu çözebilirsiniz.

Seçenek 1

Web sitesini çalıştırmak için ASP.NET 4 gerekli değilse, siteyi ASP.NET 2.0 kullanacak şekilde yeniden eşle.

Seçenek 2

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.

Seçenek 3

Web sitesini ASP.NET 2.0'a yeniden eşlemek veya bir sanal dizinin konumunu değiştirmek pratik değilse, ASP.NET 4'te uzantısız URL işlemeyi açıkça devre dışı bırakın. Aşağıdaki yordamı kullanın:

1. Windows kayıt defterinde aşağıdaki düğümü açın:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.30319.0

1. EnableExtensionlessUrls adlı yeni bir DWORD değeri oluşturun.
2. EnableExtensionlessUrls değerini 0 olarak ayarlayın. Bu, uzantısız URL davranışını devre dışı bırakır.
3. Kayıt defteri değerini kaydedin ve kayıt defteri düzenleyicisini kapatın.
4. IIS'nin yeni kayıt defteri değerini okumasına neden olan iisreset komut satırı aracını çalıştırın.

Uyarı

EnableExtensionlessUrls ayarının 1 olarak ayarlanması, uzantısız URL davranışını etkinleştirir. Değer belirtilmezse bu varsayılan ayardır.

IIS 7 veya IIS 7.5 Entegre Modu'nda Varsayılan Belgede Olay İşleyicileri Tetiklenmeyebilir

ASP.NET 4, uzantısız bir URL varsayılan belgeye çözümlendiğinde HTML form öğesinin eylem özniteliğinin işlenme biçimini değiştiren değişiklikler içerir. Varsayılan bir belgeye dönen uzantısız bir URL örneği, http://contoso.com/ sonucunda http://contoso.com/Default.aspx için bir istek olurdu.

ASP.NET 4 artık html form öğesinin eylem öznitelik değerini, varsayılan bir belgenin eşlendiği uzantısız bir URL'ye istek gönderildiğinde boş bir dize olarak işleniyor. Örneğin, ASP.NET'in önceki sürümlerinde, http://contoso.com isteği Default.aspx ile sonuçlanırdı. Bu belgede, açılış formu etiketi aşağıdaki örnekte olduğu gibi işlenir:

<form action="Default.aspx" />

ASP.NET 4'te, http://contoso.com isteği aynı zamanda Default.aspx isteğine de yol açar. Ancak ASP.NET şimdi HTML açma formu etiketini aşağıdaki örnekte olduğu gibi işler:

<form action="" />

Eylem özniteliğinin nasıl işlendiğindeki bu fark, form gönderisinin IIS ve ASP.NET tarafından işlenme biçiminde küçük değişikliklere neden olabilir. Eylem özniteliği boş bir dize olduğunda, IIS DefaultDocumentModule nesnesi için Default.aspxbir alt istek oluşturur. Çoğu koşulda, bu alt istek uygulama kodu için saydamdır ve Default.aspx sayfa 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, belgeye Default.aspx yönelik alt istek bir hataya veya beklenmeyen davranışa neden olur:

1. Form öğesinin eylem özniteliği "" olarak ayarlanmış bir .aspx sayfası tarayıcıya gönderilir.
2. Form ASP.NET'e geri gönderilir.
3. Yönetilen HTTP modülü varlık gövdesinin bir bölümünü okur. Örneğin, bir modül Request.Form veya Request.Params 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.
4. IIS DefaultDocumentModule nesnesi sonunda çalışır ve belgeye bir alt istek Default.aspx 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.
5. 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.
6. Varlık gövdesi olmadığından, form değişkenleri ve görünüm durumu yoktur ve bu nedenle .aspx sayfa işleyicisi hangi olayın (varsa) tetikleneceğ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 davranışa aşağıdaki yollarla geçici bir çözüm bulabilirsiniz:

• Varsayılan belge istekleri sırasında isteğin varlık gövdesine erişen HTTP modülünü belirleyin ve yalnızca yönetilen istekler için çalışacak şekilde yapılandırılıp yapılandırılamayacağını belirleyin. Hem IIS 7 hem de IIS 7.5 için tümleşik modda HTTP modülleri, modülün system.webServer/modules girişine aşağıdaki öznitelik eklenerek yalnızca yönetilen istekler için çalışacak şekilde işaretlenebilir:

• precondition="managedHandler"

• Bu ayar, IIS 7 ve IIS 7.5'in yönetilen istek olmadığını belirlediği istekler için modülü devre dışı bırakır. Varsayılan belge istekleri için ilk istek, uzantısız bir URL'ye yöneliktir. Bu nedenle IIS, ilk istek işleme sırasında yönetilen İşleyicinin önkoşuluyla işaretlenmiş yönetilen modülleri çalıştırmaz. Sonuç olarak, yönetilen modüller varlık gövdesini yanlışlıkla okumaz. Böylece varlık gövdesi hâlâ erişilebilir durumdadır ve alt isteğe ile varsayılan belgeye aktarılır.

• Sorunlu HTTP modüllerinin tüm istekler için (statik dosyalar, DefaultDocumentModule nesnesine çözümlenen uzantısız URL'ler, yönetilen istekler vb.) çalıştırılması gerekiyorsa, sayfanın System.Web.UI.HtmlControls.HtmlForm denetiminin Action özelliğini açıkça boş olmayan bir dizeye ayarlayarak etkilenen .aspx sayfalarını değiştirin. Örneğin, varsayılan belge ise Default.aspx, sayfanın kodunu htmlform denetiminin Action özelliğini açıkça "Default.aspx" olarak ayaracak şekilde değiştirin.

ASP.NET Kod Erişim Güvenliği (CAS) Uygulamasında yapılan değişiklikler

2.0 ASP.NET ve uzantı olarak 3.5'te eklenen ASP.NET özelliklerini kullanarak .NET Framework 1.1 ve 2.0 kod erişim güvenliği (CAS) modelini kullanın. Ancak, ASP.NET 4'te CAS'nin uygulanması önemli ölçüde elden geçirilmiştir. Sonuç olarak, genel derleme önbelleğinde (GAC) çalışan güvenilir kodu kullanan kısmi güvene sahip ASP.NET uygulamaları çeşitli güvenlik özel durumlarıyla başarısız olabilir. Makine CAS ilkesinde kapsamlı değişikliklere dayanan kısmi güven uygulamaları da güvenlik özel durumlarıyla başarısız olabilir.

Aşağıdaki örnekte gösterildiği gibi, güven 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 davranışlarına döndürebilirsiniz:

<trust level= "Medium" legacyCasModel="true" />

Eski CAS modeline geri döndüğünüzde, aşağıdaki eski CAS davranışları etkinleştirilir:

• Makine CAS ilkesi kabul edilir.
• Tek bir uygulama etki alanında birden çok farklı izin kümesine izin verilir.
• Yığında yalnızca ASP.NET veya başka bir .NET Framework kodu olduğunda çağrılan GAC derlemeleri için açık izin onayları gerekli değildir.

.NET Framework 4'te bir senaryo geri alınamaz: Web dışı kısmi güven uygulamaları artık System.Web.dll ve System.Web.Extensions.dll'da belirli API'leri çağıramaz. .NET Framework'ün önceki sürümlerinde, Web dışı kısmi güven uygulamalarına açıkça AspNetHostingPermission izinleri verilmesi mümkündü. Bu uygulamalar daha sonra System.Web.HttpUtility, System.Web.ClientServices.* ad alanları içindeki türler ve üyelik, roller ve profillerle ilgili türler kullanabilir. Web dışı kısmi güven uygulamalarından bu türlerin çağrılması artık .NET Framework 4'te desteklenmiyor.

Uyarı

System.Web.HttpUtility sınıfının HtmlEncode ve HtmlDecode işlevleri yeni .NET Framework 4 System.Net.WebUtility sınıfına taşındı. Kullanılan tek ASP.NET işlev buysa, uygulamanın kodunu yeni WebUtility sınıfını kullanacak şekilde değiştirin.

Aşağıda, ASP.NET 4'teki varsayılan CAS uygulamasında yapılan değişikliklerin üst düzey bir özeti yer almakta:

• ASP.NET uygulama etki alanları artık homojen uygulama etki alanlarıdır. Uygulama etki alanında yalnızca kısmi güven ve tam güven verme kümeleri kullanılabilir.
• ASP.NET kısmi güven verme kümeleri, herhangi bir kurumsal düzey, makine düzeyi veya kullanıcı düzeyi CAS ilkesinden bağımsızdır.
• 3.5 ve 3.5 SP1'de gönderilen ASP.NET derlemeleri .NET Framework 4 saydamlık modelini kullanacak şekilde dönüştürüldü.
• ASP.NET AspNetHostingPermission özniteliğinin kullanımı önemli ölçüde azaltıldı. Bu özniteliğin çoğu örneği genel ASP.NET API'lerinden kaldırılmıştır.
• ASP.NET derleme sağlayıcıları tarafından oluşturulan dinamik olarak derlenmiş derlemeler, derlemeleri açıkça saydam olarak işaretlenecek şekilde güncelleştirildi.
• Tüm ASP.NET derlemeleri artık APTCA özniteliği yalnızca Web barındırma ortamlarında kabul edilir şekilde işaretlenir. ClickOnce gibi kısmen güvenilen Web dışı barındırma ortamları, ASP.NET derlemelerine çağrı yapamaz.

Yeni ASP.NET 4 kod erişimi güvenlik modeli hakkında daha fazla bilgi için bkz. MSDN Web sitesindeki ASP.NET Uygulamalarında Kod Erişim Güvenliğini Kullanma .

System.Web.Security Ad Alanı'ndaki MembershipUser ve Diğer Türler Taşındı

ASP.NET üyeliğinde kullanılan bazı türler System.Web.dll konumundan yeni 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ı.

Web sitesi projeleri, ASP.NET derleme sistemi tarafından varsayılan olarak kullanılan başvurulan derlemeler listesine System.Web.ApplicationServices.dll eklendiği için bu türlerin taşınması sonucu sorun yaşamaz. visual studio 2010'da açarak ASP.NET 4'e ASP.NET önceki bir sürümü kullanılarak oluşturulmuş bir Web sitesi projesini yükseltirseniz, proje hatasız derlenir.

Benzer şekilde, ASP.NET'in önceki bir sürümünde oluşturulmuş bir Web uygulaması projesini Visual Studio 2010'da açarak ASP.NET 4'e yükseltirseniz, yükseltme işlemi projeye System.Web.ApplicationServices.dll başvuru ekler. Bu nedenle, yükseltilen Web uygulaması projeleri de hatasız derlenir.

ASP.NET'nin önceki sürümleri kullanılarak oluşturulan derlenmiş (ikili) dosyalar, üyelik türleri farklı bir derlemeye taşınmış olsa bile ASP.NET 4'te hatasız olarak da çalışır. Tür iletme bilgileri, bu türlerin çalışma zamanı başvurularını otomatik olarak türlerin System.Web.dll yeni konumuna yönlendiren ASP.NET 4 sürümüne eklendi.

Ancak, belirli üyelik türlerini kullanan ve önceki ASP.NET sürümlerinden yükseltilen sınıf kitaplıkları, ASP.NET 4 projesinde kullanıldığında derlenemiyor. Örneğin, bir sınıf kitaplığı projesi aşağıdaki gibi bir hatayı derleyip bildiremeyebilir:

• The type 'System.Web.Security.MembershipUser' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Web.ApplicationServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.

• The type name 'MembershipUser' could not be found. This type has been forwarded to assembly 'System.Web.ApplicationServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. Consider adding a reference to that assembly.

System.Web.ApplicationServices.dll sınıf kitaplığı projenize bir referans ekleyerek bu soruna geçici bir çözüm bulabilirsiniz.

Aşağıdaki listede System.Web.Security türlerinin öğesinden System.Web.ApplicationServices.dll'e taşındığı gösterilmektedir:

• System.Web.Security.MembershipCreateStatus
• System.Web.Security.Membership.CreateUserException
• System.Web.Security.MembershipPasswordException
• System.Web.Security.MembershipPasswordFormat
• System.Web.Security.MembershipProvider
• System.Web.Security.MembershipProviderCollection
• System.Web.Security.MembershipUser
• System.Web.Security.MembershipUserCollection
• System.Web.Security.MembershipValidatePasswordEventHandler
• System.Web.Security.ValidatePasswordEventArgs
• System.Web.Security.RoleProvider
• System.Web.Configuration.MembershipPasswordCompatibilityMode

Çıktı Önbelleğe Alma Değişiklikleri Vary * HTTP Üstbilgisi

ASP.NET 1.0'da bir hata, Location="ServerAndClient" çıkış-önbellek ayarı olarak belirtilen önbelleğe alınmış sayfaların yanıtta bir Vary:* HTTP üst bilgisi oluşturmasına 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, System.Web.HttpCachePolicy.SetOmitVaryStar yöntemi eklendi, bu yöntemi Vary:* üst bilgisini bastırmak için çağırabilirsiniz. Bu yöntem seçildi, çünkü gönderilen HTTP üst bilgisinin değiştirilmesi o sırada hataya neden olabilecek bir değişiklik olarak kabul edildi. Ancak, geliştiricilerin ASP.NET davranışlarından kafası karışmıştır ve hata raporları geliştiricilerin mevcut SetOmitVaryStar davranışının farkında olmadığını göstermektedir.

ASP.NET 4'te kök sorunu düzeltme kararı alınmıştı. Vary:* HTTP başlığı, artık aşağıdaki yönergeyi belirten yanıtlardan gönderilmez.

<%@OutputCache Location="ServerAndClient" %>

Sonuç olarak, SetOmitVaryStar üst bilgiyi gizlemek için artık gerekli değildir.

Bir sayfadaki Location="ServerAndClient" yönergesinde belirtilen uygulamalarda, artık Location özniteliğinin değerinin adının ima ettiği davranışı görürsünüz; yani sayfalar, SetOmitVaryStar yöntemini çağırmanıza gerek kalmadan tarayıcıda önbelleğe alınabilecektir.

Uygulamanızdaki sayfaların yayması Vary:*gerekiyorsa, aşağıdaki örnekte olduğu gibi AppendHeader yöntemini çağırın:

HttpResponse.AppendHeader("Vary","*");

Alternatif olarak, çıkış önbelleğe alma Konumu özniteliğinin değerini "Sunucu" olarak değiştirebilirsiniz.

Passport için System.Web.Security Türleri Kullanımdan Kaldırıldı

ASP.NET 2.0'da yerleşik olan Passport desteği, Passport'taki değişiklikler (şimdi LiveID) nedeniyle birkaç yıldır kullanımdan kaldırılmıştır ve desteklenmemektedir. Sonuç olarak, System.Web.Security'de Passport ile ilgili beş tür artık ObsoleteAttribute özniteliğiyle işaretlenir.

MenuItem.PopOutImageUrl Özelliği, ASP.NET 4'te bir görüntüyü işleyemiyor

ASP.NET 3.5'te MenuItem.PopOutImageUrl özelliği, menü öğesinin dinamik bir alt menüsü olduğunu belirtmek için menü öğesinde görüntülenen görüntünün URL'sini belirtmenize olanak tanır. Aşağıdaki örnekte, ASP.NET 3.5'teki işaretlemede bu özelliğin nasıl belirtileceğini gösterilmektedir.

<asp:menu id="NavigationMenu"
    staticdisplaylevels="1"
    staticsubmenuindent="10" 
    orientation="Vertical" 
    target="_blank"  
    runat="server">
  <items>
    <asp:menuitem navigateurl="default2.aspx" 
        text="Home" 
        PopOutImageUrl="~/Images/Popout.gif"   
        tooltip="Home">
      <asp:menuitem navigateurl="default3.aspx"
          text="Movies"
          PopOutImageUrl="~/Images/Popout.gif"
          tooltip="Movies"> 
      </asp:menuitem>
    </asp:menuitem>
  </items>
</asp:menu>

ASP.NET 4'teki bir tasarım değişikliğinin sonucu olarak, özelliği MenuItem sınıfı için ayarlandıysa PopOutImageUrl için hiçbir çıkış işlenmez. Bunun yerine, StaticPopOutImageUrl özelliğini veya DynamicPopOutImageUrl özelliğini kullanarak doğrudan Menü denetiminde bir görüntü URL'si belirtmeniz gerekir. Statik bir menüyle çalışırken Menu.StaticPopOutImageUrl özelliği, aşağıdaki örnekte gösterildiği gibi statik menü öğesinin bir alt menüsü olduğunu belirtmek için görüntülenen görüntünün URL'sini belirtir:

<asp:menu id="NavigationMenu"
    staticdisplaylevels="1"
    staticsubmenuindent="10" 
    orientation="Vertical" 
    target="_blank" 
    StaticPopOutImageTextFormatString="More..."
    StaticPopOutImageUrl="Images/Popout.gif"   
    runat="server">
  <items>
    <asp:menuitem navigateurl="default2.aspx" 
        text="Home" 
        tooltip="Home">
      <asp:menuitem navigateurl="default3.aspx"
          text="Movies"
          tooltip="Movies"> 
      </asp:menuitem>
    </asp:menuitem>
  </items>
</asp:menu>

Dinamik bir menüyle çalışıyorsanız, bir dinamik menü öğesinin alt menüsü olduğunu belirten bir görüntünün URL'sini belirtmek için Menu.DynamicPopOutImageUrl özelliğini kullanırsınız. Aşağıdaki örnek öncekine benzer, ancak dinamik menü için DynamicPopOutImageUrl özelliğinin nasıl ayarlanacağı gösterilmektedir.

<asp:menu id="NavigationMenu"
    staticdisplaylevels="1"
    staticsubmenuindent="10" 
    orientation="Vertical" 
    target="_blank" 
    DynamicPopOutImageTextFormatString="More..."
    DynamicPopOutImageUrl="Images/Popout.gif" 
    runat="server">
  <items>
    <asp:menuitem navigateurl="default2.aspx" 
        text="Home" 
        tooltip="Home">
      <asp:menuitem navigateurl="default3.aspx"
          text="Movies"
          tooltip="Movies"> 
      </asp:menuitem>
    </asp:menuitem>
  </items>
</asp:menu>

Menu.DynamicPopOutImageUrl özelliği ayarlanmamışsa ve Menu.DynamicEnableDefaultPopOutImage özelliği false olarak ayarlandıysa görüntü görüntülenmez. Benzer şekilde StaticPopOutImageUrl özelliği ayarlanmamışsa ve StaticEnableDefaultPopOutImage özelliği false olarak ayarlanmışsa görüntü görüntülenmez.

Bu özelliklerin yollarını ayarladığınızda, ters eğik çizgi (\) yerine eğik çizgi (/) kullanın. Daha fazla bilgi için, bu belgenin başka bir yerinde bulunan Menu.StaticPopOutImageUrl ve Menu.DynamicPopOutImageUrl, yollar ters eğik çizgi içerdiğinde görüntüleri işleyemiyor bölümüne bakın.

Menu.StaticPopOutImageUrl ve Menu.DynamicPopOutImageUrl, Yollar Ters Eğik Çizgi İçerdiğinde Görüntü İşlemede Başarısız Oldu

ASP.NET 4'te, Menu.StaticPopOutImageUrl ve Menu.DynamicPopOutImageUrl özelliklerini kullanarak belirttiğiniz görüntüler, yol ters eğik çizgi () içeriyorsa işlenmez. Bu, ASP.NET önceki sürümlerinden bir değişikliktir.

Aşağıdaki Menü denetimi işaretleme örneği, ters eğik çizgi içeren bir yol kullanarak StaticPopOutImageUrl özellik kümesini gösterir. ASP.NET 4'te özelliğinde belirtilen görüntü işlenmez.

<asp:menu id="NavigationMenu"
    staticdisplaylevels="1"
    staticsubmenuindent="10" 
    orientation="Vertical 
    target="_blank" 
    StaticPopOutImageTextFormatString="More..."
    StaticPopOutImageUrl="Images\Popout.gif"   
    runat="server">
  <items>
    <asp:menuitem navigateurl="default2.aspx" 
        text="Home" 
        tooltip="Home">
      <asp:menuitem navigateurl="default3.aspx"
          text="Movies"
          tooltip="Movies"> 
      </asp:menuitem>
    </asp:menuitem>
  </items>
</asp:menu>

Bu sorunu düzeltmek için StaticPopOutImageUrl ve DynamicPopOutImageUrl özelliklerinde belirtilen yol değerlerini eğik çizgi (/) kullanacak şekilde değiştirin. Aşağıdaki örnekte bu değişiklik gösterilmektedir:

<asp:menu id="NavigationMenu"
    staticdisplaylevels="1"
    staticsubmenuindent="10" 
    orientation="Vertical 
    target="_blank" 
    StaticPopOutImageTextFormatString="More..."
    StaticPopOutImageUrl="Images/Popout.gif"   
    runat="server">
  <items>
    <asp:menuitem navigateurl="default2.aspx" 
        text="Home" 
        tooltip="Home">
      <asp:menuitem navigateurl="default3.aspx"
          text="Movies"
          tooltip="Movies"> 
      </asp:menuitem>
    </asp:menuitem>
  </items>
</asp:menu>

MenuItem.PopOutImageUrl özelliği değiştirildiğinden, ASP.NET önceki sürümlerinden ASP.NET 4'e geçirilen uygulamaların da etkilenebileceğini unutmayın. Daha fazla bilgi için, belgenin başka bir yerinde bulunan MenuItem.PopOutImageUrl Özelliği, ASP.NET 4'te bir görüntüyü işleyemez.

Bildirim

Bu bir ön belgedir ve burada açıklanan yazılımın son ticari sürümünden önce önemli ölçüde değiştirilebilir.

Bu belgede yer alan bilgiler, Microsoft Corporation'ın yayın tarihi itibariyle tartışılan sorunlarla ilgili geçerli görünümünü temsil eder. Microsoft'un değişen pazar koşullarına yanıt vermesi gerektiğinden, bu durum Microsoft'un bir taahhüdü olarak yorumlanmamalıdır ve Microsoft yayın tarihinden sonra sunulan bilgilerin doğruluğunu garanti edemez.

Bu Beyaz Kitap yalnızca bilgilendirme amaçlıdır. MICROSOFT, BU BELGEDEKI BILGILERLE ILGILI OLARAK AÇıK, ZıMNI VEYA YASAL HIÇBIR GARANTI VERMEZ.

Geçerli tüm telif hakkı yasalarına uymak kullanıcının sorumluluğundadır. Telif hakkı kapsamındaki haklar sınırlandırılmadan, bu belgenin hiçbir bölümü, Microsoft Corporation'ın açık yazılı izni olmadan herhangi bir biçimde veya herhangi bir yolla (elektronik, mekanik, fotokopi, kayıt veya başka bir yolla) çoğaltılamaz, depolanamaz veya bu sisteme eklenemez.

Microsoft bu belgedeki konuyu kapsayan patentlere, patent uygulamalarına, ticari markalara, telif haklarına veya diğer fikri mülkiyet haklarına sahip olabilir. Microsoft'un herhangi bir yazılı lisans sözleşmesinde açıkça belirtilmedikçe, bu belgenin sağlanması size bu patentler, ticari markalar, telif hakları veya diğer fikri mülkiyetler için herhangi bir lisans vermez.

Aksi belirtilmediği sürece, burada gösterilen örnek şirketler, kuruluşlar, ürünler, etki alanı adları, e-posta adresleri, logolar, kişiler, yerler ve etkinlikler kurgusaldır ve hiçbir gerçek şirket, kuruluş, ürün, etki alanı adı, e-posta adresi, logo, kişi, yer veya olayla ilişkili değildir veya çıkarılmalıdır.

© 2010 Microsoft Corporation. Tüm hakları saklıdır.

Microsoft ve Windows, Microsoft Corporation'ın ABD'deki ve/veya diğer ülkelerdeki tescilli ticari markaları veya ticari markalarıdır.

Burada bahsedilen gerçek şirketlerin ve ürünlerin adları, ilgili sahiplerinin ticari markaları olabilir.