Каталоги inc-win32 и inc-x64

[Андрей Бушман]

Доброго времени суток.

В каталоге ObjectARX SDK присутствуют, помимо прочего, следующие подкаталоги:

• inc - ресурсы, не зависящие от разрядности AutoCAD (x86\x64)
• inc-win32 - ресурсы, предназначенные для использования в AutoCAD x86
• inc-x64 - ресурсы, предназначенные для использования в AutoCAD x64

Как правило, библиотеки присутствующие в п.2 и п.3 линкуются с опцией CopyLocal = False. Обычно, когда я компилирую плагин с опцией x86 или x64, то не выполняю переподключение ссылок на одноимённые библиотеки из каталога соответствующей разрядности, предполагая, что CopyLocal = False избавляет меня от такой необходимости. Однако возможно, что если Autodesk сделала такое разделение, то оно для чего-то  всё-таки нужно...

1. Может ли обозначенный мною подход выйти мне боком? Если да, то в каких случаях? Пока, вроде бы, проблем не возникало.
2. Если по п.1 проблем не возникает, тогда для чего выполнено разделение на inc-win32 и inc-x64?

Спасибо.

[Александр Ривилис]

Так сложилось исторически. Во-первых, не забывай что ObjectARX - это ObjectARX. И AutoCAD .NET API к нему лишь приложение. Почему я так пишу? Потому что каталоги inc, inc-x86 и inc-Win32 в первую очередь содержат *.h файлы C++. Часть из них не зависит от разрядности, часть (в первую очередь связанная с ActiveX/COM) - зависит.
Что касается AutoCAD .NET API, то в версиях до 2010 включительно сборки AcDbMgd.dll, AcMgd.dll и т.д. компилированы отдельно для x86 и для x64. Начиная с версии 2011 эти сборки не зависят от разрядности.
Т.к. эти сборки лишь "заглушки", а реально используются те, которые в составе AutoCAD, то твой подход должен работать всегда.

[Андрей Бушман]

Всё же непонятно, зачем заглушки для .NET библиотек разнесены по разным каталогам, если без разницы какие из копий подключать? Зачем такое дублирование и почему они попросту не выложены все в inc?

"Исторически сложилось" - я понимаю это применительно к C++, но .NET "играет" по несколько иным правилам. Ведь до сих пор .NET заглушки присутствуют в трёх каталогах:
- inc
- inc-win32
- inc-x64
Возможно всё же существуют объективные причины такого положения дел применительно к заглушкам .NET, помимо "исторически сложилось"? Ведь начиная с 2011-й версии часть заглушек была перенесена в inc. Почему только часть, почему не все? Я предполагаю, что в основе такого решения должны быть объективные причины. Вот о них я и спрашиваю. Не принципиально, в каком каталоге размещались бы недублируемые .NET заглушки: хоть в "net", без всяких заголовочных файлов C++ и всего того, что не относится к .NET.

[Александр Ривилис]

Возможно всё же существуют объективные причины такого положения дел применительно к заглушкам .NET, помимо "исторически сложилось"?

Ты меня не читаешь. Повторюсь:

Часть из них не зависит от разрядности, часть (в первую очередь связанная с ActiveX/COM) - зависит.

Дополнительная расшифровка:
Autodesk.AutoCAD.Interop.dll, Autodesk.AutoCAD.Interop.Common.dll (оба файла сгенерированы на основе ActiveX/COM-модели), а также все tlb-файлы зависят от разрядности AutoCAD.
.c и .h-файлы в каталогах inc-win32 и inc-x64 генерируется на основе ActiveX/COM модели AutoCAD и тоже зависят от разрядности AutoCAD. И это принципиально неустранимо.

[Андрей Бушман]

Ты меня не читаешь. Повторюсь:

Я вас внимательно читаю. Давайте повторим цитату более полно, не вырывая предложений из контекста:

Потому что каталоги inc, inc-x86 и inc-Win32 в первую очередь содержат *.h файлы C++. Часть из них не зависит от разрядности, часть (в первую очередь связанная с ActiveX/COM) - зависит.

Т.е. в контексте данной фразы речь шла о заголовочных файлах C++, а не об обёртках .NET.

Что касается AutoCAD .NET API, то в версиях до 2010 включительно сборки AcDbMgd.dll, AcMgd.dll и т.д. компилированы отдельно для x86 и для x64. Начиная с версии 2011 эти сборки не зависят от разрядности.

Вот я и спрашиваю: зачем две версии заглушек? Означает ли это, что компилируя для x86 и x64, необходимо и ссылки каждый раз переподключать, используя заглушки из соответствующих каталогов (если заглушка находится не в inc)? Временами я этого не делаю и не помню, чтобы возникали какие-либо проблемы (возможно память подводит).

Дополнительная расшифровка:
Autodesk.AutoCAD.Interop.dll, Autodesk.AutoCAD.Interop.Common.dll (оба файла сгенерированы на основе ActiveX/COM-модели), а также все tlb-файлы зависят от разрядности AutoCAD.
.c и .h-файлы в каталогах inc-win32 и inc-x64 генерируется на основе ActiveX/COM модели AutoCAD и тоже зависят от разрядности AutoCAD. И это принципиально неустранимо.

Это всё понятно, но спрашиваю я несколько о другом... Возможно не достаточно чётко сформулирован вопрос, поэтому стараюсь пояснить его... Нужно ли для таких библиотек, компилируя код под разные платформы, переподключать и ссылки проекта, каждый раз указывая заглушки из соответствующего каталога? Если всё же в этом нет необходимости, то возникает законный вопрос: тогда для чего дубляж заглушек?

[Александр Ривилис]

Нужно ли для таких библиотек, компилируя код под разные платформы, переподключать и ссылки проекта, каждый раз указывая заглушки из соответствующего каталога?

Да. Конкретных примеров когда без этого не будет работать - не приведу. Но на это указывал Stephen Preston, что говорит о том, что в ряде случае есть различия между этими сборками в зависимости от разрядности.

[Александр Ривилис]

В дополнение к вышесказанному: Где находятся сборки COM взаимодействия (Interop) ?

[Андрей Бушман]

Спасибо