ASP.NET 4 Sürümündeki Hataya Neden Olan Değişiklikler

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

İçindekiler

Web.config Dosyasında ControlRenderingCompatibilityVersion Ayarı
ClientIDMode Değişiklikleri
HtmlEncode ve UrlEncode Artık Tek Tırnak İşaretlerini Kodla
ASP.NET Sayfası (.aspx) Ayrıştırıcısı Daha Katı
Tarayıcı Tanım Dosyaları Güncelleştirildi
System.Web.Mobile.dll Kök Web Yapılandırma Dosyasından Kaldırıldı
İsteği Doğrulamayı _Toc256770147
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ının AltındaYken 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 Belgede Olay İşleyicileri Tetiklenmeyebilir
ASP.NET Kod Erişim Güvenliği (CAS) Uygulamasında yapılan değişiklikler
System.Web.Security Ad Alanında MembershipUser ve Diğer Türler Taşındı
Çıkış Önbelleğe Alma Değişiklikleri Değişiklik Göster * HTTP Üst Bilgisi
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üleri İşlemez
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 ö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 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 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.
• BaseValidator sınıfı ve ondan türetilen 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 işlemez.
• Kullanıcı girişi için tasarlanmamış denetimler (örneğin, Etiket denetimi), Enabled özellikleri false olarak ayarlanırsa (veya bu ayarı kapsayıcı denetiminden devralırlarsa) özniteliğini işlemezdisabled="disabled".

ClientIDMode Değişiklikleri

ASP.NET 4'teki ClientIDMode ayarı, ASP.NET HTML öğeleri için id ö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 ö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 aşağıdaki ayarı Web.config ekleyin:

<pages clientIDMode="AutoID" />

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

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 %27 olarak 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"  />

CssClass özniteliğiyle çalışan kapatılmamış stil özniteliğ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 devralan ö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:

• Kimliği 'IE2' olan tarayıcı veya ağ geçidi öğesi bulunamıyor.

Not

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 karşılık gelen \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'ın önceki sürümlerinde, altındaki derlemeler bölümündeki kök Web.config dosyaya System.Web.Mobile.dll derlemesine başvuru eklenmiştir. Performansı geliştirmek için bu derlemenin başvurusu kaldırıldı.

System.Web.Mobile.dll derlemesi ASP.NET 4'e dahil edilir, ancak kullanım dışıdır. System.Web.Mobile.dll derlemedeki türleri kullanmak istiyorsanız, bu derlemeye kök Web.config dosyaya veya uygulama Web.config dosyasına bir başvuru ekleyin. Örneğin, mobil denetimler ASP.NET (kullanım dışı) herhangi birini kullanmak istiyorsanız, dosyaya System.Web.Mobile.dll derlemesine Web.config 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ştirildi. 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, bir HTTP isteğinin BeginRequest aşamasından önce etkinleştirildiğinden, istek doğrulama varsayılan olarak tüm istekler için etkinleştirilir. Sonuç olarak, istek doğrulaması yalnızca .aspx sayfa istekleri için değil, tüm ASP.NET kaynaklarına yönelik 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 de istek doğrulama 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 dönmek için dosyaya Web.config aşağıdaki ayarı ekleyin:

<httpRuntime requestValidationMode="2.0" />

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

Varsayılan karma algoritması artık HMACSHA256

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 artık tanımlama bilgileri ve görüntüleme durumu üzerinde karma işlemleri için HMACSHA256 algoritmasını kullanır. ASP.NET'in önceki sürümleri eski HMACSHA1 algoritmasını kullanıyordu.

Form kimlik doğrulaması tanımlama bilgileri gibi verilerin Framework sürümleri across.NET çalışması gereken karma ASP.NET 2.0/ASP.NET 4 ortamları çalıştırdığınızda 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 (machine.configve dolayısıyla ASP.NET 4) için kök yapılandırma dosyaları (dosya ve kök Web.config dosya), ASP.NET 3.5'te bulunan ortak yapılandırma bilgilerinin çoğunu içerecek Web.config şekilde güncelleştirildi. 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 ASP.NET 3.5 uygulamalarını yeniden derlemeden ç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 KB958854 ne de SP2 düzeltmesinin 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ı hatalı bir şekilde birleştirir. Bu nedenle, .NET Framework 3.5 veya sonraki sürümlerin uygulama düzeyindeki Web.config dosyaların IIS 7 doğrulama hatasına neden olmaması için 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 girişleri düzgün çalışır.) 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ı yaygın bir sorundur. 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 oluşması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 KB958854 düzeltmesinin 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şleyicilerinin 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" bulunduğ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, uygulama düzeyi Web.config dosyasından 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ı silmek veya açıklama satırı yapmaktır. Bu tanımlar genellikle uygulama düzeyi Web.config dosyasının en üstündedir ve configSections öğesi ve alt öğeleri tarafından tanımlanabilir.

Her iki senaryo için de system.codedom bölümünü el ile silmeniz önerilir, ancak bu gerekli değildir.

