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

Question

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

Другая информация:

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

Answer 1

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

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

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

Answer 2

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

• 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 Framework делает много дополнительной работы для проверки сборки. Если это так, то вы можете настроить его так, чтобы он не был таким требовательным.

Answer 3

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

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

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

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

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

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

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

Answer 4

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

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

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

Answer 5

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

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

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

Answer 6

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

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

Answer 7

Может быть, подписанные сборки не являются NGEN'd, а неподписанные -.