Nuget Moq 4.0.10827 и InternalsVisibleTo (снова) - PullRequest
Новая
       27

Nuget Moq 4.0.10827 и InternalsVisibleTo (снова)

4 голосов
/ 25 августа 2011

Я пытался заставить Moq (или, скорее, Castle.Core) создать прокси для моих внутренних типов.

Следующее (при добавлении в тестируемый проект) позволяет работать: 

[assembly: InternalsVisibleTo("DynamicProxyGenAssembly2")]

Однако это (более безопасная версия) не: 

[assembly: InternalsVisibleTo("DynamicProxyGenAssembly2, PublicKey=002400000480000094000000060200000024000052534131000400000100010077f5e87030dadccce6902c6adab7a987bd69cb5819991531f560785eacfc89b6fcddf6bb2a00743a7194e454c0273447fc6eec36474ba8e5a3823147d214298e4f9a631b1afee1a51ffeae4672d498f14b000e3d321453cdd8ac064de7e1cf4d222b7e81f54d4fd46725370d702a05b48738cc29d09228f1aa722ae1a9ca02fb")]

Примечание: открытый ключ здесь отличается от того, что задокументировано здесь . Я повторно проверил открытый ключ Castle.Core.dll, который поставляется с текущей версией Nuget Moq.

У меня все еще неправильный ключ?

[EDIT]

Я заметил, что полная загрузка Moq с официального сайта (а не Nuget) содержит папку NET40-requireCastle с меньшим dll, что подразумевает, что код Castle.Core был включен в Moq.dll по умолчанию, я полагаю.

Я смотрел на Castle.Core.dll, который они предоставляют для Silverlight, и предполагал, что они использовали одну и ту же версию повсюду?

1 Ответ

7 голосов
/ 10 декабря 2011

Я знаю, что это старо, но для любого, кто сталкивается с этим, у меня возникла проблема с версиями Pex и Moq в один момент, и я нашел самый прямой и полезный подход - инструмент Strong Name. . То есть я обнаружил, что открыл командную строку Visual Studio и использовал «sn -Tp ThirdPartyAssembly.dll» для прямого запроса ключа. Это оказалось намного более эффективным, чем просмотр Интернета, ищущий различные, документированные открытые ключи, чтобы попробовать.

...