web-dev-qa-db-ja.com

ファイルまたははアセンブルを読みませんでした...誤った形式でプログラムを読みましょうとしました(System.BadImageFormatException)。

私は2つのプロジェクトProjectAProjectBを持っています。 ProjectBはコンソールアプリケーションで、ProjectAに依存しています。昨日は、すべてが問題なく動作していましたが、突然今日ProjectBを実行すると、次のようになります。

BadImageFormatExceptionが処理されませんでした
ファイルまたはアセンブリ 'ProjectA、バージョン= 1.0.0.0、カルチャ=ニュートラル、PublicKeyToken = null'、またはその依存関係の1つをロードできませんでした。誤った形式でプログラムをロードしようとしました。

どちらも通常のプロジェクトであり、他の非.NETプロジェクトには依存していません。どちらも完全に.NETです。ネイティブコードもP/Invokeもありません。私はProjectAに依存していてもまだうまく動作する他のプロジェクトを持っています。

私が試したこと

  • build チェックボックスがチェックされた状態で、両方のプロジェクトが "Any CPU"に設定されていることを確認してください。彼らです。
  • 両方のプロジェクトが同じターゲットフレームワーク用であることを確認してください (.Net 4.0 Client Profile)
  • [ProjectB] - > [参照設定] - > [ProjectA] - > [プロパティ]で、 "Copy Local" "True" _ に設定されていることを確認します。正しくコピーされています)
  • ソリューションをクリーン/再構築します。私は手動で両方のプロジェクトの/ binと/ objフォルダを削除しようとさえしました。
  • Visual Studioを再起動します。コンピュータを再起動してください。
  • 全く新しいリポジトリのコピーをチェックしてください。

しかし、私はまだ同じエラーが出ます。私はこれを引き起こすために何をしたのか、それをどのように修正するのかわかりません。何か案は?

32ビット/ 64ビットの競合があることは間違いありません。メインプロジェクトが32ビットに設定されていて、その参照先クラスが64ビットに設定されているようです。 this SO question そして これも を見てみてください。それらの2つの間で、あなたはあなたの問題を理解することができるはずです。

539
Icemanind

サーバーにデプロイした後、Webサイトで問題に直面している可能性があります。

次に、32ビットアプリケーションを有効にするようにアプリケーションプールを調整する必要があります。

ステップ:

  1. IISマネージャを開く
  2. アプリケーションプールをクリックします
  3. 使用しているアプリケーションプールを選択します
  4. 右ペインから、詳細設定...をクリックします。
  5. 32ビットアプリケーションを有効にするをTrueに設定する

enter image description here

170
Ali Adravi

このエラーメッセージは、Visual Studio 2015でIIS Expressを実行したところです。私の場合は、64ビット版のIIS Expressを実行する必要がありました。

「ツール」 - >「オプション」 - >「プロジェクトとソリューション」 - >「Webプロジェクト」
「Webサイトおよびプロジェクトに64ビットバージョンのIIS Expressを使用する」というボックスにチェックマークを付けます。

スクリーンショット

Screenshot of VS options for Web Project.

101
TTT

私はこれと同じ問題を抱えていました。プロジェクトAの「プラットフォームターゲット」(「プロジェクトA」(右クリック) - >「プロパティ」 - >「ビルド」 - >「プラットフォームターゲット」)をx86に設定しましたが、プロジェクトBは「Any CPU」のままにしました。プロジェクトBを「x86」に設定するとこれが修正されました。

23
user1732234

私は、Visual Studio 2015でユニットテスト(xunit)を実行する際にこの問題が発生し、次の修正を見つけました。

Menu Bar -> Test -> Test Settings -> Default Processor Architecture -> X64
13
mkaj

プロジェクトに少なくとも1つの32ビットdll\exeがある場合、IIS 7で アプリケーションプール 設定 "32ビットアプリケーションを有効にする"をTRUEに変更する必要があります。

6
fergal303

まず第一にVS2017でこれを手に入れたのは、古いプロジェクトで 小さな に変更し、すべてのプロジェクトをフレームワーク4.7にアップグレードすることでした。


他の何人かはAny CPUを選択することでこの問題を解決できると述べています。

あなたがそれをする必要があるいくつかの場所があります、そしてそれはドロップダウンから選択するほど単純ではないかもしれません。これは私のためにそれを修正しました:

1)あなたはそれを両方ここでする必要があります:

enter image description here

2)Configuration Manager(解を右クリック)でも

enter image description here

しかし、それがなければどうでしょうか。

