Geekly articles weekly

Perbedaan antara kompilasi situs web dan aplikasi web

Ada banyak jenis modul ASP.NET yang didasarkan pada berbagai platform seperti Formulir Web, Halaman Web, Model-View-Controller (MVC) dan yang terbaru - Core. Pada artikel ini, saya ingin melihat sejumlah perbedaan antara menyusun situs web ASP.NET dan aplikasi web ASP.NET.



Kompilasi situs web (Gbr. 1) dan aplikasi web (Gbr. 2).



Fig. 1: situs web ASP.NET dan perbedaan antara situs web ASP.NET dan aplikasi web ASP.NET



Fig. 2: aplikasi web ASP.NET dan perbedaan antara situs web ASP.NET dan aplikasi web ASP.NET

Artikel ini bukan tentang struktur internal proyek ASP.NET, tetapi tentang pengalaman yang saya peroleh saat bekerja pada platform Azure App Service. Perangkat internal sudah didokumentasikan di sini - "Mengompilasi Situs Web Anda (C #)" ("Mengompilasi Situs Web dalam C #"). Anda harus memahami perbedaan antara kompilasi otomatis dan eksplisit. Juga, jika Anda berurusan dengan situs web ASP.NET, pertimbangkan dengan serius sebelum melakukan kompilasi dengan aspnet_compiler.exe, seperti yang dijelaskan dalam Cara: Mengompilasi Situs Web ASP.NET (Cara Mengompilasi Situs Web) ASP.NET ").

Berikut adalah sejumlah publikasi yang akan membantu Anda memperluas wawasan Anda tentang masalah ini dan menjelajahi topik-topik lain:


Jadi dari mana semua ini dimulai? Saya ingin memeriksa apakah saya memahami proses mengkompilasi modul ASP.NET ke dalam rakitan dengan benar, dan memutuskan untuk melakukan ini di lingkungan Layanan Aplikasi Azure. Saya sudah memiliki konsep tentang file ASP.NET sementara, tentang mengkompilasi file ASPX ke dalam perakitan. Saya yakin bahwa pada platform Layanan Aplikasi dua poin pertama diimplementasikan dengan cara yang sama, tetapi saya meragukan yang ketiga - yaitu, di mana majelis yang dikompilasi disimpan. Jadi saya menulis kode untuk mencari tahu.

public partial class _default : System.Web.UI.Page { protected void Page_Load(object sender, EventArgs e) { LabelFileLocation.Text = $"{System.Web.HttpRuntime.CodegenDir}"; rptResults1.DataSource = System.IO.Directory.GetFiles(System.Web.HttpRuntime.CodegenDir, "*.dll"); rptResults1.DataBind(); } }      () <asp:Repeater ID="rptResults1" runat="server"> <HeaderTemplate><table></HeaderTemplate> <ItemTemplate> <tr> <td><%# Container.DataItem %></td> </tr> </ItemTemplate> <FooterTemplate></table></FooterTemplate> </asp:Repeater>

Lalu saya menerbitkan kode ini pada platform Layanan Aplikasi.

Ketika saya pertama kali mengakses situs web, saya mendapatkan hasil yang ditunjukkan pada Gambar. 3 (awalnya pada akar situs web ASP.NET saya adalah tiga halaman)



Fig. 3: kompilasi situs web ASP.NET pada platform Azure App Service

Saya me-restart situs web dan binari dikompilasi menjadi majelis baru (Gambar 4). Ini sangat tidak terduga, karena saya hanya reboot dan tidak membuat penyebaran atau perubahan.



Fig. 4: mengkompilasi situs web ASP.NET pada platform Azure App Service

Saya mencari di direktori perakitan KUDU dan tidak menemukannya; itu sangat aneh.

Setelah mengklik tautan “Another Page” dan “And Another Page”, semua halaman saya dikompilasi menjadi satu rakitan, dan saya sangat terkejut menemukan ini karena debug = true diatur dalam file web.config saya.

