ASP.NET MVC 4 Bundling ve Minification

25 Aralık 2012 meersoy
ASP.NET 4.5 ile yeni gelen özelliklerden biri olan Bundling and Minification temelde sunucuya gelen bir talebe (request), talep sayısını ve boyutunu düşürerek performans kazandırmayı amaçlayan bir özellik. Bu yazımda ASP.NET 4.5 ile gelen bu yeni özelliği ASP.NET MVC 4 ile incelemeye çalışacağım. Bundling ve Minification'dan Önce Bundling ve Minification öncesinde bir çok projemizde stil ve script dosyalarımızı sayfalarımıza aşağıdaki gibi tek tek tanımlardık :  <script src="~/Scripts/SiteScripts/LargeJSFile.js" type="text/javascript"></script> <script src="~/Scripts/SiteScripts/SmallJSFile.js" type="text/javascript"></script> <script src="~/Scripts/SiteScripts/Z_HighPriorityScript.js" type="text/javascript"></script> <link href="~/Content/Site.css" rel="stylesheet" type="text/css" /> Yukarıdaki script ve stil dosyalarını referans eden bir sayfaya istemciden gelen bir talep dört yeni talep daha yaparak her bir dosyayı da sunucudan talep eder (tabii eğer dosyalar cachelenmedi ise). Sayfamızda bulunan resim, video veya animasyon dosyaları gibi harici dosyaların da ayrı birer talep olarak sunucuya geldiği de düşünülürse bir web sayfası içerisinde kaç dosyaya referans veriyor ise sunucuya her biri için birer talep gidiyor demektir. Bu da web sayfalarımızın yüklenme zamanı performansını etkileyen kriterlerden biridir.    Yukarıdaki kod örneğindeki sayfamızı Google Chrome Developer Tools ile izler isek yukarıdaki gibi bir manzara ile karşılaşırız. Sayfamız ilk satırda yükleniyor, sonrasında stil ve script dosyaları (turuncu ve yeşil renkli) sunucudan talep ediliyor. Bundlelar  ASP.NET MVC 4 template projesini açtığınızda bu projede bundle'ların kullanıldığını farkedeceksiniz. Aşağıdaki gibi App_Start dizini altındaki BundleConfig sınıfına gözatarsak projede kullanılan script ve stil bundlelarının bu sınıf içerisinde tanımlandığını görürüz. Global.asax.cs sınıfına da gözatarsak eğer Application_Start olayında App_Start dizinindeki tüm config sınıflarının metodları çağrılarak web uygulamamızın ayarlarının yapıldığını görebiliriz. Eğer ASP.NET MVC 3 veya daha önceki versiyondan upgrade ettiğiniz bir web MVC uygulaması üzerinde çalışıyorsanız NuGet ile Microsoft.AspNet.Web.Optimization paketini almayı unutmayın. StyleBundle ve ScriptBundle sınıflarını kullanıp yaratacağımız yeni bundleları BundleCollection'a ekleyerek uygulamamız içerisinde kullanacağımız yeni bundleları tanımlayabiliriz. bundles.Add(new ScriptBundle("~/bundles/SiteScripts") .Include("~/Scripts/SiteScripts/*.js")); Yukarıdaki örnekte joker karakterler (* wildcard karakteri) ile Scripts/SiteScripts dizini altındaki tüm javascript dosyalarını yeni tanımladığım bundle'a dahil ediyorum. Burada ufak bir kısıtımız var, joker karakterleri, dizindeki tüm dosyaları kapsayacak şekilde tanımlamama izin verilmiyor.  Yani "Scripts/SiteScripts/*" şeklinde bir tanım çalışma zamanında aşağıdaki hata ile engelleniyor :  Yukarıdaki yarattığımız bundle'ı aşağıdaki gibi View'larımızda kullanabiliriz :  @Scripts.Render("~/bundles/SiteScripts") @Styles.Render("~/Content/css") Bu durumda sunucudan talep ettiğimiz sayfamızın kaynak koduna gözatarsak eğer aşağıdaki gibi bundle'ımızı tanımladığımız dizindeki script dosyalarının alfabetik olarak sıralı biçimde sayfamıza eklendiğini görebiliriz :  Hiyerarşik yapıda bir script veya stil dizinimiz var ve bunu bundle haline getirmek istiyorsak IncludeDirectory metodu daha çok işimize yarayacaktır. Metod bize aşağıdaki gibi alt dizinleri de yönetebileceğimiz bir esneklik sağlıyor :  bool includeSubDirectories = true; bundles.Add(new ScriptBundle("~/bundles/SiteScripts").IncludeDirectory( "~/Scripts/SiteScripts", "*.js", includeSubDirectories)); Minification Şimdiye kadar yaptığımız bundle örneklernini tek dosya halinde toplayıp içerisindeki gereksiz satırları (yorum satırları, boşluklar, yeni satırlar, vb. ) atıp, değişken isimlerini kısaltıp yani script veya stil dosyamızı optimize edip istemciye gönderilecek dosya boyutunu ve talep sayısını azaltan sihir aşağıdaki gibi EnableOptimization propertisi ile sağlanıyor :  // BundleConfig.cs içerisine eklenecek. BundleTable.EnableOptimizations = true;  Minification'ı aktif hale getiren yukarıdaki satırı eklediğimiz zaman aşağıdaki gibi bir sonuç ile karşılaşıyoruz :  Görüldüğü üzere üç script dosyası tek dosya halinde ve optimize edilmiş olarak 'SiteScripts?v=xyz-xyz-xyz' gibi bir dosya şeklinde istemciye gönderiliyor. Burada dikkat etmemiz gerene bir diğer nokta dosya isminin sonundaki v parametresi. Versiyon amaçlı kullanılan v parametresi sayesinde optimize ettiğimiz script dosyalarımız 1 sene boyunca istemcide cachelenmiş oluyor. Bu zaman zarfında eğer script dosyalarımız değişir ise yeni bir versiyon numarası otomatik olarak verilerek yeni bir dosya oluşturulup, istemcinin bu yeni dosyayı kullanması sağlanıyor. Toplam boyutu 160KB olan ve 3 script dosyasından oluşan örneğimin 89KB'a ve tek dosyaya indirmemi sağlayan Bundling and Minification özelliği performans açısından getirdiği artıların yanı sıra uygulamamızda kullandığımız script ve stil dosyalarını derleyip toparlayıp ve daha okunabilir bir kod sağlıyor. Güncelleme 16 Şubat 2014  Eğer ASP.NET MVC 3 veya daha önceki versiyondan upgrade ettiğiniz bir web ASP.NET MVC uygulaması üzerinde çalışıyorsanız NuGet ile Microsoft.AspNet.Web.Optimization paketini almayı unutmayın. Bu sayede System.Web.Optimization isim alanına ve yazımda bahsettiğim bundling sınıflarına erişebilirsiniz.

