Как исправить ошибку "Ссылочная сборка не имеет строгого имени"?

Question

Я добавил сборку со слабым именем в свой проект Visual Studio 2005 (который строго назван). Теперь я получаю сообщение об ошибке:

"Ссылочная сборка" xxxxxxxx "не имеет строгого имени"

Нужно ли подписывать эту стороннюю сборку?

Answer 1

Чтобы избежать этой ошибки, вы можете:

• Загрузите сборку динамически или
• Подписать стороннюю сборку.

Инструкции по подписанию сторонних сборок вы найдете в .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
}

Answer 2

Разверните файл проекта, который использует проект, у которого нет "ключа строгого имени", и найдите файл.snk (.StrongNameKey).

Просмотрите этот файл в проводнике Windows (просто, чтобы вы знали, где он находится).

Вернувшись в Visual Studio в проект, который не имеет "ключа строгого имени", выполните

• Щелкните правой кнопкой мыши файл проекта
• Выберите Свойства
• Выберите вкладку "Подпись" (слева)
• Установите флажок "Подписать сборку"
• Затем в файл.snk, который вы нашли ранее

Это должно делать свое дело. Это решило проблему для меня для одного проекта, используя форму внутри другого проекта в том же решении.

Я надеюсь, что это помогает.

Answer 3

Я искал решение той же проблемы, и снятие галочки с опции "Подписать сборку" работает для меня:

(как вы можете заметить, скриншот взят с VS2010, но, надеюсь, он кому-нибудь поможет)

Answer 4

Я написал инструмент для автоматической сборки знаков со строгими именами, в том числе тех, для которых у вас нет исходного кода, или проектов, которые были заброшены. Он использует многие из методов, описанных в ответах, простым способом без каких-либо недостатков или недостатков существующих инструментов или устаревших инструкций.

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

Надеюсь, что это поможет любому, кому нужно подписать стороннюю сборку без необходимости прыгать через обручи, чтобы добраться туда.

Answer 5

Вы можете использовать неподписанные сборки, если ваша сборка также не подписана.

Answer 6

Подписание сторонней сборки у меня сработало:

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 inD:/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

Answer 7

Как подписать стороннюю сборку без подписи

1. Откройте командную строку разработчика для Visual Studio. Этот инструмент доступен в ваших программах Windows и может быть найден с помощью поиска Windows по умолчанию.
2. Убедитесь, что ваша подсказка имеет доступ к следующим инструментам, выполнив их один раз: snildasm а также 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.

Answer 8

Для меня проблема заключалась в пакете NuGet без строгого имени. Решением было установить StrongNamer из NuGet, который автоматически добавляет строгое имя ко всем сборкам, на которые есть ссылки. Простая ссылка на него в проекте решила мою проблему.

Answer 9

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

Answer 10

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

Answer 11

Я добавил пакет NuGet StrongNamer, и моя проблема решена.

Answer 12

Старый вопрос, но я удивлен, что еще никто не упомянул 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

Answer 13

Для меня проблема заключалась в том, что у меня было два одинаковых пакета NuGet, установленных с разными версиями.

Answer 14

Снятие флажка "Подписать сборку" на вкладке "Подписывание" работает, как сказал @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)"

Вы можете подписывать файлы других людей или свои собственные файлы и столько, сколько хотите.

Answer 15

Ситуация: у вас был проект 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.

Answer 16

Существует пакет NuGet под названием StrongNamer от Даниэля Плейстеда, который, кажется, помогает .

Это самое простое решение, которое я нашел до сих пор.

Существует также ряд других пакетов NuGet для устранения сильной проблемы с именами, таких как Brutal.Dev.StrongNameSigner от Вернера ван Девентера , но я не тестировал ни тот, ни другой.

Answer 17

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

Обновление-Пакет -reinstall

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

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