Saya perlu menemukan jawaban untuk pertanyaan-pertanyaan berikut:

  1. Mengapa aplikasi saya dikompilasi ulang setelah reboot, meskipun saya tidak melakukan perubahan penerapan atau konfigurasi?
  2. Mengapa saya tidak menemukan perakitan di KUDU meskipun kode sumber saya benar?
  3. Mengapa aplikasi saya dikompilasi ke dalam satu rakitan, meskipun debug = true diatur dalam file web.config?

Jawaban untuk pertanyaan pertama adalah bahwa saya benar-benar melihat majelis KUDU, bukan yang dikompilasi untuk Layanan Aplikasi. Lihatlah Gambar 2 di artikel “Buat tempat penyimpanan memori untuk Aplikasi Web Anda yang lambat”. Ini menunjukkan bahwa KUDU berjalan dalam proses yang berbeda dari Layanan Aplikasi. Oleh karena itu, KUDU mengkompilasi ulang dirinya sendiri saat membuat instance, dan itu bukan instance saya dari Layanan Aplikasi.

Saya juga menyortir pertanyaan kedua berdasarkan informasi yang diterima pada pertanyaan pertama. Saya akan mengabaikan detail tentang konfigurasi file pada platform Layanan Aplikasi dan mengatakan bahwa saya dapat menampilkan rakitan situs web ASP.NET di platform ini: untuk ini saya mengatur WEBSITE_DISABLE_SCM_SEPARATION menjadi true (lihat Gambar 5). Lakukan ini hanya untuk pengujian dan (atau) debugging dan tidak lebih. Saya tidak merekomendasikan pemetaan beberapa halaman situs web ke satu proses dalam Layanan Aplikasi. Setelah debugging selesai, setel ulang nilai ini dan pisahkan prosesnya lagi.



Fig. 5: kompilasi situs web ASP.NET di Layanan Aplikasi Azure; Saya tidak dapat menemukan file ASP.NET sementara di KUDU

Jawaban untuk pertanyaan ketiga adalah bahwa jika file Web.Debug.config hadir, atribut debug = true dihapus selama proses penyebaran.

 <compilation xdt:Transform="RemoveAttributes(debug)" />

Saya menulis tentang file XDT di sini , di sini dan di sini , tetapi dalam hal ini saya harus berpikir sedikit untuk memahami (mengingat, menyadari) maknanya.

Setelah mengatur WEBSITE_DISABLE_SCM_SEPARATION menjadi true, saya berhenti dan mulai, dengan kata lain, awal yang dingin ... dan saya melihat bahwa SCM / KUDU dan situs web saya benar-benar memulai proses yang sama (Gbr. 6.)



Fig. 6: kompilasi situs web ASP.NET di Layanan Aplikasi Azure; Saya tidak dapat menemukan file ASP.NET sementara di KUDU

Publikasi dan kompilasi default.aspx dimulai, nama majelis tetap tidak berubah setelah semua permintaan (Gbr. 7).



Fig. 7: kompilasi situs web ASP.NET pada platform Azure App Service

Untuk memverifikasi ini, saya mengambil dump dari memori proses, mengambil dump modul, dan menganalisisnya. Jujur, saya masih bingung dengan hasil yang ditampilkan oleh majelis, karena saya tahu parameter debug = true hanya setelah semua tes selesai. Terkadang saya menulis artikel dengan urutan yang salah di mana acara mengikuti. Bingung, saya memutuskan untuk menguji kompilasi batch; baca di sini : "Elemen Kompilasi (Skema Pengaturan ASP.NET)" ("Elemen Kompilasi - ASP.NET Skema Parameter Web"). Saya berharap satu perakitan per halaman akan dikompilasi, jadi hasilnya (lihat Gambar 8) benar-benar mengejutkan.



Fig. 8: kompilasi situs web ASP.NET pada platform Azure App Service

Saya berharap melihat satu perakitan per halaman, karena saya pikir saya bekerja dengan parameter debug = true. Membaca tentang kompilasi batch, saya menyadari bahwa ia mengkompilasi semua halaman ke dalam rakitan yang terdapat dalam direktori tertentu. Jadi saya membuat dua direktori dan meletakkan file .aspx di masing-masing. PID tidak berubah, jadi tidak ada "awal yang dingin" (Gbr. 9).



