@ITで興味深い記事を見つけました。
ASP.NETで使える、チャート描画コントロールです。

新しいASP.NETのチャート・コントロール：<asp:chart runat="server"/>

　Microsoftは素晴らしくて新しいASP.NET用のサーバ・コントロール － <asp:chart /> － を先日リリースしました。これは無償で、ASP.NET 3.5上で使用でき、ブラウザでリッチなチャートを利用可能にします。

• 無償のMicrosoft Chart Controlsをダウンロード
• Chart Controls用のVisual Studio 2008 Tool Supportをダウンロード
• Microsoft Chart Controlsサンプルをダウンロード
• Microsoft Chart Controlsのドキュメントをダウンロード
• Microsoft Chart Controlフォーラムへ

　インストールすると、<asp:chart />コントロールはツールボックスの“データ”タブの下に表示され、標準のサーバ・コントロールとして、すべてのASP.NETページ上で簡単に宣言できます。

略

　<asp:chart />はリッチなチャート － 円グラフ、エリア・グラフ、範囲グラフ、点グラフ、円状グラフ、積層型グラフ、データ分布図、AJAX対応グラフ、ドーナツ・グラフなど － を各種サポートしています。コントロールの宣言内で静的にチャートのデータを宣言することも、動的にそれをデータバインドしてひも付けることもできます。実行時には、サーバ・コントロールは画像を生成し（例えば.PNGファイルなど）、それは、<asp:chart />コントロールから出力される<img/>要素を使用して、クライアントのHTMLページから参照されます。サーバ・コントロールはチャート画像をキャッシュするか、またはそれを永続的にディスクに保存する機能をサポートしています。ほかのサーバ・ソフトウェアをインストールする必要はなく、標準のASP.NETで動作します。

　<asp:chart />の使用方法を理解するために、Microsoft Chart Controls サンプル・プロジェクトのダウンロードをお勧めします。これにはローカルで実行可能な200を超えるASP.NETのサンプル・ページが含まれています。実際の動きを確認するにはVS 2008でWebプロジェクトを開いて起動するだけです。そして、それぞれの.aspxソースを開けば実装方法が確認できます。

動作サンプルを見てみると、実に美しく表示されています。
ローソクチャートやボリンジャーバンドなんかも簡単に書けるようで、チャートコントロールとしては非常に多機能・高性能に見えます。
これが無償で使えるのですが、１０万円程度でも結構売れそうな気がします。

MVCに対応した「ASP.NET 3.5 Extensions Preview版」リリース

　Microsoftは9日、「ASP.NET 3.5 Extensions」のPreview版を公開した。Microsoftダウンロードセンターより入手できる。

　ASP.NET 3.5 Extensionsは、2008年公開予定のASP.NET 3.5・ADO.NETに組み込まれる。ASP.NET 3.5は、MVCによる開発スタイルを初めて採用、Web開発者にとってなじみのあるアプリケーション開発が行えるようになっている。

　その他、今回のプレビュー版にはASP.NET Dynamic Data機能、ブラウザの「戻る」ボタンをサポートしたASP.NET AJAX、ADO.NET Entity Framework、ADO.NET Data Services、Silverlight Controls for ASP.NETなどの機能が盛り込まれており、正式版公開前に評価できるようになっている。

とのこと。
正直なところ、ASP.NET開発において、MVCモデルが有効とは思えないのですが、その他の機能で使えそうなものもあり、今後の動きに注目したいところです。

ソースファイル一式

Higtyさんのオリジナル版はこちらから
[CodeZine]ASP.NETのセッションをタイプセーフに取り扱うクラスの作成
[ひぐたぅん]ASP.NETのセッションをタイプセーフに取り扱うクラスの作成

GW前に出来ていたのですが、アップロードを忘れていました（汗）

オリジナル版と比べて、抽象化しまくっているので構造は複雑になっていると思います。
中級者以上向けでお願いします。
あと、弁慶Frameworkに組み込むことを前提に作っていますので、namespaceは変わっています。
オリジナル版と比較される時は、そのあたりに注意してください。

実際に作ってみて、オリジナル版のシンプルさと使いやすさのバランスの良さを感じました。
弁慶Frameworkに入れるためとはいえ、ちょっといじりすぎたかもしれません。
ほとんどの場合は、オリジナル版の方が使いやすいんじゃないかと思います。

以下、説明

まず、Castクラスですが、オーバーロードを１つ増やしています。
で、オーバーロードしたメソッドを呼ぶようにしたことで、重複したコードが無いようにしました。
速度を重視すると重複して書いた方がいい訳ですが、弁慶Frameworkは速度をあまり重視していないので。
で、オブジェクトの型変換は、オリジナル版ではToStringでしたが、これだとDouble型のときに丸められてしまうため、普通(?)に型変換することにしました。
型変換に失敗すると、当然の事ながらExceptionが出ますので、呼び出し元で処理してください。
Exceptionを呼び出し元に任せるのも、弁慶Franeworkの考え方に合わせました。

