Неподписанное приложение .NET дает сбой после обновления поля до подписанной зависимости сборки

У меня есть неподписанное тестовое приложение MyApp, которое ссылается на неподписанную DLL MyDll. Я недавно подписал MyDll и хочу протестировать его на MyApp в полевых условиях, но приложение больше не запускается. Я делаю это, просто перезаписывая MyDll. Я не хочу перекомпилировать MyApp.

Средство просмотра журнала Fusion доказывает, что проблема связана с несовпадающим открытым ключом:

LOG: Assembly Name is: MyDll, Version=1.0.0.0, Culture=neutral, PublicKeyToken=abcd1234abcd1234
WRN: Comparing the assembly name resulted in the mismatch: PUBLIC KEY TOKEN
ERR: The assembly reference did not match the assembly definition found.
ERR: Run-from-source setup phase failed with hr = 0x80131040.
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.

В прошлом я имел дело с несоответствием версий, создавая файл конфигурации, например. MyApp.exe.config с такой записью:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <runtime>
    <publisherPolicy apply="no" />
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="MyDll" publicKeyToken="abcd1234abcd1234" culture="null" />
        <bindingRedirect oldVersion="1.0.0.0" newVersion="1.0.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

В данном конкретном случае номер версии не изменился, но я оставил его для тестирования.

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


person Dave    schedule 28.04.2017    source источник
comment
Это нельзя скрыть с помощью bindingRedirect, приложение, использующее DLL, должно быть перестроено.   -  person Hans Passant    schedule 28.04.2017
comment
Ну это облом. :( У меня сложилось впечатление, что неподписанные сборки могут использовать подписанные.   -  person Dave    schedule 28.04.2017
comment
Неподписанные сборки ссылаются на подписанные сборки, но вы не можете изменить подписи после компиляции. Это включает в себя подписание неподписанной сборки (если только вы не отложили ее подписание).   -  person Mike Zboray    schedule 28.04.2017
comment
Если бы можно было возиться с подписями и все продолжало бы благополучно работать - какой смысл вообще подписывать dll?   -  person Evk    schedule 28.04.2017
comment
Достаточно справедливо, это имеет смысл.   -  person Dave    schedule 28.04.2017


Ответы (1)


Изменение сигнатуры зависимостей (будь то удаление сигнатуры, добавление ее или замена на другую) требует перекомпиляции сборки с использованием сигнатуры новой зависимости.

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

Поскольку это функция безопасности, вы не можете обойти ее с помощью записей конфигурации приложения.

person nvoigt    schedule 28.04.2017
comment
Я скажу, что сочетание отчаяния и пренебрежения безопасностью в моей конкретной области сделало меня слепым к тому факту, что предоставление кому-либо возможности просто изменить сигнатуры DLL, используемые приложением, открывает его для некоторого злонамеренного поведения. :) - person Dave; 28.04.2017