WinDbgとSOS拡張でVSを使わずに.NETアプリをデバッグ - 異常終了時の調査

.NET Frameworkには「SOS デバッガー拡張」という機能があり、デバッガからCLRの状態を追いかけることができる。これを使うと、重いVisual Studioを使わなくても、WinDbgで.NET Frameworkのアプリケーションをデバッグすることができる。今回は、.NETアプリが異常終了したときにその状態を調べるという方法について。

この役に立たないダイアログも、価値のあるものになるはず。

設定編

1. WinDbgをインストールする

今回はWinDbgを使うことにするので、WinDbgをインストールする。WinDbgをインストールするには「Windows 用デバッグ ツールのダウンロードとインストール」にある通り、WDKあるいはWindows SDKをインストールすればついてくる。途中でコンポーネント選択の画面があるので、デバッガのみ選べば、他のコンポーネントをインストールしないことも可能。

2. 自動デバッガの設定をする

上の「役に立たないダイアログ」の「プログラムをデバッグします」で起動するプログラムを変更する。やりかたは「Configuring Automatic Debugging」に書いてある通り、レジストリキー「HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug」にある「Debugger」文字列値を追加/変更し、以下のようにする。

"C:\Program Files\Windows Kits\8.0\Debuggers\x86\windbg.exe" -p %ld -e %ld -g

x64版Windowsの場合は、SOS拡張を利用するには、実行するアプリケーションと同じアーキテクチャのwindbg.exeを使う必要があるので、上記のキーはx64版のwindbg.exeに向ける。

"C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\windbg.exe" -p %ld -e %ld -g

x86版のアプリを起動したとき向けに、WOW64側のレジストリキー「HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug」の「Debugger」文字列値をx86版windbg.exeに向けておく。

"C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\windbg.exe" -p %ld -e %ld -g

一応、上記のパスにインストールされていた場合（＝Windows8 SDKでWinDbgをデフォルト設定でインストールした場合）に使えるregファイルを置いておいた。
x64用 / x86用

Visual Studioがインストールされている場合、Visual Studioのデバッガを使うようすでに構成されているため、注意が必要（上記の設定をするとこのダイアログからVisual Studioが使えなくなる）。

これで設定は完了。

実行編

MSBuild Launcher v0.1.1には、「存在しないエディタが設定されていると、異常終了する」というバグがあるので、これを例にする。なお、ポイントとなりそうな部分は勝手に太字にしてある。

基本的には、「SOS.dll (SOS デバッガー拡張)」を見てコマンドを選ぶことになる。

1. 異常終了＋デバッガ起動

MSBuild Launcherの「Settings」ボタンをクリックし、「Editor」テキストボックスに存在しないパスを入力する。その後、適当なmsbuildファイルを開き、「Edit」ボタンを押すと、異常終了し、上の役に立たないダイアログが出てくるので、「プログラムをデバッグします」をクリックすると、WinDbgが立ちあがる。ワークスペースを保存するか聞かれるので、Noを選ぶと、以下の画面になる。

2. SOS拡張のロード

上記の状態になったら以下の通り入力する。

0:000> .loadby sos clr

これは「clr.dllの横にあるsos.dllをロードする」という意味。今回のケースではすでにclr.dllがロードされているので、特にメッセージなく終了するはず。なお、「clr」とするのは.NET Framework 4の場合で、.NET Frameworkの2.0/3.xの場合「clr」は「mscorwks」とする。

今回のケースとはずれるが、ロードされていない場合、例えば起動直後の場合、

0:000> sxe ld clr

としてclrのロードで止めるよう設定して

0:000> g

で進めたあと「.loadby～」を行うか、「.load」で直接DLLの場所を指定してもOK（この場合、.NETのバージョンやアーキテクチャに注意する）。

0:000> .load C:\Windows\Microsoft.NET\Framework64\v4.0.30319\SOS.dll

これで、SOS拡張がロードされた。

3. Exceptionの内容を表示する(!pe)

「CLR exception - code e0434352」が出ている通り、Exceptionが発生しているので、最後のExceptionの内容を表示する!pe (!PrintException)を実行する。

