Developer @ ADJUST

ASP.NET Webフォームで、マスターページの ID を指定する (ASP.NET 2.0以降、4より前まで)

ASP.NET Webフォームでマスターページを使うと、レンダリング結果の HTML 中、各 Web サーバーコントロールの ID には必ず "ctl00_..." というプレフィクスが付く。

これは実はマスターページの ID だ。
Web サーバーコントロールの ID は、特にプログラマが設定しなければ、ASP.NET 側で ctl<連番> という形式で自動で ID を振るが、それだ。

どうにもウザいし、ちょっと巨大なページになると、この ID が占める割合もだんだん馬鹿にならなくなってくる。
例えば 100行 の GridView があって、内3列にWebサーバーコントロールを貼り付けたとすると、ctl00=5文字 x 100行 x 3列 = 1,500 バイト、となるわけだ。

まぁ、たかだか 1,500 バイトごとき、ギガビットの時代ではゴミみたいなものに思える。
しかし、JavaScript ファイルは無駄な空白や改行を除去して圧縮していることを考えると、そのせっかくの JavaScript ファイルの圧縮によって稼いだバイト数を、あっさりと消費してしまうという見方もある。

これについての特効薬は、今後リリース予定の ASP.NET 4 で導入される Control.ClientIDMode プロパティだ（あるいは、既存のコードを全面的に書き直して良いのであれば、ASP.NET MVC へ乗り換えるという手段もあるが）。

しかし、ASP.NET 4 まで待てない場合でも、多少の緩和策はある。

マスターページの ID を明示的に指定するのだ。

マスターページのビハインドコード上で、マスターページクラスのコンストラクタ中で自身の ID を指定すればよい。

こんな感じ。

public partial class Site1 : System.Web.UI.MasterPage
{
　public Site1()
　{
　　this.ID = "_";
　}
}

マスターページの ID をアンダーバー 1文字にしてしまうことで、レンダリングされた HTML が少しはすっきりするし、1サーバーコントロールに付き 5バイト消費していたプレフィクスが 1バイトにまで収まる。

なお、「this.ID = "";」とやった場合は、結局 ASP.NET によって "ctl00" が自動で振られてしまうのであしからず。

まぁ、こんなみみっちい話題に拘泥せず、ASP.NET 4 を待った方が素直でよいとは思うが。

CLR/H 第46回勉強会 - ライトニングトーク フォロー

昨日は CLR/H 第46回勉強会に参加させて頂き、ライトニングトークにも登壇させて頂いた。

PowerPoint のスライドは、こちらに公開させて頂く。

http://tinyurl.com/yhxh8l9
置き場所は SkyDrive なので、Windows Live ID お持ちの方は、ダウンロードすることなくブラウザ上で閲覧できるはず。

なお、上記スライドからは削除してあるが、今回はスライド上に Twitter のつぶやきをティッカー表示する 、SAP の "FREE PowerPoint Twitter Tools" を使ってみた。

元ネタはこちら。

Publickey -「プレゼンしながらTwitterのつぶやきをリアルタイムでPowerPointに表示できる部品、SAPから」
http://www.publickey.jp/blog/09/twitterpowerpointsap.html

ライトニングトークの真っ最中は、時間内にしゃべることに必死で、ティッカー表示される Twitter のつぶやきを見ている余裕がなかった。
しかし、オーディエンスの皆様は気づかれていたかも、と思うが、実は今回のライトニングトーク中、 大変ありがたいご指摘を Twitter 上で流して頂いていたのだ。

今回のライトニングトークの主題は、「ASP.NET MVC でアプリケーション相対URLを解決して、うまく Content フォルダ内の画像へのクライアント側URLを手に入れるには?" というものであった。

これに対し、自分の提示した解決策は、次の二点。

• <asp:Image/> などの Web サーバーコントロールを使う


• <%= Page.ResolveUrl(～) %> を使う

しかし実は、2点目の解に対しては、ASP.NET MVC ではさらなる良解があった。

UrlHelper クラスの Content メソッドだ。