Response.RedirectPermanent ve Response.Redirect

18 Nisan 2012 meersoy
Klasik ASP'den kalan alışkanlıklarımızdan Response.Redirect("url") metodunu ziyaretçimizi bir sayfadan başka bir sayfaya yönlendirmek için yıllarca kullandık. ASP.NET geldi, Redirect metodumuz baki kaldı, kullanmaya devam ettik. ASP.NET 4.0 ile gelen Response.RedirectPermanent("url") metodu, tam olarak Response.Redirect metodunun pabucunu dama atmasa da redirect metodlarını daha dikkatli kullanmaya yönlendiriyor. Peki nedir bu iki metod arasındaki fark ?  İki metod temelde aynı işlemi yapıyorlar. Yani parametre olarak verilen URL'e ziyaretçiyi yönlendiriyorlar. Aralarındaki tek fark iki metodun ziyaretçiye döndüğü HTTP durum kodu. Aşağıdaki iki örneği, Firebug benzeri bir geliştirici aracı ile izleyerek çalıştırırsak resimlerdeki gibi iki metod arasındaki farkı izleyebiliriz   protected void linkClassicalRedirect_Click(object sender, EventArgs e) { Response.Redirect("RedirectedPage.aspx"); }   protected void linkPermanentlyRedirect_Click(object sender, EventArgs e) { Response.RedirectPermanent("RedirectedPage.aspx"); }   HTTP 302 ve HTTP 301 HTTP 302 durum kodu ziyaretçiye, istekte bulunan içeriğin, geçici olarak, transfer edilen sayfaya  (örnekteki RedirectedPage.aspx) taşındığını belirtiyor.  HTTP 301 durum kodu ise ziyaretçiye, istekte bulunan içeriğin, kalıcı olarak, transfer edilen sayfaya taşındığını ifade ediyor. Bu örneğin ve kodların bir tarayıcı vasıtası ile web uygulamamızı ziyaret eden kullanıcı için birşey ifade etmediğini söyleyebiliriz. Fakat asıl fark web uygulamamızı indexleyen arama motorlarının web uygulamamızı değerlendirmeleri sırasında ortaya çıkıyor. Sitemizi dolaşıp indexleme yapan bir arama motoru, bir içeriğin kalıcı olarak taşındığını HTTP 301 kodu ile aldığında indexlemesini yeni URL üzerinden yapacak, ve böylece arama motoru üzerinden sitemize erişen kullanıcılar için içeriğe erişim hızlanacaktır (eski link üzerinden redirect edilerek erişmek yerine yeni link ile doğrudan erişim sağlayacaklardır).