ASP.NET 4 Alt Uygulama, ASP.NET 2.0 veya ASP.NET 3.5 Uygulamalarının AltındaYken Başlatılamıyor

ASP.NET'nin önceki sürümlerini çalıştıran uygulamaların alt öğeleri olarak yapılandırılan ASP.NET 4 uygulama, yapılandırma veya derleme hataları nedeniyle başlatılamıyor olabilir. Aşağıdaki örnekte, etkilenen bir uygulama için 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 bildirir. Ö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ın nedeni, 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ıdır. 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 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.configconfigSections 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ı 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\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.

Not

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 veya IIS 7'de (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ünde dağıtılan bir Web.config dosyaya sahiptir (örneğin, c:\inetpub\wwwroot\web.config Varsayılan Web Sitesi için). 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 sitesini çalıştırmaya çalışırsanız, aşağıdaki hatayı görürsünüz:

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

ASP.NET 4 kod erişim güvenliği (CAS) altyapısı ASP.NET adlı bir izin kümesi aradığı için bu hata oluşur. Ancak, WSS_Minimal tarafından başvurulan kısmi güven yapılandırma dosyası bu ada sahip hiçbir izin kümesi içermez.

Şu anda ASP.NET uyumlu bir SharePoint sürümü yoktur. Sonuç olarak, ASP.NET 4 Web sitesini SharePoint Web sitelerinin 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ğerebir PathInfo değeri eklemıştı. ASP.NET 4 artık bu özelliklerden döndürülen değerlerde PathInfo değerini içermiyor. Bunun yerine , PathInfo bilgileri HttpRequest.PathInfo içinde kullanılabilir. Ö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 kullanmak üzere yapılandırıldığını algıladığında, ASP.NET 4'ün yerel bir bileşeni daha fazla işlem için ASP.NET yönetilen bölümüne uzantısız bir URL geçirdiği için 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 soruna geçici bir çözüm bulabilirsiniz.

1\. Seçenek

Web sitesini çalıştırmak için ASP.NET 4 gerekmiyorsa, siteyi bunun yerine ASP.NET 2.0 kullanacak şekilde yeniden eşle.

2\. Seçenek

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.

3\. Seçenek

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.

Not

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 Tümleşik Modunda 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 nasıl işlendiğini değiştiren değişiklikler içerir. Varsayılan bir belgeyi çözümleyerek uzantısız URL'ye örnek olarak , isteğiyle http://contoso.com/Default.aspxsonuçlanabilirhttp://contoso.com/.

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 yapıldığında boş bir dize olarak işleniyor. Örneğin, ASP.NET'nin http://contoso.com önceki sürümlerinde isteği, isteğine Default.aspxneden olur. Bu belgede, açılış formu etiketi aşağıdaki örnekte olduğu gibi işlenir:

<form action="Default.aspx" />

ASP.NET 4'te, isteğin http://contoso.com de isteğine neden olur Default.aspx. Ancak, ASP.NET şimdi html açma formu etiketini aşağıdaki örnekte olduğu gibi işler:

<form action="" />

Eylem özniteliğinin işlenme şeklindeki 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 öğesine 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ında olası bir etkileşim, yönetilen .aspx sayfalarının alt istek sırasında düzgün çalışmayı durdurmasına neden olabilir. Aşağıdaki koşullar oluşursa, bir Default.aspx belgeye yapılan alt istek 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'a geri nakledilir.
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ı neden olur. Sonuç olarak, varlık gövdesi artık IIS 7 veya IIS 7.5 Tümleşik modunda çalışan yerel kod modülleri için kullanılamaz.
4. IIS DefaultDocumentModule nesnesi sonunda çalışır ve belgeye bir alt istek Default.aspx oluşturur. Ancak varlık gövdesi yönetilen bir kod parçası tarafından zaten okunduğu için alt isteğe gönderilecek varlık gövdesi yoktur.
5. HTTP işlem hattı alt istek için çalıştırıldığında, dosyaların işleyicisi işleyici .aspx 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 hangi olayın (varsa) tetikleneceğini belirlemek için .aspx sayfa işleyicisi 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 geçici bir çözüm olarak aşağıdaki yöntemleri kullanabilirsiniz:

• 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 girdisine 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 ve bu nedenle varlık gövdesi hala kullanılabilir durumdadır ve alt isteğe ve varsayılan belgeye geçirilir.

