独自のGuidance Packageを作る際に
一からGuidance Packageを作ろうと思い、エクスポートしたプロジェクト テンプレートをGuidance Packageのプロジェクト内に入れてRegisterしようと思ったらエラーが。
(追加したプロジェクトの.vstemplateが読めない)との内容なので、XMLをひたすら見ていたけどなんとも誤りを発見できず。既存の.vstemplateと見比べて色々と修正した結果、WizardExtension要素を足すとエラーが出なくなった。追加したWizardExtension要素はサンプルからコピーしたもの。
<WizardExtension> <Assembly>Microsoft.Practices.RecipeFramework.VisualStudio, Version=1.0.60429.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a</Assembly> <FullClassName>Microsoft.Practices.RecipeFramework.VisualStudio. Templates.UnfoldTemplate</FullClassName> </WizardExtension>
カテゴリ整理
SC-SFというカテゴリを作っていたのですが、もっと一般的にGuidance Automationにしたほうがよさそうなのでカテゴリを変更しました。
Strong Naming Guidance Package in EntLib 3.0
http://blogs.msdn.com/tomholl/archive/2006/12/28/entlib-3-0-strong-naming-guidance-package.aspx
EntLib3.0の概要を見たとき、もしくは最初にインストールしてGuidance Automation周りを見たとき、Strong Naming Guidance Packageなるものがあったのはわかったのですが、なぜこれがあるのかがわかりませんでした。
リンク先のTomのblogに書かれていた内容によると、
- かつて、ユニット テスト コードは対象のアセンブリと同アセンブリ内にあった。
- フィードバックや、VSTSの制約から、別アセンブリに移すことになった。しかし、Privateメンバは別アセンブリから参照できない。
- 別アセンブリから参照するために、InternalsVisibleTo属性をつけるとよい。
- しかし、厳密名をつけるとInternalsVisibleToにキーをつけないといけない。この手順が面倒。というのも、ビルド前にキーを付けないといけないけど、それがわかりづらい。
- で、Guidance Automation化した。
という流れのようです。
で、このGuidance Packageは2.0のソースに対しても動作するとのことです。
ObjectBuilderを外部ファイルで制御
前にOBCABでやったことと同じことではあるのですが、p&p Summitでのネタというのをichikawaさんが書いていたので諸事情あって試すことにしました。
ObjectBuilder Dependency Injection Framework
自分の個人環境はVS2005 Pro.なのですが、このサンプルはテスト プロジェクトだったため読み込めず、仕方なく新しいプロジェクトを作ってそこに個々のファイルを追加。コンパイルは通ったものの実行時エラーが出て動かない。色々試行錯誤してようやく動いたのですが、そういえばid:afukuiさんがソース内にプロジェクト名を直書きしていると言っていたのを思い出しました。
こんな人たちと話しながらサンプルを試す機会があるのはとても幸運なのかな。
もう少し動作を追ってみたいのと、まあ本来やるべきことをやるのとで年末年始はつぶれるのでしょうか。
patterns & practices Guidance Explorer
http://www.codeplex.com/guidanceExplorer
patterns & practices Guidance Explorerはp&pのガイダンスを利用する際に便利なツールです。
Web editionもあるようなので試してみました。例によってFirefoxでは動きませんでしたが。
p&pの提供するガイドやコードなどがテクノロジー(プラットフォーム)、トピック、タイプ、カテゴリ、優先度で絞り込んで検索できます。
ASP.NETでのラジオボタン コントロールの作成
開発日記に書いた内容の転記。
ASP.NETのラジオボタンをリスト データバインドする要素内のテンプレートに書くと、各要素ごとにグルーピング範囲が作成されてしまう。
アンケート項目のリストのように、この挙動がふさわしい場合もたまにはあるのだが、よくある例としてリスト展開した要素を選択するためにラジオボタンを使うという用途には対応できない。
AAA | ◎1 | ○2 | ○3 |
BBB | ○1 | ○2 | ◎3 |
CCC | ○1 | ◎2 | ○3 |
こういうやつならいいけど…
◎AAA | xxx |
○BBB | xxx |
○CCC | xxx |
こうしたいのに…
◎AAA | xxx |
○BBB | xxx |
◎CCC | xxx |
こうなってしまう。
で、Literalを使用してinputエレメントを描画するという提案をしてみたのだが、やはり相当に難しいため素人にはオススメできない。できない以上、何らかのコントロール化するのがいいのではないかと思った。やる前は、ポストバック時に状態を更新するのが難しそうだと思ったが、やってみると案外簡単だった。
OverItemRadio.cs