これはぬかった。

"Url.Action" の利用などで、UrlHelper にさわる機会は多々あったのだが、Content メソッドの存在や役割に気づいていなかった。

これを、ライトニングトーク中、Twitter に「Url.ContentでもOK」とコメント頂けたのだ。
多謝。

CLR/H 第46回 勉強会 - LT登壇します - LTカウントダウンタイマーを Ver.Up!

今週末 2010年2月6日 は、CLR/H 第46回 勉強会に参加の予定。

性懲りもなく、今回もライトニングトークにも参加させて頂くこととした。

これを機会にとばかりに、拙作のライトニングトーク専用 5分間カウントダウンタイマー for Desktop を少しだけ改良した。

自分の手元でだけみるのではなく、プレゼン画面の上に重ねて、残り時間がじわじわ減っていくのをオーディエンスと一緒にみるタイプのものである。

LT用カウントダウンタイマーは Microsoft 系では Tech Fielders セミナー版 をはじめ、いくつか存在する が、いずれにしてもデジタル表示では、トークでいっぱいいっぱいの頭では残り時間の把握が直感的に難しかった。

そこで今回はリング状のプログレスバー(サークル?)を追加した次第。

アプリ本体の構造は、クライアント側 JavaScript で構築した HTML ページに過ぎない。
それを、IE を埋め込んだ .NET Windows フォームアプリ（常に最前面、50%透過）で開いているだけ。
時間表示部分をクリックするごとに、カウントダウン開始・リセットが行われる。

よそ様のタイマーと異なり、こちらは上記のとおりの稚拙なつくりであるため、なんとこの LT カウントダウンタイマーのウィンドウ移動には、「ウィンドウのボーダーをドラッグする」という、知らなければどうにもできないような変態的 UI となっている。
終了は Alt + F4 で。

SkyDrive に置いておきます。
ご利用はご自由にどうぞ。
http://cid-5dd1e083875ff918.skydrive.live.com/self.aspx/%e5%85%ac%e9%96%8b/LTCountDownTimerForDesktopV2-bin.zip
Zipを解凍したら、HTMLファイルや GIFファイルに紛れて、.exe がひとつだけあるので、それを実行すればよい。
要 .NET 3.5 SP1。

ソース一式はこちらから。
改造等ご自由にどうぞ。
http://cid-5dd1e083875ff918.skydrive.live.com/self.aspx/%e5%85%ac%e9%96%8b/LTCountDownTimerForDesktopV2-src-vs2010.zip
Visual C# Express 2010 Beta2 で編集したため、プロジェクト形式等が変わってしまっているのはご容赦の程。
とはいえ、プロジェクトを作り直せば、Visual Studio 2008 でも開けるのではないかと思われる。

追記
その名もズバリ、"Lightning Talks.com" なんていうサイトもあるのですね。
知りませんでした。
こちらにもカウントダウンタイマーがいろいろあるようです。

Plone の「マイフォルダ」で、共有タブが表示されない

Plone には「マイフォルダ」という機能がある。
Plone の各ユーザーに対して、そのユーザー固有に割り当てられるフォルダだ。

各個人のメモ書きを残すのもよし、サンドボックスとして Plone 上のコンテンツ作成になれてもらうのもよし、といったものである。

「マイフォルダ」機能は Plone をインストールした直後は既定で無効となっている。
もし「マイフォルダ」機能を使いたければ、「サイト設定」のページから「セキュリティ」カテゴリを開き、「ユーザーフォルダを利用可能にする」のチェックを On にしてやればよい。
こうしておくと、Plone のユーザーアカウントを作成する際に「マイフォルダ」が同時に作られるようになる。

さて、とあるユーザーから、自分のマイフォルダを他人にみられないようにして欲しい、との話が。

ああ、そんなの簡単ですよ、「共有」タブから、「上位レベルからパーミッションを引き継ぐ」をチェック Off にしておくだけですよ、と話したのだが、そのユーザー曰く、そもそも「共有」タブがないのだとか。

