ASP.NET Archive

@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秒になったとしても、実際にほとんど影響が無いと言えます。（それでも早くしたいなら、性能の良い動作環境を買ってもらいましょう）

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

ファーストサーバ

ファーストサーバで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つ
・諦めて、他の方法で実装する
・自分でコントロールを拡張する
なんじゃないかなと思います。

Continue reading

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

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

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

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

ASP.NETのデバッグ実行時に、ASP.NET開発サーバが起動するのですが、これがランダムなポートなのでいろいろと面倒な場合があります。
（例えば、WEBプロジェクトを複数のソリューションに追加すると、ソリューションごとにポートが違ったり）
ただ、ランダムに設定されるのは初回だけで、以降は同じポートを使い続けています。
ということは、ソリューションファイルかな？ということで覗いてみました。

VWDPort = "ランダムに設定されたポート番号"
と書いてあるあたりが怪しいので、早速変更してみるとビンゴ！

※ソリューションファイルをテキストエディタで変更する方法なので、自己責任で行うようにしてください。
　何か不具合がありましても責任を取りかねます。
　念のため、バックアップしておく等の措置を行った方が良いと思います。

タイトルに書いたとおり、HyperLinkFieldでJavaScriptをリンクするとリンクタグが表示されなくなってしまいます。（DataTextFieldは正しく表示されます）
恐らくはクロスサイトスクリプティング対策なんでしょうが、もう少しなんか方法があればいいんですが．．．

<asp:HyperLinkField DataNavigateUrlFields="Url" DataNavigateUrlFormatString="javascript:hoge({0})" DataTextField="Name" />

仕方がないので、TemplateFieldに置き換えたら問題なく動きましたが、やはり面倒ですね。

<asp:TemplateField>
<ItemTemplate>
    <A id="ALinkFix" runat="server" href='<%# "javascript:hoge(" + DataBinder.Eval(Container.DataItem, "Url") + ")" %>'>
    <%# DataBinder.Eval(Container.DataItem, "Name") %>
    </A>
</ItemTemplate>
</asp:TemplateField>

Button.OnClientClickプロパティを利用したJavascriptの実行

Button.OnClientClick プロパティ

この機能もASP.NET2.0で追加されたものです。
ASP.NET1.1までは、
Button.Attributes("OnClick") = "javascript:*******";
のように記述していたものが、
Button.OnClientClick = "*******";
のように短縮することができます。

例えば、
Button.OnClientClick = "return confirm('****してもよろしいですか？');";
のように書けば、確認ダイアログを表示し、OKボタンが押されたときのみ Button.OnClickイベントが実行されるようになります。

以前、SQL文を実行してSQLServer上のテーブル一覧を取得する方法を紹介しましたが、今回はスキーマコレクションから取得する方法です。

参考
SqlConnection.GetSchema メソッド
GetSchema メソッドの使用

参考の例だとSqlConnectionを使っていますが、.NET Framework version 2.0なら DbConnectionを使うこともできます。
実際に他のデータベースで試したことはないですが、テーブル情報取得のSQL文はデータベースによって大きく異なるため、結構使えるかもしれません。

マスターページの仕組みは一貫したデザインを実現したい場合、大変便利な方法ですが、コンテンツページからマスターページのデータにアクセスするのはとても面倒です。
多くの人が Master.FindControl("コントロール名")のように記述していることと思います。
この場合、コントロール名が変更になったときの修正漏れが心配になります。

ところが、@MasterTypeディレクティブを追加することで、プロパティ経由のデータアクセスが可能になります。
簡単に説明すると、コンテンツページ(*.aspx)に、<%@ MasterType virtualPath="~/MasterPage.master"%>のような１行を加えるだけです。
（MasterPage.masterの部分は各自の環境に合わせて変更してください）
あとはマスターページにプロパティを追加するだけです。

例えばLabelであれば、

public string LabelText

{

    get { return Label1.Text; }

    set { Label1.Text = value; }

}

参考
プログラムによる ASP.NET マスター ページの操作

@IT:［ASP.NET］コンテンツ・ページからマスター・ページの情報に簡単にアクセスするには？［2.0のみ、C#、VB］

