Загрузки DLL и .NET assemblies

[Dimka]

Чисто эмпирически и native DLL, и .NET assembly DLL не загружаются автоматически, пока нет обращений.

Для native DLL требуется, чтобы в программе были обращения к импортируемым данным и функциям, иначе загрузка не происходит. Однако если обращения есть, то загрузка DLL по умолчанию происходит вместе с загрузкой вызывающего модуля.

Для .NET assembly DLL тоже нужны обращения. Но загрузка происходит в отложенном режиме - только при первом обращении.


Вопрос:

Можно ли как-нибудь настроить саму DLL таким образом, чтобы она загружалась вместе с загрузкой вызывающего модуля вне зависимости от обращений к ней? (Связано с тем, что при загрузке DLL выполняется тяжёлая инициализация, которая, во-первых, должна выполняться вне зависимости от использования функций DLL, во-вторых, плохо, если она выполняется в отложенном режиме - вызывает подвисание вызывающей программы.

Интересуют варианты как для native DLL, так и для .NET assembly DLL. Варианты изменения вызывающих модулей не предлагать.

[RXL]

Дим, а если принудительно загрузить библиотеку через LoadLibrary?

[Джон]

quick and dirty:
просто тупо встроить dummy функцию и вызывать её всегда.

Хотя, наверное, вызов относится к запрещённому варианту "изменения вызывающего модуля", или?. Если чисто саму dll... Её загрузка и управление осуществляется средствами винды, т.к. dll может использоваться другими приложениями тоже, т.е. скорей всего придётся менять винду . Например повесить хук, который бы загружал dll при старте вызывающего модуля.

[Dimka]

RXL, Джон, да, всякие dummy функции и LoadLibrary подразумевают "изменение вызывающего модуля". Я эти модули не контролирую - это разные приложения, большинство из которых я в глаза не видел, и написанные чёрте знает кем (во всех коннотациях этого выражения).

скорей всего придётся менять винду

Ты пессимист. При обычной сборке DLL с использованием dllexport вместе с DLL формируется lib. Этот lib собирается вместе с "вызывающим модулем". Если этот lib прилинкован, DLL загружается автоматически при старте "вызывающего модуля".

В принципе, никто не мешает такой lib реализовать вручную, написав в нём LoadLibrary и всё прочее.

Но это потребует как минимум пересборки "вызывающих модулей", и ко всему прочему некоторые из них могут вообще грузить DLL при помощи LoadLibrary. Поэтому решение через lib годится только для новых или пересобираемых "вызывающих модулей" (без их изменения на уровне их исходного кода).

А вот с .NET assembly вообще беда. В частности, если собрать DLL, написанную на C++.NET, одновременно являющуюся обычной DLL и assembly, то при подключении этой DLL как assembly к другой assembly DllMain вообще не стартует, поскольку assembly загружаются при помощи своего особого механизма. И что с этим делять, я пока не знаю. Аналога lib-файла в .NET нет. Вернее, есть загадочные module в противовес assembly, но я нигде никогда не видел их применения на практике, допустим, в C#.