ASP.NET MVC 3 ve Elmah İle Hata Loglama

25 Mart 2012 meersoy
Elmah (Error Logging Modules and Handler) kütüphanesi ASP.NET 2.0'dan beri kullandığım, ASP.NET web uygulamaları için hata loglama ve yönetimi kütüphanesi. Geliştirdiğim web uygulamalarında sadece birkaç ayar ile hata yönetimini çalışır hale getirebiliyor olmam, beni Elmah'a hayran bırakan özelliklerinden sadece biri. ASP.NET HTTP Handlers kullanımına verilebilecek en yaratıcı örneklerden biri, hatta muhtemelen en iyisi.  ASP.NET MVC uygulamamızda Elmah'ı çalışır hale getirmek için aşağıdaki adımları takip edebiliriz.   ASP.NET MVC 3 Web Uygulamasına Elmah Kurulumu 1. İlk yapmamız gereken solution'ımıza sağ tıklayıp "Manage Nuget Packages"a tıklayıp NuGet paketleri içerisinde Elmah diye aratıp Elmah MS SQL Server'ı seçmek. Başka veritabanları üzerinde loglama yapacak, veya logları dosya sisteminde XML olarak kaydedecek Elmah paketleri de göreceksiniz listede. Ben örneğimi SQL Server üzerinde geliştireceğim.     2. Elmah NuGet paketini uygulamanıza yükledikten sonra solution'ınızda references'te Elmah referansını göçrebilirsiniz. Aynı zamanda uygulamanıza App_Readme diye bir dizin eklenmiş, ve içerisinde Elmah.SqlServer.sql isminde bir dosya olmalı. İşte bu dosya Elmah'ın hata loglarken kullanacağı SQL Server tablosunun ve Stored Procedure'lerinin scriptlerini barındırıyor. Şimdi yapmamız gereken bu dosyayı uygulamamızın bağlanacağı SQL Server veritabanında çalıştırmak.        3. Web uygulamamızın konfigurasyon dosyasını yani web.config'i açar isek, NuGet paketi yüklenirken konfigurasyon dosyamıza elmah diye bir bölüm tanımladığını ve içerisine Elmah'ın varsayılan ayarlarını yaptığını görebiliriz. İlk aşamada yapmamız gereken Elmah'ın veritabanına bağlanırken kullanacağı bağlantı cümleciğini (connection string) uygulamamızın kullandığı bağlantı cümleciğine eşitlemek.  Elmah'ın kullandığı bağlantı cümleciği aşağıdaki bölümde yer almakta.    <elmah> <errorLog type="Elmah.SqlErrorLog, Elmah" connectionStringName="elmah-sqlserver" /> </elmah>   connectionStringName değerini, webconfig dosyamızın connectionStrings bölümüne ekleyeceğimiz ve uygulamamızın kullanacağı bağlantı cümleciği ile değiştirebiliriz :  <connectionStrings> <add name="connStr" connectionString="Data Source=INSTANCE;Initial Catalog=DB;Persist Security Info=True;User ID=USER_NAME;Password=SIFRE" providerName="System.Data.SqlClient" /> </connectionStrings> <!-- ... --> <elmah> <errorLog type="Elmah.SqlErrorLog, Elmah" connectionStringName="connStr" /> </elmah>   Eğer bağlantı cümleciğini doğru tanımladıysak Elmah şuan çalışır hale gelmiş olmalı. Test edebilmek için, web uygulamamızı çalıştıralım ve uygulamamızın ana dizininde elmah.axd'yi çağıralım. Yani henüz localhostta çalıştığımız için benim çağırdığım link şu şekilde :  http://localhost:46352/elmah.axd   Loglanacak Hataların Filtrelenmesi Farkedeceğiniz üzere henüz yeni bir ASP.NET MVC uygulaması açmış olmama rağmen tarayıcım favicon.ico dosyasını sunucudan talep etmiş fakat 404 yani dosya bulunamadı hatası almış, ve bu hatalar Elmah tarafından loglanmış. İyi haber, uygulamama eklediğim Elmah paketim başarıyla çalışıyor. Kötü haber tarayıcım varsayılan olarak web uygulamalarının favicon.ico dosyasını sunucudan talep ettiği için bu hata sunucuya gelen her talepte loglanıyor olacak. Bunun önüne geçebilmek için web.config konfigurasyon dosyam içerisindeki elmah bölümünde aşağıdaki gibi filtre tanımı yapabilirim. errorFilter tag'ı ile loglamasını istemediğimiz logları filtreleyebiliriz : <elmah> <errorFilter> <test> <and> <equal binding="HttpStatusCode" value="404" type="Int32" /> <regex binding="Context.Request.ServerVariables['URL']" pattern="/favicon\.ico(\z|\?)" /> </and> </test> </errorFilter> </elmah>   Elmah Güvenlik Ayarları  Web uygulamamızı geliştirip sunucuya taşıma vakti geldiğinde, elmah.axd sayfasına yetkisiz kişilerin girmesini ve hatalarımızı görmesini istemeyiz. Hata mesajları sakıncalı ve güvenlik açığı oluşturabilecek bilgiler içerebilirler. Bu yüzden, web uygulamamızı web sunucusuna taşırsak ve tarayıcımızdan elmah.axd kaynağını talep edersek HTTP 403 Erişim Engellendi hatası ile karşılaşırız. Elmah önyüzü varsayılan ayarlarda yalnızda localde çalışır. Bunu açıp, elmah.axd'yi uygulamamızın yönetim alanına almak için öncelikle yapmamız gereken, web.config içerisindeki elmah bölümü altına security tagını eklemek ve allowRemoteAccess değerini true olarak vermek :  <elmah> <security allowRemoteAccess="true" /> <errorFilter> <test> <and> <equal binding="HttpStatusCode" value="404" type="Int32" /> <regex binding="Context.Request.ServerVariables['URL']" pattern="/favicon\.ico(\z|\?)" /> </and> </test> </errorFilter> </elmah> Şu durumda elmah.axd sunucudan talep eden herkese açık hale geldi. Şimdi location tagı ile elmah.axd'yi sadece yetkili kullanıcılarca erişilebilir hale getirelim. Tabi bunu kullanabilmek için uygulamamızın kullanıcı yönetiminin geliştirilmiş olması gerekmektedir :   <location path="elmah.axd"> <system.web> <authorization> <deny users="?" /> <allow roles="admin" /> </authorization> </system.web> </location> Sonuç Bu günlük yazımı yazmaya başladığımda ilk aklıma gelen Java dünyasında geçirdiğim 9 ay oldu. Başarılı pek çok kütüphaneyi çalışır hale getirebilmek için konfigürasyon dosyaları arasında kaybolmak... 2dk sürmeyen ve sadece 3 adımda tamamladığımız Elmah kurulumu ile web uygulamamızın hata loglama işlemlerini yapabiliyor hale getirdik. Filtreleme ve güvenlik ayarlarına göz attık. Basit ve hızlı bir çözüm ile uygulamamızda hata loglamasını, kendini kanıtlamış bir kütüphaneye emanet etmiş oluyoruz.