Можно ли запустить управляемый код инициализации для динамической библиотеки c ++ / cli?
У меня есть большая коллекция управляемых классов, охватывающих все неуправляемые функции, которые используются многими различными решениями. Теперь мне нужно вызвать некоторый управляемый код перед выполнением чего-либо еще, и я попробовал несколько попыток, но пока не увенчался успехом.
Сначала я попытался запустить код в функции DllMain, но быстро понял, что нельзя вызывать управляемый код внутри DllMain, поскольку это небезопасно и происходит LoaderLock.
Затем я обнаружил, что могу написать свой собственный конструктор модулей следующим образом:
#pragma warning( disable : 4483 )
void __clrcall __identifier(".cctor")()
{
// Do managed code initialisation here
}
Однако это, кажется, переопределяет конструктор модуля по умолчанию, и я получаю много предупреждений компоновщика, таких как:
warning LNK4210: .CRTMP section exists; there may be unhandled static initializers or terminators
Некоторые исследования показывают, что конструктор модуля по умолчанию _DllMainCRTStartup вызывает _CRT_INIT, который инициализирует статические объекты C / C ++. По общему мнению, переопределять точку входа для dll очень плохая идея, и я не хочу создавать больше проблем для себя в будущем.
Последнее, что я попробовал, было создание глобального статического объекта из класса управляемых инициализаторов в глобальной области, в надежде, что он может быть инициализирован внутри _CRT_INIT, но, похоже, это не так.
Есть ли ЛЮБОЙ способ, которым я могу выполнить некоторый управляемый код в качестве инициализации модуля или даже выполнить отложенный код, который все еще гарантированно будет вызываться раньше всего в модуле?
Спасибо, в данный момент я полагаюсь на предоставление статической функции инициализации, которая вызывается на уровне приложения, но я, очевидно, не могу заставить всех пользователей этой библиотеки делать это в своих приложениях.
Другой вариант, который я вижу, заключается в добавлении вызова инициализации во все конструкторы управляемого класса, но, опять же, я не могу быть уверен, что кто-то, строящий эту библиотеку, будет следовать тому же шаблону проектирования, и, похоже, его нужно поддерживать, особенно если это простой способ инициализации модуля CLR.
Задача ещё не решена.
Других решений пока нет …