Почему медленные загрузки подписанных сборок?

Question

На этой неделе я столкнулся с какой-то странной проблемой, о которой я не могу объяснить: я переключил свое приложение на использование подписанной версии некоторых сторонних сборок (Xceed Grid и некоторые другие их компоненты), а время запуска приложения зашло в туалет. Каждый раз, когда приложение загружало подписанную сборку, для загрузки потребовалось 30 секунд. Начало применения - от 5 секунд до более 90 секунд. Что, черт возьми, происходит здесь ?!

Некоторые другая информация:

• Это приложение WinForms работает под .NET 3.5 SP1.
• Компьютер не имел подключения к Интернету (специально для обеспечения безопасности).

Answer 1

Посмотрите на эти ссылки:

• http://blogs.technet.com/markrussinovich/archive/2009/05/26/3244913.aspx
• http://blogs.msdn.com/tess/archive/2008/05/13/asp-net-hang-authenticode-signed-assemblies.aspx

Они могли бы помочь. Возможно, конфигурация вашей системы означает, что платформа .NET делает много дополнительной работы для проверки сборки. Если это так, то вы можете настроить его так, чтобы он не был настолько придирчивым.

Answer 2

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

Передача данных с 5 секунд до 90 секунд? Я думаю, вам нужно связаться с автором собрания и спросить их, если они изменили только подпись :-)

Answer 3

Возможно, подписанные сборки не являются NGEN'd, а беззнаковые.

Answer 4

Я бы предположил, что у вас есть параметры безопасности, установленные таким образом, чтобы сертификаты сборок были проверены. Поэтому он, вероятно, пытается получить доступ к веб-сайту, чтобы проверить сертификат, а затем ждет тайм-аут (30 секунд - ОЧЕНЬ типичный номер тайм-аута).

Вы можете проверить это, если вы посмотрите, что произойдет за эти 30 секунд. Для моего предположения, что это правда, должно быть небольшое использование ЦП и мало доступа к жесткому диску за эти 90 секунд. Если у вас высокая загрузка процессора или связанная с вашим жестким диском, то это что-то еще.

BTW: Еще один вариант был бы, если ваш жесткий диск полностью заполнен, а сборки EXTREMELY фрагментированы (но в 90 секунд это было бы больше, чем я когда-либо слышал в этом случае).

Answer 5

Попробуйте запустить приложение из визуальной студии с надписью «Step over». Это запустит код, перейдя через каждое приложение, чтобы вы могли проверить, что так долго. У меня когда-то было это, и оказалось, что мой сервер sql действительно перепутался.

Еще один способ узнать, почему так долго нужно разместить точку останова, разбросанную по коду загрузки, и посмотреть, что такое узкое место. Если приложение занимает 90 секунд до его ваш первый, вероятно, что-то с XCeed или загрузка подписанных сборок.

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

Answer 6

Jason Эванса сообщение действительно содержит ответ, но в виде ссылки. Я подумал, что было бы неплохо опубликовать фактическое решение здесь:

Создайте файл Appname.exe.config в той же папке, что и исполняемый файл (где Appname - это имя исполняемого файла; для разработки это будет в отладочную папку вывода). Это показывает xml-файл, предполагающий, что у вас нет других записей в главном файле конфигурации; если у вас есть файл уже, я полагаю, вы бы просто добавить новые разделы/текст по мере необходимости:

<?xml version="1.0" encoding="utf-8"?> 
<configuration> 
    <runtime> 
     <generatePublisherEvidence enabled="false" /> 
    </runtime> 
</configuration> 

Answer 7

Просто упакуйте кто-либо приходит на этот пост, я проследил вопрос немного дальше, потому что я был просто пытаясь понять это и нашел эту страницу.

Похоже, что CRL проверяется каждый раз, когда вы запускаете свой процесс, если существующий CRL, который находится на вашем компьютере, имеет тайм-аут и еще не обновлен новым. Вы можете проверить это, нажав CRL на http://crl.microsoft.com/pki/crl/products/CodeSignPCA.crl и проверить дату истечения срока действия. Теперь настройте прокси в IE, который не работает. Установите дату своего устройства после даты истечения срока действия и повторите проверку приложения.

Если ваш сетевой адаптер отключен, CRL не проверяется.

Если ваш сетевой адаптер не имеет шлюза, CRL не проверяется.

Если у вас есть прокси-сервер и шлюз, тогда проверяется CRL, и если есть проблема с прокси-сервером, вы получите этот таймаут.

Если вы подключаетесь к Интернету успешно, то CRL обновляется, и пока вы будете в порядке.

Мое приложение использовало некоторые старые компоненты Xceed в .NET 2.0 и работает навсегда, поэтому потребовалось некоторое время, чтобы выяснить, что происходит.