なになに、そんな馬鹿な、と思いながらも、そのユーザーの席に出向いて、画面を見せてもらったのだが、たしかに「共有」タブが表示されていない。

はたと思い出したのが、このユーザー、マイフォルダ機能を有効にする以前からの利用者で、マイフォルダ機能を有効にしただけではマイフォルダができあがらず、手作業でほかのユーザーのマイフォルダからコピーして作成したのだ。
おそらくそのときに、そのユーザーのマイフォルダの Owner として、そのユーザー自身をローカルロールに設定するのを忘れたに違いない。

ということで、はてさて、どこで設定するんだっけ? としばらく探索。

まず ZMI ( Zope 管理画面、Zope Management Interface ) を開く。

/Plone/Members まで開くと、リストボックスにマイフォルダを持つユーザーのユーザー名一覧が表示されているので、目的のユーザー名を選択して [Edit] ボタンをクリック。

"ATFolder at /Plone/Members/(ユーザー名)" のページが開くので、さらに [Security] のタブに切り替える。

すると、ページ上部に長々と書かれている英文中に、"local rolse" というリンクが埋もれているので、これをクリックして開く。

すると案の定、チェックボックスと並んで、目的のユーザー名が表示されていた。
そしてこれまた予想どおり、コピー元のマイフォルダの持ち主のユーザー名も併せて表示されており、こちらが "Owner" となっていた。

ユーザー名部分がリンクになっているので、目的のユーザー名をクリック。
するとようやく、ロール設定を行うページになる。
ロールを選ぶ複数選択リストボックスが表示されているので、ここから "Owner" を選択、[Save Changes] をクリックして保存することで、処理完了である。

今は昔 - AjaxControlToolkit の CalendarExtender のカレンダーを日本語表記にする

懐かしの「AJAX ControlToolkit の CalendarExtender の完全日本語化」のネタについて再び、である。
なんと、もう2年も前の話で懐かしい次第だが、さて。

最新の AJAX Control Toolikt、Release 30930 ( Sep 30 2009 ) では、ついに本家にて修正が行われていた。

(...と、昨年の9月末のリリースについて今頃投稿しているのは、今更ながらようやくこの最新リリースへのリプレースに着手したため。)

残念ながら(?)、リソース切り替えによる自動での修正は行われないようだが、しかし、新たに DaysModeTitleFormat と、TodaysDateFormat の 2 つのプロパティが追加された。

もう大体察しはつくと思うが、これらプロパティに、日付の書式文字列を日本語風になるよう設定してやればよいわけである。

具体的には、

• DaysModeTitleFormat = yyyy年 MMMM


• TodaysDateFormat = yyyy年 MMMM d日

を設定してやればいい感じになるだろう。

この修正が行われたのは change set 54957。
2009年6月のことだそうで、ひとつ前のリリース、30512 ( May 13 2009 ) 以前では修正に至っていないようだ。

発端は Issue #9332 の投稿らしい。
事例に "for fr-FR" と引き合いに出しているところみると、フランスの方なのだろうか?
おかげさまで、日本語を扱う自分も恩恵にあずかれた。
感謝。

こちらも今更ながら... WF ( Windows Workflow ) のシーケンシャルワークフローに開眼

.NET Framework 3.0 とともにリリースされた WF こと Windows Workflow。

デザイナ画面でフローチャートを描くような感覚で、シーケンシャルワークフローをコーディングできる姿を見て大変興味を覚えたのだが、しかし、なかなか実務でどこに応用したものかわからぬままに、手を付けずにいた。

正直なところ、いくらカスタマイズ性能や仕様変更に対する耐性が高くなるとはいえ、"IfElseアクティビティを Drag & Drop して..." とかやるよりも、普通に C# で if 文書いたほうが早いじゃん、としか思えなかったのである。

しかし最近、まさしくこれこそ WF シーケンシャルワークフローを使うといいのでは、と思い当たるアプリ開発が発生。
そこで下記書籍をガイドブックにして、いよいよ WF を実務で使ってみた。

