2011-01-01 9 views
8

私は数多くのプロジェクト(クラスライブラリとWebアプリケーション)を備えた.NET Visual Studioソリューションを持っています。"ファイルまたはアセンブリ 'XXX.YYY'またはその依存関係の1つを読み込めませんでした。システムは指定されたファイルを見つけることができません。

プロジェクト間でファイルを移動したり、新しいプロジェクトを作成したり、削除されていないプロジェクトを削除したり、既存のプロジェクトの名前を変更したりしました。

ソリューションは問題なくビルドしますが、私は、Webアプリケーションを実行すると、次の例外が発生します。

「ファイルまたはアセンブリ 『XXX.YYY』またはその依存関係の1つをロードできませんでしたシステムが見つけることができません。ファイルが指定されました。

refractoringで削除されたXXX.YYYというプロジェクトは、XXX.YYYというdllを出力しました。しかし、これはアプリケーションのどこにも使われていません。私は、Webアプリケーションのobjディレクトリとbinフォルダを削除して再構築しますが、それでも問題は発生します。

これが発生している可能性がある場合は、誰でも任意のアイデアがあります。

UPDATE:私の問題について

更新。私はコードの場所を別のコンピュータに持ち込み、そこから実行し、この問題が発生しなければ正常にビルドして実行しました。だから、この問題はコードベースではなく私のPCであると私は思う。多分私のPCに何かがキャッシュされているかもしれません。私は "C:\ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Temporary ASP.NET Files"で一時ファイルを削除しましたが、運はありません。

キャッシュされている可能性がある他の理由、または私のPCでそれが発生する他の理由。

FURTHER UPDATE

この上の別の更新。他の開発者のマシンで同じコードを実行していて、実行している問題がありません。間違いなく私のマシン上に何かあるはずです!私たちのマシン上の唯一の違いは、私がIIS7をそのアプリケーションのアプリケーションプールでクラシックモードで実行していることです。他の開発者はIIS6を実行しています。

2つの新しい情報です。まず、web.configのhttpmodulesで、カスタムhttpモジュールを削除してから追加する必要があります。他の開発者はこれを行う必要はありません。第2に、「XXX.YYYまたはその依存関係のファイルまたはアセンブリをロードできませんでした」という問題を、「XXX」というプロジェクトでクラスライブラリを作成することによって短期的な修正となる「ハック」を介して修正できました。 .YYYと検索されるクラスを含む。これはすべてカスタムコントロールです。 System.Web.UI.WebControls.WebControlから継承します。

どれさらに思考....

+0

リフレクターを試しましたか? – jgritty

+1

ASP.NETの一時ファイルディレクトリをクリーンアップしようとしましたか? C:\ WINDOWS \ Microsoft.NET \ Framework \ v2.0.50727 \ Temporary ASP.NET Files –

+0

@Harvey - 一時ファイルを削除しようとしましたが運がまだありません – amateur

答えて

0

素晴らしいニュース私は問題を解決しました! .netランタイム環境を再インストールする必要がありました。私はまた、IISからサイトを削除し、再びウェブサイトを読んだ。私がそれを実行したとき、問題は発生せず、サイトは実行されました。

大変感謝してくれた皆様、お手伝いをしていただきありがとうございます。すべてのアドバイスと助けが私をこの問題を解決する方向に向ける!

1

ちょうどあなたの参照とあなたの主なプロジェクトの64ビットコンパイルされたDLLがある場合、32ビット(または任意のCPUとマシンが32でます。..コンフィギュレーションを構築するプロジェクトをチェックビット)またはその逆の場合は、このエラーが発生します

+0

でない場合は、** BadImageFormat **例外をスローしないと試してみる価値はあると思いますか? – BrokenGlass

+0

@BrokenGlass - はい..「ファイルまたはアセンブリ 'XXX.YYY、Version = 1.0.XXX、Culture = neutral、PublicKeyToken = null」またはその依存関係の1つを読み込めませんでした。 –

1

Dependency Walker(依存する)をすべてのEXEとDLLに使用して、いずれの依存関係が欠落しているかを確認します。最良の結果を得るには、プロジェクトの作業ディレクトリから依存する必要があります。

どのEXE/DLLが原因であるかを知ったら、そのプロジェクトの設定に行き、そこに依存関係について述べられているかどうかを確認してください。

EDIT:数分前に別のことが起こりました... 依存関係のいずれかが、実行可能コードのロードを妨げる可能性があるMSのハードウェア(たとえば、Inetエクスプローラを使用してDLするとき)によってダウンロードされたとマークされているため、「ブロック」されています。 Windowsエクスプローラで実行ファイル(DLL/EXE)のプロパティを見て、最初のページにブロック解除ボタンがあるかどうかを確認します。その場合は、そのボタンをクリックします。 これは私がしばらく後で理解するのに時間がかかりました。うまくいけば助けになるでしょう。