それからNewをクリックして以下の設定を選択してください:( thanks @RckLN

enter image description here

3
Simon_Weaver

VSでMSIインストーラを使用して64ビットプロジェクトをパッケージ化しようとしている場合も、この問題が発生する可能性があります。 (「その理由は、.msiファイルに同梱されているネイティブシムが32ビットの実行可能ファイルであるためです。」

詳細についてはこちらを参照してください。 http://blogs.msdn.com/b/heaths/archive/2006/02/01/64-bit-managed-custom-actions-with-visual-studio.aspx

2
G88

私は同じソリューションの複数のプロジェクトで同じ問題を抱えていた、私はターゲットCPUのための.NET Framework 4とx86にすべてのターゲットフレームワークを設定することになった、そしてそれは最終的にうまくコンパイルされた。

2
Flood Techs

Visual Studio Buildステップを使用してVisual Studio Online(VSTS)ビルドでプロジェクトをビルドするときにこれを得ました。

解決策は次のとおりです。

  • 既存のソースフォルダを削除する
  • 依存関係を含むすべてのVisual Studioビルドに対して、プラットフォームに明示的に「Any CPU」を設定します(下のスクリーンショットを参照)。
  • ビルドを再実行してください

VSO Screenshot

2
HockeyJ

これらの解決策のどれも私のために働きませんでした - しかし、binとobjフォルダの内容を削除することによってすべてが再びかっこよかったです。

2
saille

私もプロジェクトでこの問題に直面していますが、数分後に解決策が見つかりました、この問題はCPU構成によるものです、Visual Studio 2010またはVS 201を使用している場合は、プロジェクトに移動してください- プロパティを選択し、サイドバーからコンパイルを選択すると、5つのドロップダウンがあり、5番目のドロップダウンはターゲットCPU:に設定する必要があります要件に応じて、任意のCPUではなくx86またはx64に変更します。

X86に変更した後、私の問題は解決しました。

1
Jawad Nadeem

私のC#プロジェクトでは、プロジェクトプロパティ - > [ビルド] - >プラットフォームターゲット:任意のCPU、およびコンパイラに自動的に選択させるにはPrefer 32-bitのチェックを外してください。

1
bruce

あなたがあなたのプログラムからcli .net統合を介してLibreOfficeを使用している場合私のように、私は同じエラーを受けました。私は私のPC上の実稼働環境でLibreOfficeの古いバージョンを使用しています。競合している新しいバージョンをインストールしました。 LibreOfficeをアンインストールするだけです。 私はここで解決策を見つけました .NET CLI:ファイルまたはアセンブリ 'cli_cppuhelper'を読み込めませんでした

1
Jan Sršeň

私は同じ問題に遭遇しました。それは青から飛び出して、それは私には奇妙に思えました。

FusionLogの例外スナップショットで、私はそのメッセージの中に次のことを見ました。

... C:\ Windows\Microsoft.NET\Framework64 ...

フュージョンログについての詳細: http://msdn.Microsoft.com/ja-jp/library/e74a18c4(v=vs.110).aspx

すべてのプロジェクトはAnyCPUのターゲットCPUを持っていました。私は、アプリケーションプロジェクト(他のすべてのプロジェクトを参照するプロジェクト)をx86のターゲットCPUに変更しました。それは今うまくいきます。

ターゲットCPUの混同が明白な理由もなく発生したかどうかはわかりませんが、発生しました。

1

app.config ファイルに サポートされている複数のフレームワーク を定義し、 上記以外の別の.NETフレームワークでアプリケーションを実行するように強制することによっても、これが発生することがありますapp.configファイルの最初の部分

そして、これはあなたがあなたのシステムで利用可能な言及されたフレームワークの両方を持っているときにも発生します。

回避策として、app.configでデバッグに使用する予定のターゲットフレームワークを起動します。

例:あなたが.NET 4で走らせようとしているなら、configファイルはこれに類似した何かを持つべきです、

<supportedRuntime version="v4.0"/>
<supportedRuntime version="v2.0.50727"/>
1
kuma DK

Chilkat .NET 4.5アセンブリでは、アプリケーションが実行されている任意のコンピュータにVC++ 2012または2013ランタイムをインストールする必要があります。ほとんどのコンピュータにはすでにインストールされています。 Visual Studioがインストールされているため、開発用コンピュータにインストールされます。ただし、必要なVC++ランタイムが利用できないコンピュータに展開すると、上記のエラーが発生します。

以下のパッケージをすべてインストールしてください。

Visual Studio 2013用のVisual C++再頒布可能パッケージ - vcredist_x64

Visual Studio 2013用のVisual C++再頒布可能パッケージ - vcredist_x86

Visual Studio 2012用のVisual C++再頒布可能パッケージ - vcredist_x64

Visual Studio 2012用のVisual C++再頒布可能パッケージ - vcredist_x86

1
Sukesh Chand

私はまた、Visual Studio 2017でReSharperを使用してユニットテストを実行することでこの問題を抱えており、以下の設定でそれを修正しました:

enter image description here

また、ReSharperの実行テスト設定を変更することもできます。 https://resharper-support.jetbrains.com/hc/en-us/articles/207242715-How-to-run-MSTest-tests-using-x64-configuration

0
Feiyu Zhou

シュート!私はこの問題について知っていました。誤ってVSの出力ウィンドウに 'x86'が表示されるまで、私はすべてをうまくやっていたと思いました。それが原因を把握したときです。今日それで数分を無駄にしました。

'Publish'ウィンドウの下の設定は 'x86'に設定されています。それに対して、他のどこでも、それは 'x64'でした。

設定マネージャ、パブリッシュ設定、ソリューション設定、およびIIS設定間で同期されていることを確認してください(Webサーバーの場合)。

また、覚えておいてください - VSは32ビットアプリで、IISは64ビットです。 32ビットアプリケーションは、IISではデフォルトで無効になっています。

enter image description here

0
Mandeep Janjua

それは少し面白いかもしれませんが、私は通常の作業コードで同じ問題を抱えていました。 StreamWriterとStreamReaderを追加したところ、そのエラーが発生しました。解決策は、そのコードをコメントの括弧に入れてからデバッグし、それが再び機能し始めたことです。

0

私の場合は、この例外を投げたDLLに依存関係がありませんでした。 Dependency Walkerに確認し、足りないDLLを追加して問題を解決しました。

具体的には、SVNキーワードを誤って追加することで、どういうわけか私のopencv_core340.dllを破損させたため、私のdllでは使用できなくなりました。しかし、私はこの問題の解決策は、DLLが破損しているか欠けているかどうかに依存しているとは思わない。完全な情報を提供するためにこれを追加しただけです。

0
Alex