WebSurfer's Home

トップ > Blog 1   |   ログイン
APMLフィルター

ASP.NET 4.5 ScriptManager

by WebSurfer 2018年4月23日 16:47

ASP.NET 4.5 以降での話ですが、クライアントスクリプトを利用するサーバーコントロールが正しく機能するには、必要なクライアントスクリプトの ScriptManager への登録と、全ページでの ScriptManager の配置が必要という話を書きます。

RequiredFieldValidator

元の話は MSDN Forum のスレッド「検証コントロール + マスターページ in WebサイトのWebアプリケーション」です。

MSDN Forum の話は検証コントロールによるクライアント側での検証が働かなかったということですが、ScriptManager を正しく使わないと、多分それ以外(ASP.NET AJAX Extensions など)にも影響があると思われます。

ASP.NET 4.5 では、Microsoft Ajax と WebForms 用のスクリプトファイルはアプリケーションの Scripts フォルダに格納し、そこから ScriptManager を介してダウンロードできるように改善されたそうです。(旧来は WebResource.axd, ScriptResource.axd というハンドラを使ってサーバーコントロールのリソースからダウンロードしていました)

さらに、jQuery, Bootstrap 等のスクリプトも、Microsoft Ajax と WebForms 用のスクリプトに加えて、ScriptManager で統合できるようになりました。

そのあたりの詳しい話は MSDN Blog の記事 ASP.NET 4.5 ScriptManager Improvements in WebForms に書いてありますので一読されると良いと思います。

Visual Studio Commnunity 2015 のテンプレートを利用して ASP.NET Web フォームアプリケーションを作成すると、以下のスクリプト関係の NuGet パッケージが自動的にプロジェクトにインストールされ、App_Start/BundleConfig.cs にバンドル定義のコード、Global.asax の Application_Start メソッドにバンドル定義を登録するためのコードが自動生成されます。

NuGet パッケージ

そして、マスターページ Site.Master に ScriptManager が配置され、必要なスクリプト参照が登録されます。Visual Studio Community 2015 の場合は以下の通りとなります。

<asp:ScriptManager runat="server">
  <Scripts>
    <asp:ScriptReference Name="MsAjaxBundle" />
    <asp:ScriptReference Name="jquery" />
    <asp:ScriptReference Name="bootstrap" />
    <asp:ScriptReference Name="respond" />
    <asp:ScriptReference Name="WebForms.js" 
        Assembly="System.Web" 
        Path="~/Scripts/WebForms/WebForms.js" />
    <asp:ScriptReference Name="WebUIValidation.js" 
        Assembly="System.Web" 
        Path="~/Scripts/WebForms/WebUIValidation.js" />
    <asp:ScriptReference Name="MenuStandards.js" 
        Assembly="System.Web" 
        Path="~/Scripts/WebForms/MenuStandards.js" />
    <asp:ScriptReference Name="GridView.js" 
        Assembly="System.Web" 
        Path="~/Scripts/WebForms/GridView.js" />
    <asp:ScriptReference Name="DetailsView.js" 
        Assembly="System.Web" 
        Path="~/Scripts/WebForms/DetailsView.js" />
    <asp:ScriptReference Name="TreeView.js" 
        Assembly="System.Web" 
        Path="~/Scripts/WebForms/TreeView.js" />
    <asp:ScriptReference Name="WebParts.js" 
        Assembly="System.Web" 
        Path="~/Scripts/WebForms/WebParts.js" />
    <asp:ScriptReference Name="Focus.js" 
        Assembly="System.Web" 
        Path="~/Scripts/WebForms/Focus.js" />
    <asp:ScriptReference Name="WebFormsBundle" />
  </Scripts>
</asp:ScriptManager>

この ScriptManager の新機能には重複排除の機能も含まれているようで、例えば検証コントロールを使っても、旧来だったら自動生成される WebResource.axd ハンドラを使うコードは生成されません。