アプリケーション起動中、常にファイル監視をする要件があったとします。
具体的に言うと、あるファイルを常に監視し、ファイルが変更されたときに再読み込みをする等のイベントを処理させます。
実装例としては、自前で用意した環境ファイルのデータを保持するといったようなものが考えられると思います。

ファイルの監視方法ですが、FileSystemWatcherで監視するファイルを設定し、FileSystemEventHandlerでイベントハンドリングを行えばよさそうです。
こういう仕組みが備わっているのが.NETの良さですね～

FileSystemWatcher watcher = new FileSystemWatcher(ファイルパス, ファイル名);
watcher.Changed += new FileSystemEventHandler(処理したいメソッド名);

のようにすればOKです。
常時監視ということなので、監視モジュールが常にメモリにロードされている必要があります。
常時ロードとなると、ASP.NETの場合、Application_Startに記述してしまえばいいのですが、そのロジックをWindowsアプリでも汎用的に使うことはできません。

そこで、ASP.NETでも常にメモリにロードされているということで、Singleton実装にしてみました。
Singletonのそもそもの目的は、アプリケーション内で唯一存在するオブジェクトを作成するためなのですが、唯一存在させるためにインスタンスをstaticで保持しています。
そのため、Singletonのコンストラクタで上記の監視ロジックを入れておけば、常にメモリに存在することとなり、どのプログラムを実行していてもイベントが発生します。
問題点は、Singletonなので複数のファイルを監視できないことですが、そのような場合はGetInstanceの仕組みを変えてあげることで対処できそうです。

HttpModuleでゴリゴリやってたら、HttpModule内でポストバックの判定が必要になってしまいました。
ところが、IsPostBack()メソッドってPageにしか存在しないため使えないんですね。

