Господа, не замечали ли вы такую странную вещь: если посмотреть (например, ProcessExplorer'ом) список загруженных DLL различных процессов, то частенько попадаются процессы с одной и той же DLL, загруженной дважды с разными базовыми адресами. Причем путь к обеим образам одинаков (т.е., WinSxS тут, скорее всего, ни при чем). Например, в процессе devenv.exe 8-й студии две копии devenv.dll, а NATDbgDEUI.dll - аж четыре (!) штуки, все с разными базовыми адресами и одинаковыми image path. Что это за странности?
Может просто глюк какой? Скажем подгрузили библиотеку не тогда когда нужно, а старую перед етим не выгрузили. Вообще-то не вижу смысла для чего такое делать...
Возможные предположения: одна из копий загружена виндой как inprocess COM server по вызову CoCreateInstance(), а вторая прилинкована динамически через LoadLibrary() или таблицу импорта... Хотя смысловая нагрузка такого решения все равно сомнительна...
Народ, как раз пытаемся разобраться с именно этой проблемой, обсуждение начато в гугл группах, http://groups.google.com/group/microsoft.public.vc.atl/browse_thread/thread/6798d92924ea759c, но, увы, там тишина (равно как и на msdn форумах, ссылку припводить не буду - там вообще обсуждения нет никакого), поэтому хотел бы услышать ваше мнение тут. В нашем рассматриваемом примере (http://www.megafileupload.com/en/file/29786/SideBySideTest--2--zip.html), да, мы грузим эту длл вначале с помощью SxS COM, создавая объект, живущий в ней, а воторой раз - как статически прилинкованную к загружаемой через LoadLibrary длл (т.е. делаем LoadLibrary "промежуточной" длл, в таблице импорта которой находится "проблемная" первоначальная дублирующаяся длл (та, в которой живут созданные раньше через SxS ком объекты)). Порядок загрузки изображен тут: http://i10.photobucket.com/albums/a148/JamieRThomson/SideBySideCOMProblem.jpg. Меня бы может и устроил ответ, что, типа, в одном случае у нас ком грузит, а в другом - LoadLibrary, да и то опосредованно через таблицу импорта и все такое (хотя это, имхо, бред, какая разница как оно грузится, если образ один и тот-же, да и поискать в нете если, то везде говорят, что "dll can't be loaded twice" с различным вариациями), если бы не еще несколько НО с нашей точки зрения: 1. Если в указанном примере использовать обычный ком, а не SxS, то копия длл оказывается одна. 2. Если изменить порядок загрузки и вначале грузить через LoadLibrary, а потом создавать объект через SxS ком - то опять-же, копия одна. И пускай уже, пункт 1 я готов принять как некий by design, но вот пункт 2 ставит большой знак вопроса. Какими бы ни были разными механизмы загрузки, но порядок не должен влиять на конечный результат, при использовании одних и тех же механизмов. Более того, если поставить бряки в DllMain дублирующейся длл, то студия дуреет: при первоначальной загрузке через SxS все красиво брякается, а вот при повторной непонятной загрузке студийные бряки не срабатывают, а int3 приводит студию в шок и она показывает в стеке вызовов полную ерунду + асм код вместо исходников. Т.е. она видит, что длл загружена по одному базовому адресу и никак не хочет принимать тот факт, что та же длл есть и еще по одному адресу. Ну и напоследок скажу, что mapping type для обоих инстансов этой длл одинаков - Image. Безусловно, image path также идентичны. Заранее благодарен за ваши соображения на этот счет.
TheRawGod И правда, 2 экземпляра одной ДЛЛ... :0 Если это представляет проблему, то можно грузить COM-овскую DLL (SideBySideDLL.dll) только динамически, в этом случае, кажется, всё в порядке. Или, что то же самое, сделать её delay loaded - тогда не придётся ничего менять в коде.