.NET開発テクノロジ入門~.NETの基礎からクラウドテクノロジ Windows Azureまで (マイクロソフト公式解説書) (マイクロソフト公式解説書 Microsoft.net)

マイクロソフト株式会社 エバンジェリストチーム / 日経BPソフトプレス

その結果、正直、いろいろ床下配線が必要でまどろっこしい感じは拭えないし、やはり相変わらず応用すべき場面・局面は限られると思われるものの、それでもなお、「これはやってみるべき!」との結論に達した。

特に、並列処理の記述が簡便にできること ( Parallel アクティビティや、Replicator アクティビティの Parallel モードの利用 ) 、また、"コードの可視化" の恩恵で、どこが並列処理可能かを見つけやすくなることが、これからのマルチコア時代、非常にポイントが高いと感じている。

そういうわけで、社内でも WF シーケンシャルワークフローの実装を扱えるメンバーを増やすべく、社内勉強会をハンズオン形式で開催。

その際のプレゼン資料だが、上長の厚意により、一般公開してよいとの承諾を頂いた。

下記、slideshare にアップロードしてある。

http://www.slideshare.net/jsakamoto/windows-workflow-2860205

SkyDrive にもアップロード済み。
Windows Live ID お持ちの方であれば、いちいちダウンロードすることなくブラウザ内でそのまま閲覧できるので、こちらからご覧頂くのもよいだろう。

http://cid-5dd1e083875ff918.skydrive.live.com/self.aspx/%e5%85%ac%e9%96%8b/%e3%81%84%e3%81%be%e3%81%95%e3%82%89%e3%81%aa%e3%81%8c%e3%82%89%e3%81%ae%20Windows%20Workflow%20%e5%85%a5%e9%96%80.ppt

XBAP ( WPF ブラウザーアプリケーション ) にて、自身のダウンロード元 URL を取得するには

先日、XBAP ( WPF ブラウザアプリケーション) に開眼、の記事を投稿したが、さて。

XBAP から、Webサービスの呼び出しを行いたいケースがある。

XBAP はブラウザのウィンドウ内にはめ込まれた外観で動作するため、一見、普通の Web ページと見分けがつかないこともあり、それが開発者側としての狙いであり、思うつぼである。
しかし、XBAP の実行のコンテキストは結局のところローカル側であり、一連の Web システムの一部として構築した XBAP の場合は、Web サーバー側との通信は必須となるわけである。

こちらの記事を参考にすると、どうやら、XBAP から WCF によるサービス呼び出しは不便で、クラシックな ASP.NET Web サービス、すなわち、.asmx 相手の呼び出しであれば簡単らしい。
まぁ幸い、.asmx で Web サービス側を実装してもさして不都合な事情はなかったので、この件はほとんど問題にならなかった。

さてさて、.asmx による Web サービスと、XBAP とを同じ Web アプリケーション上に配置し、XBAP では、自身のダウンロード元 URL から、その .asmx Web サービスの URL を割り出してサービス呼び出ししようと考えた。
こうすれば、.config を書き換えて Web サービス URL を都度設定することなく、.asmx と XBAP とを、どのような URL にでも配置することができる。
開発/検証/デモンストレーション/リリースの各ステージングごとに .config の書き換えが要らない、ということだ。

じゃぁ、XBAP 側のコードで、ダウンロード元 URL を取得するには... と調べてみたが、これがどうもおぼつかない。
意外と簡単なことのように思えるのだが、MSDN Library を歩いてみたり、ネットで検索してみたり、Visual Studio 上でいろいろインテリセンスで探索していたりしても、判然としない。

...と思い出したのが、.NET のコードアクセスセキュリティにおける、"エビデンス"（Evidence, 根拠） の話。
.NET アプリケーションでは、そのアプリケーションを構成するアセンブリ(.dllなど)が、ローカルファイルシステムにあるのか、インターネット経由でブラウザからダウンロードされてきたのか、など、出生の場所に応じてセキュリティが厳しくなったりする。
すなわち、アセンブリの出生場所を "エビデンス"、根拠としてセキュリティレベルが決定されているのだ。