テンプレートでアプリケーションを作ったら、必ず上記の <Scripts> ~ </Scripts> の間のコードを含めた ScriptManager が全ページに配置されるようにするのが正解と思われます。

単に <asp:ScriptManager runat="server"></asp:ScriptManager> としたら、検証コントロールを配置してもクライアント側での検証が動かなかったというのが上に紹介した MSDN Forum の話でした。

なお、テンプレートの選択で「Web フォーム」ではなく「空」を選んだ場合はスクリプトの設定は一切されず、例えばその状態で検証コントロールを使うと、以下のようなサーバーエラーとなります。

"WebForms UnobtrusiveValidationMode には、'jquery' の ScriptResourceMapping が必要です。jquery (大文字と小文字が区別されます) という名前の ScriptResourceMapping を追加してください。"

ASP.NET 4.5 で利用可能になった控えめな JavaScript による検証を止めて旧来のものに戻すとか(web.config の appSettings で設定可能)、クライアント側での検証を無効にすればエラーは回避できますが、それは望ましい解決法ではないので、エラーメッセージに従って対処した方がよさそうです。

また、検証コントロール以外にも、クライアントスクリプトを利用するサーバーコントロール(UpdatePanel とか)を使うと、必要なスクリプトがダウンロードされず期待通り動かないという問題が出そうな気がします。

なので、テンプレートで「空」を選択した場合は、最低でも jQuery, MSAjax, WebForms の 3 つの NuGet パッケージはインストールして、ScriptManager に登録し、全てのページに ScriptManager を配置するのがよさそうです。

その手順は別の記事「ASP.NET 4.5 スクリプトリソースマッピング」に書きましたので、興味があれば見てください。

Tags: ,

ASP.NET

型付 DataSet の名前に注意

by WebSurfer 2018年4月9日 14:33

Visual Stidio のデータソース構成ウィザードを使って型付 DataSet を生成するとき、その名前を DataSet とすると、System.Data.DataSet と名前が衝突して問題を起こすので要注意という話を書きます。

型付 DataSet の作成

上の画像は、ウィザードで型付 DataSet(.xsd ファイル)を生成しようとしているところですが、ファイル名がデフォルトで DataSet.xsd となるのが諸悪の根源(?)です。

デフォルトの名前が DataSet.xsd のなるのは、自分が調べた限りでは、Visual Studio Cummunity 2015 で、ASP.NET Web Forms アプリケーションを Web サイトプロジェクトとして作り、その App_Code フォルダに .xsd ファイルを生成する場合だけでした。(それ以外ではデフォルトの名前は DataSet1.xsd となります)

なので余計に気づき難いと思います。もちろんコンパイルエラーは出ませんし。

具体的にどういうことになるかと言うと、以下の通りです。

ファイル名を DataSet.xsd とすると、それから生成される型付 DataSet の名前も以下の通り DataSet となります。

/// <summary>
///Represents a strongly typed in-memory cache of data.
///</summary>
 [global::System.Serializable()]
// ・・・中略・・・
public partial class DataSet : global::System.Data.DataSet {
        
    private ProductsDataTable tableProducts;

    // ・・・中略・・・
}

そうなると、単に DataSet と宣言しただけでは型付 DataSet に定義された DataSet と見なされます。using 句に System.Data を設定しても同じです。

下の画像を見てください。上の型付 DataSet のコードの summary に設定された "Represents a strongly typed in-memory cache of data." がイン���リセンスで表示されています。

インテリセンスの表示

この状態で System.Data.DataSet を使うには、上の画像の一番下の行に書いたようにしなければなりません。

自分のケースでは、上の ds を ds.ReadXml(xmlTextReader); というように使ったのですが、ds にデータを取得できない(エラーも出ない)というトラブルにハマって 1 ~ 2 時間悩みました。

今時こんなトラブルにハマるのは自分だけかもしれませんが、一応備忘録として残しておくことにします。(笑)

