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

Взгляните на эти ссылки:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Кстати: Другой вариант - если ваш жесткий диск полностью заполнен, а сборки ЧРЕЗВЫЧАЙНО фрагментированы (но в этом случае 90 секунд будет больше, чем я когда-либо слышал).

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

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

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

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