Смешанный управляемый / неуправляемый порядок загрузки сборки

У меня есть несколько вопросов о порядке инициализации для CLR и CRT для смешанных сборок .NET (т.е. имеется в виду смешанные управляемые / неуправляемые сборки C ++).

Итак, если у меня есть файл dll сборки смешанного режима, и он загружается через Assembly.Load. Я заметил, что любые статические собственные объекты не будут инициализированы или вызваны до тех пор, пока сначала не будет вызван некоторый управляемый код. В ПОРЯДКЕ. Итак, я полагаю, что при запуске сначала инициализируется код CLR, а инициализация CRT вызывается последней. Как порядок на отключение? Завершается ли сначала CRT, а последним - CLR?

Так вот как это происходит?

start of program lifetime

initilialize CLR
...initilialize CRT
...construct native static instances

... program runs....

...shutdown CLR
...destruct native static instances
shutdown CLR

end of program lifetime

Или в другом порядке?

Мой вопрос также относится к сборкам смешанного режима, которые являются исполняемыми файлами (например, .exe). Это похоже?

start of program lifetime

initilialize CLR
...initilialize CRT
...construct native static instances

... program runs....

...shutdown CLR
...destruct native static instances
shutdown CLR

end of program lifetime

person C Johnson    schedule 20.12.2011    source источник
comment
Непонятно, недавно была инициализирована среда CLR, если вы используете Assembly.Load (). CRT инициализируется неясной функцией интерфейса командной строки, называемой инициализаторами модулей. Подобен инициализатору класса, но автоматически запускается при загрузке сборки. Он не инициализируется обработчиком событий для AppDomain :: DomainUnload и ProcessExit, поэтому до выхода из среды CLR. Возможно, вам стоит сосредоточиться на причине, по которой вы задаете этот вопрос.   -  person Hans Passant    schedule 20.12.2011
comment
см. мои комментарии с Ридом ниже для частичного объяснения.   -  person C Johnson    schedule 21.12.2011


Ответы (1)


Это описано на странице MSDN для Инициализации сборок смешанного режима.

На самом деле это противоположно вашей идее. Внутренний код инициализируется сначала, а затем управляемый код. Вам не разрешен доступ к какому-либо управляемому коду внутри DllMain.

Порядок процесса удаления явно не задокументирован в MSDN и не задокументирован явно в спецификациях C ++ / CLI. Я считаю, что это зависит от реализации и рассматривается в разделе «Недокументированное поведение», касающемся взаимодействия между собственными и управляемыми библиотеками приложения.

person Reed Copsey    schedule 20.12.2011
comment
Спасибо за ссылку. Моя проблема в том, что когда наше приложение закрывается, у нас есть собственные статические объекты, которые взрываются и приводят к сбою нашего приложения. - person C Johnson; 21.12.2011
comment
@CJohnson Я бы попытался исправить их напрямую. Нет причин, по которым они должны вылетать из приложения при завершении работы ... - person Reed Copsey; 21.12.2011
comment
В том-то и дело ... иногда они падают, а иногда нет. На самом деле это сложно описать одним предложением. Но у меня есть хорошие минидампы (из поля), которые показывают стек вызовов при сбое, как это происходит спустя долгое время после выхода из winmain. - person C Johnson; 21.12.2011
comment
Не знаю, возможно, если бы мы говорили об этом в автономном режиме. Это действительно кажется довольно сложным, и мне нужен кто-то, кто знает меня выше меня, чтобы посоветоваться. - person C Johnson; 21.12.2011