お世話になります。かまたです。
早速ですが
①VC++2005で.NETでアプリケーションとDLLを作成しました。
②一つのソリューション内にアプリケーションとDLLのプロジェクトがあります。
③現在まで、私の環境ではなにも問題なく動いていました。
④クライアントにはDLLのソースは公開したくないため、
DLLのプロジェクトのみ削除してソリューション一式を送付しました。
⑤ところがクラアントの環境でアプリケーションをデバックしようとすると
(アプリケーションのコードに対する変更はありません)
以下の様なエラーが発生してアプリケーションのフォームすら表示されません。
『'SystemIO.FileLoadException'のハンドルされていない例外が
System.Windows.Forms.dllで発生しました。
追加情報: ファイルまたはアセンブリ '～ Version=～,
Culture=neutral,PublicKeyToken=null'、
またはその依存関係の一つが読み込めませんでした。
アプリケーションを再度インストールすることにより
問題が解決する場合があります。』
⑥他のVC++2005がインストールされている環境でも同様でした。
⑦ところが問題が発生する環境でDLLリビルドして
アプリケーションのみのソリューションへコピーして
デバックを行うとうまくいきます。
⑧.NETのDLLはアプリケーション側で
#using hogehoge.dll
の様な形で使用しています。
正直、なにが問題なのか検討もつきません。
参照とかその辺りなのでしょうか？
アプリケーションのプロパティでは自作のDLLは参照していないのですが‥
(というか問題が発生してから無駄な参照と思われるものは全て削除しました)
ただ、気になるのがDLL側で定義した構造体をアプリケーション側でも
使用するために『プロジェクトの参照』を行ったのですが
(参照を行わないとビルドが通らなかった)、
現在参照を切ってもビルドが通ります‥。
クラアントにDLLのソースを公開してリビルドしてもらえば
問題ないのかもしれませんが、どうしても避けたい状況です。
識者の方々、なにかアドバイス等ありましたら
ご教授いただければ幸いと思います。
よろしくお願いいたします。
SP1が適用されてるかどうかの環境も同じですか？
＞通行人さん
返信有り難うございます。
確認してみました。
問題が発生した環境と私の環境では
VisualStudioのバージョンも.NET Frameworkのバージョンも一致していません。
私の環境
Microsoft Visual Studio 2005
Version 8.0.50727.762 (SP.050727-7600)
Microsoft .NET Framework
Version 2.0.50727 SP1
問題が発生する環境
Microsoft Visual Studio 2005
Version 8.0.50727.42 (RTM.050727-4200) ← テスト環境がありませんでした
Microsoft .NET Framework
Version 2.0.50727
ただし、同様の問題が発生するクラアントのVisualStudio環境はRTMではないです。
どうなんでしょうか。この辺も影響してくるのでしょうか？
影響するとしたら、特定のバージョンのVisualStudioでビルドしたDLLは
違うバージョンのVisualStudioでビルドしたアプリケーションからは
使用できないのでしょうか？
(以前VisualStudio.NET 2003で作成したDLLを
VisualStudio2005から使用してみましたが、問題なく使えましたが‥)
俺の経験
.NETではなくC++だし
VC6やVC2005などのことだが
SPなど少しでもバージョンが違うデバッグ版のDLLを動かすとデバッガが誤動作する。
.NETでもそうなのかもしれない。
推測です。
リリース版DLLという手もある。
ソース渡さないんだからこのDLLにデバッグ情報要らないし。
無論デバッグ版EXEから呼び出すと問題あるつくりだとNGだけど。
そのあたり.NETのことは俺知らん。
＞wclrpさん
返信誠に有り難うございます。
クラアントにはアプリケーションの
カスタマイズを行ってもらいます。
(渡しているアプリケーションは
あくまでDLL使用方法のサンプルとしてです。)
なのでクラアントがこちらで作成したDLLで
アプリケーションのデバックができなければ困るので
デバックビルドおよびリリースビルドのDLLのみを渡したいと思っています。
＞subaruさん
いつも適切なアドバイス、本当に有り難うございます。
ずばりsubaruさんが示してくれた問題そのものだと思うのですが
情けないことに現在ドキュメントの読解に苦しんでいます。
『DLLのプロジェクトのマニフェストの生成をOFFにすればいいのかなぁ‥』
『アプリケーションのプロジェクトの設定は変えなくていいんだよなぁ‥』
の様なレベルです。
もう少し示していただいたドキュメントの読解に努力してみます。
お世話になっております。かまたです。
以下の方法等試してみたのですが
①
mt /manifest CppCLI.dll.intermediate.manifest /outputresource:CppCLI.dll;#2
ビルド後、DLLとintermediate.manifestファイルを同じパスに置き
コマンドラインから実行、上記のコマンド実行 → 正常終了
②
vcredist_x86.exeを開発環境から問題のある環境にコピーしインストール
③
ソリューションからDLLのプロジェクトを削除し、問題が発生する環境にコピー。
問題が発生する環境でソリューションを開き、アプリケーションリビルド → 問題なし
デバック開始 → NG
カオスモードです‥。
試しにですが、プロジェクト参照を行わないので
DLLとアプリケーションを作成した場合は問題ありませんでした。
どうもこの辺が怪しいと踏んでいます。
(subaruさんのご指摘通り、ここだろうと思いますし、
アプリ側のプロジェクト参照を切りたい)
プロジェクト参照の削除の仕方を教えていただければ幸いと思います。
表示上、参照からDLLのネームスペースは削除されてはいるのですが、
削除したにもかかわらずDLL側で定義している構造体を参照できるのは
削除されていない証拠かと‥。
しかもプロジェクト参照にはDLLプロジェクトのパスが残ったままになっています。
識者の方々、お手数をおかけしますが、なにかアドバイスを頂ければ幸いです。
DLLのビルドマシンがSP1で、使う側がSP1なしによる
ランタイムのバージョン違いが原因のようなので、
アプリケーション開発側もSP1を当てて環境を合わせることは
できないのでしょうか？
ちなみにプロジェクト参照はそのプロジェクトがビルドしたDLLを
参照するだけで結果的に、
#using hogehoge.dll
と同じ効果があるので直接関係ないような気がします。
削除自体は参照のときと同様のUIから行えます。
VC2005って自動更新されませんでしたか？
インストールしたらすぐ更新ってでましたが..........
基本的に開発環境は合わせるべきだと思います。
少なくともSP1を当てない理由が無いのであれば、当てるべきです。
通常、ライブラリ提供を行う時は使用ランタイムに関しても
条件として提示するのが普通だと思います。
この辺の話に関しては.NETもネイティブも同じではないかと
思います。
subaruさん紹介の記事でも
http://d.hatena.ne.jp/KrdLab/20070224/1172290039
このように書かれています。
やはり、SP1適用が早道ですね。
Windows Update でうまくいったと思います。
＞subaruさん、ITOさん、PATIOさん
かまたです。返信遅れて申し訳ありません。
結局、原因はみなさんが懸念されていたとおりSP1でした。
うまくいかなかったのは
DLL内でもさらにネイティブなDLLを使用していました。
ですが、そのドライバがインストールされていませんでした。
申し訳ありません。つまらないところでゴチャゴチャになっていました。
みなさん、本当に沢山のアドバイス有り難うございました。
特にsubaruさんにはお世話になってしまいました。
本当に参考になりました。
みなさん、どうぞ今後ともよろしくお願いいたします。
返信する
最新の投稿: お久しぶりです、いかがお過ごしでしょうか。 最新のメンバー: gantez 最近の投稿 未読の投稿
