Сообщество программистов Autodesk в СНГ
ADN Club => AutoCAD .NET API => Тема начата: Андрей Бушман от 27-02-2014, 15:16:48
-
Доброго времени суток.
В каталоге 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) ? (http://adn-cis.org/gde-naxodyatsya-sborki-com-vzaimodejstviya-%28interop%29.html)
-
Спасибо