[ASP.NET]ASP.NET 4.0 Overview-Core Services

2010-01-03

9701
0
ASP.NET
2010-01-08

ASP.NET 4.0 Beta 2跟VS2010 Beta 2推出都1-2個月了，還沒有時間把他的White paper跟IDE裝起來玩一下，今天晚上總算將White paper看了一遍，有興趣的人可以到這個網址看看細節：

ASP.NET 4 and Visual Studio 2010 Web Development Beta 2 Overview

時間如果允許的話，我希望能將以下幾個大章節都帶過一遍：

Core Services

New Features in the Microsoft Ajax Library

Web Forms

ASP.NET MVC

Dynamic Data

Visual Studio 2010 Web Designer Improvements

Web Application Deployment with Visual Studio 2010

而本篇我們先著重在Core Services的部分，來看看ASP.NET 4.0在核心服務的部分提供了哪些新功能：

Web.config File Minification

若你開發ASP.NET已經有一段時日，對於站台的web.config結構應該不會太陌生，在建立起站台時，許多不知作用的tag也被一起建立起來了，而這個問題在4.0將被解決，多數的設定功能已經被移到machine.config中，而透過組態繼承的效果，讓站台的web.config不用再做這些設定，所以4.0的web.config一開始的內容只有這樣，真的超級精簡：
<?xml version="1.0"?>
<configuration>
  <system.web>
    <compilation targetFramework="4.0" />
  </system.web>
</configuration>

Extensible Output Caching

ASP.NET提供了強大的Cache功能，相關的細節可以參考這篇：[ASP.NET]淺談Cache機制

這個Cache功能雖然強大，但卻有個缺點，若大家有印象，應該知道Session的儲存模式分成四種吧，其中的InProc就是將Session的內容放到本機的記憶體中，這種儲放法最大的問題主要在於記憶體的使用量會較高，因此ASP.NET還多提供了SQLServer跟StateServer兩種儲存模式，但這樣的模式在Cache機制中並沒有被提供，直到ASP.NET 4.0中才真正完成實作，我們可以自行實作我們Cache的data要以什麼方式儲存，進行步驟如下：

1.在web.config中定義Provider
<caching>
  <outputCache defaultProvider="AspNetInternalProvider">
    <providers>
      <add name="DiskCache"
          type="Test.OutputCacheEx.DiskOutputCacheProvider, DiskCacheProvider"/>
    </providers>
  </outputCache>
</caching>

2.在Page/Control上設定CacheProvider名稱


<%@ OutputCache Duration="60" VaryByParam="None" providerName="DiskCache" %>

3.或者在程式中指定不同的request要由不同的Cache Provider來處理


public override string GetOutputCacheProviderName(HttpContext context)
{
    if (context.Request.Path.EndsWith("Advanced.aspx"))
       return "DiskCache";
    else
        return base.GetOutputCacheProviderName(context);
}

Auto-Start Web Applications

這個功能其實讓我頗為驚豔，ASP.NET在之前一直有個讓我們頭痛的地方，那就是第一次啟動系統、網頁時需要比較長的時間，之前我還寫過一篇文章，希望能解決這個問題：

[ASP.NET]監控ASP.NET執行緒(w3wp)狀態

但這樣的解法畢竟並非正規解法，一直希望ASP.NET能推出一個完整的解決方案，而Auto-Start這個功能可以幫助我們在站台啟動時預先執行一些處哩，減少第一次使用等候的時間，此功能雖然沒達到治本的需求，但起碼也能治標了，細節的話這邊講的比我清楚，可以參考一下：Application Warm-Up

我們可以透過在applicationHost.config中設定以下內容讓特定的Pool永遠在暖機狀態：
<applicationPools>
    <add name="MyApplicationPool" startMode="AlwaysRunning" />
</applicationPools>

不過有個很遺憾的點，那就是這個功能竟然只支援以下環境，真是讓人心碎阿：ASP.NET 4 runs on IIS 7.5 on Windows Server 2008 R2

Permanently Redirecting a Page

Response.Redirect會造成HTTP 302的狀態碼(temporary redirect)，而4.0的RedirectPermanent則提供了HTTP 301(permanent redirect)，兩個代碼間的差異可以參考保哥的：

網頁開發人員應了解的 HTTP 狀態碼

The Incredible Shrinking Session State

