Я добавил сборку со слабым именем в мой проект 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, используя приведенные выше команды, но во время выполнения загрузка B.dll не будет выполнена, поскольку A.dll изначально был создан со ссылкой на неподписанную версию B.dll .

Решением этой проблемы является исправление файла IL, созданного на шаге 1 выше. Вам нужно будет добавить токен открытого ключа 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

Последняя строка содержит токен открытого ключа. Затем вам нужно найти в IL файла A.dll ссылку на 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. Убедитесь, что у вашего приглашения есть доступ к следующим инструментам, выполнив их один раз: 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.

У меня была эта проблема для приложения, которое было строго названо, затем пришлось изменить его, чтобы ссылаться на сборку с неназванным именем, поэтому я снял флажок «Подписать сборку» в разделе «Подписание свойств» проекта, но он все еще жаловался. Я подумал, что это должен быть артефакт где-то, вызывающий проблему, поскольку я все делал правильно, и это было именно так. Я нашел и удалил строку: [assembly: AssemblyKeyFile ("yourkeyfilename.snk")] из его файла assemblyInfo.cs. Тогда никаких нареканий после этого.

Я столкнулся с этим с DLL ServiceStack, которую я установил с Nuget. Оказывается, был еще один набор доступных библиотек, которые были помечены как подписанные. Не будет ответом для всех, но вам, возможно, просто нужно проверить существующую подписанную версию вашей сборки.

Для меня проблема заключалась в том, что у меня было два одинаковых пакета 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

Ситуация: у вас был проект A, B, C, D в решении X, Y

Проект A, B, C в X Проект A, C, D в Y

Мне нужно использовать проект C в проекте A, но позже я не буду использовать. В отладочном проекте bin A был C.dll.

Если я компилирую решение X, все хорошо (в этом решении я удаляю ссылку A -> C.), но в решении Y я получаю эту проблему.

Решение - удалить C.dll в проекте A bin Debug.

Сначала убедитесь, что все пакеты nuget имеют одинаковую версию для всех проектов в вашем решении. Например, вы не хотите, чтобы один проект ссылался на NLog 4.0.0.0, а другой - на NLog 4.1.0.0. Затем попробуйте переустановить пакеты nuget с

Update-Package -reinstall

У меня было 3 сторонних сборки, на которые ссылалась моя сборка А, и только 2 были включены в Ссылки моей сборкой Б, которая также ссылалась на А.

Отсутствующая ссылка на стороннюю сборку была добавлена ​​командой пакета обновления, и ошибка исчезла.