0:000> !pe
PDB symbol for clr.dll not loaded
Exception object: 0000000003078d10
Exception type:   System.ComponentModel.Win32Exception
Message:          指定されたファイルが見つかりません。
InnerException:   
StackTrace (generated):
    SP               IP               Function
    00000000001BD130 000007FEEB0CCBF3 System_ni!System.Diagnostics.Process.StartWithShellExecuteEx(System.Diagnostics.ProcessStartInfo)+0x4a3
    00000000001BD220 000007FEEB0CD03C System_ni!System.Diagnostics.Process.Start(System.Diagnostics.ProcessStartInfo)+0x3c
    00000000001BD260 000007FEE9BD1C51 PresentationCore_ni!System.Windows.EventRoute.InvokeHandlersImpl(System.Object, System.Windows.RoutedEventArgs, Boolean)+0x271
    00000000001BD490 000007FEE9BB8BBC PresentationCore_ni!System.Windows.UIElement.RaiseEventImpl(System.Windows.DependencyObject, System.Windows.RoutedEventArgs)+0x15c
    00000000001BD520 000007FEE91EC26D PresentationFramework_ni!System.Windows.Controls.Button.OnClick()+0xad
    00000000001BD590 000007FEE914B868 PresentationFramework_ni!System.Windows.Controls.Primitives.ButtonBase.OnMouseLeftButtonUp(System.Windows.Input.MouseButtonEventArgs)+0x148
（中略）
    00000000001BE9D0 000007FEE85486DF PresentationFramework_ni!System.Windows.Application.RunInternal(System.Windows.Window)+0x12f
    00000000001BEA40 000007FEE8547CEB PresentationFramework_ni!System.Windows.Application.Run()+0xbb
    00000000001BEA90 000007FF0015024F MsbuildLauncher!MsbuildLauncher.App.Main()+0x12f

StackTraceString: 
HResult: 80004005

これでもう「System.Diagnostics.Process.StartWithShellExecuteEx」を呼んだ結果「System.ComponentModel.Win32Exception」が発生し「指定されたファイルが見つかりません。」というメッセージが出ていることがわかった。MSBuild Launcherにおいて「System.Windows.Controls.Button.OnClick」から「System.Diagnostics.Process.Start」を呼ぶところなんて限られてくるので、もうわかったも同然なのだが、もう少し調べてみる。

4. スタックのオブジェクトを一覧する(!dso)

今回の場合「InnerException」がnoneなので、そこは調べられない。SOS拡張では、!dso (!DumpStackObjects)で、スタックのオブジェクトを一覧できるので、表示してみる。

0:000> !dso
OS Thread Id: 0x1208 (0)
RSP/REG          Object           Name
r15              0000000002e69448 System.Windows.Input.NotifyInputEventArgs
00000000001BCE68 0000000003078d10 System.ComponentModel.Win32Exception
00000000001BCF08 0000000003078d10 System.ComponentModel.Win32Exception
00000000001BCF50 0000000003074ca0 System.Windows.EventRoute
00000000001BCF68 0000000003078d10 System.ComponentModel.Win32Exception
00000000001BCF80 0000000003078d10 System.ComponentModel.Win32Exception
00000000001BCF98 0000000003078d10 System.ComponentModel.Win32Exception
00000000001BCFA0 0000000003078d10 System.ComponentModel.Win32Exception
00000000001BD030 0000000003074ca0 System.Windows.EventRoute
00000000001BD048 0000000003078db0 System.Text.StringBuilder
00000000001BD080 0000000003078d10 System.ComponentModel.Win32Exception
00000000001BD090 0000000003078d10 System.ComponentModel.Win32Exception
00000000001BD0B0 0000000003074ca0 System.Windows.EventRoute
00000000001BD0B8 0000000002e69448 System.Windows.Input.NotifyInputEventArgs
00000000001BD120 0000000003078c40 Microsoft.Win32.NativeMethods+ShellExecuteInfo
00000000001BD130 0000000003078d10 System.ComponentModel.Win32Exception
00000000001BD168 0000000003078360 System.Windows.RoutedEventArgs
00000000001BD1D0 0000000003078c40 Microsoft.Win32.NativeMethods+ShellExecuteInfo
00000000001BD1F8 0000000003078860 System.Diagnostics.ProcessStartInfo
00000000001BD200 0000000003078360 System.Windows.RoutedEventArgs
00000000001BD210 0000000003078b28 System.Diagnostics.Process
00000000001BD220 0000000003078b28 System.Diagnostics.Process
（略）

太字の 「System.Diagnostics.ProcessStartInfo」オブジェクトを見ればもうすこしわかりそうなので、表示してみることにする。

