ASP.NET 4 Perubahan Mencolok

Artikel
06/16/2023

Dokumen ini menjelaskan perubahan yang telah dibuat untuk rilis .NET Framework versi 4 yang berpotensi memengaruhi aplikasi yang dibuat menggunakan rilis sebelumnya, termasuk rilis ASP.NET 4 Beta 1 dan Beta 2.

Unduh Laporan Resmi Ini

Konten

Pengaturan ControlRenderingCompatibilityVersion di File Web.config
Perubahan ClientIDMode
HtmlEncode dan UrlEncode Sekarang Enkode Tanda Kutip Tunggal
ASP.NET Page (.aspx) Parser Lebih Ketat
File Definisi Browser Diperbarui
System.Web.Mobile.dll Dihapus dari File Konfigurasi Web Root
Validasi Permintaan
Algoritma Hash Default Sekarang HMACSHA256
Kesalahan Konfigurasi Yang Terkait dengan Konfigurasi Akar ASP.NET 4 Baru
ASP.NET 4 Aplikasi Anak Gagal Dimulai Saat Di bawah Aplikasi ASP.NET 2.0 atau ASP.NET 3.5
ASP.NET 4 Situs Web Gagal Dimulai di Komputer Tempat SharePoint Diinstal
Properti HttpRequest.FilePath tidak lagi menyertakan nilai PathInfo
aplikasi ASP.NET 2.0 Mungkin Menghasilkan Kesalahan HttpException yang Mereferensikan eurl.axd
Penanganan Aktivitas Mungkin Tidak Dimunculkan dalam Dokumen Default dalam Mode Terintegrasi IIS 7 atau IIS 7.5
Perubahan pada Implementasi ASP.NET Code Access Security (CAS)
MembershipUser dan Jenis Lain di Namespace System.Web.Security Telah Dipindahkan
Perubahan Penembolokan Output ke Bervariasi * Header HTTP
Jenis System.Web.Security untuk Paspor Kedaluwarsa
Properti MenuItem.PopOutImageUrl Gagal Merender Gambar di ASP.NET 4
Menu.StaticPopOutImageUrl dan Menu.DynamicPopOutImageUrl Gagal Merender Gambar Saat Jalur Berisi Garis Miring Terbelakang
Disclaimer

Pengaturan ControlRenderingCompatibilityVersion di File Web.config

ASP.NET kontrol telah dimodifikasi di .NET Framework versi 4 untuk memungkinkan Anda menentukan dengan lebih tepat bagaimana mereka merender markup. Di versi .NET Framework sebelumnya, beberapa kontrol memancarkan markup yang tidak dapat Anda nonaktifkan. Secara default, ASP.NET 4 jenis markup ini tidak lagi dihasilkan.

Jika Anda menggunakan Visual Studio 2010 untuk meningkatkan aplikasi dari ASP.NET 2.0 atau ASP.NET 3.5, alat ini secara otomatis menambahkan pengaturan ke Web.config file yang mempertahankan penyajian warisan. Namun, jika Anda meningkatkan aplikasi dengan mengubah kumpulan aplikasi di IIS untuk menargetkan .NET Framework 4, ASP.NET menggunakan mode penyajian baru secara default. Untuk menonaktifkan mode penyajian baru, tambahkan pengaturan berikut dalam Web.config file:

<pages controlRenderingCompatibilityVersion="3.5" />

Perubahan penyajian utama yang dibawa perilaku baru adalah sebagai berikut:

Kontrol Image dan ImageButton tidak lagi merender border="0" atribut.
Kelas BaseValidator dan kontrol validasi yang berasal darinya tidak lagi merender teks merah secara default.
Kontrol HtmlForm tidak merender atribut nama .
Kontrol Tabel tidak lagi merender border="0" atribut.
Kontrol yang tidak dirancang untuk input pengguna (misalnya, kontrol Label ) tidak lagi merender disabled="disabled" atribut jika properti Diaktifkan diatur ke false (atau jika mereka mewarisi pengaturan ini dari kontrol kontainer).

Perubahan ClientIDMode

Pengaturan ClientIDMode di ASP.NET 4 memungkinkan Anda menentukan bagaimana ASP.NET menghasilkan atribut id untuk elemen HTML. Dalam versi ASP.NET sebelumnya, perilaku default setara dengan pengaturan AutoIDClientIDMode. Namun, pengaturan default sekarang Dapat Diprediksi.

Jika Anda menggunakan Visual Studio 2010 untuk meningkatkan aplikasi dari ASP.NET 2.0 atau ASP.NET 3.5, alat ini secara otomatis menambahkan pengaturan ke Web.config file yang mempertahankan perilaku versi .NET Framework sebelumnya. Namun, jika Anda meningkatkan aplikasi dengan mengubah kumpulan aplikasi di IIS untuk menargetkan .NET Framework 4, ASP.NET menggunakan mode baru secara default. Untuk menonaktifkan mode ID klien baru, tambahkan pengaturan berikut dalam Web.config file:

<pages clientIDMode="AutoID" />

HtmlEncode dan UrlEncode Sekarang Enkode Tanda Kutip Tunggal

