Re[2]: null в AppDomain.CurrentDomain.SetupInformation.Targe
От: drVanо Россия https://vmpsoft.com
Дата: 04.10.23 10:35
Оценка: 88 (3)
Здравствуйте, Михаил Романов, Вы писали:

V>>Куда копать?

МР>А если не добавлять конструктор, то всё инициализируется нормально?
МР>Ну и сразу уточню, а как получаете сборку? У неё есть TargetFrameworkAttribute?

Вобщем исследования показали, что AppDomain.CurrentDomain.SetupInformation.TargetFrameworkName инициализируется из нативного кода нетового рантайма.

Чуть выше пишут:

// Retrieves a possibly-cached target framework name for this appdomain. This could be set
// either by a host in native, a host in managed using an AppDomainSetup, or by the
// TargetFrameworkAttribute on the executable (VS emits its target framework moniker using this
// attribute starting in version 4).


При этом, если в процессе работы конструктора будет хоть одно обращение к AppDomain (или к его статическим членам в виде AppDomainSetup, AppContextSwitches и т.п.), то он инициализируется пустым значение TargetFrameworkName. Почему AppDomainSetup вызывается ПОСЛЕ <Module>.cctor, а не ДО — для меня очень большая загадка.

P.S. Инициализацию AppContextSwitches может вызвать даже банальный вызов метода, который работает с именами файлов (Assembly.Location, Path.GetRootPath и т.п.), который в итоге лезет в AppContextSwitches.UseLegacyPathHandling.
Отредактировано 04.10.2023 10:42 drVanо . Предыдущая версия . Еще …
Отредактировано 04.10.2023 10:36 drVanо . Предыдущая версия .
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.