ASP.net　でセッションが切れる時

ASP.netではデフォルトで扱うとちょっとした事でセッションが切れて、ブラウザに保持していた値など情報が消滅してしまう。

どのような行為でセッションが切れるかとなると、以下のサイトに記述があった。
↓[参照：[ASP.NET] セッションのモード設定は「InProc」で良いのか？]
http://www.ilovex.co.jp/Division/SRD/archives/2007/07/aspnet_inproc.html
まとめると
・大量のファイルが更新された場合
・仮想ディレクトリの接続パスが変更された場合
・web.configファイルが変更された場合（※前述）
・global.asaxファイルが変更された場合
・binディレクトリ内のファイルが変更された場合
との事。

binディレクトリ以下に随時更新するiniファイルを作ったためにトラブルが発生したという事例もある。
その教訓には「binフォルダには触れるな！」とある事からbinフォルダ内のファイルに関しては本番オープン後に絶対に更新しないファイルを置く必要がある。
[参照：http://playtoto.blog55.fc2.com/blog-entry-165.html]


「[ASP.NET] セッションのモード設定は「InProc」で良いのか？]」の中では
「基本的には、「InProc」ではなく、「StateServer」や「SqlServer」へモード設定をしておくのが正しい対応策でしょう。
これらの設定であれば、アプリケーションのリスタート、プロセスリサイクリングによっても、
セッション情報が失われることはありません」。
とある。

しかし、「StateServer」や「SqlServer」モードというのは「InProc」よりも低速、かつ内容がよくわからないので、今後も検証の必要があるだろう。

クエリストリングから取得した日本語が文字化けする。

Dim member_fname As String = Request.QueryString("member_fname") 'お客様情報：名前氏
↑のようにRequest.QueryStringで漢字やひらがなを取得すると文字化けする。

■原因
デフォルトではUTF-8に対応しているため。

■対応
クエリストリングで取得した文字列の文字化けを回避するために以下のコードをweb.configに加える

例)




■備考
※※既にサイトを作りこんでおり、上記の対応を行う事で他に不具合が発生するばあいは、この対応をやめて、クエリストリングで取得するパラメタをURLエンコードしたもので送信してもらう。

そして受信するときにURLデコードを行なう。
例）URLデコードのRequest.QueryString
Dim member_fname As String = HttpUtility.UrlDecode(Request.QueryString("member_fname")) 'お客様情報：名前氏

.netによる日付の計算

★netで日付の加減算を行なうサンプル

・日付加減算
Dim datSetDate As Date

・一月前
datSetDate = Now.AddMonths(-1)
・3日後
datSetDate = Now.AddDays(3)
・3時間前
datSetDate = Now.AddHours(-3)

・二つの日付から日数を計算。(DATE2 - DATE1 = ？日)
Private decDAY As Decimal
decDAY = DateDiff(DateInterval.Day, DATE1, DATE2)


・参考
http://go2vb.cocolog-nifty.com/blog/2007/04/post_8728.html

エラー：このページの状態情報は無効です。壊れている可能性があります。

■事象
ASP.netでビルドし、ボタン等のイベントを実行すると
「このページの状態情報は無効です。壊れている可能性があります。」
というエラーメッセージが表示される。


■原因
.aspxファイル内の以下のタグが原因であった。
<div>
<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/wEPDwULLTIwNzk2NjI1ODQPZBYCAgMPZBYCAgUPZBYCAgEPFgIeB1Zpc2libGVnZBgBBR5fX0NvbnRyb2xzUmVxdWlyZVBvc3RCYWNrS2V5X18WAgUTdXNlcmxvZ2luMzEkY2hrc2F2ZQUTdXNlcmxvZ2luMzEkQnV0dG9uMUGJYuas7VbnHwvL9QP/YFmnG06m" />
</div>

<div>
<input type="hidden" name="__EVENTVALIDATION" id="__EVENTVALIDATION" value="/wEWBQK5pe/FBQK4ysvfDwKK8sjdCQLvzN7iAgKnjajgDGJrtd1jyU1LfOSAz3GheRiWonce" />
</div>

■対応
これらのタグはASP.netが自動的に生成するものなので、デザイン上に不要である。

デザイナーが他の.netのサイトからデザインをパクッたらしく、この不要タグが入っていたことがそもそもの原因。
これらを削除する。

ASP.netでクッキー(cookies)を使う時の注意

ASP.netはクッキーにセッション情報を渡しているが、レガシーASP同様に「Response.Cookies」や「Request.Cookies」の通常のクッキーも使えます。

しかしローカルでビルドし検証した時は異常がないが、IISに上げるとクッキーが文字化けする現象が発生します。


その原因はIIS上でUTF-8として扱われるため送信時との文字コードの違いにより文字化けが発生します。クッキーの書き込みと受信のサンプルを以下に記載。

以下のサンプルはASP.netのテキストボックス「txtUserName」の値をクッキーへの書き込みとクッキーから受信した値を「txtUserName」へ入れる。

▼書き込み
'※変数など書き込む値をServer.UrlEncode() で囲む
Response.Cookies("userName").Value = Server.UrlEncode(txtUserName.Text.Trim())

▼受信
'※変数を作成し、デコードして書き込む。書き込むまえにNothingの判定が必要。
Dim ck_username As String = String.Empty
If Not (Request.Cookies("userName") Is Nothing) Then
ck_username = Trim(Server.UrlDecode(Request.Cookies("userName").Value.ToString))
　 If Not ck_username.ToString = String.Empty Then
　txtUserName.Text = ck_username.ToString
End If
End If

画面遷移：Response.Redirect と Server.Transfer の違いは？

画面遷移時のコントロールにResponse.Redirect と Server.Transferの２種類を使用している。

この２つの違いは何のか？


以下のサイトを参照
10 行でズバリ !! Web アプリケーションの画面遷移

この最後に書いているが、

                                                                                                • -

メニュー画面からの単純な分岐を行う画面遷移であれば、HyperLink などのリンクを使うのが簡単です。画面遷移前に、ポストデータの検証を行うのであれば、Response.Redirect が適当です。


しかし、これら 2 つは、遷移前の Page オブジェクトを参照できないので、遷移前の Page オブジェクトから複雑なデータを受け取るのであれば、Server.Transfer を使う方法が考えられます。ただし、ブラウザによっては、[戻る] ボタンを押してしまった場合、誤動作する可能性があります。ユーザーが本来はどの画面まで進んだか、画面遷移を追跡する仕組み (ワークフローの進捗を追跡する仕組み)が、サーバー側に必要になるでしょう。(もっとも、信頼性ある本格的なアプリケーションならば、どの画面遷移方法を問わず、サーバー側でどこまでワークフローが進んだか、追跡する仕組みは必要ですが。) もちろん、Server.Transfer でも、遷移前のアドレスにポストするので、遷移前に値の検証ができます。
さらに、ASP.NET 2.0 では、遷移先に直接ポストする仕組みが登場しました。この方法も、遷移前の Page オブジェクトを参照できます。1 つのページが複数の論理的なフォームに分割されていたとき、フォームごとにポスト先を変えたいときなどに便利です。それぞれの特色を踏まえた上で適切な使い分けをご検討ください。

                                                                                                                          • -

→との事で、特に必要がなければ画面遷移がそのままURLと直結している Response.Redirect でいいのではないかと思う。