+0

Windowsエクスプローラを使用して、私はbinディレクトリのすべてのdllを右クリックし、プロパティを表示しました。私はどこにでもブロック/ブロック解除を見なかった。これに関係しているなら、どこで見たらいいですか?私はDependency Walkerをあらかじめ使っていないので、私は初心者です。 binディレクトリの各dllファイルを開きますか? (注:binディレクトリはWebアプリケーションのディレクトリです。すべてのクラスライブラリで必要ですか?私は30以上あります) – amateur

+0

依存関係ウォーカーは、私が知る限り、PEのインポートとエクスポートのテーブルからDLLの依存関係を解決します。彼がいくつかのアンマネージDLLを使用していない限り、私は依存性ウォーカーがどのように役立つのか分かりません。最新の依存性歩行者もアセンブリの参照を歩くことができますか? –

+0

@Niall Collins:ブロックオプションはありません。ブロックを解除するだけです。あなたがそれを見ないなら、あなたは大丈夫でしょう。 – JimR

0

"XXX.YYY"というテキストを検索してすべての発生を削除します。たぶん、あなたはいくつかのweb.configファイルに残っている可能性があります。

また、ソリューション検索で何も検出されない場合は、* .csprojファイルを確認できます。基本的にテキストファイルなので、参照を削除する際に問題はありません。

+0

XXX.YYYのソリューション全体(すべてのファイル)を検索しようとしましたが、参照が見つかりませんでした。あなたの入力のおかげで – amateur

0

あなたは単に依存関係がありません。おそらくプロジェクトAのような状況は、プロジェクトCの参照を持つプロジェクトBへの参照があります。出力ディレクトリにプロジェクトCのDLLがありません。

+0

しかし、この場合、ソリューションは構築されませんでした - 正しい?ソリューションは大丈夫です。 – amateur

+0

@Niall必ずしもそうではありません。すべてのプロジェクトは同じソリューションになっているので、各プロジェクトには必要な参照があり、すべてが依存関係を構築するために必要な順序で構築されています。公開されたアプリケーションの場合、binフォルダに必要なすべてのDLLが含まれている限り、アプリケーションは実行されますが、単一のDLLが見つからない場合は、発生している問題が表示されます。あなたはIISにアプリケーションを公開しているのですか、あるいは単にVSでデバッグしていますか? – mikesigs

+0

興味深い。 Windows 7のローカルIIS7で実行しています。これは問題でしょうか? – amateur

5

考えられる原因は2つあります。

1)webappを実行しても、マシン上の古いアセンブリは引き続き使用されます。あなたの古いアセンブリは古いアセンブリ "XXX.YYY"を参照していました。

2)作成した最新のバイナリは、依然として古いアセンブリ "XXX.YYY"を参照しています。

ウェブアプリケーションがどのアセンブリを使用しているかを調べるには、デバッガを実行している場合は、出力ウィンドウから簡単に見つけることができます。出力の最初の数行でなければなりません。もう一つの方法は、デバッグ中にVS.NET IDEでモジュールウィンドウを開くことです。

何らかの理由でデバッグできない場合、またはデバッガを接続する際に問題が発生した場合は、fuslogvwを使用して簡単に行うこともできます。これは、正常にロードされたすべてのアセンブリの正確な場所と、ロードに失敗したアセンブリを提供します。 Windows 7の管理者としてfuslogvwを実行してください。

Webappが正常にロードされたアセンブリを見つけたら、それらのアセンブリでildasmを実行して、参照しているアセンブリを確認できます。あなたは残念なことにそれらを一つずつチェックする必要があります。

正常に読み込まれたアセンブリのいくつかは、実際にはASP.NETキャッシュまたはGACのどこかから来ていると思います。

+2

+1教育のため。私はfuslogvwについて知らなかった。 – JimR

+0

私は融合ロガーについても言及したかったが、私はそのツール名を覚えていなかった。 – jgritty

1

ビルド出力(TOols - >オプション - >ビルドアンドラン - >出力ログ詳細 - >診断)の診断ログを有効にし、ソリューションをビルドし、Visual Studioがdllを選択する場所(somedll.dllバージョンxxx)を確認します。 yy)。次に、アプリケーションを実行し、ランタイムがdllを解決しようとしている場所を確認します。 (Windbgはオプションです)。

0

Solution ExplorerVisual Studioに移動します。不平を言っているアセンブリを選択してください。それを選択し、メニューオプションViewに行き、下部にProperty Windowを選択して下さい。アセンブリが選択されている間、プロパティウィンドウでそのプロパティを表示し、Copy Localの値を探します。値がFalseに設定されている場合は、Trueに設定します。ソリューションをビルドして公開します。それは問題をうまく解決するはずです。

関連する問題

 関連する問題