仕方がないので、Page.IsPostBack()と同等の機能を実装することにします。
ポストバックとそうでないときで違うところと言えばViewStateの扱いなので、このあたりを実装すると良さそうです。
サンプルコード(C#)は下記のとおりです。
「this.httpApp」の部分は、各自の環境に合わせたHttpApplicationオブジェクトを指定してください。

#region ポストバック判定処理
/// 

/// ポストバックかどうか判定する。
/// 
/// ポストバック時は true、ポストバックではないときは falseを返します。
/// 
/// HttpModule では IsPostBack を実装していないため、「__VIEWSTATE」が Request.Params に存在するかでチェックしています。
/// 
private bool IsPostBack()
{
    try
    {
        return (this.httpApp.Context.Request.Params["__VIEWSTATE"] != null);
    }
    catch
    {
        return false;
    }
}
#endregion

仕事でURLの置き換えをする必要が出てきたので、IHttpModuleを使用することにする。
受信フィルタとも呼ばれる仕組みらしいですが、メリットとしてはaspxの画面が開かれる前に呼ばれる点でしょう。
呼ばれたページが開かれた際にリダイレクトするより、ページが開かれる前にURLを書き換えてしまうほうが、よりスマートと言えるのではないでしょうか。

URLの置き換えを知るには、以下のページが参考になると思います。
ASP.NET での URL 書き換え
MSDN:特集2.NET実践プログラミング PartVII ASP.NET ISAPIとASP.NETのもとでHTTPフィルタを使ってWeb要求を横取り，監視，変更する
URL Mapping for ASP.NET 1.1
ASP.NET 2.0: Rewriting URL Paths just got a whole lot easier
ASP.NET 2.0: URL Mapping with RegEx Support

また、URLの書き換えだけでなく、HTTPモジュールについても知っておく必要があります。
HTTP モジュールの概要
方法 : カスタム HTTP モジュールを作成する
ASP.NET アプリケーションのライフ サイクルの概要
@IT:［ASP.NET］アプリケーション共通のロギングを行うには？（HTTPモジュール編）

HTTPモジュールを使うとして、問題になりそうなのが単体試験をどうやってやるかってことなんですが、
Visual C# .NET を使用して ASP.NET HTTP モジュールを作成する方法
テスト方法が載っているけど、こういう方法じゃ単体テストとは言えないですね。
NUnitAspを使う方法で考えてみようと思います。

システム内部で唯一のインスタンスがほしいときは、Singletonパターンが有効的な手段になります。
具体的な利用例としては、共通変数の管理や滅多に変更されないコードと名称の組み合わせを持っておく等が考えられると思います。

私はJavaでデザインパターンを覚えたこともあって、インスタンス取得のために GetInstance のようなメソッドを用意したいたのですが、もっと画期的な方法がありましたので紹介したいと思います。
C# でのシングルトンの実装
画期的と言っても、実装方法はほとんど変わらず、プロパティを利用しただけなのですが、コードはとてもすっきり見やすくなっています。
応用例としてマルチスレッド対応のシングルトンや静的な初期化も説明が載っています。

先日から悩んでいるJavaScript問題ですが、Literalを配置しておき、どこかしらのイベントでjavaScriptを埋め込んでやることで一応の分離は可能でした。
あとは、埋め込んでやるJavaScriptをある程度生成できるような抽象Builderクラスを作り、サブクラス化するようにすれば、それなりに再利用もできそう。
また、デバッグ実行時のみJavaScriptを返すようなサブクラスを作成してあげれば、テスト時も少しは楽になるかもしれません。
Literalの配置はマスターページで行えば、処理の手順を共通化することもできそうだ。
JavaScriptが必要ない画面であれば、そのまま放置しておいても特に問題ないし。（気分的には気持ち悪いけど）

と、このあたりまでは普通に思いつくんですが、どうにもすっきりしないんですよね。
JavaScriptを力ずくでどうにか手なずけようとしている訳だから、当たり前といえば当たり前なんですが．．．
ぐぐってみたものの、同じようなことを企んでいる人はほとんどいない状況でした。イエイ！
やっぱり、ずるい方法だよなあと思いつつ、もうどうでもよくなってきたので、このまま実装することに決定（おい）。

ASP.NETの画面を見ていると、当然のごとくJavaScriptが出てくる。
よくよく考えてみると、JavaScriptはエンジニアに嫌われる代表的な技術だと思う。
ブラウザ依存するし、デバッグは面倒くさい。
作り方によってはセキュリティに影響を与えることもある。
しかも、ブラウザの設定でオフに出来ちゃう。
でも、応答速度を求められると、これを使わざるを得ないのが現状なんですよね。

あと、とっても気になる点として、コードとビューの分離「コードビハインド」に関わる問題があります。
ASP.NETでは、JavaScriptで処理していたコードをイベント記述することで、コードとビューを分割できることを売りの一つとしています。
要は、「画面は画面、ロジックはロジック」とハッキリさせた方が分かりやすいし、メンテナンスしやすいでしょ？ってことなんだと理解してます。
従って、いくら入力チェックとはいえ、HTML（ASPやJSPも含む）上にロジックを書くってのは、ちょっと違うんじゃないかなあと思うわけです。

しかしながら、現実的に目の前に広がる世界にはJavaScriptが溢れているわけで、急に無くすと政治的な問題になりかねないので、思案のしどころです。
とりあえずの策として、WEBコントロールのAttributeにJavaScriptを突っ込む方法でいこうかと考えていますが、普通はどうやるんでしょうね？？？

謎は深まるばかり。

System.Data.Common 名前空間
ADO.NET でのプロバイダに依存しないコードの作成

これすごいです。
7/4の記事でポリモーフィズムがどうたらとか書いていたんですが、もうどうでもいいです（泣）
VisualStudio.NET 2003までは、各プロバイダ用にサブクラス化していた（さらに言うと、依存DLLの関係でプロジェクトも分けていた）んですが、もうそんな必要は無いようです。

で、早速使ってみました。
たとえば、SqlParameterなんかの場合はDbParameterなんて感じになります。
基本的にDb****という命名になるようですね。
Newする際には、ファクトリクラスを使ってCreateするだけのお手軽さでした。
デバッグ実行でブレークしたついでに、オブジェクトの状態を見てみると、ちゃんとプロバイダごとのオブジェクトが生成されてます！
速度も特に遅いと感じたこともなかったので、今後はこれがスタンダードになるのかな。

テスト用にVisualStudioの出力ウインドウにメッセージを表示させたいとき、System.Diagnostics.Debug、System.Diagnostics.TraceのWriteメソッドを使用します。

両者の違いは、それぞれDEBUGディレクティブ、TRACEディレクティブが宣言されているかどうかです。
この宣言はVisualStudio2005の場合、プロジェクトのプロパティでチェックするだけで宣言したことになります。

[HOWTO] Visual C# .NET でのトレースとデバッグの方法

O/Rマッピングを調査中です。
というか、激しく悩んでいます。

O/Rマッピングを簡単に説明すると、オブジェクトとリレーショナルデータベースを自動的にマッピングする仕組みです（簡単すぎ：汗）。
Hibernateなんかが有名なんですが、SQL文、データベース名とオブジェクト名のマッピング、テーブルのカラムとクラスのフィールドのマッピング等をXMLに定義しておくことで、自動的に変換してくれる仕組みです。

これを導入することで、オブジェクト指向とリレーショナルデータベースの思想の違い（インピーダンスミスマッチ）を解決できるし、ビジネスロジックにSQLが紛れ込むこともなくなります。
また、SQLがXMLに書かれるため、メンテナンスがし易いといったメリットもあるのです。

当然のことながら、C#でも実装できますし、オープンソースでもいくつかあります。
ところが、.NETではDataSetというのがあって、これを使うことでデータグリッド等の表示が簡単に行えるので、わざわざエンティティクラスを定義する必要があるのか微妙なところです。
というか、DataSetをエンティティクラスの代わりに使うこともできちゃいますし。（現実世界の構造とは狂うかもしれないが）
あと、DataTableを変更したときに、変更内容に応じて自動的にInsert、Update、Deleteを行ってくれる機能まであったりする。
しかも、Abstractクラスでメソッド宣言するときに、パラメータなんかとインタフェースで定義しておいて、実装はサブクラスで行うようにすれば、ADO.NETだけでなく、ODP.NETやpgsqlでも、ポリモーフィズムが実現できる。

また、SQLをXMLに書くというのも、私は大歓迎ですが、O/Rマッピングを知らないエンジニアがすんなり受け入れてくれるとも思えないんですよねえ。
とりあえず、
・SQLをXMLに書かないが、データベース層に該当するクラス内に閉じ込める
・DataSetを返す
・機能（SELECT、INSERT、UPDATE、DELETE）と実装（SQLの実行、トランザクション処理、コネクション管理）を分ける
といったあたりを念頭にコーディングしてみることとする。

構成ファイル（Web.config、App.config）の値を読み込む際に
[VB.NET - .NET2003]
myConfig = (NameValueCollection)ConfigurationSettings.AppSettings(strAddress);
myConfig = (NameValueCollection)ConfigurationSettings.GetConfig(strAddress);

こんな風に書いていた訳だが、そのままC#にコンバートしたらWarningが出た（泣）
警告'System.Configuration.ConfigurationSettings.AppSettings' は古い形式です: 'This method is obsolete, it has been replaced by System.Configuration!System.Configuration.ConfigurationManager.AppSettings'
Warningなので放置プレイでも良かったんだけど、そこはエンジニアとしてのプライドが．．．

[C# - VS2005]
myConfig = ConfigurationManager.AppSettings[strAddress];
myConfig = ConfigurationManager.GetSection[strAddress];

単純にConfigurationManagerに置き換えるだけかと思いきや、MSDNを見るとSystem.Configurationを参照に追加しないといけないみたい。
あと、GetConfigはGetSectionに。
usingはそのままでいいのに、変なの～

今月から仕事の関係でC#を勉強中。
と言っても、いきなりフレームワークの作成なんかしてたりする。

以前VB.NETをやっていたので、文法の置き換えだけですぐなじめると思っていたのだが甘かった．．．
C#に比べると、VB.NETは規則が緩いのである意味何でもできたりする。
逆にC#はいろいろな部分が厳密なため、品質の高いコードが書けそうな気がする。

また、今使っているのがVisualStudio2005なので、新たな機能も当然の事ながら追加されている。
この辺りも備忘録として残していくつもり。