- ベストアンサー
VB.NETで参照設定したDLLの修正反映
- VB.NETで開発している場合、参照設定したDLLを修正した場合にはリビルドが必要ですか?
- 「Const.dll」を修正しても、参照設定先のモジュールは仕様変更前のパスで処理しようとしてしまいますか?
- 参照設定先のモジュールを修正した場合、参照設定元のモジュールもリビルドが必要ですか?
- みんなの回答 (3)
- 専門家の回答
質問者が選んだベストアンサー
ConstではなくShared ReadOnlyにしましょう。 Public Shared ReadOnly TEST_PATH As String = "C:\Temp"
その他の回答 (2)
- _backyarD
- ベストアンサー率34% (199/580)
その程度の修正であれば、普通は利用側(参照している方)はビルドし直す必要無く、古いDLLに上書きコピーするだけでOKのはずです。 念のため確認ですが、まず、 ・古いのを参照しているというのは、 参照する側のVisual Studio上での動きか? それとも、参照する側をビルドして、VisualStudioを介さずに 動かしたときの話か? この点がちょっとよく分かりません。開発環境か、稼働環境かということですね。稼働環境であれば、冒頭に書いたとおり「これまでのConst.dllに新しいConst.dllを上書きするだけ」です。 Visual Studio上での動きについてであれば、まず確認すべきなのは ・変更したConst.dllの完成品を、Const.dllを利用する(参照する)ソースが 参照している場所に正しく置いていますか? ですね。参照先のパスはプロジェクトのプロパティに出ているはずなので、そのフォルダに「新しいConst.dllが置いてあるか」を確認するのが先決です。置いてあるのに参照がおかしい場合、ありそうなのは「ローカルコピーがFalseになっていて、参照しているフォルダと、デバッグモードなどで動かすときのフォルダに違うバージョンのConst.dllが入ってる」というようなケースですね。 基本、ローカルコピーはTrueのまま使うのをお勧めします。そうすれば、参照先とVisual Studio上での動作フォルダのDLLは同一になるので、普通は問題になりません。 なお、この手の問題を回避/予防/検出する良い方法として、DLLのバージョン番号を変更のたびに更新し、機能の変更とバージョン番号の対応をきちんと記録しながら「今使ってるDLLはどのバージョンか」がバージョン番号で判るようにするというものがあります。 一旦混乱が起きると、ちょっとした間違いでもあっという間に時間を消費するので、面倒かもしれませんがこうした管理をきちんとすることでトータルの作業時間は少なくなりやすいです。 ダラダラ書きましたが、参考になれば幸いです
補足
申し訳ございません、古いのを参照しているのは「参照する側はビルドせず、VisualStudioを介さずに動かした場合」です。 そして参照設定で、「ローカルコピー = True」にしています。 基本的には上書きするだけ、というイメージはあっているということですね。認識相違がなくて良かったです。 ただ、動作が想定どおりでないので、困ってはいますが。 さらに現状を詳しく書かせていただくと、 実行EXEを起動すると、別出しで処理を記載しているDLL((1))を呼び出します。 (1)の別だし処理DLLで、質問させていただいた「Const.dll」をImportし、(1)の処理を行っています。 新しい「Const.dll」の参照設定が正しいことを確認した上で、 DLL((1))を再ビルドすると、変更後パスで処理するようになりました。「Const.dll」を上書きしても、再ビルドしていないDLL((1))では、変更前パスで処理しようとしています。 他に何か考えられることはありませんでしょうか。 お手数をお掛けしますが、よろしくお願いします。
- redfox63
- ベストアンサー率71% (1325/1856)
参照設定で指定したDLLをローカルコピー=Trueにしていませんか? つまり 他の場所にあるDLLを自分のプロジェクトの出力フォルダーにコピーする設定ですとご質問のような現象になると思います
補足
ご回答ありがとうございます。 参照設定のローカルコピーをFALSEにしても、同様の事象が発生してしまいます。 ビルドした利用側モジュールのなかには、Const.dllの情報も含まれているのでは、と思ってしまいます。
お礼
ご回答いただいた内容で解決しました!ありがとうございました! 他のご回答いただいた方もご協力ありがとうございました!