5. オブジェクトの内容を表示する(!do)

オブジェクトの内容を表示するには、!do (!DumpObj)コマンドを使う。引数には、先程の「System.Diagnostics.ProcessStartInfo」のオブジェクトアドレスを指定する。

0:000> !do 0000000003078860
Name:        System.Diagnostics.ProcessStartInfo
MethodTable: 000007feeab807a0
EEClass:     000007feea86a628
Size:        128(0x80) bytes
File:        C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System\v4.0_4.0.0.0__b77a5c561934e089\System.dll
Fields:
              MT    Field   Offset                 Type VT     Attr            Value Name
000007feeb866738  4002fc9        8        System.String  0 instance 0000000003078808 fileName
000007feeb866738  4002fca       10        System.String  0 instance 0000000003078aa8 arguments
000007feeb866738  4002fcb       18        System.String  0 instance 0000000000000000 directory
000007feeb866738  4002fcc       20        System.String  0 instance 0000000000000000 verb
000007feeabb2ae8  4002fcd       68         System.Int32  1 instance                0 windowStyle
000007feeb86d450  4002fce       6c       System.Boolean  1 instance                0 errorDialog
000007feeb873318  4002fcf       60        System.IntPtr  1 instance                0 errorDialogParentHandle
000007feeb86d450  4002fd0       6d       System.Boolean  1 instance                1 useShellExecute
000007feeb866738  4002fd1       28        System.String  0 instance 0000000000000000 userName
000007feeb866738  4002fd2       30        System.String  0 instance 0000000000000000 domain
000007feeb87e6d0  4002fd3       38 ...rity.SecureString  0 instance 0000000000000000 password
000007feeb86d450  4002fd4       6e       System.Boolean  1 instance                0 loadUserProfile
000007feeb86d450  4002fd5       6f       System.Boolean  1 instance                0 redirectStandardInput
000007feeb86d450  4002fd6       70       System.Boolean  1 instance                0 redirectStandardOutput
000007feeb86d450  4002fd7       71       System.Boolean  1 instance                0 redirectStandardError
000007feeb873738  4002fd8       40 System.Text.Encoding  0 instance 0000000000000000 standardOutputEncoding
000007feeb873738  4002fd9       48 System.Text.Encoding  0 instance 0000000000000000 standardErrorEncoding
000007feeb86d450  4002fda       72       System.Boolean  1 instance                0 createNoWindow
000007feeb887510  4002fdb       50 System.WeakReference  0 instance 0000000000000000 weakParentProcess
000007feeab80948  4002fdc       58 ....StringDictionary  0 instance 0000000000000000 environmentVariables

「fileName」が使えそうなので、さらに表示してみる。

0:000> !do 0000000003078808
Name:        System.String
MethodTable: 000007feeb866738
EEClass:     000007feeb3eed68
Size:        86(0x56) bytes
File:        C:\Windows\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll
String:      C:\Windows\invalid-notepad.exe
Fields:
              MT    Field   Offset                 Type VT     Attr            Value Name
000007feeb86c620  4000103        8         System.Int32  1 instance               30 m_stringLength
000007feeb86b160  4000104        c          System.Char  1 instance               43 m_firstChar
000007feeb866738  4000105       10        System.String  0   shared           static Empty
                                 >> Domain:Value  00000000002dafa0:0000000002a11420 <<

これで、「C:\Windows\invalid-notepad.exe」という文字列がfileNameに入っていることがわかった。これでは実行できそうもない。

---
と、このような感じで、異常終了時の例外情報を調べるくらいならわりと簡単にできる。.NETプログラマなら覚えておくのがおすすめ。

本当は、AppDomainの中を旅するだけの機能もついているのだけど、それはまた機会があれば。

Loqui 0.5.5リリース/LoquiのISO-2022-JP半自前変換の仕組み

Loqui 0.5.5を出しました。受信時に行なっていたISO-2022-JPの半自前変換を、送信時にも行うようにしました。ただし、受信時と異なり、「半角カナ」などの文字は、エラーにします。

これもまたSolaris用で、Solaris iconvでUTF-8からISO-2022-JPに変換すると、IRCNet的に困ったエスケープシーケンスをつけてしまうことへの対応です。Solarisで起きる現象については、この一連のスレッドにまとまっています（もう少しするとopensolaris.orgがなくなるので消えてしまうのですが…）