• Sorunlu HTTP modüllerinin tüm istekler için çalıştırılması gerekiyorsa (statik dosyalar, DefaultDocumentModule nesnesine çözümlenen uzantısız URL'ler, yönetilen istekler vb.), 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'e 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'teki CAS uygulaması önemli ölçüde elden geçirilmiştir. Sonuç olarak, kısmi güven ASP.NET genel derleme önbelleğinde (GAC) çalışan güvenilir kodu kullanan 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 uygulamayı ASP.NET 1.1 ve 2.0 davranışlarına döndürebilirsiniz:

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

Eski CAS modeline geri dönerek 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.
• Yalnızca ASP.NET veya başka bir .NET Framework kodu yığında olduğunda çağrılan GAC derlemeleri için açık izin onayları gerekli değildir.

.NET Framework 4'te bir senaryo geri döndürülemez: Web olmayan kısmi güven uygulamaları artık System.Web.dll ve System.Web.Extensions.dll belirli API'leri çağıramaz. .NET Framework önceki sürümlerinde, Web olmayan 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. Bu türlerin Web dışı kısmi güven uygulamalarından çağrılması artık .NET Framework 4'te desteklenmiyor.

Not

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ılmakta olan tek ASP.NET işlevselliği 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 alır:

• 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 derlemeler .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ğini yalnızca Web barındırma ortamlarında yerine getirebilecek şekilde işaretlenir. ClickOnce gibi kısmen güvenilen Web dışı barındırma ortamları ASP.NET derlemelere çağrı yapamayacaktır.

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

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

ASP.NET üyelikte kullanılan bazı türler yeni System.Web.ApplicationServices.dll derlemesine taşındı System.Web.dll . 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ı.

System.Web.ApplicationServices.dll, ASP.NET derleme sistemi tarafından varsayılan olarak kullanılan başvurulan derlemeler listesine eklendiğinden, web sitesi projelerinde bu türlerin taşınması nedeniyle sorun olmaz. Visual Studio 2010'da açarak ASP.NET önceki bir sürümü kullanılarak oluşturulmuş bir Web sitesi projesini ASP.NET 4'e yükseltirseniz, proje hatasız derlenir.

Benzer şekilde, ASP.NET'nin ö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şınsa 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 yeni konumuna yönlendiren ASP.NET 4 sürümüne System.Web.dll eklenmiştir.

Ancak, belirli üyelik türlerini kullanan ve ASP.NET önceki 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 için sınıf kitaplığı projenize bir başvuru ekleyerek bu soruna geçici bir çözüm bulabilirsiniz.

Aşağıdaki listede, System.Web.ApplicationServices.dll taşınan System.Web.dllSystem.Web.Security türleri 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

Değişkenlik Için Çıktı Önbelleğe Alma Değişiklikleri * HTTP Üst Bilgisi

ASP.NET 1.0'da bir hata, çıktı-önbellek ayarı olarak belirtilen Location="ServerAndClient" önbelleğe alınmış sayfaların yanıtta bir Vary:* HTTP üst bilgisi yaymasına neden oldu. Bu, istemci tarayıcılarına sayfayı hiçbir zaman yerel olarak önbelleğe almamalarını söyleme etkisine neden oldu.

ASP.NET 1.1'de, üst bilgiyi engellemek Vary:* için çağırabileceğiniz System.Web.HttpCachePolicy.SetOmitVaryStar yöntemi eklendi. Bu yöntem seçildi, çünkü yayılan HTTP üst bilgisini değiştirmek 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 üst bilgisi artık aşağıdaki yönergeyi belirten yanıtlardan belirtilmez:

<%@OutputCache Location="ServerAndClient" %>

Sonuç olarak, üst bilgiyi bastırmak Vary:* için SetOmitVaryStar artık gerekli değildir.

Bir sayfadaki @ OutputCache yönergesinde belirtilen Location="ServerAndClient" uygulamalarda, artık Location özniteliğinin değerinin adının kapsadığı 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 olarak sunulan Passport desteği, Passport'taki (şimdi LiveID) değişiklikler 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 Görüntü İşlenemiyor

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

<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 bkz Menu.StaticPopOutImageUrl ve Menu.DynamicPopOutImageUrl, Yollar bu belgenin başka bir yerinde Ters Eğik Çizgi İçerdiğinde Görüntüleri İşlemez .

Menu.StaticPopOutImageUrl ve Menu.DynamicPopOutImageUrl Yollar Ters Eğik Çizgi İçerdiğinde Görüntüleri İşlemez

ASP.NET 4'te, path ters eğik çizgi () içeriyorsa Menu.StaticPopOutImageUrl ve Menu.DynamicPopOutImageUrl özelliklerini kullanarak belirttiğiniz görüntüler 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 kullanılarak 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 bkz MenuItem.PopOutImageUrl Özelliği bu belgenin başka bir yerindeki ASP.NET 4'te Görüntü İşlenemiyor .

Disclaimer

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.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. 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 Teknik İnceleme yalnızca bilgilendirme amaçlıdır. MICROSOFT, BU BELGEDEKI BILGILERLE ILGILI 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ırlanmadan, 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 bir alma sistemine eklenemez veya iletilmez.

Microsoft bu belgede konu başlığını 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 sunulması 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 herhangi bir gerçek şirket, kuruluş, ürün, etki alanı adı, e-posta adresi, logo, kişi, yer veya etkinlikle ilişki amaçlanmamıştır veya çıkarılmamalıdır.

© 2010 Microsoft Corporation. All rights reserved.

Microsoft ve Windows, Microsoft Corporation'ın Birleşik Devletler ve/veya diğer ülkelerde kayıtlı ticari markaları veya ticari markalarıdır.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.