Tags:

.NET Framework

SessionStateModule によるロック

by WebSurfer 2018年4月6日 18:21

ASP.NET Web アプリで Session を利用する場合、同一ユーザー(= SessionID が同じユーザー)が同時にアクセスすると、最初の要求に受けた時点で Session へのアクセスがロックされるので、最初の要求に対する応答が返されるまで次の要求は待たされるという話を書きます。

(元の話は MSDN フォーラムのスレッド「非同期ポストバック中のキャンセルとその後のポストバックについて」です)

非同期ポストバック中のキャンセル

SessionStateModule によるロックメカニズムはマイクロソフト公式解説書「プログラミング Microsoft ASP.NET 4」という本の 17.2.1 章「セッション状態 HTTP モジュール」の「セッション状態へのアクセスの同期」というセクションに詳しく書いてあります。その一部を抜粋すると:

"セッション状態モジュールはリーダー / ライター方式のロックメカニズムを実装し、状態値へのアクセスをキューで管理します。セッション状態への書き込みアクセスを許可されたページは、リクエストの処理が終了するまで、そのセッションのライターロックを保持します。 ・・・(中略)・・・ セッション状態への読み取りアクセスを許可されたページは、リクエストの処理が終了するまでセッションのリーダーロックを保持します"

上記の通り、Session を使うケースでは、応答が返されるまで Session へのアクセスはロックされ、その間次の要求は処理されないのですが、普通に同期ポストバックを行っている限り、それにユーザーが気が付くことはなさそうです。

ところが、ScriptManager + UpdataPanel を利用して非同期ポストバックで要求を出すようにし、それにキャンセル機能を実装した場合は話が違ってきます。

ユーザーが、処理に長い時間がかかる「要求 A」を出したが、応答が返ってくるのを待ちきれないので、一旦その要求をキャンセルして、処理に時間のかからない(=すぐ応答が返ってくる)「要求 B」を出すというケースを考えてみてください。

ユーザーは、「要求 A」はキャンセルしたのだから、「要求 B」はすぐ処理されて応答が返ってくると期待するはずです。

ところが Session を利用しているアプリの場合はユーザーの期待通りにはなりません。「要求 A」をキャンセルする / しないにかかわらず、「要求 B」の応答が返ってくるのは、普通に「要求 A」を処理する時間だけ待たされた後になります。

ユーザーが「要求 A」をキャンセルしてもサーバー側での実行が中断されるわけではなく、サーバーは「要求 A」を処理して応答を返すところまで行うということがポイントです。

Session を利用していない場合、「要求 B」をサーバーが受けると、先に受けた「要求 A」の処理と並行して、直ちに「要求 B」の処理が始まって応答が返されます。結果、ユーザーの期待通り、処理に時間のかからない「要求 B」の応答はすぐ返ってきます。

ところが、Session を利用している場合、Session ロックによって、「要求 A」の処理が終わって応答が返されるまで、「要求 B」の処理は待たされます。結果、「要求 A」の処理のキャンセルが効いてないように見えます。

下の画像を見てください。この記事の下の方に示したサンプルコードを実行し、Fiddler で要求・応答をキャプチャしたものです。

Fiddler によるキャプチャ

実行手順は以下の通りです。

  1. [非同期]ボタンをクリックして非同期ポストバックによる「要求 A」をかける。(この記事の一番上の画像がその時のもの)
  2. [Cancel]ボタンをクリックして「要求 A」をキャンセル。
  3. [同期]ボタンをクリックして「要求 B」をかける。

上の Fiddler のキャプチャ画像で、キャンセルした上記 1 の要求もサーバー側では正しく処理され、完全な応答が返ってきているのが分かるでしょうか? (ただし、ブラウザで abort されています)

