1

私のソリューションで非常に奇妙なエラーが発生しました。クラスライブラリである私のプロジェクトの1つが、参照されているプロジェクトにTypeLoadExceptionをスローさせています。私はSOに関するさまざまな回答を調べましたが、私の問題に最も近いのは次のとおりです。

TypeLoadExceptionはC#で処理されませんでした[クローズ]

この回答により、これが私の問題であるかどうかを疑問視することになりました。デバッグフォルダーを掘り下げて、クラスライブラリを参照しているプロジェクトが同じ名前のDLLとEXEを生成していることがわかりました。これが私の問題でしょうか?

もしそうなら、どうすればこれを修正できますか?、このプロジェクトで参照されている他のクラスライブラリがソリューションにあり、DLLファイルとEXEファイルの両方を生成していません。

4

3 に答える 3

3

私はそれを信じていませんが、私は実際に同僚を介して原因を見つけました.これがこれに遭遇した他の人を助けることを願っています.

その理由は、私のクラス ライブラリを参照している私のプロジェクトが同じアセンブリ名を持っていたためです。名前空間の再ジグを行っていたのですが、メイン プロジェクトが同じ名前であることに気づいていませんでした。これは、私のコードがビルドされたときにコンパイラがメイン プロジェクト用に EXE を作成し、クラス ライブラリ用に DLL を作成すると、コンパイラが同じ名前の EXE を既に読み込んでいたため、TypeLoadException が強制的に発生しました。

私のコードは現在動作しています。時間を割いて投稿してくれたすべての人に感謝します。

于 2012-11-05T17:07:28.197 に答える
2

クラス ライブラリが同じ名前の DLL と EXE を生成しています

はい、それがこの問題を引き起こします。Fuslogvw.exe を実行し、すべてのバインドをログに記録することで、簡単に確認できます。これは Fusion のやや奇妙な癖ですが、アセンブリを探すときはファイル名だけを調べて拡張子を無視します。.dll と .exe の両方を、探しているアセンブリの許容可能な一致として受け入れます。これはある程度論理的ですが、マネージド コードが含まれている場合、DLL と EXE の間に真の違いはありません。たとえば、EXE の参照は完全にサポートされています。

ローダーにこれを別の方法で強制する方法はありません。それ以外の場合、回避策は簡単です。必ず個別のアセンブリ名を生成してください。

于 2012-11-05T17:50:55.340 に答える
1

Project -> (YourProjectName) Properties -> Application の下で、"Output Type" が "Class Library" に設定されていることを確認します。

于 2012-11-05T16:55:31.157 に答える