web-dev-qa-db-ja.com

「アセンブリ '* .dll'が前提条件としてマークされるには強力な署名が必要です」というメッセージが表示されるのはなぜですか?

C#4.0を使用してExcelアドインをコンパイルしようとしていますが、Visual Studioでプロジェクトをビルドするときにこの問題が発生し始めました。私が以前にこの問題を経験したことがないことを伝えることが重要です。これが起こる原因は何ですか?

258
Sergey Kucher

私の推測では、厳密な名前のアセンブリを使用しているわけではありません。 2つのプロジェクトが同じアセンブリのわずかに異なるバージョンを参照し、より依存性の高いプロジェクトがこれらのプロジェクトを参照する場合、このエラーが発生しました。私の場合の解決策は、.csprojファイルのアセンブリ名からキーとバージョン情報を削除し(とにかく重要ではありませんでした)、クリーンビルドを実行することでした。

異なるアセンブリバージョン間の変更は、それらを参照するソリューションの部分と互換性がありました。これが当てはまらない場合は、問題を解決するためにさらに作業が必要になる場合があります。

NuGet

NuGetを使用すると、次の場合にこの状況に陥りやすくなります。

  1. ソリューション内の1つのプロジェクトにパッケージをインストールします。
  2. そのパッケージの新しいバージョンがパッケージソースに展開されます。
  3. 同じソリューション内の別のプロジェクトにインストールします。

これにより、ソリューションの2つのプロジェクトが、そのパッケージのアセンブリの異なるバージョンを参照します。一方が他方を参照し、ClickOnceアプリである場合、この問題が発生します。

これを修正するには、Nuget Package Managerコンソールでupdate-package [package name]コマンドを発行して、すべてを平等な競技場に上げます。この時点で、問題はなくなります。

NuGetパッケージを、プロジェクトレベルではなくソリューションレベルで管理する必要があります。ソリューションレベルのパッケージ管理により、依存関係の複数のバージョンの可能性が回避されます。管理UIを使用するときに、統合タブに1つ以上のパッケージに複数のバージョンがあることが示されている場合は、それらを1つに統合することを検討してください。

231
CRAGIN

この問題が発生したとき、「ClickOnceセキュリティ設定を有効にする」をオフにして修正しました。

メニュー:プロジェクト| 「プロジェクト名」のプロパティ... | [セキュリティ]タブ| [ClickOnceセキュリティ設定を有効にする]チェックボックス。

264
CharleZ

こちらをご覧ください answer

公開ページに移動し、「アプリケーションファイル」をクリックします。そこから、DLLのリストが表示されます。問題を引き起こしているものの公開ステータスが「前提条件」ではなく「含める」とマークされていることを確認します。

68
Otiel

プロジェクトのプロパティページに移動します。次に、「公開」、「アプリケーションファイル」の順に進みます。エラーに記載されているdllは、前提条件としてマークされます。それらを「含める」に変更します

23
Krishh

この問題が発生しました。それは、同じアセンブリを指すが異なるバージョンの多くのプロジェクトがあったために起こりました。ソリューションのすべてのプロジェクトに同じバージョンを選択して解決します。

21
daniel

アセンブリのバージョンを変更した場合、またはエラーに示されているマネージライブラリの別のバージョンをコピーした場合は、間違ったバージョンを参照する以前にコンパイルされたファイルもある可能性があります。 「すべて再構築」(または、以前のコメントで述べたように「bin」フォルダーと「obj」フォルダーを削除)でこのケースを修正する必要があります。

13
Sogger

DLL(エラーが発生した場所)を削除し、ソリューションを再構築すると問題が解決しました。ありがとう

6
Kishore

この問題に対する私の解決策を追加することで、助けになるかもしれません。

このエラーをスローするClickOnceソリューションがありました。アプリは共通の「Libs」フォルダーを参照し、Foo.dllへのプロジェクト参照を含んでいました。ソリューション内のプロジェクトはいずれも「Libs」フォルダー内のFoo.dllの静的コピーを参照しませんでしたが、そのフォルダー内の参照の一部は参照しました(つまり、私のソリューションはLibs\Bar.dllを参照するFoo.dllへの参照を持っていました)。 Libsからの依存関係とその依存関係、両方のコピーがプロジェクトに入りました。これは上記のエラーを生成していました。

Libs\Foo.dll静的バージョンをサブフォルダーLibs\Fix\Foo.dllに移動することで問題を修正しました。この変更により、ClickOnceアプリはDLLのプロジェクトバージョンのみを使用するようになり、エラーは表示されなくなりました。

6
Nick Gotch

この質問の他のすべての回答を試してみた場合:

  • ソリューションに複数のプロジェクトがある
  • 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を使用してインストールします。

6
David Murdoch

キーでアセンブリに署名する必要があります。タブ署名の下のプロジェクトプロパティに移動します。 enter image description here

6
Felice Pollano

更新後にWindowsAPICodePackを使用してこの問題が発生した場合、ソリューションを再構築しました。

ビルド->ソリューションのリビルド

5
Nathan

問題のあるプロジェクトをアンロードして再ロードすると解決しました。

4
ChrisO

ソリューションに含まれるプロジェクトが多すぎて個別に更新できないため、次の方法で修正しました。

  • ソリューションを右クリックし、[ソリューションのNuGetパッケージの管理...]を選択します。
  • [更新]タブに移動する
  • 影響を受けるパッケージを見つけて、更新を選択する
  • [OK]をクリックすると、パッケージのすべてのインスタンスが最新になりました
4
RagtimeWilly

アセンブリは適切に署名されていますか?

これを確認するには、プロジェクトでAlt + Enterを押します(または右クリックしてから[プロパティ])。 「署名」に進みます。 [アセンブリに署名する]チェックボックスがオンになり、厳密な名前のキーファイルが選択され、[署名のみ遅延]が未チェックであることを確認します。

3

publish、アプリケーションファイルに移動し、エラーをスローするdllが'Include'から 'Include(Auto)'に変更したことを発見しました。これで公開できます。

3
Jimmy

これは、参照されている.dllのバージョンを変更すると発生します。すべてのアイテム、またはターゲットビルドフォルダー内の.dllを削除する必要があります。

3
Hoang Ha

次に、問題に対する別のアプローチを示します。

  • プロジェクトを右クリックして、「プロジェクトのアンロード」オプションを選択します。プロジェクトが利用できなくなることがわかります。

  • 利用できないプロジェクトを右クリックし、「編集」オプションを選択します。

  • すべてのリソースタグを含む '<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 >
  • 変更を保存し、使用できないプロジェクトをもう一度右クリックして、[プロジェクトの再読み込み]オプションをクリックしてからビルドします。
3
Tech

Packages.configからPackageReferenceにExcelアドインを移行した後、この問題が発生しました。 この問題 に関連しているようです。

以下は、ClickOnceを使用していない場合の大まかな回避策として機能します(.manifestファイルからすべての依存情報を省略します)。

  1. プロジェクトをアンロードし、.csprojを編集します
  2. 次のようなセクションを見つけます。

    <!-- Include additional build rules for an Office application add-in. -->
    <Import Project="$(VSToolsPath)\OfficeTools\Microsoft.VisualStudio.Tools.Office.targets" Condition="'$(VSToolsPath)' != ''" />
    
  3. 参照されている.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のコピーを作成しました-別のフォルダーから機能するかどうかはチェックしませんでした)。

  4. GenerateApplicationManifest要素を見つけて、その属性Dependencies="@(DependenciesForGam)"Dependencies=""に変更します。

  5. 代わりに、編集した.targetsファイルを参照するように2.のセクションを変更します。

これは、VSに同梱されている.targetsファイルのバージョンが更新されるたびに繰り返す必要があります(または更新を取得できません)が、すぐに修正されることを望んでいます...

3
FunctorSalad

同様のコンパイラエラーが発生しました。 dllファイルの依存プロジェクトをソリューションに追加すると、問題は解決しました。

2
Minny

メインプロジェクトがいくつかのライブラリプロジェクトを使用しており、それらを参照している場合、ライブラリプロジェクトで何かを変更するときにプロジェクトがライブラリプロジェクトではなくアセンブリdllファイルを参照している場合、この問題が発生する可能性があります(例:クラスの名前を変更する)。

オブジェクトブラウザーウィンドウ(メニュービュー->オブジェクトブラウザー)で表示することにより、メインプロジェクトへのすべての参照を確認できます。 dllファイルへの参照には、常にバージョン番号があります。例:TestLib [1.0.0.0]

解決策:ライブラリプロジェクトへのメインプロジェクトの現在の参照を削除し、そのライブラリプロジェクトへの参照を再度追加します。

2
Huy Nguyen

私が助けたのは、Package Manager Solutionにアクセスして、問題の原因となっているインストール済みパッケージを調べたことです。いくつかのプロジェクトが同じパッケージで異なるバージョンを参照していることがわかりました。私は自分のニーズに基づいてそれらを調整しましたが、うまくいきました。

1
Artexias

ここでほとんどのソリューションを試した後、ついにクリックワンスプロジェクトからプロジェクトへの参照を追加しました。これにより、IncludeからInclude(Auto)に変更され、最終的に機能しました。

0
PatFromCanada

Update-package -reinstall -ignoredependenciesで試してください

0
Stella Oliveira

依存関係の依存関係が一致しない場合は、ソリューションレベルでNuGetパッケージマネージャーに移動し、[更新]タブと[統合]タブを確認して、すべてを調整します。

0
Luke Puplett

私はまた、ちょっとした問題にぶつかりました。私がしなければならなかったのは、。dllを削除(参照で見つけることができます)エラーの原因であり、再度追加です。

魔法のように機能します。

0
FritsJ

私は最近この問題にぶつかりました。私の場合、異なるアセンブリにNuGetパッケージがあります。私が持っていたのは、自分のアセンブリに関連付けられた同じNuGetパッケージの異なるバージョンでした。
私のソリューションは、個々のプロジェクトではなく、ソリューションでNuGetパッケージマネージャーを使用することでした。これにより、「統合」オプションが有効になります。このオプションでは、NuGetパッケージを必要な数のプロジェクトでアップグレードできます。これらのプロジェクトはすべて同じバージョンのアセンブリを参照します。統合を行ったとき、ビルドの失敗は消えました。

0
Simon Miller

私はこれを6つのプロジェクトで解決しました。私のプロジェクトの1つは、名前付きアセンブリをファイル参照として参照していました。他はすべてプロジェクト参照を指していました。

これらの場合、通常は別のエラーが発生します。

私の解決策は、指定されたアセンブリを参照されている場所から削除してから追加し直すことでした。プロジェクトを終えると、この問題はなくなりました。これを行う前に、ソリューションのクリーニングを試み、プロジェクトに署名がないことを確認しました。

それが誰かを助けることを願っています...

0
greg