Di ASP.NET 4, metode HtmlEncode dan UrlEncode dari kelas HttpUtility dan HttpServerUtility telah diperbarui untuk mengodekan karakter tanda kutip tunggal (') sebagai berikut:

Metode HtmlEncode mengodekan instans tanda kutip tunggal sebagai ' .
Metode UrlEncode mengodekan instans tanda kutip tunggal sebagai %27.

ASP.NET Page (.aspx) Parser Lebih Ketat

Pengurai halaman untuk halaman ASP.NET (.aspx file) dan kontrol pengguna (.ascx file) lebih ketat di ASP.NET 4 dan akan menolak lebih banyak instans markup yang tidak valid. Misalnya, dua cuplikan berikut akan berhasil diurai dalam rilis ASP.NET sebelumnya, tetapi sekarang akan menimbulkan kesalahan pengurai di ASP.NET 4.

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

Perhatikan titik koma yang tidak valid di akhir tag HiddenField .

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

Perhatikan atribut gaya tidak tertutup yang berjalan ke atribut CssClass .

File Definisi Browser Diperbarui

File definisi browser telah diperbarui untuk menyertakan informasi tentang browser dan perangkat baru dan yang diperbarui. Browser dan perangkat yang lebih lama seperti Netscape Navigator telah dihapus, dan browser serta perangkat yang lebih baru seperti Google Chrome dan Apple iPhone telah ditambahkan.

Jika aplikasi Anda berisi definisi browser kustom yang diturunkan dari salah satu definisi browser yang telah dihapus, Anda akan melihat kesalahan. Misalnya, jika App_Browsers folder berisi definisi browser yang mewarisi dari definisi browser IE2, Anda akan menerima pesan kesalahan konfigurasi berikut:

Elemen browser atau gateway dengan ID 'IE2' tidak dapat ditemukan.

Catatan

Objek HttpBrowserCapabilities (yang diekspos oleh properti Request.Browser halaman) didorong oleh file definisi browser. Oleh karena itu, informasi yang dikembalikan dengan mengakses properti objek ini di ASP.NET 4 mungkin berbeda dari informasi yang dikembalikan dalam versi ASP.NET sebelumnya.

Anda dapat kembali ke file definisi browser lama dengan menyalin file definisi browser dari folder berikut:

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

Salin file ke folder yang \CONFIG\Browsers sesuai untuk ASP.NET 4. Setelah Anda menyalin file, jalankan alat baris perintah Aspnet_regbrowsers.exe.

System.Web.Mobile.dll Dihapus dari File Konfigurasi Web Root

Dalam versi ASP.NET sebelumnya, referensi ke perakitan System.Web.Mobile.dll disertakan dalam file akar Web.config di bagian rakitan di bawah. Untuk meningkatkan performa, referensi ke perakitan ini dihapus.

Rakitan System.Web.Mobile.dll disertakan dalam ASP.NET 4, tetapi tidak digunakan lagi. Jika Anda ingin menggunakan jenis dari rakitan System.Web.Mobile.dll, tambahkan referensi ke rakitan ini ke file akar Web.config atau ke file aplikasi Web.config . Misalnya, jika Anda ingin menggunakan salah satu kontrol seluler ASP.NET (tidak digunakan lagi), Anda harus menambahkan referensi ke perakitan System.Web.Mobile.dll ke Web.config file.

Validasi Permintaan ASP.NET

Fitur validasi permintaan di ASP.NET memberikan tingkat perlindungan default tertentu terhadap serangan scripting lintas situs (XSS). Di versi ASP.NET sebelumnya, validasi permintaan diaktifkan secara default. Namun, itu hanya diterapkan ke halaman ASP.NET (.aspx file dan file kelasnya) dan hanya ketika halaman tersebut dijalankan.

Di ASP.NET 4, secara default, validasi permintaan diaktifkan untuk semua permintaan, karena diaktifkan sebelum fase BeginRequest dari permintaan HTTP. Akibatnya, validasi permintaan berlaku untuk permintaan untuk semua sumber daya ASP.NET, bukan hanya permintaan halaman .aspx. Ini termasuk permintaan seperti panggilan layanan Web dan penangan HTTP kustom. Validasi permintaan juga aktif saat modul HTTP kustom membaca konten permintaan HTTP.

Akibatnya, kesalahan validasi permintaan sekarang mungkin terjadi untuk permintaan yang sebelumnya tidak memicu kesalahan. Untuk kembali ke perilaku fitur validasi permintaan ASP.NET 2.0, tambahkan pengaturan berikut dalam Web.config file:

<httpRuntime requestValidationMode="2.0" />

Namun, kami sarankan Anda menganalisis kesalahan validasi permintaan untuk menentukan apakah penangan, modul, atau kode kustom lainnya yang ada mengakses input HTTP yang berpotensi tidak aman yang bisa menjadi vektor serangan XSS.

Algoritma Hash Default Sekarang HMACSHA256

ASP.NET menggunakan enkripsi dan algoritme hash untuk membantu mengamankan data seperti cookie autentikasi formulir dan status tampilan. Secara default, ASP.NET 4 sekarang menggunakan algoritma HMACSHA256 untuk operasi hash pada cookie dan melihat status. Versi ASP.NET sebelumnya menggunakan algoritma HMACSHA1 yang lebih lama.

Aplikasi Anda mungkin terpengaruh jika Anda menjalankan lingkungan campuran ASP.NET 2.0/ASP.NET 4 di mana data seperti cookie autentikasi formulir harus berfungsi across.NET versi Framework. Untuk mengonfigurasi aplikasi Web ASP.NET 4 untuk menggunakan algoritma HMACSHA1 yang lebih lama, tambahkan pengaturan berikut dalam Web.config file:

<machineKey validation="SHA1" />

File konfigurasi akar (machine.configfile dan file akarWeb.config) untuk .NET Framework 4 (dan oleh karena itu ASP.NET 4) telah diperbarui untuk menyertakan sebagian besar informasi konfigurasi boilerplate yang dalam ASP.NET 3.5 ditemukan dalam file aplikasiWeb.config. Karena kompleksitas sistem konfigurasi IIS 7 dan IIS 7.5 terkelola, menjalankan aplikasi ASP.NET 3,5 di bawah ASP.NET 4 dan di bawah IIS 7 dan IIS 7.5 dapat mengakibatkan kesalahan konfigurasi ASP.NET atau IIS.

Kami menyarankan agar Anda meningkatkan aplikasi ASP.NET 3.5 ke ASP.NET 4 dengan menggunakan alat peningkatan proyek di Visual Studio 2010, jika praktis. Visual Studio 2010 secara otomatis memodifikasi file aplikasi Web.config ASP.NET 3.5 agar berisi pengaturan yang sesuai untuk ASP.NET 4.

Namun, ini adalah skenario yang didukung untuk menjalankan aplikasi ASP.NET 3.5 menggunakan .NET Framework 4 tanpa kompilasi ulang. Dalam hal ini, Anda mungkin harus memodifikasi file aplikasi Web.config secara manual sebelum menjalankan aplikasi di bawah .NET Framework 4 dan di bawah IIS 7 atau IIS 7.5.

Dua bagian berikutnya menjelaskan perubahan yang mungkin perlu Anda buat untuk kombinasi perangkat lunak yang berbeda.

Windows Vista SP1 atau Windows Server 2008 SP1, di mana hotfix KB958854 maupun SP2 tidak diinstal. Dalam konfigurasi ini, sistem konfigurasi IIS 7 salah menggabungkan konfigurasi terkelola aplikasi dengan membandingkan file tingkat Web.config aplikasi dengan file ASP.NET 2.0 machine.config . Karena itu, file tingkat Web.config aplikasi dari .NET Framework 3.5 atau yang lebih baru harus memiliki definisi bagian konfigurasi system.web.extensions (elemen) agar tidak menyebabkan kegagalan validasi IIS 7.

Namun, entri file tingkat Web.config aplikasi yang dimodifikasi secara manual yang tidak sama persis dengan definisi bagian konfigurasi boilerplate asli yang diperkenalkan dengan Visual Studio 2008 akan menyebabkan kesalahan konfigurasi ASP.NET. (Entri konfigurasi default yang dihasilkan oleh Visual Studio 2008 berfungsi dengan benar.) Masalah umumnya adalah bahwa file yang dimodifikasi Web.config secara manual meninggalkan atribut konfigurasi allowDefinition dan requirePermission yang ditemukan pada berbagai definisi bagian konfigurasi. Ini menyebabkan ketidakcocokan antara bagian konfigurasi yang disingkat dalam file tingkat Web.config aplikasi dan definisi lengkap dalam file ASP.NET 4 machine.config . Akibatnya, pada waktu proses, sistem konfigurasi ASP.NET 4 melemparkan kesalahan konfigurasi.

Windows Vista SP2, Windows Server 2008 SP2, Windows 7, Windows Server 2008 R2, dan juga Windows Vista SP1 dan Windows Server 2008 SP1 tempat hotfix KB958854 diinstal.

Dalam skenario ini, sistem konfigurasi asli IIS 7 dan IIS 7.5 mengembalikan kesalahan konfigurasi karena melakukan perbandingan teks pada atribut jenis yang ditentukan untuk penangan bagian konfigurasi terkelola. Karena semua Web.config file yang dihasilkan oleh Visual Studio 2008 dan Visual Studio 2008 SP1 memiliki "3.5" dalam string jenis untuk penangan bagian konfigurasi system.web.extensions (dan terkait), dan karena file ASP.NET 4 machine.config memiliki "4.0" dalam atribut jenis untuk penangan bagian konfigurasi yang sama, aplikasi yang dihasilkan di Visual Studio 2008 atau Visual Studio 2008 SP1 selalu gagal validasi konfigurasi di IIS 7 dan IIS 7.5.

Mengatasi Masalah Ini

Solusi untuk skenario pertama adalah memperbarui file tingkat Web.config aplikasi dengan menyertakan teks konfigurasi boilerplate dari Web.config file yang dihasilkan secara otomatis oleh Visual Studio 2008.

Solusi alternatif untuk skenario pertama adalah menginstal Paket Layanan 2 untuk Vista atau Windows Server 2008 di komputer Anda untuk memperbaiki perilaku penggabungan konfigurasi yang salah dari sistem konfigurasi IIS. Namun, setelah Anda melakukan salah satu tindakan ini, aplikasi Anda kemungkinan akan mengalami kesalahan konfigurasi karena masalah yang dijelaskan untuk skenario kedua.

Solusi untuk skenario kedua adalah menghapus atau mengomentari semua definisi bagian konfigurasi system.web.extensions dan definisi grup bagian konfigurasi dari file tingkat Web.config aplikasi. Definisi ini biasanya berada di bagian atas file tingkat Web.config aplikasi dan dapat diidentifikasi oleh elemen configSections dan turunannya .

Untuk kedua skenario, disarankan agar Anda juga menghapus bagian system.codedom secara manual, meskipun ini tidak diperlukan.

ASP.NET 4 Aplikasi Anak Gagal Dimulai Saat Di bawah Aplikasi ASP.NET 2.0 atau ASP.NET 3.5

Aplikasi ASP.NET 4 yang dikonfigurasi sebagai turunan dari aplikasi yang menjalankan versi ASP.NET yang lebih lama mungkin gagal untuk memulai karena kesalahan konfigurasi atau kompilasi. Contoh berikut menunjukkan struktur direktori untuk aplikasi yang terpengaruh.

/parentwebapp (dikonfigurasi untuk menggunakan ASP.NET 2.0 atau ASP.NET 3.5)
/childwebapp (dikonfigurasi untuk menggunakan ASP.NET 4)

Aplikasi dalam childwebapp folder akan gagal dimulai pada IIS 7 atau IIS 7.5 dan akan melaporkan kesalahan konfigurasi. Teks kesalahan akan menyertakan pesan yang mirip dengan yang berikut ini:

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.

Pada IIS 6, aplikasi di childwebapp folder juga akan gagal dimulai, tetapi akan melaporkan kesalahan yang berbeda. Misalnya, teks kesalahan mungkin menyatakan hal berikut:

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

Skenario ini terjadi karena informasi konfigurasi dari aplikasi induk di parentwebapp folder adalah bagian dari hierarki informasi konfigurasi yang menentukan pengaturan konfigurasi gabungan akhir yang digunakan oleh aplikasi web anak di childwebapp folder. Bergantung pada apakah aplikasi Web ASP.NET 4 berjalan pada IIS 7 (atau IIS 7.5) atau di IIS 6, sistem konfigurasi IIS atau sistem kompilasi ASP.NET 4 akan mengembalikan kesalahan.

Langkah-langkah yang harus Anda ikuti untuk mengatasi masalah ini dan agar aplikasi anak ASP.NET 4 berfungsi bergantung pada apakah aplikasi ASP.NET 4 berjalan pada IIS 6 atau di IIS 7 (atau IIS 7.5).

Langkah 1 (hanya IIS 7 atau IIS 7.5)

Langkah ini hanya diperlukan pada sistem operasi yang menjalankan IIS 7 atau IIS 7.5, yang mencakup Windows Vista, Windows Server 2008, Windows 7, dan Windows Server 2008 R2.

Pindahkan definisi configSections dalam Web.config file aplikasi induk (aplikasi yang berjalan ASP.NET 2.0 atau ASP.NET 3.5) ke dalam file root Web.config untuk the.NET Framework 2.0. Sistem konfigurasi asli IIS 7 dan IIS 7.5 memindai elemen configSections saat menggabungkan hierarki file konfigurasi. Memindahkan definisi configSections dari file aplikasi Web.config Web induk ke file akar Web.config secara efektif menyembunyikan elemen dari proses penggabungan konfigurasi yang terjadi untuk aplikasi turunan ASP.NET 4.

Pada sistem operasi 32-bit atau untuk kumpulan aplikasi 32-bit, file akar Web.config untuk ASP.NET 2.0 dan ASP.NET 3.5 biasanya terletak di folder berikut:

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

Pada sistem operasi 64-bit atau untuk kumpulan aplikasi 64-bit, file akar Web.config untuk ASP.NET 2.0 dan ASP.NET 3.5 biasanya terletak di folder berikut:

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

Jika Anda menjalankan aplikasi Web 32-bit dan 64-bit pada komputer 64-bit, Anda harus memindahkan elemen configSections ke file root Web.config untuk sistem 32-bit dan 64-bit.

Saat Anda meletakkan elemen configSections di file akar Web.config , tempelkan bagian segera setelah elemen konfigurasi . Contoh berikut menunjukkan seperti apa bagian atas file akar Web.config ketika Anda telah selesai memindahkan elemen.

Catatan

Dalam contoh berikut, baris telah dibungkus untuk keterbacaan.

<?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>

Langkah 2 (semua versi IIS)

Langkah ini diperlukan apakah aplikasi Web ASP.NET 4 anak berjalan pada IIS 6 atau di IIS 7 (atau IIS 7.5).

Web.config Dalam file aplikasi Web induk yang berjalan ASP.NET 2 atau ASP.NET 3.5, tambahkan tag lokasi yang secara eksplisit menentukan (untuk sistem konfigurasi IIS dan ASP.NET) yang hanya diterapkan entri konfigurasi ke aplikasi Web induk. Contoh berikut menunjukkan sintaks elemen lokasi untuk ditambahkan:

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

Contoh berikut menunjukkan bagaimana tag lokasi digunakan untuk membungkus semua bagian konfigurasi yang dimulai dengan bagian appSettings dan berakhir dengan bagian system.webServer .

<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>

Ketika Anda telah menyelesaikan langkah 1 dan 2, aplikasi Web ASP.NET 4 anak akan dimulai tanpa kesalahan.

ASP.NET 4 Situs Web Gagal Dimulai di Komputer Tempat SharePoint Diinstal

Server web yang menjalankan SharePoint memiliki Web.config file yang disebarkan di akar situs Web SharePoint (misalnya, c:\inetpub\wwwroot\web.config untuk Situs Web Default). Dalam file ini Web.config , SharePoint menetapkan tingkat kepercayaan parsial kustom bernama WSS_Minimal.

Jika Anda mencoba menjalankan situs Web ASP.NET 4 yang disebarkan sebagai anak dari tipe situs Web SharePoint ini, Anda akan melihat kesalahan berikut:

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

Kesalahan ini terjadi karena infrastruktur keamanan akses kode (CAS) ASP.NET 4 mencari kumpulan izin bernama ASP.NET. Namun, file konfigurasi kepercayaan parsial yang dirujuk oleh WSS_Minimal tidak berisi set izin apa pun dengan nama tersebut.

Saat ini tidak ada versi SharePoint yang tersedia yang kompatibel dengan ASP.NET. Akibatnya, Anda tidak boleh mencoba menjalankan situs Web ASP.NET 4 sebagai situs anak di bawah situs Web SharePoint.

Properti HttpRequest.FilePath tidak lagi menyertakan nilai PathInfo

Versi ASP.NET sebelumnya menyertakan nilai PathInfo dalam nilai yang dikembalikan dari berbagai properti terkait jalur file, termasuk HttpRequest.FilePath, HttpRequest.AppRelativeCurrentExecutionFilePath, dan HttpRequest.CurrentExecutionFilePath. ASP.NET 4 tidak lagi menyertakan nilai PathInfo dalam nilai yang dikembalikan dari properti ini. Sebagai gantinya, informasi PathInfo tersedia di HttpRequest.PathInfo. Misalnya, bayangkan fragmen URL berikut:

/testapp/Action.mvc/SomeAction

Di versi ASP.NET sebelumnya, properti HttpRequest memiliki nilai berikut:

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

HttpRequest.PathInfo: (kosong)

Di ASP.NET 4, properti HttpRequest memiliki nilai berikut:

HttpRequest.FilePath: /testapp/Action.mvc

HttpRequest.PathInfo: SomeAction

ASP.NET 2.0 Aplikasi Mungkin Menghasilkan Kesalahan HttpException yang Mereferensikan eurl.axd

Setelah ASP.NET 4 telah diaktifkan di IIS 6, aplikasi ASP.NET 2.0 yang berjalan di IIS 6 (di Windows Server 2003 atau Windows Server 2003 R2) mungkin menghasilkan kesalahan seperti berikut ini:

System.Web.HttpException: Path '/[yourApplicationRoot]/eurl.axd/[Value]' was not found.

Kesalahan ini terjadi karena ketika ASP.NET mendeteksi bahwa situs Web dikonfigurasi untuk menggunakan ASP.NET 4, komponen asli ASP.NET 4 meneruskan URL tanpa ekstensi ke bagian ASP.NET terkelola untuk pemrosesan lebih lanjut. Namun, jika direktori virtual yang berada di bawah situs Web ASP.NET 4 dikonfigurasi untuk menggunakan ASP.NET 2.0, memproses URL tanpa ekstensi dengan cara ini menghasilkan URL yang dimodifikasi yang berisi string "eurl.axd". URL yang dimodifikasi ini kemudian dikirim ke aplikasi ASP.NET 2.0. ASP.NET 2.0 tidak dapat mengenali format "eurl.axd". Oleh karena itu, ASP.NET 2.0 mencoba menemukan file bernama eurl.axd dan menjalankannya. Karena tidak ada file seperti itu, permintaan gagal dengan pengecualian HttpException .

Anda dapat mengatasi masalah ini menggunakan salah satu opsi berikut.

Opsi 1

Jika ASP.NET 4 tidak diperlukan untuk menjalankan situs Web, jalankan ulang situs untuk menggunakan ASP.NET 2.0 sebagai gantinya.

Opsi 2

Jika ASP.NET 4 diperlukan untuk menjalankan situs Web, pindahkan direktori virtual turunan ASP.NET 2.0 ke situs Web lain yang dipetakan ke ASP.NET 2.0.

Opsi 3

Jika tidak praktis untuk memetakan ulang situs Web ke ASP.NET 2.0 atau mengubah lokasi direktori virtual, nonaktifkan pemrosesan URL tanpa ekstensi secara eksplisit di ASP.NET 4. Gunakan prosedur berikut:

Di registri Windows, buka simpul berikut:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.30319.0

Buat nilai DWORD baru bernama EnableExtensionlessUrls.
Atur EnableExtensionlessUrls ke 0. Ini menonaktifkan perilaku URL tanpa ekstensi.
Simpan nilai registri dan tutup editor registri.
Jalankan alat baris perintah iisreset , yang menyebabkan IIS membaca nilai registri baru.

Catatan

Mengatur EnableExtensionlessUrls ke 1 memungkinkan perilaku URL tanpa ekstensi. Ini adalah pengaturan default jika tidak ada nilai yang ditentukan.

Penanganan Aktivitas Mungkin Tidak Dimunculkan dalam Dokumen Default dalam Mode Terintegrasi IIS 7 atau IIS 7.5

ASP.NET 4 menyertakan modifikasi yang mengubah bagaimana atribut tindakan elemen formulir HTML dirender saat URL tanpa ekstensi diselesaikan ke dokumen default. Contoh URL tanpa ekstensi yang diselesaikan ke dokumen default adalah http://contoso.com/, menghasilkan permintaan ke http://contoso.com/Default.aspx.

ASP.NET 4 sekarang merender nilai atribut tindakan elemen formulir HTML sebagai string kosong saat permintaan dibuat ke URL tanpa ekstensi yang memiliki dokumen default yang dipetakan ke dalamnya. Misalnya, dalam rilis ASP.NET sebelumnya, permintaan untuk http://contoso.com akan menghasilkan permintaan ke Default.aspx. Dalam dokumen tersebut, tag formulir pembuka akan dirender seperti dalam contoh berikut:

<form action="Default.aspx" />

Di ASP.NET 4, permintaan untuk http://contoso.com juga menghasilkan permintaan ke Default.aspx. Namun, ASP.NET sekarang merender tag formulir pembuka HTML seperti dalam contoh berikut:

<form action="" />

Perbedaan dalam bagaimana atribut tindakan dirender dapat menyebabkan perubahan halus dalam cara posting formulir diproses oleh IIS dan ASP.NET. Ketika atribut tindakan adalah string kosong, objek IIS DefaultDocumentModule akan membuat permintaan anak ke Default.aspx. Dalam sebagian besar kondisi, permintaan anak ini transparan terhadap kode aplikasi, dan Default.aspx halaman berjalan normal.

Namun, interaksi potensial antara kode terkelola dan mode terintegrasi IIS 7 atau IIS 7.5 dapat menyebabkan halaman .aspx terkelola berhenti bekerja dengan benar selama permintaan turunan. Jika kondisi berikut terjadi, permintaan anak ke Default.aspx dokumen akan mengakibatkan kesalahan atau perilaku yang tidak terduga:

Halaman .aspx dikirim ke browser dengan atribut tindakan elemen formulir diatur ke "".
Formulir diposting kembali ke ASP.NET.
Modul HTTP terkelola membaca beberapa bagian dari isi entitas. Misalnya, modul membaca Request.Form atau Request.Params. Hal ini menyebabkan isi entitas permintaan POST dibaca ke dalam memori terkelola. Akibatnya, isi entitas tidak lagi tersedia untuk modul kode asli apa pun yang berjalan dalam mode terintegrasi IIS 7 atau IIS 7.5.
Objek IIS DefaultDocumentModule akhirnya berjalan dan membuat permintaan anak ke Default.aspx dokumen. Namun, karena isi entitas telah dibaca oleh sepotong kode terkelola, tidak ada isi entitas yang tersedia untuk dikirim ke permintaan turunan.
Ketika alur HTTP berjalan untuk permintaan anak, handler untuk .aspx file berjalan selama fase handler-execute.
Karena tidak ada badan entitas, tidak ada variabel formulir dan tidak ada status tampilan, dan oleh karena itu tidak ada informasi yang tersedia untuk penangan halaman .aspx untuk menentukan peristiwa apa (jika ada) yang seharusnya dinaikkan. Akibatnya, tidak ada penanganan aktivitas postback untuk halaman .aspx yang terpengaruh berjalan.

Anda dapat mengatasi perilaku ini dengan cara berikut:

Identifikasi modul HTTP yang mengakses badan entitas permintaan selama permintaan dokumen default dan tentukan apakah modul tersebut dapat dikonfigurasi untuk berjalan hanya untuk permintaan terkelola. Dalam mode Terintegrasi untuk IIS 7 dan IIS 7.5, modul HTTP dapat ditandai untuk berjalan hanya untuk permintaan terkelola dengan menambahkan atribut berikut ke entri modul system.webServer/modules :
precondition="managedHandler"
Pengaturan ini menonaktifkan modul untuk permintaan yang ditentukan IIS 7 dan IIS 7.5 sebagai permintaan yang tidak dikelola. Untuk permintaan dokumen default, permintaan pertama adalah ke URL tanpa ekstensi. Oleh karena itu, IIS tidak menjalankan modul terkelola apa pun yang ditandai dengan prasyarat Handler terkelola selama pemrosesan permintaan awal. Akibatnya, modul terkelola tidak akan secara tidak sengaja membaca isi entitas dan dengan demikian badan entitas masih tersedia dan diteruskan ke permintaan anak dan ke dokumen default.
Jika modul HTTP bermasalah harus berjalan untuk semua permintaan (untuk file statis, untuk URL tanpa ekstensi yang diselesaikan ke objek DefaultDocumentModule , untuk permintaan terkelola, dll.), ubah halaman .aspx yang terpengaruh dengan secara eksplisit mengatur properti Tindakan dari kontrol System.Web.UI.HtmlControls.HtmlForm halaman ke string yang tidak kosong. Misalnya, jika dokumen default adalah Default.aspx, ubah kode halaman untuk secara eksplisit mengatur properti Tindakan kontrol HtmlForm ke "Default.aspx".

Perubahan pada Implementasi ASP.NET Code Access Security (CAS)

ASP.NET 2.0, dan dengan ekstensi fitur ASP.NET yang ditambahkan dalam 3.5, gunakan model keamanan akses kode (CAS) .NET Framework 1.1 dan 2.0. Namun, implementasi CAS di ASP.NET 4 telah dirombak secara substansial. Akibatnya, aplikasi ASP.NET kepercayaan parsial yang mengandalkan kode tepercaya yang berjalan di cache perakitan global (GAC) mungkin gagal dengan berbagai pengecualian keamanan. Aplikasi kepercayaan parsial yang mengandalkan modifikasi ekstensif pada kebijakan CAS mesin mungkin juga gagal dengan pengecualian keamanan.

Anda dapat mengembalikan kepercayaan parsial ASP.NET 4 aplikasi ke perilaku ASP.NET 1.1 dan 2.0 menggunakan atribut legacyCasModel baru dalam elemen konfigurasi kepercayaan , seperti yang ditunjukkan dalam contoh berikut:

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

Saat Anda kembali ke model CAS warisan, perilaku CAS lama berikut diaktifkan:

Kebijakan CAS mesin dihormati.
Beberapa set izin yang berbeda dalam satu domain aplikasi diizinkan.
Pernyataan izin eksplisit tidak diperlukan untuk rakitan di GAC yang dipanggil ketika hanya ASP.NET atau kode .NET Framework lainnya ada di tumpukan.

Satu skenario tidak dapat dikembalikan dalam aplikasi .NET Framework 4: non-Web partial-trust tidak dapat lagi memanggil API tertentu di System.Web.dll dan System.Web.Extensions.dll. Dalam versi .NET Framework sebelumnya, dimungkinkan bagi aplikasi kepercayaan parsial non-Web untuk secara eksplisit diberikan izin AspNetHostingPermission. Aplikasi ini kemudian dapat menggunakan System.Web.HttpUtility, jenis di namespace System.Web.ClientServices.* , dan jenis yang terkait dengan keanggotaan, peran, dan profil. Memanggil jenis ini dari aplikasi kepercayaan parsial non-Web tidak lagi didukung di .NET Framework 4.

Catatan

Fungsi htmlEncode dan HtmlDecode dari kelas System.Web.HttpUtility dipindahkan ke kelas System.Net.WebUtility .NET Framework 4 baru. Jika itu adalah satu-satunya fungsi ASP.NET yang sedang digunakan, ubah kode aplikasi untuk menggunakan kelas WebUtility baru sebagai gantinya.

Berikut ini adalah ringkasan tingkat tinggi dari perubahan pada implementasi CAS default di ASP.NET 4:

ASP.NET domain aplikasi sekarang menjadi domain aplikasi homogen. Hanya set pemberian kepercayaan parsial dan kepercayaan penuh yang tersedia di domain aplikasi.
ASP.NET set pemberian kepercayaan parsial independen dari kebijakan CAS tingkat perusahaan, tingkat komputer, atau tingkat pengguna apa pun.
ASP.NET rakitan yang dikirim dalam 3,5 dan 3,5 SP1 telah dikonversi untuk menggunakan model transparansi .NET Framework 4.
Penggunaan atribut ASP.NET AspNetHostingPermission telah dikurangi secara substansial. Sebagian besar instans atribut ini telah dihapus dari API ASP.NET publik.
Rakitan yang dikompilasi secara dinamis yang dibuat oleh penyedia build ASP.NET telah diperbarui untuk secara eksplisit menandai rakitan sebagai transparan.
Semua rakitan ASP.NET sekarang ditandai sedidahnya sehingga atribut APTCA hanya dihormati di lingkungan hosting Web. Lingkungan hosting non-Web yang tepercaya sebagian seperti ClickOnce tidak akan dapat memanggil rakitan ASP.NET.

Untuk informasi selengkapnya tentang model keamanan akses kode ASP.NET 4 baru, lihat Menggunakan Keamanan Akses Kode di Aplikasi ASP.NET di situs Web MSDN.

MembershipUser dan Tipe Lain di Namespace Layanan System.Web.Security Telah Dipindahkan

Beberapa jenis yang digunakan dalam keanggotaan ASP.NET telah dipindahkan dari System.Web.dll ke assembly System.Web.ApplicationServices.dll baru. Jenis dipindahkan untuk menyelesaikan dependensi lapisan arsitektur antara jenis di klien dan di diperpanjang .NET Framework SKU.

Proyek situs web tidak memiliki masalah sebagai akibat dari pemindahan tipe ini, karena System.Web.ApplicationServices.dll ditambahkan ke daftar rakitan yang dirujuk yang digunakan secara default oleh sistem kompilasi ASP.NET. Jika Anda memutakhirkan proyek situs Web yang dibuat menggunakan versi ASP.NET yang lebih lama ke ASP.NET 4 dengan membukanya di Visual Studio 2010, proyek akan dikompilasi tanpa kesalahan.

Demikian pula, jika Anda meningkatkan proyek aplikasi Web yang dibuat dalam versi ASP.NET yang lebih lama ke ASP.NET 4 dengan membukanya di Visual Studio 2010, proses peningkatan menambahkan referensi ke System.Web.ApplicationServices.dll ke proyek. Oleh karena itu, proyek aplikasi Web yang ditingkatkan juga akan dikompilasi tanpa kesalahan.

File yang dikompilasi (biner) yang dibuat menggunakan versi ASP.NET sebelumnya juga akan berjalan tanpa kesalahan pada ASP.NET 4, meskipun jenis keanggotaan dipindahkan ke rakitan yang berbeda. Informasi penerusan jenis System.Web.dll telah ditambahkan ke versi ASP.NET 4 yang secara otomatis merutekan referensi run-time untuk jenis ini ke lokasi baru untuk jenis tersebut.

Namun, pustaka kelas yang menggunakan jenis keanggotaan tertentu dan yang telah ditingkatkan dari versi ASP.NET sebelumnya akan gagal dikompilasi saat digunakan dalam proyek ASP.NET 4. Misalnya, proyek pustaka kelas mungkin gagal mengkompilasi dan melaporkan kesalahan seperti berikut ini:

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.

Anda dapat mengatasi masalah ini dengan menambahkan referensi di proyek pustaka kelas Anda ke System.Web.ApplicationServices.dll.

Daftar berikut ini memperlihatkan tipe System.Web.Security yang dipindahkan dari System.Web.dll ke System.Web.ApplicationServices.dll:

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

Perubahan Penembolokan Output menjadi Bervariasi * Header HTTP

Di ASP.NET 1.0, bug menyebabkan halaman cache yang ditentukan Location="ServerAndClient" sebagai pengaturan output–cache untuk memancarkan Vary:* header HTTP dalam respons. Ini memiliki efek memberi tahu browser klien untuk tidak pernah meng-cache halaman secara lokal.

Dalam ASP.NET 1.1, metode System.Web.HttpCachePolicy.SetOmitVaryStar ditambahkan, yang dapat Anda panggil untuk menekan Vary:* header. Metode ini dipilih karena mengubah header HTTP yang dipancarkan dianggap sebagai perubahan yang berpotensi melanggar pada saat itu. Namun, pengembang telah bingung dengan perilaku dalam ASP.NET, dan laporan bug menunjukkan bahwa pengembang tidak menyadari perilaku SetOmitVaryStar yang ada.

Pada ASP.NET 4, keputusan dibuat untuk memperbaiki masalah akar. Header Vary:* HTTP tidak lagi dipancarkan dari respons yang menentukan direktif berikut:

<%@OutputCache Location="ServerAndClient" %>

Akibatnya, SetOmitVaryStar tidak lagi diperlukan untuk menekan Vary:* header.

Dalam aplikasi yang menentukan Location="ServerAndClient" di arahan @ OutputCache pada halaman, Anda sekarang akan melihat perilaku yang tersirat dengan nama nilai atribut Lokasi - yaitu, halaman akan dapat di-cache di browser tanpa mengharuskan Anda memanggil metode SetOmitVaryStar .

Jika halaman dalam aplikasi Anda harus memancarkan Vary:*, panggil metode AppendHeader , seperti dalam contoh berikut:

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

Atau, Anda dapat mengubah nilai atribut Lokasi penembolokan output menjadi "Server".

Jenis System.Web.Security untuk Paspor usang

Dukungan Paspor yang disertakan dalam ASP.NET 2.0 telah usang dan tidak didukung selama beberapa tahun karena perubahan Paspor (sekarang LiveID). Akibatnya, lima jenis yang terkait dengan Paspor di System.Web.Security sekarang ditandai dengan atribut ObsoleteAttribute .

Properti MenuItem.PopOutImageUrl Gagal Merender Gambar di ASP.NET 4

Di ASP.NET 3.5, properti MenuItem.PopOutImageUrl memungkinkan Anda menentukan URL untuk gambar yang ditampilkan dalam item menu untuk menunjukkan bahwa item menu memiliki submenu dinamis. Contoh berikut menunjukkan cara menentukan properti ini dalam markup di ASP.NET 3.5.

<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>

Sebagai akibat dari perubahan desain di ASP.NET 4, tidak ada output yang dirender untuk PopOutImageUrl jika properti diatur untuk kelas MenuItem . Sebagai gantinya, Anda harus menentukan URL gambar langsung di kontrol Menu menggunakan properti StaticPopOutImageUrl atau properti DynamicPopOutImageUrl . Saat Anda bekerja dengan menu statis, properti Menu.StaticPopOutImageUrl menentukan URL untuk gambar yang ditampilkan untuk menunjukkan bahwa item menu statis memiliki submenu, seperti yang ditunjukkan dalam contoh berikut:

<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>

Jika Anda bekerja dengan menu dinamis, Anda menggunakan properti Menu.DynamicPopOutImageUrl untuk menentukan URL untuk gambar yang menunjukkan bahwa item menu dinamis memiliki submenu. Contoh berikut mirip dengan yang sebelumnya, tetapi menunjukkan cara mengatur properti DynamicPopOutImageUrl untuk menu dinamis.

<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>

Jika properti Menu.DynamicPopOutImageUrl tidak diatur dan properti Menu.DynamicEnableDefaultPopOutImage diatur ke false, tidak ada gambar yang ditampilkan. Demikian pula, jika properti StaticPopOutImageUrl tidak diatur dan properti StaticEnableDefaultPopOutImage diatur ke false, tidak ada gambar yang ditampilkan.

Saat Anda mengatur jalur untuk properti ini, gunakan garis miring (/) alih-alih garis miring terbelakang (). Untuk informasi selengkapnya, lihat Menu.StaticPopOutImageUrl dan Menu.DynamicPopOutImageUrl Gagal Merender Gambar Saat Jalur Berisi Garis Miring Terbelakang di tempat lain dalam dokumen ini.

Menu.StaticPopOutImageUrl dan Menu.DynamicPopOutImageUrl Gagal Merender Gambar Saat Jalur Berisi Garis Miring Terbelakang

Di ASP.NET 4, gambar yang Anda tentukan menggunakan properti Menu.StaticPopOutImageUrl dan Menu.DynamicPopOutImageUrl tidak akan dirender jika jalur berisi backlashes (). Ini adalah perubahan dari versi ASP.NET sebelumnya.

Contoh markup kontrol Menu berikut menunjukkan kumpulan properti StaticPopOutImageUrl menggunakan jalur yang berisi garis miring terbalik. Dalam ASP.NET 4, gambar yang ditentukan dalam properti tidak akan dirender.

<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>

Untuk memperbaiki masalah ini, ubah nilai jalur yang ditentukan dalam properti StaticPopOutImageUrl dan DynamicPopOutImageUrl untuk menggunakan garis miring (/). Contoh berikut menunjukkan perubahan ini:

<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>

Perhatikan bahwa aplikasi yang dimigrasikan dari versi ASP.NET sebelumnya ke ASP.NET 4 mungkin juga terpengaruh, karena properti MenuItem.PopOutImageUrl telah diubah. Untuk informasi selengkapnya, lihat Properti MenuItem.PopOutImageUrl Gagal Merender Gambar di ASP.NET 4 di tempat lain dalam dokumen ini.

Disclaimer

Ini adalah dokumen awal dan dapat diubah secara substansial sebelum rilis komersial akhir perangkat lunak yang dijelaskan di sini.

Informasi yang terkandung dalam dokumen ini menunjukkan tampilan Microsoft Corporation saat ini tentang masalah yang dibahas pada tanggal publikasi. Karena Microsoft harus menanggapi perubahan kondisi pasar, itu tidak boleh ditafsirkan sebagai komitmen dari pihak Microsoft, dan Microsoft tidak dapat menjamin keakuratan informasi apa pun yang disajikan setelah tanggal publikasi.

Laporan Resmi ini hanya untuk tujuan informasi. MICROSOFT TIDAK MEMBERIKAN JAMINAN, TERSURAT, TERSIRAT, ATAU WAJIB, SEPERTI INFORMASI DALAM DOKUMEN INI.

Mematuhi semua undang-undang hak cipta yang berlaku adalah tanggung jawab pengguna. Tanpa membatasi hak cipta, tidak ada bagian dari dokumen ini yang dapat direproduksi, disimpan dalam atau diperkenalkan ke dalam sistem pengambilan, atau dikirimkan dalam bentuk apa pun atau dengan cara apa pun (elektronik, mekanis, fotokopi, perekaman, atau lainnya), atau untuk tujuan apa pun, tanpa izin tertulis dari Microsoft Corporation.

Microsoft mungkin memiliki paten, aplikasi paten, merek dagang, hak cipta, atau hak kekayaan intelektual lainnya yang mencakup materi pelajaran dalam dokumen ini. Kecuali secara tegas disediakan dalam perjanjian lisensi tertulis dari Microsoft, perabotan dokumen ini tidak memberi Anda lisensi apa pun untuk paten, merek dagang, hak cipta, atau kekayaan intelektual lainnya.

Kecuali dinyatakan lain, contoh perusahaan, organisasi, produk, nama domain, alamat email, logo, orang, tempat, dan peristiwa yang digambarkan di sini bersifat fiktif, dan tidak ada hubungan dengan perusahaan, organisasi, produk, nama domain, alamat email, logo, orang, tempat, atau acara yang sebenarnya dimaksudkan atau harus disimpulkan.

Microsoft dan Windows adalah merek dagang terdaftar atau merek dagang Microsoft Corporation di Amerika Serikat dan/atau negara lain.

Nama perusahaan dan produk sebenarnya yang disebutkan di sini mungkin merupakan merek dagang dari pemiliknya masing-masing.

Bagikan melalui

ASP.NET 4 Perubahan Mencolok

Konten

Pengaturan ControlRenderingCompatibilityVersion di File Web.config

Perubahan ClientIDMode

HtmlEncode dan UrlEncode Sekarang Enkode Tanda Kutip Tunggal

ASP.NET Page (.aspx) Parser Lebih Ketat

File Definisi Browser Diperbarui

System.Web.Mobile.dll Dihapus dari File Konfigurasi Web Root

Validasi Permintaan ASP.NET

Algoritma Hash Default Sekarang HMACSHA256

Mengatasi Masalah Ini

ASP.NET 4 Aplikasi Anak Gagal Dimulai Saat Di bawah Aplikasi ASP.NET 2.0 atau ASP.NET 3.5

Langkah 1 (hanya IIS 7 atau IIS 7.5)

Langkah 2 (semua versi IIS)

ASP.NET 4 Situs Web Gagal Dimulai di Komputer Tempat SharePoint Diinstal

Properti HttpRequest.FilePath tidak lagi menyertakan nilai PathInfo

ASP.NET 2.0 Aplikasi Mungkin Menghasilkan Kesalahan HttpException yang Mereferensikan eurl.axd

Opsi 1

Opsi 2

Opsi 3

Penanganan Aktivitas Mungkin Tidak Dimunculkan dalam Dokumen Default dalam Mode Terintegrasi IIS 7 atau IIS 7.5

Perubahan pada Implementasi ASP.NET Code Access Security (CAS)

MembershipUser dan Tipe Lain di Namespace Layanan System.Web.Security Telah Dipindahkan

Perubahan Penembolokan Output menjadi Bervariasi * Header HTTP

Jenis System.Web.Security untuk Paspor usang

Properti MenuItem.PopOutImageUrl Gagal Merender Gambar di ASP.NET 4

Menu.StaticPopOutImageUrl dan Menu.DynamicPopOutImageUrl Gagal Merender Gambar Saat Jalur Berisi Garis Miring Terbelakang

Disclaimer

Saran dan Komentar

Saran dan Komentar

Sumber Daya Tambahan: