情報科学屋さんを目指す人のメモ(FC2ブログ版)

何かのやり方や、問題の解決方法をどんどんメモするブログ。そんな大学院生の活動「キャッシュ」に誰かがヒットしてくれることを祈って。

ブログ内検索

スポンサーサイト このエントリーを含むはてなブックマーク

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
スポンサー広告 | 編集

XML形式の設定ファイルを利用する このエントリーを含むはてなブックマーク

背景

プログラムの入力ファイル(設定ファイルなど)をXML形式にしたいとする。

XMLの形式を作成する

入力ファイル(設定ファイル)が非常に簡単な形式なら、今回のような工夫は必要ありません。しかし、本当に簡単な形式であったとすれば、そもそもXML形式である必要すらありません。そこで、今回は、とある項目があったりなかったり大規模であったり論理的な制約があるなど、XMLにするだけ複雑だとします。

そんなとき、まずはその複雑なXMLファイルの定義を作成する必要があります。今回は、その定義をXML Schemaという形式で作成します。作成したファイルの拡張子は.xsdです。.xsdファイルの書き方についてはいつか記事に出来ればと思っています。かなりとっかかりがつかみにくいので

XML Schema(.xsd)ファイルからC#のクラスファイルを作成する

.xsdファイルから.csファイルを作成します。この作成には、Visual Studioに含まれるXMLスキーマ定義ツール(xsd.exe)を利用します。Visual Studio 2008で確認すると、xsd.exeは「C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\xsd.exe」にあります。

そして、XMLSchema.xsdは、次のようにしてC#のクラスファイルに変換可能です。

>xsd.exe /l:cs /c XMLSchema.xsd

XMLSchema.xsdで定義されたXML Schemaに従って作成されたファイルは、生成されたC#のクラスにデシリアライズ可能です。しかし、XML Schemaを完全に反映したクラスファイルになっていない点に注意してください。たとえば、maxOccursなどは反映されないので、生成されたクラスを必ずしもXML Schemaに従ったXMLファイルにシリアライズ可能というわけではないみたいです。

また、生成するクラスの名前空間を指定したい場合は、指定したい名前空間が「MyNameSpace」のときは、次のようにすればOKです。

>xsd.exe /l:cs /c XMLSchema.xsd /n:MyNameSpace

シリアライズ・デシリアライズ

ここまで来れば、あとはシリアライズだろうがデシリアライズだろうが自由にやってあげてください。これについては、以下のmsdnが参考になります。

スポンサーサイト
.NET | コメント:0 | トラックバック:0 | 編集

regsvr32の「依存.DLLファイルに問題がないかを調べてください」について(3) このエントリーを含むはてなブックマーク

前回は、DLLが参照しているDLLの一覧をdumpbin.exeを利用して取得しました。

そのDLLは、

  • KERNEL32.dll
  • GDI32.dll
  • ADVAPI32.dll
  • ole32.dll
  • OLEAUT32.dll
  • SHLWAPI32.dll
  • MSVCR70.dll
  • RPCRT4.dll
であり、この中に問題があるDLLが含まれていることになります(前々回参照)。

では、ささっと調べてみましょう。基本的な調べ型は、まずWeb検索ですが、今回は、問題があるDLLをまず1つ見つければいいので、あらっぽく調べます。

system32フォルダ

system32フォルダ内にDLLがあれば、とりあえず利用可能になっていると考えられます。 実際、

  • MSVCR70.dll
以外はすべてsystem32フォルダ内部にありました。

MSVCR70.dll

msvcr70.dllは、Visual C++ version 7.0 用のdllです。ちょっと古いです。

msvcr70.dllは、BANG.ROや、DLL-files.comNODEVICE.jpなど、多くのサイトからダウンロードできます。信頼できるサイトからダウンロードしましょう。また、普通はソフトウェアに付属しています。

たねあかし

実は、RealThumb.dllのreadme.txtには、

---------------
Troubleshooting
---------------
When installing the program, you may get the message "LoadLibrary("RealThumb.dll") failed - The specified module could not be found." This message means that the computer is missing a DLL, most likely MSVCR70.DLL (Microsoft Visual C++ 7.0 Runtime Library). This file should be in C:\WINDOWS\SYSTEM32. If you do not already have it, you can download a copy from . Copy it to the directory, then try installing again as above.
と書かれており、msvcr70.dllをsystem32フォルダにコピーして利用するように書かれています。今回の記事では、あえてこのような表記がなかったもしくは見つけられなかった場合などを含めて、前々回紹介したようなエラーに出くわしたときにどうするべきかを記述しました。

MSVCR70.dllをSystem32フォルダへ

いよいよ終盤。MSVCR70.dllをDownloadしたら、System32フォルダへコピーします。

そして、もう一度

C:\Wiondows\system32>regsvr32 RealThumb.dll
を実行すると、
RealThumb.dll の DllRegisterServer は成功しました。
と表示されて、無事成功しました。めでたしめでたし。

実は

実は、regsvr32的には成功したのですが、サムネイル表示がされませんでした。残念。

おわりに

今回は記事3回に渡って、RealThumb.dllを題材に、dllが利用するdllを調べる方法について説明しました。dllだけではなく、exeが利用するdllも同様に調べられるので、なにか問題が発生したときには、ぜひ試してみてください。

Windowsダンプの極意 エラーが発生したら、まずダンプ解析!
Windowsデバッグの極意 ツールを使いこなして、バグハント!
Debug Hacks -デバッグを極めるテクニック&ツール

Windows | コメント:0 | トラックバック:0 | 編集

regsvr32の「依存.DLLファイルに問題がないかを調べてください」について(2) このエントリーを含むはてなブックマーク

今回は、「regsvr32の「依存.DLLファイルに問題がないかを調べてください」について(1)」の続きで、DLLが利用しているDLLを調べる方法についてとりあげます。

詳細は前回の記事参照と言うことで、今回はとにかくRealThumb.dllが参照しているdllを特定することにします。

dumpbin.exe

今回は、dumpbin.exeを利用します。Visual Studioに付属するツールで、Visual Studio の無償版に付属するかは不明です。

dumpbin.exeは、

"C:\Program Files\Microsoft Visual Studio 9.0\VC\bin\dumpbin.exe"
(Windows Vista SP2, Visual Studio 2008)
にあります。

dumpbin.exeをコマンドプロンプトから実行してみる

では、実行してみましょう。コマンドプロンプトから、とりあえず

C:\Program Files\Microsoft Visual Studio 9.0\VC\bin\dumpbin.exe /?
と実行して、dumpbin.exeのオプション一覧の参照しようとすると、

link.exe - コンポーネントが見つかりません

mspdb80.dll が見つからなかったため、このアプリケーションを開始できませんでした。アプリケーションをインストールし直すとこの問題は解決される場合があります。

というエラーが発生した後、Microsoft Incremental Linkerは動作を停止しましたと表示されてしまい、結果としてdumpbin.exeが実行できません

dumpbin.exeの正しい利用方法

このように、dumpbin.exeは、コマンドプロンプトから実行しようとすると、失敗します。

そのため、コマンドプロンプトからではなく、Visual Studio に付属するVisual Studio 用のコマンドプロンプトを利用してください。すべてのプログラム>Microsoft Visual Studio 2008>Tools>Visual Studio 2008 コマンドプロンプトから起動できます。

ここから余談。下の「DLLが参照しているDLLを調べる」へどうぞ。

たとえば、Visual Studio 2008だと、「Visual Studio 2008 コマンド プロンプト」は、

C:\Windows\System32\cmd.exe
にあります。

お気づきの通り、実態は普通のコマンドプロンプトです。実は、スタートメニューのすべてのプログラムからMicrosoft Visual Studio 2008のフォルダのToolsフォルダにある「Visual Studio 2008 コマンドプロンプト」から起動できるのですが、実際は、

%comspec% /k ""C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat"" x86
というコマンドでコマンドプロンプトを起動しているに過ぎません%comspec%は実行ファイルである「C:\Windows\system32\cmd.exe」に展開されます。

ここで、cmd.exeの/kオプションは、続くダブルクオテーションで与えられた引数をコマンドとして実行するオプションです。

つまりこのコマンドでは、vcvarsall.batがx86という引数で実行されます。

vcvarsall.batの内部では今回の引数x86だけではなく、amd64、x64、ia64、x86_amd64、x86_ia64を引数として受け付け、引数に応じたbatファイルを呼び出します。

x86の場合は、vcvars32.batC:\Program Files\Microsoft Visual Studio 9.0\VC\bin\vcvars32.batを呼び出し、さらにvcvars32.batがvsvars32.batC:\Program Files\Microsoft Visual Studio 9.0\Common7\Tools\vsvars32.batを呼び出します。

このvsvars32.batの内部で必要な変数を登録しています。変数が登録されたおかげでdumpbin.exeが正しく動くcmd.exeが起動されているわけですね。

ちょっと余談でしたが、とにかくdumpbin.exeを利用するときは、Visual Studio コマンドプロンプトから実行してください。

DLLが参照しているDLLを調べる

ついに、本題です。前述の通り、Visual Studio 2008 コマンドプロンプトを起動して、

C:\(略)\VC>bin\dumpbin.exe /dependents C:\Windows\system32\RealThumb.dll
と実行します。すると、
Microsoft (R) COFF/PE Dumper Version 9.00.21022.08
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file C:\Windows\system32\RealThumb.dll

File Type: DLL

  Image has the following dependencies:

    KERNEL32.dll
    USER32.dll
    GDI32.dll
    ADVAPI32.dll
    ole32.dll
    OLEAUT32.dll
    SHLWAPI.dll
    MSVCR70.dll
    RPCRT4.dll

  Summary

        1000 .data
        1000 .orpc
        3000 .rdata
        1000 .reloc
        4000 .rsrc
        8000 .text
と表示されて、
  • KERNEL32.dll
  • GDI32.dll
  • ADVAPI32.dll
  • ole32.dll
  • OLEAUT32.dll
  • SHLWAPI32.dll
  • MSVCR70.dll
  • RPCRT4.dll
が、RealThumb.dllが参照しているDLLということが分かりました。

次回は、このDLLたちの正体を探ります。

Windowsダンプの極意 エラーが発生したら、まずダンプ解析!
Windowsデバッグの極意 ツールを使いこなして、バグハント!
Debug Hacks -デバッグを極めるテクニック&ツール

Visual Studio | コメント:0 | トラックバック:0 | 編集

アプリケーションの特定にSpy++ このエントリーを含むはてなブックマーク

突然表示されるエラーメッセージや、アプリケーションから間接的に起動された別のアプリケーション。エラーを起こしたプログラムは何なのか、実行ファイルはどこの何というファイルなのか、表示されている画面を見ても、特定できないことがあります。

そんなときに使える、「Spy++」というツールがあります。

今までWebページ上で見かけることはあっても、使ってはいませんでした。使ってみると便利なのでメモ。

Spy++

Spy++は、Visual Studioの一部というか、同時にインストールされるツールのうちの一つです。その他のツールには、errlook.exeなどがあります。

Spy++は、実行ファイルを特定するのに便利ですが、Spy++自身の実行ファイル名は、spyxx.exeです。Spy++の場所は、

C:\Program Files\Microsoft Visual Studio 9.0\Common7\Tools\spyxx.exe
(ただし、環境はWindows Vista SP2, Visual Studio 2008)
です。少しわかりにくいというか、紛らわしかったりするので、"C:\Program Files"内を"spyxx.exe"というファイル名で検索するとすぐ見つかると思います。

Spy++の使い方

利用方法ですが、ダブルクリックで起動し、「スパイ(S)>ウィンドウ検索(F)...」で、「ウィンドウ検索」ダイアログを表示させ、中央にある「ターゲットマークの画像」を目的のアプリケーション画面やダイアログにドラッグアンドドロップします。すると、「ハンドル」のテキストボックスにそのハンドルが入力されます。

そして、OKをクリックすると、「プロパティ インスペクタ」が表示されるので、「プロセス」タブを選択し、「プロセス ID:」の右に表示されている数字をクリックします。

すると今度は「プロセス プロパティ」が表示されるので、「モジュール名」をメモしますメモしなくても、表示しっぱなしでOK

続いて、タスクマネージャを「Shift + Ctrl + Esc」等で起動します。「プロセス」タブを選択した状態で「表示(V)>列の選択(S)...」で表示される「プロセス ページの列の選択」ダイアログで、「イメージパス名」にチェックを入れてOKをクリックして閉じます。あとは、プロセスタブ中の「イメージ名」の中から先ほどメモった「モジュール名」を探し、該当する「イメージ パス名」を見つけます。

このイメージ パス名が、ウィンドウを表示しているアプリケーションの正体です。

実行ファイルパスを特定できたら

Spy++で、とりあえずファイルパス名が分かったら、その実行ファイル名でWeb上を検索しましょう。

名前が分からないと満足に検索もできない」の記事で紹介したように、調べたいものの名前が分からないと、検索できません。Spy++を使うことによって、検索したいものの名前を見つけることができました。あとは、検索で関連情報を見つけてください。

Spy++便利ですね。

ひなた先生が教えるデバッグが256倍速くなるテクニック
Windowsデバッグの極意 ツールを使いこなして、バグハント!
Debug Hacks -デバッグを極めるテクニック&ツール

Visual Studio | コメント:0 | トラックバック:0 | 編集

msdnが新デザインに このエントリーを含むはてなブックマーク

msdnライブラリが新デザインになりました。

msdnライブラリはほぼ毎日見ているので、だんだんと変化したのが分かりました。

今までは、濃いオレンジ色がベースで、msdnのロゴには、右下に矢印がありました。

そして、ついこの間、その濃いオレンジ色だった背景が、濃い青のグラデーションになりました。ちなみに、背景に模様はありません。また、背景は変わりましたが、オレンジ色の矢印のあるロゴはそのまま。

そして、何より大きな変化が、右下に出るようになったビューの切り替えというボタン

ボタンを押すと、

  • クラシック
  • ライトウェイト
  • ScriptFree
という3つの選択ができます。

クラシックは今までと同様です。

ライトウェイトは、すっきりとしたデザインで、言語ごとに表示されていたサンプルコードが、一つにまとめられ、タブ表示になっています。また、いままで左のツリー表示が、ただのリンクになっています。

ScriptFreeは、まさしく、JavaScriptなしのページです。ライトウェイトよりも、さらにシンプルですが、見た目は今までの表示に近いままです。しかし、左のツリーはシンプルなものに変わっています。なぜかライトウェイトよりも見やすい

結論から言うと、見た目は好みですが、ライトウェイトと言いつつ、msdnが重いのはそういう問題じゃないよねということです。検索や、ページ間移動に時間がかかりすぎます。

そんなときのためのオフラインで利用できるmsdnライブラリですが、これまた、ローカルといえども、フリーワード検索にはとても時間がかかります。さすがにページ間の移動は早いですが、たまに、リンク切れ(?)になっているリンクがあったり。。。Visual Studio 2010がもうすぐということでわくわくしていますが、こんなところも改善されるといいですね。なんだか、2010のbetaは遅いみたいですが

Visual Studio | コメント:0 | トラックバック:0 | 編集
 | HOME |  OLD >>
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。