「アセンブリ '* .dll'が前提条件としてマークされるには強力な署名が必要です」というメッセージが表示されるのはなぜですか？
C＃4.0を使用してExcelアドインをコンパイルしようとしていますが、Visual Studioでプロジェクトをビルドするときにこの問題が発生し始めました。私が以前にこの問題を経験したことがないことを伝えることが重要です。これが起こる原因は何ですか？
私の推測では、厳密な名前のアセンブリを使用しているわけではありません。 2つのプロジェクトが同じアセンブリのわずかに異なるバージョンを参照し、より依存性の高いプロジェクトがこれらのプロジェクトを参照する場合、このエラーが発生しました。私の場合の解決策は、.csprojファイルのアセンブリ名からキーとバージョン情報を削除し（とにかく重要ではありませんでした）、クリーンビルドを実行することでした。
異なるアセンブリバージョン間の変更は、それらを参照するソリューションの部分と互換性がありました。これが当てはまらない場合は、問題を解決するためにさらに作業が必要になる場合があります。
NuGet
NuGetを使用すると、次の場合にこの状況に陥りやすくなります。
- ソリューション内の1つのプロジェクトにパッケージをインストールします。
- そのパッケージの新しいバージョンがパッケージソースに展開されます。
- 同じソリューション内の別のプロジェクトにインストールします。
これにより、ソリューションの2つのプロジェクトが、そのパッケージのアセンブリの異なるバージョンを参照します。一方が他方を参照し、ClickOnceアプリである場合、この問題が発生します。
これを修正するには、Nuget Package Managerコンソールでupdate-package [package name]コマンドを発行して、すべてを平等な競技場に上げます。この時点で、問題はなくなります。
NuGetパッケージを、プロジェクトレベルではなくソリューションレベルで管理する必要があります。ソリューションレベルのパッケージ管理により、依存関係の複数のバージョンの可能性が回避されます。管理UIを使用するときに、統合タブに1つ以上のパッケージに複数のバージョンがあることが示されている場合は、それらを1つに統合することを検討してください。
この問題が発生したとき、「ClickOnceセキュリティ設定を有効にする」をオフにして修正しました。
メニュー：プロジェクト| 「プロジェクト名」のプロパティ... | [セキュリティ]タブ| [ClickOnceセキュリティ設定を有効にする]チェックボックス。
こちらをご覧ください answer 。
公開ページに移動し、「アプリケーションファイル」をクリックします。そこから、DLLのリストが表示されます。問題を引き起こしているものの公開ステータスが「前提条件」ではなく「含める」とマークされていることを確認します。
プロジェクトのプロパティページに移動します。次に、「公開」、「アプリケーションファイル」の順に進みます。エラーに記載されているdllは、前提条件としてマークされます。それらを「含める」に変更します
この問題が発生しました。それは、同じアセンブリを指すが異なるバージョンの多くのプロジェクトがあったために起こりました。ソリューションのすべてのプロジェクトに同じバージョンを選択して解決します。
アセンブリのバージョンを変更した場合、またはエラーに示されているマネージライブラリの別のバージョンをコピーした場合は、間違ったバージョンを参照する以前にコンパイルされたファイルもある可能性があります。 「すべて再構築」（または、以前のコメントで述べたように「bin」フォルダーと「obj」フォルダーを削除）でこのケースを修正する必要があります。
DLL（エラーが発生した場所）を削除し、ソリューションを再構築すると問題が解決しました。ありがとう
この問題に対する私の解決策を追加することで、助けになるかもしれません。
このエラーをスローするClickOnceソリューションがありました。アプリは共通の「Libs」フォルダーを参照し、Foo.dllへのプロジェクト参照を含んでいました。ソリューション内のプロジェクトはいずれも「Libs」フォルダー内のFoo.dllの静的コピーを参照しませんでしたが、そのフォルダー内の参照の一部は参照しました（つまり、私のソリューションはLibs\Bar.dllを参照するFoo.dllへの参照を持っていました）。 Libsからの依存関係とその依存関係、両方のコピーがプロジェクトに入りました。これは上記のエラーを生成していました。
Libs\Foo.dll静的バージョンをサブフォルダーLibs\Fix\Foo.dllに移動することで問題を修正しました。この変更により、ClickOnceアプリはDLLのプロジェクトバージョンのみを使用するようになり、エラーは表示されなくなりました。
この質問の他のすべての回答を試してみた場合：
- ソリューションに複数のプロジェクトがある
- NuGetパッケージを参照するプロジェクトの別のプロジェクト（プロジェクトB）を参照するプロジェクト（プロジェクトA）があります。
- プロジェクトAでは、Intellisense/ReSharperを使用して、プロジェクトBで参照されるNuGetパッケージへの参照を取り込みました（これは、プロジェクトBのメソッドがNuGetパッケージで提供される型を返し、そのメソッドがプロジェクトAで使用される場合に発生します）
- nuGetパッケージマネージャー（またはCLI）を使用してNuGetパッケージを更新しました。
... Intellisense/ReSharperによって作成される参照は「通常の」参照であり、NuGetの参照ではないため、プロジェクトの参照にNuGetパッケージDLLの個別のバージョンがある場合があります。 NuGet更新プロセスはそれを見つけたり更新したりしません！
これを修正するには、プロジェクトAの参照を削除し、NuGetを使用してインストールし、すべてのプロジェクトのNuGetパッケージが同じバージョンであることを確認します。 （ this answer ）で説明しています
Life Proのヒント：
この問題は、ReSharper/Intellisenseがプロジェクトへの参照の追加を提案するたびに発生する可能性があります。複数の織り交ぜられたプロジェクトと依存関係により、追跡が困難になるため、上記の例よりもはるかに複雑になる可能性があります。 ReSharper/Intellisenseによって提案されている参照が実際にNuGetパッケージからのものである場合は、NuGetを使用してインストールします。
キーでアセンブリに署名する必要があります。タブ署名の下のプロジェクトプロパティに移動します。 
更新後にWindowsAPICodePackを使用してこの問題が発生した場合、ソリューションを再構築しました。
ビルド->ソリューションのリビルド
問題のあるプロジェクトをアンロードして再ロードすると解決しました。
ソリューションに含まれるプロジェクトが多すぎて個別に更新できないため、次の方法で修正しました。
- ソリューションを右クリックし、[ソリューションのNuGetパッケージの管理...]を選択します。
- [更新]タブに移動する
- 影響を受けるパッケージを見つけて、更新を選択する
- [OK]をクリックすると、パッケージのすべてのインスタンスが最新になりました
アセンブリは適切に署名されていますか？
これを確認するには、プロジェクトでAlt + Enterを押します（または右クリックしてから[プロパティ]）。 「署名」に進みます。 [アセンブリに署名する]チェックボックスがオンになり、厳密な名前のキーファイルが選択され、[署名のみ遅延]が未チェックであることを確認します。
publish、アプリケーションファイルに移動し、エラーをスローするdllが'Include'から 'Include（Auto）'に変更したことを発見しました。これで公開できます。
これは、参照されている.dllのバージョンを変更すると発生します。すべてのアイテム、またはターゲットビルドフォルダー内の.dllを削除する必要があります。
次に、問題に対する別のアプローチを示します。
プロジェクトを右クリックして、「プロジェクトのアンロード」オプションを選択します。プロジェクトが利用できなくなることがわかります。
利用できないプロジェクトを右クリックし、「編集」オプションを選択します。
すべてのリソースタグを含む '<ItemGroup>'タグまでスクロールします。
エラーリストに表示されている参照に移動すると、単一のタグ（
< Reference Include="assemble_name_here, Version=0.0.0.0, Culture=neutral" / >）を使用していることに気付くでしょう。次のように変更します。
。
<Reference Include="assemble_name_here, Version=1.0.0.0, Culture=neutral, processorArchitecture=MSIL" >
< Private > True < / Private >
< HintPath > path_here\assemble_name_here.dll < / HintPath >
< / Reference >
- 変更を保存し、使用できないプロジェクトをもう一度右クリックして、[プロジェクトの再読み込み]オプションをクリックしてからビルドします。
Packages.configからPackageReferenceにExcelアドインを移行した後、この問題が発生しました。 この問題 に関連しているようです。
以下は、ClickOnceを使用していない場合の大まかな回避策として機能します（.manifestファイルからすべての依存情報を省略します）。
- プロジェクトをアンロードし、.csprojを編集します
次のようなセクションを見つけます。
<!-- Include additional build rules for an Office application add-in. --> <Import Project="$(VSToolsPath)\OfficeTools\Microsoft.VisualStudio.Tools.Office.targets" Condition="'$(VSToolsPath)' != ''" />参照されている
.targetsファイルの名前を変更したコピーを編集します（私の場合、ファイルはC:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\VisualStudio\v15.0\OfficeTools\Microsoft.VisualStudio.Tools.Office.targetsに解決され、同じフォルダーでMicrosoft.VisualStudio.Tools.Office_FIX.targetsのコピーを作成しました-別のフォルダーから機能するかどうかはチェックしませんでした）。GenerateApplicationManifest要素を見つけて、その属性Dependencies="@(DependenciesForGam)"をDependencies=""に変更します。代わりに、編集した
.targetsファイルを参照するように2.のセクションを変更します。
これは、VSに同梱されている.targetsファイルのバージョンが更新されるたびに繰り返す必要があります（または更新を取得できません）が、すぐに修正されることを望んでいます...
同様のコンパイラエラーが発生しました。 dllファイルの依存プロジェクトをソリューションに追加すると、問題は解決しました。
メインプロジェクトがいくつかのライブラリプロジェクトを使用しており、それらを参照している場合、ライブラリプロジェクトで何かを変更するときにプロジェクトがライブラリプロジェクトではなくアセンブリdllファイルを参照している場合、この問題が発生する可能性があります（例：クラスの名前を変更する）。
オブジェクトブラウザーウィンドウ（メニュービュー->オブジェクトブラウザー）で表示することにより、メインプロジェクトへのすべての参照を確認できます。 dllファイルへの参照には、常にバージョン番号があります。例：TestLib [1.0.0.0]
解決策：ライブラリプロジェクトへのメインプロジェクトの現在の参照を削除し、そのライブラリプロジェクトへの参照を再度追加します。
私が助けたのは、Package Manager Solutionにアクセスして、問題の原因となっているインストール済みパッケージを調べたことです。いくつかのプロジェクトが同じパッケージで異なるバージョンを参照していることがわかりました。私は自分のニーズに基づいてそれらを調整しましたが、うまくいきました。
ここでほとんどのソリューションを試した後、ついにクリックワンスプロジェクトからプロジェクトへの参照を追加しました。これにより、IncludeからInclude（Auto）に変更され、最終的に機能しました。
Update-package -reinstall -ignoredependenciesで試してください
依存関係の依存関係が一致しない場合は、ソリューションレベルでNuGetパッケージマネージャーに移動し、[更新]タブと[統合]タブを確認して、すべてを調整します。
私はまた、ちょっとした問題にぶつかりました。私がしなければならなかったのは、。dllを削除（参照で見つけることができます）エラーの原因であり、再度追加です。
魔法のように機能します。
私は最近この問題にぶつかりました。私の場合、異なるアセンブリにNuGetパッケージがあります。私が持っていたのは、自分のアセンブリに関連付けられた同じNuGetパッケージの異なるバージョンでした。
私のソリューションは、個々のプロジェクトではなく、ソリューションでNuGetパッケージマネージャーを使用することでした。これにより、「統合」オプションが有効になります。このオプションでは、NuGetパッケージを必要な数のプロジェクトでアップグレードできます。これらのプロジェクトはすべて同じバージョンのアセンブリを参照します。統合を行ったとき、ビルドの失敗は消えました。
私はこれを6つのプロジェクトで解決しました。私のプロジェクトの1つは、名前付きアセンブリをファイル参照として参照していました。他はすべてプロジェクト参照を指していました。
これらの場合、通常は別のエラーが発生します。
私の解決策は、指定されたアセンブリを参照されている場所から削除してから追加し直すことでした。プロジェクトを終えると、この問題はなくなりました。これを行う前に、ソリューションのクリーニングを試み、プロジェクトに署名がないことを確認しました。
それが誰かを助けることを願っています...