肝心なSession操作ですが、機能と実装を分けています。
何故か？というと、NUnit等を使用するときSession操作が出来ないので、一時的にHashTableを使用するようにするためです。（というか、このためだけに面倒くさくなりました）
機能と実装を分けたことで、一時的に実装部分を差し替えるという訳です。
この差し替えサンプルについては、NUnitのテストクラス（SessionValueTest）を見てください。

Form、QueryStringも大体同じです。
ViewState、Cockieは、あえて操作クラスを作る必要性が無いような気がしたので、今回は作ってません。

セッションを扱うクラスまで、とりあえず完成しました。
あとは、Coockie、QueryString、ViewState用クラスを作ったところで、アップしようと思います。
公開後、特に問題も無いようでしたら、弁慶フレームワークに入れたいなと企んでいたり。

緊張性頭痛が再発してしまったので、ペース落ち気味です。
期待してらっしゃる方がいたら申し訳ありませんが、もう少しお待ちくださいませ。

CodeZineでCool!なエントリを見つけたのでご紹介したいと思います。

[CodeZine]ASP.NETのセッションをタイプセーフに取り扱うクラスの作成
[ひぐたぅん]ASP.NETのセッションをタイプセーフに取り扱うクラスの作成

Sessionを操作するのはHashtableのようにキーを与えてobjectで取得し、型変換処理を行う訳ですが、この方法を使うとインテリセンスが効いてくれるので、大変使いやすくなります。
ラッパークラスで吸収する形なので初心者にも分かりやすいのが素晴らしいと思います。

実は、私も同じようなクラスを作ろうと思っていたところだったのですが、いいラッピングの仕方が思いつかず今に至っておりました。
著者のHigtyさんの許可が頂けたらですが、私のやりたいことを組み合わせたカスタムバージョンを公開したいなあと思いました。

やりたいこと
・staticメソッドではなくて、クラス自体をSingletonにする
・Session、QueryString、Cookie、ViewStateのBaseクラスを作成し、サブクラスはプロパティのみの実装とする
　Sessionをひとまとめではなく、なんらかのグループで纏めたい場合もあるので、サブクラスできるのは便利だと思う
・機能と実装を分離する形で、実際のデータ取得をするクラスに委譲するようにBaseクラスを実装する
　データ取得クラスは実行時に入れ替え可能にする。そうすることでNUnit等からSessionクラスを仮想操作できる
　仮想操作用としては、Hashtableでも使えばよいと思う。

と、いったところでしょうか。
頭の中ではもうできていたりします。

ReadOnlyなので入力はできませんが、JavaScriptで値を変えることはできる訳で、ちょっとハマりました。
PostBackすると、どうやら初期値に戻ってしまうみたい。

解決するには、デザイン時にReadOnly属性をfalseにしておいて、実行時のPage_Loadあたりで

TextBox1.Attributes.Add("readOnly", "readOnly");

をしてあげれば、無事に値が残っています。
なんか、ASP.NETのバグな予感。

ある理由から、意味の分からないソースコード（C#）を読んでいます。
資料はそれなりに揃っているものの、ソースコード上にコメントがほとんど無く、資料と整合性が合っていない場合、なぜ違うのかが全く分からないんですよね。
かなり苦戦している訳ですが、せっかくなので、なぜ読みにくいコードになっているか考えてみようと思います。

簡単に思いつくあたりでは、
・コメントが圧倒的に足りない。というか必要なところになく、役に立たないコメントだけ存在。
・「とりあえず動けばいいや」的な場当たりな作り方。
・間違った共通化。共通ロジックの呼び出し方が暗号みたいな作りになっていた。

と、こういうのは大体どこにでも存在するコード（泣）で、どちからというとマナーみたいなもんなんですが、果たしてこれが解決すると読みやすいか？というと、そうでもない気がしてきました。
根本的な問題があるのはプログラムの構造で、モジュール分割や機能と実装の分離が正しく行われていないことが原因だと思います。

特に重要だと思うのが、機能と実装の分離です。
例えば、機能説明に「検索ボタン押下時に受注情報を取得する」と書いてあるのに、その処理を示すメソッドが「SelectOrder」となっていたとします。
これは最終的な結果から見ると正しい動作になっていますが、構造では欠陥があります。
つまり、「受注情報を取得する」をしたいときに、何故「SelectOrder」なのか関連性が不明だからなんです。
（この例は単純な例なので容易に想像できちゃいますが．．．）

検索ボタン押下→SelectOrder

ではありません。
この場合は、

検索ボタン押下→Get受注情報→SelectOrder

とすべきです。
なぜなら、機能説明に忠実に作成するなら、検索ボタン押下に要求される機能は「受注情報を取得する」ことだからです。
そして、「受注情報を取得する」ための実装として「SelectOrder」が呼ばれます。
このように、機能と実装を分離すると、もし実装が変わっても（例えばデータベースが変わるとか）、ボタン押下イベント側には影響が出ません。
また逆に、ボタン押下イベント側から利用する際にも、どんな実装をしているかを気にせずに呼び出すことができるようになります。