前面有提到，ASP.NET的 Session提供了數種的儲存模式，其中的SQLServer與StateServer是分別將Session放到資料庫與Web farm中，而這兩種儲存方式其實是透過序列化的方式進行資料傳輸，這樣的傳輸最大的缺點就是效率會比InProc慢一些，特別是若在Session中放了太大的資料量時，而4.0針對這樣的提供了Session壓縮的功能，主要是透過System.IO.Compression.GZipStream這個namespace來處理，只要在web.config中設定compressionEnabled即可：


<sessionState
    mode="SqlServer"
    sqlConnectionString="data source=dbserver;Initial Catalog=aspnetstate"
    allowCustomSqlDatabase="true"
    compressionEnabled="true"
/>

Expanding the Range of Allowable URLs

ASP.NET的網址過去受到NTFS檔案系統的限制，URL的長度最多只能有260位元，QueryString的長度雖與NTFS無關，但也有2048位元的長度限制，相關資訊可以參考保哥的資料：

Windows / .NET / ASP.NET 的路徑、檔名長度限制

但在4.0我們可以透過config來修改這個設定，分別透過maxRequestPathLength與maxQueryStringLength屬性：
<httpRuntime maxRequestPathLength="260" maxQueryStringLength="2048" />
除此之外，另一個小功能就是可以設定哪些字元不能出現在URL中，可以減少一些安全性的問題：
<httpRuntime requestPathInvalidChars="&lt;,&gt;,*,%,&amp;,:,\"  />

Extensible Request Validation

ASP.NET的request validation主要是用來防堵XSS攻擊，然而XSS的攻擊手法非常多光靠ASP.NET內建的機制可能無法全部都檔到，若我們身處的環境比較複雜，我們可以透過自訂request validation logic來達到檢查每個request的效果，我們可以new一個class繼承自System.Web.Util.RequestValidator：
public class CustomRequestValidation : RequestValidator
{
  protected override bool IsValidRequestString(
        HttpContext context, string value, 
        RequestValidationSource requestValidationSource, 
            string collectionKey, 
        out int validationFailureIndex)
   {...}
}
並在web.config中設定：
<httpRuntime requestValidationType="Samples.MyValidator, Samples" />
往後此站台的request都將透過我們撰寫的邏輯進行檢查了。

Object Caching and Object Caching Extensibility

因為Cache的功能是位於System.Web.dll這個dll中，過去若Winform或者WPF的應用程式想要使用到Cache的功能，就必須要參考System.Web.dll這個dll，在4.0之後，微軟將Cache的功能獨立到另一個dll中-System.Runtime.Caching.dll。

Extensible HTML, URL, and HTTP Header Encoding

在4.0，我們可以針對以下幾個文字內容進行自定編碼：HTML、URL、HTML attribute、HTTP headers，做法上我們要繼承System.Web.Util.HttpEncoder來時做我們所要的客製的encoding邏輯，並在web.config中設定：
<httpRuntime encoderType="Samples.MyCustomEncoder, Samples"  />
如此一來當我們在程式中呼叫System.Web.HttpUtility或System.Web.HttpServerUtility裡頭的public方法時，會自動以我們自定義的encoding邏輯進行編碼。

Performance Monitoring for Individual Applications in a Single Worker Process

主要是用在多個站台共用同一個Application Pool的狀況下，系統管理員不容易分辨哪個站台發生了問題(分開Pool不就好了？)，而這個功能可以讓我們透過設定去監控Pool的執行狀況，只要在aspnet.config中設定以下內容即可：
<?xml version="1.0" encoding="UTF-8" ?>
<configuration>
  <runtime>
    <appDomainResourceMonitoring enabled="true"/>
  </runtime>
</configuration>
目前不知道這個功能與以前的Health Monitor有多大差別。

Multi-Targeting

可以在編譯時期指定要編譯的.net版本，只要設定以下屬性，則編譯時會以.net 4.0的編譯器進行編譯：
<compilation targetFramework="4.0"/>
而這個設定有幾個點要特別留意：

1.在4.0的Pool中，預設是以framework 4.0來編譯

2.若web.config中同時包含了system.codeDom定義，在設定時需要額外留意(還沒研究)

3.若我們透過aspnet_compiler進行precompile，則必須要注意Command line中指定的編譯器版本要與targetFramework一致

游舒帆 (gipi)

探索原力Co-founder，曾任TutorABC協理與鼎新電腦總監，並曾獲選兩屆微軟最有價值專家 ( MVP )，離開職場後創辦探索原力，致力於協助青少年培養面對未來的能力。認為教育與組織育才其實息息相關，都是在為未來儲備能量，2018年起成立為期一年的專題課程《職涯躍升的關鍵24堂課》，為培養台灣未來的領袖而努力。

回首頁