GNU iconvではこのようなことがないので、Linuxユーザの方は今までのままで大丈夫です（0.5.5からLinuxでも自前になるので、かえってあやしいかもしれません。うまく変換できていたのにいかなくなったケースがあれば教えてもらえると助かります。）

さて、せっかくなのでずっと前から実装されていた半自前変換について書いておこうと思います。UTF-8⇔ISO-2022-JP変換をする人の参考になれば。（パフォーマンスはよくないし、ISO-2022-JP-2004なども視野に入れるとやることが増えるので、対応できるケースは限られるのですが…）

Loquiの半自前UTF-8⇔ISO-2022-JP変換

Loquiでは、アカウント設定の「コード」の「一覧から選択する」で「Japanese」を選んだ場合、あるいは「ロケール情報から自動判定する」を選んで「ja_JP」から始まるlocaleで利用している場合、（ただのiconv呼び出しでない）ISO-2022-JP向けの文字コード変換ロジックが動きます。

この変換ロジックはいわゆる「半角カナ」や機種依存文字（の一部：NEC特殊文字(13区)）を受信しても化けずに表示させるためのものなのですが、ざっくり言うと、「iconvが失敗しそうな文字は自前で変換」「そうでない文字はiconvに変換してもらう」（半自前変換）という処理になっています。ただし、以下の図のような、ちょっと変わった流れをしています。

Gtk+(2以降)は、画面に表示するためにUTF-8を要求するのですが、日本語でIRCを使おうとすると、ISO-2022-JPを使っていることがあるので、この場合ISO-2022-JPからUTF-8に変換しないといけません。pureにISO-2022-JPのバイト列が来るならGLibのiconv wrapperでさくっと変換するだけで良いのですが、先の「半角カナ」があったりするので、手を入れないといけないわけです。

まぁ、変換処理を自前で持とう、という話になるのですが、ISO-2022-JPは漢字にJIS X 0208という文字セットを使っているのに対し、UTF-8はUnicodeなので、基本的には1文字1文字の変換テーブルを持つ必要があり、いろいろな意味でちょっとつらいです。そのため、「特殊な対応が必要な文字だけ自前で変換し、そうでないものはiconvに変換してもらう」というアプローチを考えます。

ところが、そうすると1文字1文字変換する必要がでてきますが、困ったことにISO-2022-JPは「ここからJIS X 0208の漢字だよー」といったような、文字セットの呼び出しがあり、コンテキストに意味をもったエンコーディングなのです。そのため、ISO-2022-JPのバイト列のままiconvに渡そうとすると、特殊な文字が入ってきたりこなかったりして、状態の管理がちょっとしんどくなります。

そこでどうするかというと、いったんISO-2022-JPからEUC-JPに変換します。EUC-JPでもJIS X 0208を使っているので、ISO-2022-JPからは計算式的に変換できる一方で、EUC-JPはISO-2022-JPと異なり、持続する文字セットの呼び出し（コンテキストの永続的変更）がない（次の文字だけ変更というのはあります）ので、状態の管理が簡単になります。これが上図のようなちょっと変わった流れをしている理由です。

詳しく知りたい方は、loqui_codeconv_tools.cを見てください。

ちなみに、Loquiはこういった言語ごとの特殊ロジックとlocale名の対応テーブルを持っています。10年以上に渡り、日本語以外に使われたことはないのですが…

余談

0.5.5を出してこの図を描こうと思ったら、いつのまにか横道にそれてました。

LibreOffice用カラーテーブルを作った

[2014/12/14追記] LibreOffice 4.2以降では、12色になったことによってこの8色版はまだらになってしまいます。12色対応版をどうぞ。

LibreOfficeは、もうちょっとした表や図を作るには十分なのだけど、デフォルトだと色が選択しにくい。いくつかプリセットがあるもの、どうもしっくりこなかったので、自分で作った。

ダウンロードはここから: https://github.com/sunnyone/locolor/raw/master/sunnyone.soc

作ってみたはいいものの、使い勝手がいいかどうかはまだわからない。

特徴

色相と明度/彩度の2軸で選択可能

デフォルトのカラーテーブルは一部そういう部分もあるものの、表で見たときけっこうまばらなので選びづらい。

順番に並んでいるカラーテーブルもあるのだけど、横8列であることを意識して作られていないので、まだらになってしまっている。

同じ色は縦に並んでいる（似通った濃さは横に並んでいる）

LibreOfficeは一番上のスクリーンショットの通り、2通りの色選択のUIがあり、リスト形式の場合は表の横の順に8つ出てくる。つまり、表の横1列が表示される。オフィスソフトで色を選択するときは、色相よりも先にトーン（濃さだとか）が決まっていることが多いので、同一トーンのものが一画面に出てくると選びやすい（はず）。

使い方

一時的に試してみたい場合は、適当に図を挿入して、右クリック→「領域...」でダイアログが出てくるので、「色」タブからフォルダのアイコンをクリックして出てくるファイル選択の画面でsunnyone.socを選べばOK。

デフォルトの設定にしてしまいたい場合は、LibreOfficeをいったん閉じたあと、configのディレクトリ（最近のWindowsならC:\Users\(Username)\AppData\Roaming\LibreOffice\4\user\config）のstandard.socをバックアップした後、入れ替えればOK。

作りかた

上の配色が気にいらない場合でも、このカラーテーブルの作りかたは参考になるかもしれないので、一応書いておく。

1. 色相を選択する

マンセル環から色をチョイスする。マンセル表色系の色相は、5色とその間の5色、さらに倍…という感じなので、8色はちょっとつらいんだけど、がんばって4色＋補色を選んだ。

2. 彩度/明度を選択する

マンセル表色系では、色相によって最高彩度が違うのでしんどいのだけど、概ね横の三角形の形をしているので、三角形の頂点を決めたあと、間の点を機械的に選んだ（実際はマンセルの等色相面はいびつな形をしているので、本当はない色があるかもしれない）。

詳しくはレポジトリに置いてあるシートを参照。

3. Color::Model::Munsell::Utilを使ってマンセル値からRGB値に変換

マンセル表色系に対応しているライブラリはけっこう少ないのだけど、PerlのColor::Model::Munsell::Utilは対応していたので、これで変換した。
マンセル値は直接RGBにはできないので、テーブルでCIE-XYZに変換して、そこからsRGBに変換している（はず）。
出力はLibreOfficeで使っている簡単なXMLにするだけで、完了。

詳しくはリポジトリに置いてあるスクリプトを参照。

Q&A

なんでPCCSじゃないの？

色彩＋トーン（彩度・明度）という考え方は、まさしくPCCS向けなのだけど、PCCSは（恐らく）物の色向けで、かつトーンの名前が人の感覚でつけられているので、RGBの世界に持ってくると、この手の世界になじみがない自分にはちょっと違和感があった。なので、類似した感じのマンセル表色系で色をチョイスした。

↑これが、「v2」というvトーンの赤、つまりvividなred (4R 4.5 / 14)をRGBに変換した色なんだけど、画面で見るとにぶく見える気がするのよねぇ。

機械的に計算するならHSVのほうがいいんじゃ？

できたあとに思った。実験してみてないのだけど、高明度の色は、HSVで機械的に出したほうがきれいな薄い色になったんじゃないかなーと思ったりもする。

が、マンセル値にしておけば、表記が人の理解できる範囲になると思うので、これはこれでいいかなと思っている。

なんで色を選ぶUIが2種類あるの？

ひとつだったらもう少し作りやすかったのに…

MSBuild Launcher 0.2.0 リリース

MSBuild Launcher 0.2.0が出ました。

0.1.xのヘンテコなJSON記法は廃止し、プロパティはファイルから取るようになりました。
右のFile Propertiesには、ImportedだとかSpecialなプロパティは出てこない（あると出すぎる）ので、
もし必要であれば、Settingからプロパティ名を追加してください。特殊なプロパティも定義されていれば表示されます。

あと、インストーラができたので、そのほうが好きな方はどうぞ。関連付けができます。
ただ、一度手動で関連付けていると、関連付かないことがあるので、そのときはいったんアンインストールして
HKCRのゴミを消してからまたインストールしてみてください（ちょっとひどい話ですが）。

---
WiXでのインストーラの作り方も記事にしようかと思ったんだけど、あまり「これだ！」という感じにならなかったので、見送り。

MSBuildからAssemblyInfoを生成する

結論から言うと、MSBuild Community TasksのAssemblyInfoタスクを使えばできる。

おすすめじゃない方法

おすすめじゃないけど簡単な方法として、既存のAssemblyInfo.csを置き変えてしまう方法がある。
Community Tasksの.targetsをImportしたあと、以下の感じのターゲットを作れば、既存のAssemblyInfo.csを置き変えることができる。



