внутреннее строгое имя, видимое для 32-битной .net 4.0

Мне дается 3 DLL (API для внешней системы), и я могу использовать их с моим исполняемым файлом в Windows 7 32bit .net 4.

Затем мне нужно подписать исполняемый файл строгим именем.

Это требует, чтобы библиотеки DLL API также были подписаны с тем же строгим именем, если я правильно понимаю.

И я видел сообщения о том, как это сделать (ildasm/ilasm, или Brutal Developer, или Crypto Obfuscator), и пробовал все, что мне попадалось в руки. Тем не менее, получение «сборок, подписанных строгим именем, должно указывать открытый ключ в их объявлении InternalsVisibleTo».

Кто-нибудь был там и сумел благополучно выбраться?

С уважением, Орен

PS 1, мне удалось заставить его работать на 64-битной Windows 7 (там 3 DLL API были подписаны с помощью Crypto Obfuscator, сделанного предыдущим разработчиком). Я начал исследовать, когда он не работал в 32-битной версии, и понял, что использую подписанные библиотеки DLL. Затем я нашел исходные библиотеки DLL, но смог работать только без «строгого имени» ни в моих сборках, ни в API. Любая другая комбинация, даже когда мои сборки не были подписаны (или все было подписано насколько я знаю), не работала.

PS 2, у меня есть еще одна моя DLL, которая прекрасно работает с исполняемым файлом (я подписываю обе, поэтому у меня всего 5 сборок, 2 мои и 3 отданные), я не уверен, что это связано, но принес тут во всяком случае.


.net assembly-signing
person Oren    schedule 14.04.2015    source источник
comment
Не то же самое строгое имя. Вам просто нужно указать открытый ключ в объявлении атрибута InternalsVisibleTo. Сообщение об ошибке довольно ясно. Почему вы пытаетесь взломать внутренности API DLL? Они, вероятно, внутренние по какой-то причине.   -  person Luaan    schedule 15.04.2015
comment
Привет Луан. Я могу указать открытый ключ в InternalsVisibleTo моего исполняемого файла. Я пробовал это. Тем не менее, у меня нет доступа к источнику API DLL, и я не уверен, почему меня считают касающимся их внутренностей. Я просто последовал примеру, который они дали. Я использую одно и то же сильное имя во всех местах и ​​со всеми попытками. Это то, что я понял из своего исследования (попытаться подписать библиотеки DLL, к которым у вас нет доступа, одним и тем же строгим именем).   -  person Oren    schedule 15.04.2015
comment
О, вам нужно, чтобы ваше приложение было подписано, а у сторонних библиотек нет подписанной версии?   -  person Luaan    schedule 15.04.2015
comment
Да, это проблема. И есть несколько тем, что делать в этой ситуации, но я думаю, что уже все перепробовал.   -  person Oren    schedule 15.04.2015

Ответы (1)


arrow_upward
2
arrow_downward

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

Учитывая это предположение, проблема совершенно ясна — отдельные библиотеки DLL сторонней библиотеки используют внутренности друг друга (по крайней мере, одна из них делает это по крайней мере с одной из других), поэтому она использует InternalsVisibleTo. Ошибка, которую вы получаете, связана с тем, что вы подписали сборки хакерским способом и не удостоверились, что все ссылки, которые сборки имеют между собой, также обновлены, поэтому InternalsVisibleTo теперь ссылается на недействительную DLL, что означает что .NET запретит целевой DLL использовать internal другой библиотеки.

Чтобы это исправить, вам нужно изменить объявления InternalsVisibleTo в сторонних библиотеках. Это легко сделать в IL — просто найдите объявление атрибута и измените имя сборки, включив в него открытый ключ (например, с InternalsVisibleTo("MyLibrary") на InternalsVIsibleTo("MyLibrary, PublicKey=4564651357987621321...")).

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

person Luaan    schedule 15.04.2015
comment
Я попробую это. Это самая многообещающая идея. Я обновлю ветку своими выводами. - person Oren; 15.04.2015
comment
Вы, наверное, правы. У меня есть «ildasm» для 3 DLL API, и действительно, 2 из них содержат InternalsVIsibleTo. Далее мне нужно выяснить, как изменить файл, поскольку он задается как: .custom instance void [mscorlib]System.Runtime.CompilerServices.InternalsVisibleToAttribute::.ctor(string) = (01 00 2 ...), я попробую ildasm DLL с тем, что вы описываете и скопируете оттуда. - person Oren; 16.04.2015
comment
@Орен Ага. Вы можете легко найти правильное значение — оно должно быть в файле il, или вы можете использовать отражение, чтобы получить полное имя, которое также содержит открытый ключ. - person Luaan; 16.04.2015
comment
Хорошо, ваше руководство было отличным, и я также обнаружил stackoverflow.com/questions/10738008/ . Сегодня я узнал о сборках .Net больше, чем когда-либо хотел знать. Не удалось заставить его работать до сих пор. Тем не менее, теперь проверено, что он работает на 64-битной версии (все подписано сильным именем), и мы попытаемся убедить других заинтересованных лиц. - person Oren; 16.04.2015
comment
@Орен Интересно. Вы уверены, что сборки по-прежнему AnyCPU? Возможно, вы по ошибке изменили их только на 64-битные? - person Luaan; 16.04.2015
comment
Привет, как проверить? Я не менял намеренно. Может быть, так они были построены поставщиком API? - person Oren; 16.04.2015
comment
С corflags все, что у меня есть, показывает 0 рядом с 32-битным. Означает ли это, что он только 64-битный? - person Oren; 16.04.2015
comment
stackoverflow.com/questions/18608785/ Хорошо, поэтому я думаю, что нет. У меня все с любым процессором. - person Oren; 16.04.2015
comment
@Oren Возможно ли, что старые сборки где-то кэшированы? В конце концов, у них будет одна и та же версия и открытый ключ. Можете ли вы попробовать на другом компьютере, где вы никогда раньше не пробовали? - person Luaan; 16.04.2015
comment
Давайте продолжим это обсуждение в чате. - person Oren; 16.04.2015