エラーCS1705： "参照されているアセンブリよりも高いバージョンを持っています"

私はこれを少し調べており解決していません。窓\アセンブリ\と記載されているCommon.dllの3つのバージョンがあったという事実の通知に行った：エラーCS1705： "参照されているアセンブリよりも高いバージョンを持っています"

Compiler Error Message: CS1705: Assembly 'My.Model, Version=1.1.4422.23773, Culture=neutral, 
PublicKeyToken=bfde95ba233094b2' uses 
'Common, Version=3.3.4273.24368, Culture=neutral, PublicKeyToken=bfde95ba233094b2' 
which has a higher version than referenced assembly 
'Common, Version=3.3.4269.17112, Culture=neutral, PublicKeyToken=bfde95ba233094b2' 

c:\WINDOWS\assembly\GAC_MSIL\Common\3.3.4269.17112__bfde95ba233094b2\Common.dll: 
(Location of symbol related to previous error)

Webサーバが、私はCに行ってきましたServer 2003を実行している：私は、次のエラーメッセージが表示されます。リストされている最高のバージョンは3.3.4269.17112でした

バージョン：3.3.4273.24368でdllをアセンブリディレクトリにコピーしました。私はその後、私のコードを再コンパイルして再展開しました（おそらく残酷でしたが、うーん）。新しいセッションでブラウザを開いてサイトのURLに行ったときにも、同じメッセージが表示されます。

Windowsエクスプローラを使用して、上位バージョンのCommon.dllが表示されることを確認できます。

さらにこの問題を解決するにはどうすればよいですか？私は古いバージョンを指すようにアセンブリ内のリファレンスを変更したくありません。あなたがしようとするため

出典

2012-02-09 jbizzle

クレイジー '*。*'バージョン番号。すべてを再構築し、確かな唯一の方法。 –

3アイデア：

すべてのDLLが共通の同じバージョンに対してコンパイルされていることを確認します。
ファイル参照の代わりにソリューション内にプロジェクト参照があることを確認してください。
あなたのweb.configファイルで使用binding redirections

出典

2012-02-09 22:59:25

バインディングリダイレクトへのリンクがもう機能しません.... – moudrick

（ヤクブのアイデアに加えて）

私は、『再構築』本当に再建されなかったため、このエラーが発生しました。
Visual Studioを閉じて、実際に行ってbinフォルダを削除してから再構築してください。

また、Visual Studioには参照があることがありますので、.csprojファイルのHintPathを確認してください。

出典

2013-02-12 06:35:03

これは私のベーコンを保存しました。ローカルで走っても問題ありませんでしたが、私は変更を公開していました。オンラインのbinフォルダの内容を削除すると、物事が同期して戻ってきました。ありがとう！ – pStan

参照に移動し、問題の原因となっているdllファイルの新しい参照を追加し、すべてのdllが同じバージョンに対してコンパイルされていることを確認してください。それは私のために働く、私はそれがあなたのためにも働くことを望む。

出典

2013-03-19 04:46:41 Rahul

私の問題は、2つのプロジェクトが異なるバージョンを持つ同じdllの2つの異なるコピーを参照していたことでした。私はそれらを両方とも削除し、同じdllファイルを参照していることを確認して修正しました。

出典

2013-05-22 04:31:37

私のチームは、ビルド環境内でこの問題に直面しました。問題は、.csprojファイルの HintPath >要素の違いによるものです。

私たちの共通アセンブリは、参照アセンブリを含むディレクトリへの正しい相対パスを持っていました。従属アセンブリには、以前のディレクトリ構造からのパスがありました。このソリューションは、GACがC：\ Program Filesにインストールされている正しいバージョンへの依存関係の参照を解決したため、devマシンで正常にコンパイルされました。ビルド環境には、アセンブリがレガシーにインストールされていました（ただし、存在していなくてもかまいません）。 <HintPath>をテキストエディタで更新すると、問題が修正されました。

出典

2013-07-29 18:49:37

-3

同様の問題がありました。私は、DLL、つまりA..dllを作成しました。これは他のDLL、つまりB.dllを参照していました。

私はアプリケーションC.exeを作成し、DLL A.dllとB.dllを参照しました。

解決策 - C.exeからB.dllの参照を削除すると、問題を修正することができました。

これが役に立ちます。

出典

2013-09-12 18:39:40 Yahya

考えられる原因の1つは、2番目のアセンブリがGACにインストールされ、上位のバージョン番号を持つ最初のアセンブリがプロジェクトの参照ファイルに追加されていることが考えられます。これを確認するには、プロジェクト参照でアセンブリをダブルクリックし、オブジェクトブラウザに同じ名前の別のアセンブリが存在するかどうかを確認します。