しかし、この方法ではプロジェクトが複数あった場合に、プロジェクト別に値を設定することができない。
これを作ったあと、Community Tasks的におすすめな方法があることがわかった（雛形がある）。

おすすめの方法

ざっくり言うと、GlobalAssemblyInfo.csを作り、それを参照する。

1. GlobalAssemblyInfo生成ターゲットを作る

Community Tasksをインポート後、このようなターゲットを作る。


次のプロセスのために1回実行しておく。

2. GlobalAssemblyInfo.csをリンクとして追加する

各プロジェクトで、GlobalAssemblyInfo.csを追加する。Visual Studioからは、「追加＞既存の項目...」で追加するが、
追加ボタンの右の▼を押して、リンクとして追加するのを忘れない。

3. 既存のAssemblyInfo.csから重複する値を削除する

GlobalAssemblyInfoに定義した値は、既存のAssemblyInfo.csから削除しておく。

これで、各プロジェクト個別の値をセットすることを可能にしつつも、バージョン等々をMSBuildから管理できるようになった。

GlobalAssemblyInfoの情報を取得する

アセンブリの情報は、リフレクションで取得することが可能だが、GetCustomAttributesが冗長な記述を要求したりして面倒。
しかし、AssemblyInfoタスクで、GenerateClass="true"にしておくと、「ThisAssembly」クラスを作ってくれる。
そのため、以下のようなシンプルな形でコードから情報を取得可能。

  string product = ThisAssembly.AssemblyProduct;

PowerShellを使ってインストールされたファイルのパスからプロダクトを調べる

rpm -qf /usr/bin/hogehogeや、dpkg -S bin/hogehogeなどとしてファイルパスからどのパッケージに入っているのか調べることありますよね？そのWindows版です。

（残念ながら入れないといけないのですが）Windows Installer PowerShell Moduleをインストールして、トップページに書いてある通り、PowerShellから以下のように打てばOKです。

PS C:\> Import-Module msi
PS C:\> Get-MSIComponentInfo | where { $_.path -eq "C:\Program Files\Reference Assemblies\Microsoft\Framework\.NETFramew
ork\v4.0\System.dll" }  | Get-MSIProductInfo

ProductCode                            ProductVersion      ProductName
-----------                            --------------      -----------
{CFEF48A8-BFB8-3EAC-8BA5-DE4F8AA267CE} 4.0.30319           Microsoft .NET Framework 4 Multi-Targeting Pack

Windows Installer (msi) で入っていないものには使えないですが、参考になるかもしれません。

MSBuild Launcher 0.1.0 リリース

最近またMSBuildをちょっと使うようになったので、MSBuild Launcherの新版をリリースしました。
  http://msbuildlauncher.codeplex.com/
githubダウンロード機能削除を受けて、これもCodeplexに移行です。

あと、プロパティ編集機能という大き目の機能がついたので、0.0.3ではなく0.1.0になりました。

MSBuildファイルの中のコメントに以下の感じのJSONを書くと、右側のペインにテキストボックスかコンボボックスが現れます。


本当はオレオレnamespaceを用意してオレオレ属性をプロパティのタグにつけたかったんだけど、そういうXMLファイルは食べてくれなかったので仕方なく。コメントの中にXMLが現れるとまたカオスなことになりそうなので、いっそJSONということでJSONになりました。

ちなみに上の「Common Properties」は実行ファイルと同じ場所にあるCommonProperties.jsonというファイルにJSONが書かれています（編集可能）。

これらのプロパティは、変更したものだけ（＝右側のトグルボタンがオンになっているときだけ）ビルド時に指定されるようになっています。


あとは、似非Editボタン（.xmlに関連付いたプログラムを起動する）とか、既定のターゲットを実行するBuildボタンがついたりしました。

[2013/2/7追記]
いくつかバグってたので直して0.1.1を出しました。疑似Editボタンは、設定を用意してちゃんと(？)Editボタンになりました。

[2012/2/9追記]
MSBuild LauncherのビルドをMSBuildでやるようにした関係もあって、0.1.1はAnyCPUにしたんだけど、x64環境ではx86のアセンブリがロードできずに動かないケースがあるとのこと。 そりゃそうだ。ということで、0.1.2が出て、x86に戻りました。うざったいメッセージボックスもログウィンドウに出してうざくなくしたよ。