ということで、エビデンスを探索する下記コードで、ダウンロード元 URL を特定することに。

var downloadUrlStr = AppDomain.CurrentDomain.Evidence.Cast<object>()
　.Where(ev => ev is System.Security.Policy.Url)
　.Select(ev => (ev as System.Security.Policy.Url).Value)
　.FirstOrDefault();

...うーん、もちろんちゃんと機能しているが、ここまでごちゃごちゃコード書かなくちゃいけないものなのかな?
もっと簡単な解が転がっているような気がしてならない。


2010/01/07 12:39 追記

Enumerable.OfType という技があることを教えて頂いた。
http://twitter.com/neuecc/status/7465307020
ありがとうございます。

var downloadUrlStr = AppDomain.CurrentDomain.Evidence
.OfType<System.Security.Policy.Url>()
.FirstOrDefault().Value;

こんな感じ?

今更ながら、WPF ブラウザーアプリケーション ( XBAP ) に開眼!

ある日、ふと気がつくと、イントラネット専用のWebアプリケーションのページに貼り付けた Windows フォームユーザーコントロールが、[X] になって表示されていなかった。

そう、古来 .NET 1.x の時代より、.NET の Windows フォームユーザーコントロールは、ActiveX コントロールのように、HTML ページ中に貼り付けできるのだ。
知られているような知られていないような機能ではあるが...。

クライアントが .NET Framework インストール済み Windows OS & IE だと、

<object class="Webサーバー上のアセンブリファイル名.そのアセンブリ中のクラスの完全限定名" />

というタグを HTML ページ中に記述することで、.NET の Windows フォームユーザーコントロールをページ中に貼り付けることができる。

できるのである、が、しかし、このページが私の PC では、機能しなくなっていたのだ。
同僚の PC で確認させてもらうと、こちらはちゃんと HTML ページ中に当該 Windows フォームユーザーコントロールがインスタンス化されて貼り付いて動作している。

うーん、どうなっている?
自分の PC は昨年末に Windows 7 Pro (x86) にクリーンインストールしたばかり。
同僚の PC は未だ Windows XP Pro SP3 である。
PC の各種構成は、Active Directory 傘下、グループポリシーで配信されていることを考えると、環境設定によるものではなさそうな気がする。

となると、OS の差なのか?
もう Windows 7 （ないしはその上の IE 8 ）では、HTML ページに Windows フォームユーザーコントロールを貼り付けることは許されないのだろうか...(*1)

...と思案に暮れていたときに、ふと思い出したのが、WPFブラウザアプリケーション。
拡張子 .xbap ( Xaml Browse APplication の略? ) で表される、ブラウザ(といってもIEだが) のウィンドウ内で動作する .NET アプリケーションの一形態だ（以下、XBAP と表記する）。

XBAP は ClickOnce の一種なのだが、独立したウィンドウを持つわけではなく、スタートメニューにも登録されず、Webサーバー上に配置したこのXBAP へのURLを開くことで IE のウィンドウ内でのみ動作する(*2)。
見た目はまるっきり HTML ページのようなものだ。

"ブラウザ内で動く" という意味では、Silverlight と似てはいる。

しかし、Sliverlight は ( 3 からはブラウザ外実行があるとはいえ ) 結局は HTML ページ内の object タグに過ぎないのに比べ、XBAP は IE のウィンドウ内にこそはめ込まれているものの、HTMLページは一切存在せず、HTML ページに埋まっているわけではない。

また Silverlight はクライアントの OS は Windows のみならず、Mac OS や Moonlight によって Linux 上でも動作する。
ブラウザだって、IE だけではなく、Firefox や Chrome でも動作する。
加えて、CLR のサブセットを内蔵しているのでクライアントOS への .NET Framework ランタイムのインストールは無用である。

しかし、XBAP はあくまでも ClickOnce の一種。
クライアント OS に .NET Framework がインストールされていることが必要である。
Mono の事情はよく知らないが、事実上、Windows OS & IE の組み合わせに限定されるのだろう。

