私のVisual Studio 2005プロジェクト（厳密に名前が付けられている）に、名前の弱いアセンブリを追加しました。私は今エラーを得ています：

「参照されたアセンブリ 'xxxxxxxx'には厳密な名前がありません」

このサードパーティのアセンブリに署名する必要がありますか？

このエラーを回避するには、次のいずれかを行います。

• アセンブリを動的にロードする、または
• サードパーティアセンブリに署名します。

サードパーティのアセンブリに署名する手順については、.NET-fu：署名されていないアセンブリへの署名（遅延署名なし）を参照してください。

サードパーティアセンブリの署名

サードパーティに署名する基本的な原則は、

1. ildasm.exe中間言語（IL）を使用してアセンブリを分解し、保存します。

   ildasm /all /out=thirdPartyLib.il thirdPartyLib.dll 

2. アセンブリを再構築して署名します。

   ilasm /dll /key=myKey.snk thirdPartyLib.il

追加の参照の修正

上記の手順は、サードパーティのアセンブリ（A.dll）が、署名も必要な別のライブラリ（B.dll）を参照していない限り、正常に機能します。上記のコマンドを使用して、A.dllとB.dllの両方を逆アセンブル、再構築、および署名できますが、A.dllは元々、署名されていないバージョンのB.dllへの参照を使用して構築されているため、実行時にB.dllのロードは失敗します。。

この問題の修正は、上記のステップ1で生成されたILファイルにパッチを適用することです。B.dllの公開鍵トークンを参照に追加する必要があります。このトークンを取得するには

sn -Tp B.dll 

次の出力が得られます。

Microsoft (R) .NET Framework Strong Name Utility  Version 4.0.30319.33440
Copyright (c) Microsoft Corporation.  All rights reserved.

Public key (hash algorithm: sha1):
002400000480000094000000060200000024000052534131000400000100010093d86f6656eed3
b62780466e6ba30fd15d69a3918e4bbd75d3e9ca8baa5641955c86251ce1e5a83857c7f49288eb
4a0093b20aa9c7faae5184770108d9515905ddd82222514921fa81fff2ea565ae0e98cf66d3758
cb8b22c8efd729821518a76427b7ca1c979caa2d78404da3d44592badc194d05bfdd29b9b8120c
78effe92

Public key token is a8a7ed7203d87bc9

最後の行には公開鍵トークンが含まれています。次に、A.dllのILでB.dllへの参照を検索し、トークンを次のように追加する必要があります。

.assembly extern /*23000003*/ MyAssemblyName
{
  .publickeytoken = (A8 A7 ED 72 03 D8 7B C9 )                         
  .ver 10:0:0:0
}

「厳密な名前のキー」を持たないプロジェクトを使用しているプロジェクトファイルを展開し、.snk厳密ファイル（.StrongNameKey）ます。

Windowsエクスプローラーでこのファイルを参照します。（がどこにあるかがわかるように）。

「厳密な名前のキー」を持たないプロジェクトのVisual Studioに戻って、

• プロジェクトファイルを右クリック
• プロパティを選択
• 「署名」タブ（左側）を選択します
• 「アセンブリに署名する」チェックボックスをクリックします
• 次に<Browse>、.snk以前に見つけたファイルに

これでうまくいくはずです。これにより、同じソリューションで別のプロジェクト内のフォームを使用するプロジェクトの問題が解決しました。

お役に立てば幸いです。

私は非常に同じ問題の解決策を探していて、「アセンブリに署名する」オプションのチェックを外すとうまくいきました：

（スクリーンショットはVS2010のものですが、誰かの助けになることを願っています）

ソースコードのないアセンブリや放棄されたプロジェクトを含む、厳密な名前の署名アセンブリを自動的に作成するツールを作成しました。これは、既存のツールや日付の付いた指示の欠点や欠点のないシンプルな方法で、回答に記載されているテクニックの多くを使用しています。

http://brutaldev.com/post/2013/10/18/NET-Assembly-Strong-Name-Signer

これが、そこにたどり着くためにフープを飛び越えなくても、サードパーティのアセンブリに署名する必要がある人を助けることを願っています。

アセンブリも署名されていない場合は、署名されていないアセンブリを使用できます。

サードパーティのアセンブリへの署名は私にとってうまくいきました：

http://www.codeproject.com/Tips/341645/Referenced-assembly-does-not-have-a-strong-name

編集：リンクされた記事が有効でなくなった場合に備えて、手順を投稿すると役立つことがわかりました。すべてのクレジットはHiren Khirsariaに送られます。

1. Visual Studioコマンドプロンプトを実行し、DLLが配置されているディレクトリに移動します。

   For Example my DLL is located in D:/hiren/Test.dll

2. 次に、以下のコマンドを使用してILファイルを作成します。

   D:/hiren> ildasm /all /out=Test.il Test.dll （このコマンドはコードライブラリを生成します）