さらに付け加えると、ボタン押下イベント側から呼ばれるメソッドは、機能を表す名前をつけることが望ましいです。
なので、この例でも「受注情報を取得する」のような機能の場合、動詞を前に出して「Get受注情報」としています。

他に気をつけるべき点として、メソッドを単一機能に限定することが挙げられると思います。
つまり、メソッドの説明をするときに「このメソッドは○○と××をします」のようになってしまうのは問題があります。
正しくは、「○○をする」メソッドと、「××をする」メソッドの２つのメソッドに分割することです。
そうすることにより２つの機能が独立するため、単純な構造になります。

実はこういう事を言うと、「こんなことをしたら、クラスやメソッドがいっぱい増えて、処理が遅くなってしまう」と反論する人がいます。
これはある意味では正しいと言え、実際にクラスやメソッドが増えるし、処理も遅くなります。
しかし、オブジェクト指向言語を選択した時点で、パフォーマンスが最重要課題でない（最重要課題ならC等を選びましょう）ため、例えば0.01秒掛かっていたのが0.02秒になったとしても、実際にほとんど影響が無いと言えます。（それでも早くしたいなら、性能の良い動作環境を買ってもらいましょう）

確かにわずかながらデメリットはありますが、システムの将来を考えると、より可読性の高いコードを生産する方が価値が大きいのではないでしょうか。

VSUGアカデミースペシャル 「ASP.NET AJAX 1.0 登場」

職場の仲間と一緒に参加してみました。
「ASP.NET AJAX」については、「Atlas」とコードネームで呼ばれていた頃から注目していて、実際に業務に使ったりしていたわけで、使い方なんかは大体理解していたつもりだったんですが．．．

「ASP.NET AJAX」は、今後のASP.NET開発を変えるであろうことは予想していたものの、コードを書く量が本当に必要最小限に抑えられている点が素晴らしいと思う。
AJAXというより、面倒くさかったJavaScriptを使った開発がより楽になるなあと実感できました。

実際にマイクロソフトの方がサンプルコードを作成していくデモンストレーションは、なかなか見ごたえがありました。こんな使い方もできるのかあと。
あとは、入力スピードがさすがに速いなあと思いました。インテリセンスを上手に使っているからなんですが、こういうのも生産性に絡んでくるんだなあ、などと考えてみたり。

ファーストサーバ

ファーストサーバでASP.NETが使用可能なレンタルサーバがあります。
無料で使えるプランもありますが、難点なのは３ヶ月しか使用できないこと。
３ヶ月ごとに再取得ってのはアリなのかは分かりませんが、ちょっと試してみたいときは便利かも。

[HOWTO] Internet Explorer でキャッシュを無効にする

制約の多いWEBアプリを作っていると、結構必要になりますね。
サンプルはASPですが、ASP.NETでも同様のことが簡単にできます。

ASPの場合は、特定の Active Server Pages (ASP) ページの一番最初に次のスクリプトを使用することで、非常に動的なページを簡単にマークすることができます。
<% Response.CacheControl = "no-cache" %>
<% Response.AddHeader "Pragma", "no-cache" %>
<% Response.Expires = -1 %>

[BUG] ラジオボタンを Repeater サーバー コントロールで使用すると同時に選択可能となる

要するに、GridViewとかDataGridなどで、ItemTemplateの中にRadioButtonを入れると全然排他されなくなってしまい、全部チェックできてしまうという不具合です。
原因は単純な理由で、Repeater の場合、IDが変わってしまうため。
しかも、GroupName までも変わってしまうため、手の施しようがありません。
MicroSoftもこれを不具合と認識しているとのことですが、2002年から何も修正されていないんですよねえ．．．

解決策は2つ
・諦めて、他の方法で実装する
・自分でコントロールを拡張する
なんじゃないかなと思います。

ASP.NET2.0からGridViewが追加されているので、DataGridからの置き換えをしているのですが．．．

現行プログラムをGridViewに置き換えると、BRタグなどのタグがそのまま表示されたりします。
というか、問題があるとするならば現行プログラムの方で、タグがそのまま表示されるってことはクロスサイトスクリプティングの脆弱性があるってことなので、GridViewが正しいのは間違いないんですが。

しかしながら、当面の問題として現行プログラムを移行しなければいけない訳で、ほうっておく訳にもいかないので調査してみました。
結果から言えば、BoundFieldを使用せずに、TemplateFieldを使用してItemTemplateの中で <%# DataBinder.Eval(Container.DataItem, "フィールド名") %> をするだけでタグが有効になりましたが。

クロスサイトスクリプティングみたいな基本的な脆弱性が残っているプログラムって、意外と多いなあと思う今日この頃。