3.1.31 SignedXml.ComputeSignature CryptographicException: Failed to create signing key

[emejibka]

Здравствуйте.
После обновления пакетов и рантайма из задачи #60, появились ошибки вычисления подписи в xml, на некоторых сертификатах, сделал тестовый проект на старой и новой версии рантайма, на старой версии ошибка не воспроизводится.
В стеке ничего особо информативного нет

System.Security.Cryptography.CryptographicException: Failed to create signing key.
   at System.Security.Cryptography.Xml.SignedXml.ComputeSignature()

Ссылки на примеры и тестовый сертификат (пароль на сертификат - пробел):
https://disk.yandex.ru/d/L487xFoXz6t-Hg
https://disk.yandex.ru/d/JTZYr2J7-XQSMA
https://disk.yandex.ru/d/KyTSixQutCmr6w

[emejibka]

На windows воспроизводится, перед запускам примера необходимо поставить сертификат.

[Fasjeit]

#59

[Fasjeit]

Проблема в том, в bin попадает сборка System.Security.Cryptography.Xml из рантайма, а не из packages\bin.

По опыту такое происходит тогда, когда установлена более свежая версия рантайма, чем используется в форке (в данном случае 3.1.31, используемая 3.1.30). При данной конфигурации build начинает проявлять интеллект и подсовывать сборки из рантайма, а не из указанный явно в проекте.

Дабы не выравнивать версии в форке и на машине (которые всё равно часто плавают) постоянно - решения следующие:

1. Сделать post build event, который руками положит в bin нужные xml и pkcs сборки
2. Или указать в проекте версию рантайма 3.1.3. Очень похоже, что если версия сборок меньше, чем версия рантайма - всегда используются сборки по ссылке. Бояться что стоит 3.1.3 не стоит - все сборки всё равно будут резолвиться в наш форкнутый рантайм версии 3.1.30. Т.е. будет загружен рантайм 3.1.3 для сборки, и параллельно форк 3.1.30, при этом использоваться будет второй и явно указанные сборки из проекта.

[emejibka]

Спасибо, действительно не та версия сборки попадала в бинарники, но меня смутило что на некоторых текстовых сертификатах ошибка при этом не воспроизводилась.