3. プロジェクトに署名するための新しいキーを生成します。

   D:/hiren> sn -k mykey.snk

4. 次に、ilasmコマンドを使用してライブラリに署名します。

   D:/hiren> ilasm /dll /key=mykey.snk Test.il

未署名のサードパーティアセンブリに署名する方法

1. Visual Studioの開発者コマンドプロンプトを開きます。このツールはWindowsプログラムで使用でき、デフォルトのWindows検索を使用して見つけることができます。
2. 次のツールを1回実行して、プロンプトが次のツールにアクセスできることを確認します。 sn ildasmと、ilasm
3. Cool.Library.dllがあるフォルダーに移動します。
4. sn –k Cool.Library.snk 新しい鍵ペアを作成する
5. ildasm Cool.Library.dll /out:Cool.Library.il ライブラリを分解する
6. move Cool.Library.dll Cool.Library.unsigned.dll 元のライブラリをバックアップとして保持する
7. ilasm Cool.Library.il /dll /resource=Cool.Library.res /key=Cool.Library.snk ライブラリを厳密な名前で再構築する
8. powershell -command "& {[System.Reflection.AssemblyName]::GetAssemblyName($args).FullName} Cool.Library.dll"アセンブリの完全修飾名を取得します。DLLをweb.configやapp.configなどの外部構成ファイルで参照する必要がある場合は、このビットが必要になります。

厳密に名前が付けられたアプリにこの問題があり、厳密に名前が付けられていないアセンブリを参照するために変更する必要があったため、プロジェクトプロパティの[署名]セクションで[アセンブリに署名する]をオフにしましたが、依然として問題がありました。他のすべてを正しく行ったので、それが問題の原因であるアーティファクトである必要があると考えました。次の行を見つけて削除しました：assemblyInfo.csファイルから[assembly：AssemblyKeyFile（ "yourkeyfilename.snk"）]。その後、ビルドに関する苦情はありません。

私はnugetでインストールしたServiceStack dllでこれに遭遇していました。署名付きのラベルが付けられた別のdllセットが利用可能であることがわかりました。全員の答えになるわけではありませんが、アセンブリの既存の署名済みバージョンを確認するだけでよい場合があります。

私にとって私の問題は、同じバージョンの2つのNuGetパッケージが異なるバージョンでインストールされていることでした。

[ 署名]の下の[ アセンブリに署名する]チェックマークを削除する @Michal Stefanowが言ったように、タブは動作します。

ここに追加は、自分のファイルや他の人のファイルに署名する最も簡単な方法です。この行を「ビルド後のイベントコマンドライン」の下に追加するだけです。

"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin\signtool.exe" sign /f "$(ProjectDir)\YourPfxFileNameHere.pfx" /p YourPfxFilePasswordHere /d "Your software title here" /du http://www.yourWebsiteHere.com /t http://timestamp.verisign.com/scripts/timstamp.dll /v "$(BaseOutputPath)$(TargetFileName)"

他の人のファイルや自分のファイルに好きなだけ署名できます。

古い質問ですが、ilmergeについてまだ誰も言及していません。ilmergeはMicrosoftから提供されていますが、VSまたはSDKには付属していません。ここからダウンロードすることもできます。githubリポジトリもあります。nugetからインストールすることもできます。

PM>Install-Package ilmerge

使用するには：

ilmerge assembly.dll /keyfile:key.snk /out:assembly.dll /targetplatform:v4,C:\Windows\Microsoft.NET\Framework\v4.0.30319 /ndebug

必要に応じて、sn（VSから）を使用して独自のキーファイルを生成できます。

sn -k key.snk

状況：ソリューションX、YにプロジェクトA、B、C、Dがあった

XのプロジェクトA、B、C YのプロジェクトA、C、D

プロジェクトAでプロジェクトCを使用する必要がありますが、後で使用しません。ビンでは、プロジェクトAにC.dllが含まれていました。

ソリューションXをコンパイルすると、すべて問題ありません（このソリューションでは参照A-> Cを削除します）が、ソリューションYではこの問題が発生します。

解決策は、プロジェクトAのbinデバッグでC.dllを削除することです

まず、ソリューション内のすべてのプロジェクトですべてのnugetパッケージが同じバージョンであることを確認します。たとえば、あるプロジェクトがNLog 4.0.0.0を参照し、別のプロジェクトがNLog 4.1.0.0を参照することは望ましくありません。次に、nugetパッケージを再インストールしてみます

更新パッケージ-再インストール

アセンブリAによって参照されるサードパーティアセンブリが3つあり、アセンブリBによって参照に含まれていたのは、Aも参照する2つだけでした。

サードパーティのアセンブリへの欠落した参照がupdate packageコマンドによって追加され、エラーはなくなりました。