ОК. Теперь у меня есть рабочая проверка тестового кода для моей проблемы.
В этот момент я извлек открытый ключ из моей сборки, используя следующие команды:
sn -p input.pfx output.publickey
sn -tp output.publickey
Это дает мне следующий публичный текст ключа в командной строке:
0024000004800000940000000602000000240000525341310004000001000100595757733513185e3dc44b958c76cdc1e56b73d5bd1c05a8a2b208311126cc1bc8e234a244cb1dcc3f3a25fbd82474911ce671cfd155242659a258c51d5fee8263a6a12d7a82cb98f1b5af0ac6e58afd2f02d1a8b9b34b5a4e8aa63a754830826caef3de5efe8ccbef81210a3dea0f977746b4f1d3335c1ca68d6a1894e47cb0
I затем наткнулся на этот пост, который вызвал некоторые мысли MSDN Social Forum.
Ярмарка, чтобы сказать, что это не сработало. Интересная вещь с этим сообщением - это 32-разрядная версия 64-разрядной версии инструмента sn. При добавлении сборок в реестр с помощью sn -Vr, это важно, какой sn.exe вы запускаете. Поэтому, если вы используете 32-разрядную версию sn.exe с -Vr для добавления сборок, которые хотите пропустить процесс проверки, тогда проверьте ее с 64-разрядной версией, используя sn -Vl, после чего она не покажет записи, которые вы только что зарегистрировали. Любопытно.
Я использовал следующие командные строки, чтобы зарегистрировать свои монтирует я хочу, чтобы попытаться избавиться от сообщения об ошибке для следующим образом:
"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\x64\sn.exe" -Vr "E:\Code Workbench\UnitTesting\UnitTestingStrongNames\MyTestableLib.Tests\bin\Debug\MyTestableLib.dll" * "E:\Code Workbench\UnitTesting\UnitTestingStrongNames\MyStringNameKey.Public"
"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\x64\sn.exe" -Vr "E:\Code Workbench\UnitTesting\UnitTestingStrongNames\MyTestableLib.Tests\bin\Debug\MyTestableLib.Tests.dll" * "E:\Code Workbench\UnitTesting\UnitTestingStrongNames\MyStringNameKey.Public"
"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\sn.exe" -Vr "E:\Code Workbench\UnitTesting\UnitTestingStrongNames\MyTestableLib.Tests\bin\Debug\MyTestableLib.dll" * "E:\Code Workbench\UnitTesting\UnitTestingStrongNames\MyStringNameKey.Public"
"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\sn.exe" -Vr "E:\Code Workbench\UnitTesting\UnitTestingStrongNames\MyTestableLib.Tests\bin\Debug\MyTestableLib.Tests.dll" * "E:\Code Workbench\UnitTesting\UnitTestingStrongNames\MyStringNameKey.Public"
ПРИМЕЧАНИЕ: Я сделал это для 32 и 64-разрядных версий Sn.exe. Я не думаю, что регистрация для тестового проекта требуется, но я оставил его.
Итак, на этом этапе мои тесты все еще не запускаются.
Я использовал инструмент Fusion Log, чтобы узнать, что происходит. Я сделал поиск содержимого файла (используя агент Ransack) своих журналов вывода, чтобы узнать, где используются мои DLL. Я заметил процесс с именем QTAgent32.exe, который я не знал, что это было. Я думал, что это был агент Quick Time, но, оказывается, это агент Visual Studio/Microsoft Testing Agent.
Тем не менее журналы не выявили многого. Я решил использовать SysInternals ProcMon. Затем я провел тесты, чтобы выявить 1000 направлений деятельности. Я искал свою DLL MyTestableLib.dll. Справедливый вниз, я заметил, что агент Test использовал его собственную папку, расположенную на моем пути решения:
E:\Code Workbench\UnitTesting\UnitTestingStrongNames\TestResults\paul.anderson_PAULANDERSON 2015-06-26 11_43_07\Out
Я смотрел в этой папке и там были мои MyTestableLib.d и mytestablelib.tests.dll файлов. Я думал, что буду использовать Assembly Information tool, чтобы иметь быстрый пик и одинокий созерцать, я получил ту же ошибку, что и тест. Тест-проект загружен нормально (поскольку у меня не было проверки против него в настройках MSTest)
ОК, теперь вернемся к регистрации sn.exe -Vr.
Я побежал следующую командную строку:
"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\x64\sn.exe" -Vr "E:\Code Workbench\UnitTesting\UnitTestingStrongNames\TestResults\paul.anderson_PAULANDERSON 2015-06-26 11_43_07\Out\MyTestableLib.dll"
"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\sn.exe" -Vr "E:\Code Workbench\UnitTesting\UnitTestingStrongNames\TestResults\paul.anderson_PAULANDERSON 2015-06-26 11_43_07\Out\MyTestableLib.dll"
И 32 и 64 бит, чтобы быть на безопасной стороне. Регистрации были добавлены (проверьте с помощью sn.exe -Vl - для 32 и 64 бит).
Затем я повторно провел тесты, и они побежали нормально. Теперь я могу просмотреть информацию о покрытии кода.
Надеюсь, это поможет кому-то еще бороться. Вероятно, есть ярлык где-то, где я был вокруг мельницы, так сказать.
