ちょっと奇妙な問題があります。
MVC 4と新しいWeb APIを使用してアプリを開発しましたが、ローカルで正常に動作します。サーバーにMVC4をインストールし、アプリを展開しました。今、私は次のエラーを受け取ります:
ファイルまたはアセンブリ「System.Net.Http、Version = 2.0.0.0、Culture = neutral、PublicKeyToken = 31bf3856ad364e35」またはその依存関係の1つをロードできませんでした。検出されたアセンブリのマニフェスト定義は、アセンブリ参照と一致しません。 (HRESULTからの例外:0x80131040)
説明:現在のWebリクエストの実行中に未処理の例外が発生しました。エラーとエラーの発生場所の詳細については、スタックトレースを確認してください。
おもしろいことに、パッケージフォルダーまたはASP.NET MVC 4\AssembliesフォルダーにローカルにあるSystem.Net.Httpのバージョンは1.0.0.0です。実際にプロジェクトからSystem.Net.Httpへの参照を削除しましたが、同じメッセージが表示されます。 2.0.0.0参照の取得元と、サーバーではなくローカルで機能する理由について少し混乱しています。
核の依存関係を見る:
ASP.NET WEb APIコアライブラリ(ベータ)は、System.Net.Http.Formattingに依存しています。
そしてSystem.Net.Http.FormattingはSystem.Net.Httpに依存しています。
これがその由来です。ただし、このパッケージのバージョン2.0.20126.16343がインストールされています。内部のdllにバージョン1.0.0.0が含まれているだけです
何か不足していますか?
更新:
これは別のASP.NETアプリのサブアプリケーションですが、もう1つはまだWebFormsに基づいています。だから、何かが台無しになっています。しかし、web.configのAssemblyセクションでクリーンアップを実行すると、アプリ自体が見つからない場合があります。
アプリをappharborにデプロイする際にも同じ問題が発生しました。問題はまだ.NET 4.5をサポートしていません。私がしたこと。
以前に変換された(.NET 4.5から4.0)WebアプリケーションをIIS 6.0にデプロイしているときに同じエラーが発生しました。
Web.configでruntimeセクションを見つけました
<dependentAssembly>
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="4.0.0.0"/>
</dependentAssembly>
に変更しました
<dependentAssembly>
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-1.0.0.0" newVersion="2.0.0.0"/>
</dependentAssembly>
今では魅力のように動作します。
私の仕事:
1-4から2.0へのリダイレクトに注意
<dependentAssembly>
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="2.0.0.0"/>
</dependentAssembly>
私の場合、私はそれをはるかに簡単な方法で修正し、nugetパッケージへの参照にHintPathを与えるだけです:
<Reference Include="System.Data.Entity" />
<Reference Include="System.Net.Http, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
<Private>True</Private>
+ <HintPath>..\..\packages\Microsoft.Net.Http.2.0.20710.0\lib\net40\System.Net.Http.dll</HintPath>
</Reference>
<Reference Include="System.Net.Http.WebRequest, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
<Private>True</Private>
+ <HintPath>..\..\packages\Microsoft.Net.Http.2.0.20710.0\lib\net40\System.Net.Http.WebRequest.dll</HintPath>
</Reference>
<Reference Include="System.Numerics" />
<Reference Include="System.Security" />
プロジェクトのReferencesフォルダーには、このdllへの参照があり、バージョンは2.0.0.0である必要があります。これがCopy Local = trueに設定されていることを確認してください。そして、サーバーアプリのbinフォルダーに移動することを確認します。
これは、現在nugetによって管理されているライブラリの1つです。 Nugetを開き、すべてが最新であることを確認してください。そして、プロジェクトのパッケージディレクトリで、ファイルは次のようになります:\packages\System.Net.Http.2.0.20126.16343\lib\net40
また、新しいMVC4アプリを作成して、そのアプリのファイルが表示されるかどうかを確認することもできます。
私のために働いたものの他の答えを単純化します。
NuGetマネージャーに移動し、関連パッケージ(私の場合は「Microsoft ASP.NET Web API 2.1クライアントライブラリ」および「Json.NET」)をアンインストールして、再インストールしました。数回クリックするだけです。
私は、テストサーバー(Windows 2008 R2)でこの問題に直面していました。
ヒントは、DEVマシンと展開サーバーの間でSystem.netのバージョンをチェックしたときに、一致しなかったことです。
以下の手順を使用して修正しました。
HERE から.NET Framework 4.5スタンドアロンインストーラーをダウンロードしました
展開マシンでインストーラーを実行しました
フレームワークのインストール後、サーバーは再起動を必要としたため、再起動が必要でした。行って良かった!!
ファイル構成で依存アセンブリを削除しました:
<dependentAssembly>
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="2.0.0.0"/>
<dependentAssembly>
今では正常に動作します。
私の場合、NuGetを使用してSystem.Net.Httpバージョン2.1.10.0に意図せずに依存関係を追加しました。 NuGetパッケージマネージャーでは削除できませんでした(他のパッケージがそれに依存しているように思われるため)。ただし、これらのパッケージはこの特定のバージョンに依存していません。これを取り除くために私がしたことは次のとおりです(代わりにNuGetコンソールを使用することもできます(-forceパラメーターを使用))。
VS 2013を使用し、新しいMVC 4 Web APIを作成し、TeamCityサーバーでビルドしたときにsystem.net.http.dllが正しいバージョンではないという問題がありましたが、VS 2013を備えたローカル開発者マシンでは正常にビルドしますインストール済み。
最終的に問題を特定しました。
新しいMVC 4 Web APIを作成し、プロジェクト作成時にフレームワーク4.0を選択すると、DLLの正しいNuGetパッケージバージョンが..\packages\Microsoft.Net.Http.2.0に配置されていることがわかりました。 20710.0\lib\net40\System.Net.Http.dll
ただし、このプロジェクトの.csprojファイルでは、このsystem.net.http.dllファイルのパスは次のようになっています。.\packages\Microsoft.Net.Http.2.0.30506.0\lib\net40\System.Net.Http.dll
したがって、ビルドが試行されると、このパスの違いは失敗しますが、TeamCityビルドサーバーではなく、開発者のマシンの別の場所でファイルの正しいフレームワークバージョンが検出されます。
これまでのところ、これが唯一の違いです。 .csprojファイルのパスを変更し、VS2013を使用してローカルのDevマシン上でビルドしても、引き続き機能します。
これをバージョン管理にチェックインし、TeamCityビルドサーバー(VS 2013をローカルにインストールしない)で、ソリューションのNuGetパッケージフォルダーで正しいバージョンの.dllを見つけて、system.net.httpの別のバージョンを検索するのではなく、正常にビルドします。 .dllおよびフレームワークに一致しない新しいバージョンを見つけるため、ビルドエラーが発生します。
これが役立つかどうかわかりません。
DLLのプロジェクトファイルパスを確認し、DLLのパッケージフォルダーパスと一致することを確認します。
Gembox.spreadsheet.dllバージョン31でも同じ問題が発生しました。
「ファイルまたはアセンブリ 'GemBox.Spreadsheet、Version = 39.3.30.1095、Culture = neutral、PublicKeyToken = b1b72c69714d4847'またはその依存関係の1つをロードできませんでした。検出されたAssemblyのマニフェスト定義はAssembly参照と一致しません。(HRESULTからの例外:0x80131040 ) "
これらの記事のほとんどすべてを試しましたが、どれも機能しませんでした。簡単な手順で修正されました。
基本的にdllへの正しいバージョン参照を設定する個々のプロジェクトをビルドしようとしましたが、エラーはソリューションから完全になくなりました。
このエラー(および同様の)については、NuGet統合(ソリューション> NuGetパッケージの管理...)を使用して、ソリューションで参照される各クラスライブラリで同じ参照コンポーネントバージョンが一貫していることを確認する価値があります。他の古いコンポーネント。更新プログラムと組み合わせて使用するのは簡単で、多くの苦痛を軽減できます。
これで私はこの問題を解決しました。MVCまたは他のWebベースのNuGetコンポーネントも参照するヘルパーライブラリを作成する場合は、慣れる必要があります。
私はこれとまったく同じ問題を抱えていました! VSの[警告]タブを見て、nugetパッケージの1つが.NETFrameworkバージョン4.5.0.0を間接的に参照していることに気付きました。このパッケージをアンインストールしてから4.0バージョンを再インストールする必要がありましたが、4.0をサポートするパッケージバージョンを必ず指定する必要があります(パッケージのインストール時に指定しないと、デフォルトで4.5に戻ります)。お役に立てれば!
これは、展開後にサーバーで発生していました。原因は次のいずれかです。
A)binフォルダー内の古いファイルはまだ削除されているはずです。
または
B)アプリケーションプールIDユーザーのフォルダーへの読み取りアクセス権がない。
つまり、サイトのフォルダーのアクセス許可を修正し、binフォルダーを消去して再展開することで、これを解決しました。
バージョン2.2.15.0の場合、これを行いました。
<dependentAssembly>
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="2.2.15.0"/>
</dependentAssembly>
同様の問題に行くと、多くのコメントで言及されたディレクティブはうまくいきました
<dependentAssembly>
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="2.0.0.0"/>
<dependentAssembly>
ただし、古いバージョンのカバレッジが十分に高いことを確認する必要があります。そうしないと、新しいバージョンが必要な特定のバージョンにリダイレクトされず、古い参照が既にbinディレクトリにあるため、新しい参照を使用した場所が適切に機能しません。
プロジェクトを閉じて、もう一度開きます。次に、ソリューションのクリーン+ビルド。私のために働く