Как я могу профилировать подписанные сборки с VS 2010 или VS 2013

Question

У меня есть веб-сайт, который использует AjaxControlToolkit.dll и Log4Net.dll.

Когда я пытаюсь запустить инструмент профилирования производительности в VS 2010, он выдает мне следующее предупреждение:

AjaxControlToolkit.dll подписан, и его применение сделает его подпись недействительной. Если вы продолжите без события после инструмента для повторной подписи двоичного файла, он может загружаться неправильно.

Теперь, если я выберу вариант продолжить без повторной подписи, профилирование начнется, но сборка не загрузится и выдаст исключение ASP.NET.

Answer 1

Если вы делаете это на компьютере разработчика, вы можете отключить проверку строгого имени вместе с sn -Vr *. Если вы делаете это, вам не нужно ничего подавать в отставку. Такой подход может представлять угрозу безопасности, но , если вам удобно с ним , это проще, чем уйти в отставку.

В частности, от MSDN написано:

Регистрирует сборку для пропуска проверки. При желании вы можете указать список имен пользователей через запятую. Если вы указываете infile, проверка остается включенной, но открытый ключ в infile используется в операциях проверки. Сборка может быть указана в форме *, строгое имя, чтобы зарегистрировать все сборки с указанным строгим именем. Строгое имя должно быть указано в виде строки шестнадцатеричных цифр, представляющих токенизированную форму открытого ключа. См. Параметры -t и -T для отображения токена открытого ключа.

И риск безопасности:

Внимание: используйте эту опцию только во время разработки. Добавление сборки в список пропуска проверки создает уязвимость безопасности. Злонамеренная сборка может использовать полностью указанное имя сборки (имя сборки, версия, культура и маркер открытого ключа) сборки, добавленной в список пропуска проверки, чтобы подделать свою идентификацию. Это позволило бы вредоносной сборке также пропустить проверку.

Answer 2

ghusse связано с сообщением в блоге с ответом . Ответ описан там. Как он указывает, вы должны использовать событие после инструмента в каждой подписанной сборке.

Проще всего позвонить sn.exe напрямую:

"C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\sn.exe" -R [pathOfDll] [pathOfSNK]

Обратите внимание, что [pathOfDll] находится в каталоге obj \ Debug , связанном с проектом.

Answer 3

Ответ описан здесь . Вы должны использовать событие после инструмента на каждой подписанной сборке.

Мне не удалось заставить его работать "как есть" с моей установкой VS 2010. Мне приходилось вызывать эту командную строку как событие после сборки на каждой dll:

"C:\Program Files\Microsoft Visual Studio 10.0\VC\vcvarsall.bat"   & sn -Ra [pathOfDll] [pathOfSNK]

Обратите внимание, что [pathOfDll] находится в каталоге obj \ Debug , связанном с проектом.

Answer 4

Самый простой способ получить контрольно-измерительные работы на подписанных двоичных файлах, которые не были переподписаны, - вообще отключить проверки подписи. Это настройка всей машины, которую вы можете активировать, зарегистрировав исключение для шаблона *:

sn.exe -Vr *

Эта команда должна быть выполнена из командной строки с повышенными привилегиями. Вы найдете sn.exe в SDK (в моем случае я нашел его в C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin).

Когда вы закончите тестирование, вы должны отменить регистрацию исключения:

sn.exe -Vu *

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

См. Также Доступ запрещен при запуске sn.exe в Windows 7 .

Answer 5

Профилировщик, вероятно, изменяет сборку и потому что она была ранее подписана. Очевидно, вам нужно добавить действие после инструмента, которое повторно подписывает сборку.

Это может быть проблемой, поскольку у вас нет файла sn, который использовался для подписи сторонних сборок.

Answer 6

Возможно, я выбрал ленивый путь обучения без новых вещей, но в итоге я решил эту проблему, написав скрипт powershell для подписи всех проектов в моем решении - все работало отлично. В рамках сценария я сохраняю исходные файлы csproj, чтобы потом их можно было восстановить. (Вы также можете просто отменить изменения в управлении исходным кодом).

http://pastebin.com/UbABvz7d

должен быть в состоянии вернуться, вызвав его, передав ключ -revert.