そんな XBAP だが、Silverlight との最大の違いは、XBAP は完全信頼、すなわち、ローカルにインストールされた通常の .NET アプリケーション (.exe) と同等のセキュリティ権限で動作することが可能、という点である。

Silverlight も 4 からはブラウザ外実行における権限昇格によってかなりいろいろなことができるそうで、"アプリケーションのプラットフォーム" として注目している。
しかし、Silverlight 4 は今日現在まだリリースされたわけではなく、また、権限昇格はあくまでもブラウザ外実行に限られるし、"完全信頼" というわけではないようだ。

いっぽうの XBAP はブラウザウィンドウ内にはめ込まれたまま完全信頼で動作させることが可能。
通常の Web アプリケーション・HTML ページ上から XBAP にジャンプしてきても、一貫してブラウザ内での動作であるため、ユーザー体験的には HTML なのか XBAP なのかの区別なく操作できてなかなかなよいのである。

XBAP を完全信頼で動作させるには、詳しくは下記サイトが参考になる。
http://blogs.microsoft.co.il/blogs/maxim/archive/2008/03/05/wpf-xbap-as-full-trust-application.aspx

（このページは、"XBAP 完全信頼" で検索して、.NET Framework フォーラムのスレッドにヒットして見つけた。）

ポイントをかいつまんで書くと、次のとおり。

• プロジェクトの設定で「完全信頼で動作させる」チェックをOnにしてビルドすること。


• ビルド時に、然るべき(秘密鍵付きの)電子証明書で、ClickOnce マニフェストに電子署名すること。


• 利用者側の Windows OS / ユーザープロファイルでは、この署名に使った電子証明書(公開鍵のみ)を「信頼された発行元」として登録すること。（そしてもちろん、その電子証明書を発行した認証局の証明書も、「信頼されたルート証明機関」に登録されている必要もある）

なにぶん企業内アプリなもので、Windows Server を使って企業内ローカルな認証局サービスを設置・運営するのは朝飯前。
加えて、LAN 内の Active Directory 傘下の全クライアントPCには、グループポリシーによって、各種証明書を「信頼されたルート証明機関」「信頼された発行元」に登録するよう配信することもお茶の子さいさい。
シスアドなら自分の席でマウス片手で実行できる。

こうして、.NET Windows フォームユーザーコントロールを利用していた件の Web アプリケーションは、XBAP としてリプレースに成功したのであった。

ということで、今更ながら、XBAP に開眼した次第。

白状すると、実は、XAML をちゃんと書くのはこれが初めてである。
しかしこうして XBAP に目覚めた今後は、さらに XAML に触れる機会が増えることと思う。
実際、現在稼働している .exe 形式の .NET Windows フォームアプリを、XBAP にリプレースすることまで思案中だ。
そして、こうして XAML に慣れてくることは、Silverlight 対応への布石にもつながる。

*1) 実はこれは勘違いだったかもしれない。グループポリシー配信のほうが誤っていた可能性が浮上してきたのだ。なので、Win7であろうと、適切な環境構築ができていれば、ちゃんと Winフォームを貼り付けできていたかもしれない。

*2) 必ずしも Web サーバー上に配置して HTTP,HTTPS プロトコル経由でダウンロードする、という必要はない。ファイルシステム上に配置した .xbap ファイルを、エクスプローラからダブルクリックで開いても、IEが立ち上がって動作する。

SQL Server のデータベースユーザーを削除しようとしたら「スキーマを所有しているので削除できません」

SQL Management Studio を使って、SQL Server の保守作業をしていたときのこと。

ほかのサーバーから移設したりなど、いろいろな経緯があって、いくつか無用なデータベースユーザーが残ってしまったデータベースがあった。

さてということで、このデータベースユーザーを SQL Management Studio 上から削除しようとした。
当該データベースユーザーを右クリック -> コンテキストメニューから [削除(D)] を選択して、「オブジェクトの削除」ダイアログにて [OK] をクリックする。