問題のページで Session に書き込んでいる場合は何ともならないですが、そうでない場合は以下の解決策で対応できるはずです。

  1. 他のページで Session を使っているが、問題のページでは使ってなければ EnableSessionState を False に設定する。
  2. 問題のページも Session を使っているが、読み取りのみの場合は EnableSessionState を ReadOnly に設定する。

なお、自分では Session は使っていないつもり(コードで明示的に Session["Data"] = xxx のようなことはしていない)でも、Global.asax に Session_Start ハンドラがあるとすべてのページで Session を使っているのと同じことになります。

Visual Studio のテンプレートを使ってプロジェクトを作ると、Global.asax に空の Session_Start ハンドラが生成されることがありますので注意してください。

最後に、この記事を書くときに検証用に使ったサンプルコードを以下に書いておきます。

<%@ Page Language="C#" EnableSessionState="ReadOnly" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<script runat="server">
    protected void Button_Click(object sender, EventArgs e)
    {
        System.Threading.Thread.Sleep(5000);
    }

    protected void Button2_Click(object sender, EventArgs e)
    {
        
    }
</script>

<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
    <title></title>
  <script type="text/javascript">
  //<![CDATA[
  var manager;

  function pageLoad(sender, args) {
    if (args.get_isPartialLoad() === false) {
      manager = Sys.WebForms.PageRequestManager.getInstance();
      manager.add_initializeRequest(OnInitializeRequest);
      manager.add_endRequest(OnEndRequest);
    }
  }

  function OnInitializeRequest(sender, args) {
    $get("<%=UpdatePanel1.ClientID%>").style.display = "none";
  }

  function OnEndRequest(sender, args) {
    $get("<%=UpdatePanel1.ClientID%>").style.display = "block";
  }

  function AbortPostBack() {
    if (manager.get_isInAsyncPostBack()) {
      manager.abortPostBack();
    }
  }
  //]]>
  </script>

    <style type="text/css">
    #UpdatePanel1 { 
      width: 200px; 
      height: 200px; 
      border: gray 2px solid;
      position: relative;
      float: left; 
      margin-left: 10px; 
      margin-top: 10px;
    }

    #UpdateProgress1 {
      width: 400px; 
      background-color: #FFC080;
      border: gray 1px solid;
      /*bottom: 0%; 
      left: 0px; 
      position: absolute;*/
    }

  </style>

</head>
<body>
    <form id="form1" runat="server">
    <asp:ScriptManager ID="ScriptManager1" runat="server">
    </asp:ScriptManager>

    <asp:Button ID="Button1" runat="server" 
        Text="非同期" OnClick="Button_Click" />  
    <asp:Button ID="Button2" runat="server" 
        Text="同期" OnClick="Button2_Click" />
    <br />
    <asp:UpdatePanel ID="UpdatePanel1" runat="server">
        <ContentTemplate>
            UpdatePanel
            <hr />            
            <%=DateTime.Now.ToString() %> <br />
            
            <br /><br />
            [非同期]ボタンをクリックすると、
            5 秒後にこのパネル内が更新されます。
            その間 UpdateProgress が表示されます。
        </ContentTemplate>
        <Triggers>
            <asp:AsyncPostBackTrigger ControlID="Button1" 
                EventName="Click">
            </asp:AsyncPostBackTrigger>
        </Triggers>
    </asp:UpdatePanel>

    <asp:UpdateProgress ID="UpdateProgress1" runat="server">
        <ProgressTemplate>
            非同期ポストバックで更新中です・・・  
            <input type="button" value="Cancel" 
                onclick="AbortPostBack()" />            
        </ProgressTemplate>
    </asp:UpdateProgress>
    </form>
</body>
</html>

Tags: ,

ASP.NET

About this blog

2010年5月にこのブログを立ち上げました。その後 ブログ2 を追加し、ここは ASP.NET 関係のトピックス、ブログ2はそれ以外のトピックスに分けました。

Calendar

<<  2018年8月  >>
2930311234
567891011
12131415161718
19202122232425
2627282930311
2345678

View posts in large calendar