Допустим, что тип static class MyClass не загружается во время AppDomain.AssemblyLoad. Возможно, класс содержит статическое свойство, которое считывает строку соединения из config. Будут ли дальнейшие ссылки на типы в указанной DLL причиной AppDomain.AssemblyLoad, чтобы попытаться перезагрузить DLL?Что произойдет, если статический класс Load failed
Другими словами, будет ли AppDomain.AssemblyLoad повторить загрузку DLL, которая ранее не была загружена?
так он будет перезагружаться снова для дальнейших вызовов некоторых методов в этом классе?
№ п. Если инициализация типа не выполняется для определенного типа, этот тип фактически бесполезен в жизненном цикле AppDomain. Любая дальнейшая попытка использовать тип просто сразу же вытащит тот же TypeInitializationException, без повторной попытки. Избегайте ошибочной инициализации типа, где это возможно.
Если вы создадите новый AppDomain, то , чтобы попытался снова инициализировать тип.
Я бы добавил, что если вы попытаетесь повторно использовать один и тот же тип позже, то будет отправлено одно и то же исключение без фактического повторного запуска инициализатора класса. (Я уже видел забавные вещи, такие как TimeoutExceptions, происходящие мгновенно ... из-за неудачного вызова WCF в инициализаторе класса. Eurk) – Olivier
@Olivier: Спасибо - отредактирован. –
Наверняка нет, если дизайн вашего класса этого не делает.
Например, если для каждого метода доступ к вам проверяется либо инициализирован либо класс, либо нет, а если не инициализировать его, вы можете может имитировать это поведение.
Но, честно говоря, это не очень хороший дизайн.
Можете ли вы опубликовать код в качестве примера того, что вы имеете в виду? –
Определите «сбой» в этом случае. Если он генерирует исключение, вы, скорее всего, увидите это исключение из инициализатора класса. – David