Руками добавляю <Module>.cctor и в результате получаю null в AppDomain.CurrentDomain.SetupInformation.TargetFrameworkName.

Куда копать?

Здравствуйте, drVanо, Вы писали:

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

Вообще это поле судя по устанавливаться может по-разному. Самый распространенный вариант, как я понимаю — это читать атрибут, который выше.

Здравствуйте, Михаил Романов, Вы писали:

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.