いつもならこれでデータベースユーザーは削除できておしまいなのだが、今回はちょっと勝手が違った。
エラーになってしまったのである。

エラーメッセージはこんな感じ。

ユーザー 'hoge' の削除に失敗しました。 (Microsoft.SqlServer.Express.Smo)
Transact-SQL ステートメントまたはバッチの実行中に例外が発生しました。 (Microsoft.SqlServer.Express.ConnectionInfo)
データベース プリンシパルは、データベースの スキーマ を所有しているので、削除できません。 (Microsoft SQL Server、エラー: 15138)

かなり苦労してあちこち調べた。
その結果、次の手順で削除できる、ということがようやくわかった。

-- いったん、ユーザーと、そのユーザー名と同名のスキーマを明示的に関連付け、
ALTER USER hoge WITH DEFAULT_SCHEMA = hoge
-- そのスキーマを明示的に削除してから、
DROP SCHEMA hoge
-- ユーザーを削除。
DROP USER hoge
GO

「スキーマ を所有しているので削除できません」などというエラーに遭遇するのはレアケースだとは思うが、レアケースであるが故に情報が少ないせいか、対応に困難した。
なかなかに難しいものですね。

実機のHDDをHyper-V2.0環境へ移行(P2V)

職場のPC ( Windows XP Pro SP3 ) が壊れた。

使用中に突然電源が落ち、それ以降、電源ボタンを押してもうんともすんとも言わなくなった。
HDDは問題なかったので、じゃぁ、代替機が用意できるまでの間、この HDD を VHD に吸い上げて、Hyper-V 2.0 上で稼働させ、リモートデスクトップ接続で利用しましょう、ということになった。

Xen の無償利用可能なツール、XenConvert 2.x なら、VHD への P2V 簡単だよ、という話を聞いていたので、早速ダウンロード & インストール。

インストール完了し XenConvert を起動してみたところ、たしかに、この XenConvert を起動しているこのマシンをVHDに複製できることはわかった。

しかし今回やりたいのは、P2V というよりは、故障した PC から抜き出した HDD の VHD への変換。
XenConvert の画面を見ると、ソースとして "Volume" が選べるので、これで当 HDD のパーティションを指定すれば VHD へ変換できる...と思いきや、変換先は "Volume" だけ。
つまり、Volume→ VHD はできず、Volume → Volume だけ、ということらしい。

うーん、困ったなぁ...と思案に暮れたが、そういえばこの作業を行っている PC の OS は Windows 7 なのである。
そう、VHD をマウントできるのである。

早速、[コンピュータの管理]から、[記憶域]-[ディスクの管理]と進み、右クリックから [VHDの作成] を開始し、適当な VHD を作成してマウント&初期化。

これで、XenConvert を使って Volume→Volume ができるようになった。

まぁ、こうなると、XenConvert を使う意義が薄れて、Acronis のツールなどで移行するのと変わらない気がしてきたがさておき。

こうして無事、故障PC から抜き出した HDD を VHD に変換し、Hyper-V 2.0 サーバ上に仮想マシンを作って、作成した VHD をマウント。

これでOK...と思ったら、今度は起動しない。

"ブートできるデバイスがない" と言われてしまう。
ううむ、おかしい、といことで、当該仮想マシンを WinXP Pro SP3 の CD-ROM からブート。

修復セットアップを実行するも効果なし。
回復コンソールを使い、fixboot C: や fixmbr を実行しても効果なし。
そもそも、fixmbr を何度実行しても、毎回、"警告 - 無効なブートレコードがあります" と言われて、なんだか直っていないような雰囲気なのだ。

ううーん、どうなっている?

そこでものは試しに、Windows 7 Pro(x86) の DVD-ROM からブートし、「スタートアップの修復」を試してみた。
するとどうだろう、見事、変換した VHD 上の Windows XP からのブートに成功。

なぜ Windows XP の CD-ROM からの fixmbr などが効果なかったのか、その理由・メカニズムをよく理解できていないので、後日要勉強かも。
もしかして、統合サービスとか関係あるのか?