この場合、gacutil.exeユーティリティを使用して、2番目のアセンブリをGACからアンインストールします。これらは64ビットのアセンブリであれば、例えば：

C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\x64\gacutil.exe -u <assembly_name>

出典

2013-10-09 18:10:00 jgong

2年後、あなたの提案は魅力的に機能しました。オブジェクトブラウザで参照を表示するとソートされました。 – ceebreenk

あなたはNuGetを使用している場合、それはに行く価値がある問題を引き起こし、更新に当たっているパッケージを見つけ、「ソリューションのNuGetパッケージの管理」。その後、すべてのパッケージを最新バージョンに戻して問題を解決する必要があります。

価値のあるショットはすばやく簡単です。

出典

2014-03-13 15:45:37 CountZero

これは私のためにそれを解決しました、ありがとう。私の状況は若干異なりました。アップデートには載っていなかったので、インストールしなければならず、プロジェクトごとにパッケージのバージョンを示すウィンドウがありました。いくつかの古いモジュールをcmsの新しいバージョンにアップグレードしていたので、問題のパッケージに行き、選択してインストールをクリックしなければなりませんでした。 CMSがちょうどナゲットを使用するように変更されたので、あなたが私に退屈な 'csproj'編集をたくさん保存したからかもしれません！ – rtpHarry

プロジェクトレベルではなく、ソリューションレベルでNuGetパッケージを更新してください。 – Jess

これは確かに受け入れられた答えであるはずです。私はこれを読んでいませんでしたが、偶然のようにうまくいきました。 – baymax

同様の問題がありました。私の問題は、それぞれが特定のバージョンのDLLを参照していたが、異なるバージョンを参照していた同じソリューション内にいくつかのプロジェクトがあることでした。解決策は、すべての参照のすべてのプロパティで「特定のバージョン」をfalseに設定することでした。

出典

2014-04-02 10:31:13 gnuchu

私はこれがかなり前に、上記の手順のいくつかを試してみたことを知っています。次のステップとthis articleが私を助けてくれました。

私はリファレンスを見つけ、PublicKeyTokenを古いものから参照されているものから変更しました。

私はこれも役立ちます。

出典

2015-05-18 11:28:35 Haris

あなたのプロジェクトには、参照が見つかりますSystem.Web.Mvcバージョンを確認してください。 >アセンブリとsystem.web.mvcを検索し、セットアップそれを -

その右クリックreferances後。

この問題は、これらの異なるバージョンのアセンブリを発生させます。

編集：選択はnugetパッケージの管理と更新にをインストールしたより（あなたが複数のプロジェクトを持っている場合も、それらの更新をインストールしてください。）

重要な更新がMicrosoft.AspNet.MvcとMicrosoft.Net.Compilersですそれを忘れないでください！

出典

2016-02-29 09:12:33 Hadnazzar

手作りDLLのコレクションフォルダ
あなたソリューションが
lib、source、libsなど異なるライブラリーからのDLLファイルのためのごみのフォルダを持っている場合
Visual Studioでソリューションを開くときにこの問題が発生することがあります。そして、あなたのdllの収集フォルダが何とか見逃されたり、具体的なdllファイルが見当たりません。

Visual Studioは自動的に何かのためにdllの参照を置換しようと試みます。 VSが成功すると、あなたのローカルソリューションに対して新しい参照が永続的になります。他のクローン/チェックアウト用ではありません。

I.e. <HintPath>は無視され、プロジェクトファイル（.csproj）は変更されません。私の例として

<Reference Include="DocumentFormat.OpenXml, Version=2.0.5022.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL"> 
    <SpecificVersion>False</SpecificVersion> 
    <HintPath>..\..\..\lib\DocumentFormat.OpenXml.dll</HintPath> 
</Reference>

DocumentFormat.OpenXmlがC:\Program Files (x86)\Open XML SDK\V2.5\libからではないsolution\..\libフォルダから参照されます。

速い回避策

チェックして、DLLソリューションエクスプローラからフォルダ
を集めています復元するには、プロジェクトのアンロード、その後、リロードプロジェクトを行います。

回避策は、NuGetパッケージマネージャーに移行することです。

出典

2017-02-02 11:56:39 it3xl

（SharePoint用）の場合、ルートフォルダの下にDLLの「bin」フォルダがないことを確認してください。（そしてVSの "Copy Local"をfalseに変更します）。

出典

2017-08-28 12:23:10 bresleveloper

エラーCS1705： "参照されているアセンブリよりも高いバージョンを持っています"

答えて

関連する問題