Fig. 9: kompilasi situs web ASP.NET pada platform Azure App Service

Namun, situs tersebut benar-benar dikompilasi ulang menjadi file biner lain, tetapi tetap berada di direktori (path) yang sama (Gbr. 10).



Fig. 10: menyusun situs web ASP.NET di platform Azure App Service

Saya membuang memori untuk sepenuhnya memverifikasi kebenaran kesimpulan saya. Dan, segera setelah saya beralih ke root situs dan melihat bahwa semua halaman dalam direktori dikompilasi, saya menyadari bahwa hipotesis saya tentang kompilasi batch dikonfirmasi (Gbr. 11).



Fig. 11: kompilasi situs web ASP.NET pada platform Azure App Service

Saya mengikuti tautan "Direktori 1" dan melihat perakitan lain (Gbr. 12).



Fig. 12: kompilasi situs web ASP.NET pada platform Azure App Service

Saya membuang memori lagi, melepaskan dump modul dan melihat bahwa itu benar-benar sesuai dengan halaman “Direktori 1” (Gbr. 13).



Fig. 13: kompilasi situs web ASP.NET pada platform Azure App Service

Saya melakukan hal yang sama untuk halaman Direktori 2 (Gbr. 14 dan 15).



Fig. 14: menyusun situs web ASP.NET di platform Azure App Service



Fig. 15: menyusun situs web ASP.NET di platform Azure App Service

Saya juga mendapat kesempatan untuk pergi ke majelis sendiri di SCM / KUDU (Gbr. 16).



Fig. 16: menyusun situs web ASP.NET di platform Azure App Service

Segera setelah saya menemukan masalah dengan parameter debug = true, semuanya jatuh ke tempatnya, dan itu adalah pengalaman belajar yang baik. Saya harap Anda menemukan artikel saya bermanfaat.



Sumber daya yang bermanfaat


Panduan Arsitektur Aplikasi Cloud


Ambil pendekatan terstruktur untuk mengembangkan aplikasi cloud. E-book 300 halaman tentang arsitektur komputasi awan ini membahas arsitektur, pengembangan, dan pedoman implementasi yang berlaku terlepas dari platform cloud mana yang Anda pilih. Panduan ini mencakup langkah-langkah untuk:

  • Memilih gaya arsitektur aplikasi cloud yang tepat untuk aplikasi atau solusi Anda;
  • pemilihan teknologi komputasi dan penyimpanan data yang tepat;
  • menerapkan 10 prinsip pengembangan untuk membuat aplikasi yang skalabel, tangguh, dan mudah dikelola;
  • mengikuti lima prinsip untuk menciptakan perangkat lunak berkualitas yang menjamin keberhasilan aplikasi cloud Anda;
  • Menggunakan pola desain yang dirancang untuk masalah yang Anda coba selesaikan.


→ Unduh

Panduan Pengembang Azure




Dalam pembaruan ini untuk Panduan Pengembang Azure, Anda akan melihat bagaimana rangkaian layanan lengkap untuk platform perangkat lunak Azure memenuhi kebutuhan Anda. Di sini Anda akan menemukan informasi tentang pendekatan arsitektur dan situasi paling umum yang muncul saat membuat aplikasi cloud.


→ Unduh

Dasar-Dasar Microsoft Azure


Buku ini memberikan wawasan penting tentang layanan Azure utama bagi pengembang dan profesional TI yang baru dalam komputasi awan. Demo langkah-demi-langkah disertakan untuk membantu pembaca memahami cara memulai dengan masing-masing layanan utama. Setiap bab independen, tidak diperlukan untuk melakukan demonstrasi praktis dari bab-bab sebelumnya untuk memahami bab tertentu.

Topik-topik berikut tercakup dalam buku ini:

  • Memulai dengan Azure;
  • Layanan Aplikasi Azure dan Aplikasi Web;
  • Mesin virtual;
  • Layanan penyimpanan;
  • Basis data
  • Layanan Azure Tambahan.

→ Unduh

Tautan yang bermanfaat


Source: https://habr.com/ru/post/id421995/

More articles:


All Articles