Как я могу строго подписать внешнюю DLL, сохранив метаданные ее сборки?

Question

У меня есть несколько библиотек, которые я использую в своем проекте, которые не подписаны. Поскольку мое приложение строго подписано, библиотеки тоже должны быть.

Я подписываю эти библиотеки, используя:

"%PROGRAMFILES%\Microsoft SDKs\Windows\v7.1\Bin\ildasm.exe" /nobar /all /out=library.il library.dll
"%WINDIR%\Microsoft.NET\Framework64\v4.0.30319\ilasm.exe" /dll /key=MyKey.snk library.il

Проблема в том, что любые метаданные, например номера версий, теряются в подписанной DLL. Это проблема, потому что теперь некоторые зависимости между библиотеками нарушены. Как сохранить номера версий, не прибегая к фактической компиляции исходного кода этих библиотек?

UPDATE

На самом деле это конкретная DLL, которая показывает эту проблему, и я обнаружил, что она построена с использованием ILMerge. Возможно, это вызывает проблему. Просто чтобы прояснить: DLL, созданная ILMerge, имеет правильные метаданные, только после разборки и повторной сборки метаданные исчезают.

ОБНОВЛЕНИЕ 2

Я открыл DLL в Reflector, и кажется, что по крайней мере номер версии все еще там. Я все время проверял использование диалогового окна свойств файла / вкладки сведений в проводнике Windows. Поэтому я полагаю, что вместо этого отсутствует манифест.

Answer 1

Мне интересно, почему это происходит.У меня довольно хороший опыт компиляции в оба конца с использованием ilasm и ildasm на неподписанных и подписанных сборках.Можете ли вы проверить, что вывод метаданных с помощью ILasm по-прежнему содержит информацию о версии (в нижней части области сборки):

.assembly ConsoleApplication1
{
  //...
  .hash algorithm 0x00008004
  .ver 1:0:0:0
} 

Только что еще раз проверил, он «работает на моей машине» (используя те же параметры командной строки, что и высделал).

Что на самом деле будет потеряно, это атрибут FileVersion (тот, который вы видите в проводнике Windows при наведении курсора на сборку. Атрибут AssemblyVersion по-прежнему присутствует и исправьте . Может быть, вы путаете их? Только AssemblyVersion важен для информации о привязке. Для получения дополнительной информации см. SO post .

Надеюсь, что смогупомощь, в противном случае вам нужно будет предоставить больше контекста.

Answer 2

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

Чтобы сохранить зависимости между библиотеками, вам нужнообновите ссылки в .il-коде, чтобы использовать открытый ключ сборки, на которую они ссылаются, в противном случае они попытаются сослаться на неподписанную версию сборки и, таким образом, не смогут загрузить ее во время выполнения.

Вы можетесделайте это вручную, но это становится очень утомительным после 2 или 3 сборок.Быстрое решение для этого - signer , которое решает множество трудностей, с которыми вы сталкиваетесь, и делает большую работу - обычно это довольно быстро и чисто.

(Обратите внимание, что в настоящее времяон построен на старой версии .NET. Если вы используете сборки C # 4 / .NET 4, вам нужно загрузить исходный код, изменить его на целевой .NET 4 и перестроить, чтобы получить signer.exe, который будет корректно обрабатываться.NET 4 сборки).