Создание инсталлятора для приложения AutoCAD с помощью WIX. Часть 1. Вступление.

Каждый разработчик приложений под AutoCAD (и вертикальные решения на его базе) рано или поздно сталкивается с необходимостью упрощения установки своих творений. В какой-то момент становится уже, как минимум, несолидно использовать установку через использование различных LISP-загрузчиков, загрузку частичных файлов адаптации и тому подобные способы. Пользователям же гораздо удобнее и проще использовать привычные всем программы установки. Создание действительно удобной, надёжной и функциональной программы установки - не самое простое дело. Для этой цели есть большое количество специализированных инструментов с различными возможностями, сложностью освоения и стоимостью. С наиболее популярными из них можно познакомиться в статьях "Путеводитель по системам для создания инсталляторов" на http://www.ixbt.com: Часть 1, часть 2 и часть 3. 

Из всего этого многообразия мною был выбран WIX. У этого инструмента много достоинств, такие как:

• Обширнейшие возможности - можно создавать программы установки практически с любым набором функций.
• Довольно прост в освоении - нужны базовые навыки работы с XML.
• Есть интеграция с Visual Studio - основным инструментом разработки ObjectARX и .NET-приложений для AutoCAD.
• Это абсолютно бесплатный инструмент.

Одним из определяющих факторов стало положительное мнение о нём таких разработчиков как Бушман Андрей и Накоряков Алексей (более известный как bargool). Собственно, Алексей мне его и посоветовал и помогал с освоением на первых порах.

Незаменимой кладезю информации по WIX является книга Евгения Воднева "Windows Installer XML. Создание программы установки в Visual Studio". Не смотря на то, что книга написана более 6 лет назад, и некоторая информация в ней является устаревшей, большая часть рекомендаций не потеряла своей актуальности и по сей день.

Помимо этого, конечно же, есть первоисточник знаний о WIX на сайте продукта, а также много различных обсуждений, примеров и статей на специализированных сайтах-ресурсах по программированию.

Теперь, немного о том, каким образом выполнять установку приложений под AutoCAD. В этом очень сильно разработчикам помогла сама компания Autodesk, которая добавила возможность оформлять приложения для своих программных продуктов (AutoCAD, Revit, Invertor...) в виде Bundle-пакетов. Подробнее об этой технологии - в документе под названием Autodesk Autoloader White Paper. Самое важное в этом то, что в настоящее время есть возможность оформлять в едином виде любые типы приложений: ObjectARX, LISP, VBA, COM или .NET. И для установки приложения будет достаточно просто поместить скомпонованную должным образом папку с файлами приложения в одно из следующих мест:

• %APPDATA%/Autodesk/ApplicationPlugins - приложение будет доступно только для текущего пользователя.
• %ProgramData%/Autodesk/ApplicationPlugins - приложение будет доступно всем пользователям.

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

Особенности отображения элементов сети на видах профилей.

Трубы и колодцы отображаются на видах профилей таким образом, как определено в настройках стиля.
Трубы, в зависимости от настроек, могут отображаться сечением вдоль трассы и/или сечением поперек трассы. В общем случае, одновременное отображение и вдоль и поперек не имеет практического смысла. Как правило, на видах профилей труба должна показываться каким-то одним образом. Если это труба основной сети вида профиля - то в настройках стиля должны быть заданы параметры отображения трубы вдоль трассы. Если же труба является пересекающей, то в настройках стиля задаются параметры отображения только сечения трубы в месте пересечения трассы и трубы.
Колодцы на видах профилей могут отображаться как трехмерный объект по данным из каталога элементов, контуром этого объекта или в виде блока, заданного в настройках стиля. Наиболее применимое на практике отображение - в виде контура трехмерного объекта.
Это довольно базовые понятия, поэтому подробно описывать их не вижу смысла.
Однако, есть несколько неочевидных моментов, на которые стоит обратить внимание. Одна из самых сложных ситуаций - когда трасса проходит не по элементам сети, а в стороне от них или пересекает их. В таком случае, сложно оценить, каким образом будут отображены элементы на трассе. Чтобы упростить эту задачу, предлагаю ознакомиться со следующими правилами отображения элементов сети на видах профилей:

• Отдельный колодец или отдельная труба (важно: настроенная на отображение вдоль трассы вида профиля) на отдельном виде профиля отображается только один раз. Что это означает? При любой геометрии трассы, даже если она будет несколько раз пересекать точку вставки колодца, делать несколько "петель" вокруг трубы, они будут отрисованы на виде профиля только в одном месте. В каком? Смотрите правило ниже.
• Определение места отрисовки элемента на виде профиля выполняется просто. Для колодца берется точка вставки и находится к ней ближайшая точка на трассе. Если таких точек несколько - берется та, у которой пикет меньше. Для трубы правило то же самое, только берутся начальная и конечная точки трубы. Причем, для трубы отсутствует такое явление как точная геометрическая проекция на трассу. При точном проецировании трубы на трассу в тех местах, где трасса делает поворот, на виде профиля должен наблюдаться излом трубы по вертикали. Однако, такого не наблюдается. Это объясняется тем, что отображение строится по такому алгоритму: определяются положения начальных и конечных точек трубы на виде профиля и просто строятся отрезки между начальными и конечными точками, без учета промежуточных поворотов трассы.
• Исключение из перечисленных выше правил - отображение сечения пересекающей трубы. Оно отрисовывается на одном виде профиля столько раз, сколько труба пересечет трассу вида профиля. Но опять же, если пересечение осуществляется в местах излома трассы, не соблюдается точное геометрическое формирование сечения трубы.

Каталог трубопроводной сети Civil 3D (Pipes Catalog). Экскурс в историю.

Итак, немного истории. Самая ранняя версия Civil 3D, упоминание о которой мне удалось найти в интернете – AutoCAD Civil 2004. Версия была выпущена в 2003 году, и в ней еще не было трубопроводных сетей. Мне точно неизвестно, когда они появились – в 2005 или 2006 версии, но в 2006 они уже точно были:

Но в этой версии не было еще редактора каталога для элементов трубопроводных сетей (Part Builder). Вместо этого, можно было посмотреть содержимое каталога в браузере:

Там же, в каталоге труб для версии 2006, есть интересный файл «ReadMe_Setup.txt», который объясняет, каким образом осуществляется возможность просмотра содержимого каталога в браузере:

*** iDrop enabled Web Page display of ABS Part Catalogs ***
The files contained in this zip file can be used to configure any of our xml-based catalogs to
display in an IE5 or IE6 Web Browser with iDrop enabled for all parts.
To add these files to a catalog, and configure the catalog(s) to display as web pages:
1. Unzip the files to a folder one level up from the catalog .apc file you wich to web enable.
Example: if your .apc file is D:\MyCatalogs\CoolParts\CoolParts.apc
then unzip to D:\MyCatalogs
This will add the following support file folders:
Catalog
Images
xsl
js
css
2. Copy the files from the "Catalog" folder to the folder containing the .apc file
Example: D:\MyCatalog\Catalog\*.* to D:\MyCatalogs\CoolParts
3. Edit the newly copied Catalog.htm file and make the following changes, depending on your .apc file
a) edit strCatalog to match your .apc filename, e.g. "CoolParts.apc"
b) edit strNestedPathsRelTo to be either "Table" or "Catalog" depending on your part domain.
Generally MvPart catalogs use "Table" relative paths, while all fitting catalogs use "Catalog"
c) edit strCatalogDomain to match your domain
// ********************** BEGIN CATALOG CONFIG **************************************************************
// To configure your catalog, edit the following 3 vars
//
var strCatalog = "GoboTestMvPart.apc"
var strNestedPathsRelTo = "Table" // MvParts are "Table", all other catalogs are "Catalog"
var strCatalogDomain = "MvPart_Component" // Domain "Duct_Component, Pipe_Component, MvPart_Component, etc.
//
// *********************** END CATALOG CONFIG ***************************************************************
4. Save the Catalog.htm file.
After making these changes you should be able to double-click on the Catalog.htm file and browse your catalog.

Стоит отметить, что просмотр содержимого каталога в современных браузерах недоступен. Я пробовал в IE 11, Chrome 45, FireFox 40 – результат одинаков.

Зато теперь понятно назначение папок css, xsl и js, а также файлов htm и пр. – они предназначены для отображения состава каталога в браузерах IE5 и IE6 J.

В целом же, каталог элементов с тех пор не изменил своей структуры, только наполнился новыми элементами.

Редактор каталога появился в следующей версии – 2007:

Выглядел он абсолютно так же, как сейчас, поэтому, нет смысла его описывать.

Каталог трубопроводной сети - Pipes Catalog. Детальный разбор файлов. Часть 2.

Сегодня я продолжаю разбор каталога частей безнапорной сети AutoCAD Civil 3D. Версию я не указываю, т.к. на протяжении как минимум четырех последних версий (2010-2014) эта часть не изменялась в плане структуры и организации.

Итак, продолжим. В прошлой части я закончил с разбором папки Aecc Shared Content. Переходим к следующим.

css, Images, js, xsl

Названия этих папок говорят сами за себя и никаких неожиданностей содержимое не приносит. В папке "css" хранятся файлы таблиц стилей, в "Images" - картинки и иконки, в "js" - скрипты JavaScript, в "xsl" - файлы настройки отображения xml страниц. Глядя на весь контент, возникает только один, но очень интересный вопрос: ЗАЧЕМ это тут?

Я недолго ломал голову и строил догадки. Все это служит для отображения контента в браузере. Но каком? Редактор каталога - встроенный в Civil, не браузерный. Использование каталога осуществляется без какого-либо дополнительного отображения. Отредактировал, добавил в список элементов трубопроводной сети и используй. Где еще могут понадобиться эти файлы? Загадка.

Покопавшись в этих папках, можно отметить несколько вещей:

1. Многие файлы создавались примерно в 2000 году. Об этом сообщают некоторые комментарии внутри файлов.
2. Внутри файлов нет каких-то параметров или обозначений, которые встречались бы где-нибудь в Civil. То же самое можно сказать и практически про все картинки-иконки из папки Images.
3. Сравнив наш каталог родом из 2011 версии с каталогом 2014 версии, можно обнаружить, что содержание этих папок и сами файлы остались неизменными. АБСОЛЮТНО идентичны!

Что приходит в голову:

Версия 1:

Возможно, что раньше не было редактора каталога и исправления и изменения требовалось вносить непосредственно в файлы. Чтобы как-то визуализировать структуру каталога использовался браузер, и файлы из указанных папок были востребованы. Со временем инструмент потерял свою актуальность, был удален. А папки остались как рудименты.

Версия 2:

В Autodesk используется какой-то другой инструмент для редактирования каталога, которому нужны эти папки и файлы в них. Просто забыли их удалить после редактирования.

Версия 3:

Файлы используются в каком-то внутреннем неизвестном механизме.

Если верна версия 1 или 2, то папки можно смело удалять. Если верна версия 3, то после удаления папок должны появиться неполадки в работе с каталогом. В любом случае, попробовать стоит. Предварительно, разумеется, сделав резервную копию.

Стоит сказать, что я уже попробовал это сделать. Каких-то проблем, на первый взгляд, нет. Каталог открывается на редактирование, элементы ведут себя как положено, никаких сообщений об ошибках не появляется. Возможно, что в будущем выявятся какие-то неполадки, но пока Civil не волнуется по поводу отсутствующих папок каталога.

Далее на очереди - оставшиеся папки, в которых находятся описания отдельных элементов. Думаю, что материал по ним получится обширный, поэтому оставлю его на следующий раз. 

Каталог трубопроводной сети - Pipes Catalog. Детальный разбор файлов. Часть 1.

Сегодня я начинаю разбирать состав каталога традиционной (безнапорной) трубопроводной сети Civil 3D.
У меня до этого уже был некоторый опыт работы с ним. В частности, мне удалось создать с нуля нормально функционирующий колодец (если вы думаете, что это не сильно сложно - попробуйте) и сделать некоторые вещи, которые не получались стандартными средствами. Как показала практика, функционал в каталог заложен гораздо больший, чем позволяет использовать стандартный редактор каталога. Так что, нужно детально разобраться, что же еще можно из него выжать.
Так сейчас выглядит структура нашего рабочего каталога:

Из него удалено уже все, что касается размеров труб и колодцев в британских единицах. Оставлено только то, что действительно нужно для работы. Это позволило уменьшить его размер примерно в два раза, что очень облегчает его передачу через интернет.
Пройдемся по папкам.

Aecc Shared Content

Название говорит о том, что здесь должен содержаться какой-то контент для общего доступа. Заглянем внутрь:

6 файлов XML и один TXT. Вполне читаемые и редактируемые форматы. Я для исследования буду использовать бесплатную Visual Studio Express, хотя можно было воспользоваться обычным блокнотом. Рассмотрим каждый по отдельности.

AeccCatCfg.xml

Вот все, что он содержит:

Не густо. Какие-то две настройки с малоинформативными именами. Что они означают - одному разработчику известно. Комментарий сообщает о том, что этот файл должен лежать в той папке, в которой он, собственно, и лежит. Что же, оставим его в покое.

AeccCatValCfg.xml

Хоть он также содержит всего два параметра, его содержание более информативно, чем у предыдущего файла:

Судя по описанию, параметры предназначены для настроек тестирования каталога. Возможно, что в будущем это нам как-то пригодится, но сейчас это не вызывает интереса. Закрываем файл.

AeccPartParamCfg.xml

Ого! Вот это уже похоже на серьезный файл конфигурации! Настолько серьезный, что его скрин не помещается на один экран. Будем разбирать его кусочками. Чем хороши специализированные XML редакторы - в них можно сворачивать разделы. И тогда можно более наглядно увидеть структуру этого файла:

Корневой элемент AeccParamConfigSet содержит два элемента - AeccParamDeclaration и AeccParamUsage. Рассмотрим их по очереди.

AeccParamDeclaration

Cодержит в себе несколько элементов типа AeccDfSortGroup. Эти элементы содержат элементы типа AeccDfParameter, которые хранят информацию о параметрах специфических характеристик элементов каталога. Вот несколько таких параметров:

Рассмотрим, что означает каждый атрибут одного отдельного параметра:

<AeccDfParameter name="PrtSN" desc="Название размера элемента" context="Catalog_PartSizeName" index="0" datatype="String" usage="String_Name" unit="" visible="True" internal="True"/>

• name - Сокращенное обозначение параметра, используется, например, в формулах
• desc - Описание параметра, локализуется (иногда довольно криво)
• context - Независимое от локализации имя/описание параметра. Что-то мне подсказывает, что именно по нему Civil определяет с каким параметром имеет дело и как его программно обрабатывать.
• index - Неясно, что это. У параметров этой секции преимущественно равен "0". Встречается также значение "1".
• datatype - Тип значения. Бывает "String", "Float", "Int", "Bool". Других вроде больше нет. Для тех, кто хотя бы немного знаком с программированием, ясно, что это обозначает строку, число с плавающей точкой, целое число и логическое значение соответственно.
• usage - Судя по всему, это индикатор того, как Civil должен распознавать это значение. Есть варианты:
• для datatype="String": "String_Name", "String_General", "String_EnumKey", "String_Guid"
• для datatype="Float": "Double_SmallDistance", "Double_General", "Double_Distance", "Double_Angle", "Double_NonZeroNonNeg"
• для datatype="Int": "Int_General", "Int_NonZeroNonNeg". Нашелся также один вариант для "Int" от строки - "String_EnumKey". То ли ошибка, то ли особенность.
• unit - Единица измерения. Используется для datatype="Float". В зависимости от usage может быть "in"(я так понимаю - сокращение от inch и должно быть "mm" по хорошему, чтобы соответствовать нашей метрической системе), "deg"(degrees - градусы), "" - пустое значение, если величина безразмерная или типа, отличного от "Float".
• visible - Видимость параметра. Где? Хороший вопрос. Скорее всего, это отвечает за видимость параметра в свойствах элемента на чертеже.
• internal - Судя по названию, означает что параметр внутренний. Возможно, что это ограничивает его область видимости. У всех параметров значение установлено в "True".

Попробую сделать некоторые выводы из этой информации на основе своего опыта.

Большая часть параметров вопросов не вызывает, т.к. они используются в стандартном редакторе каталога.

Можно безбоязненно отредактировать здесь такой атрибут, как desc - это повлияет на то, какое описание параметра будет отображаться в редакторе каталога. Обязательно этим займусь, так как от описания некоторых параметров просто мозг взрывается (например "Зазор вертикальной трубы").

Атрибуты name и context трогать не стоит - первый используется в формулах, второй - для идентификации параметра Civil'ом. Если их отредактировать, каталог будет работать криво. То же самое касается атрибутов datatype и usage.

Атрибуты index и internal непонятны, а посему их тоже трогать не стоит.

Сомневаюсь, что где-то используется атрибут unit, иначе уже давно бы были проблемы с его неправильным значением. Как-никак, каталог уже несколько лет в работе. Раз проблем нет - значит это чисто справочная информация. Но для порядка, надо попробовать заменить in на mm.

Атрибут visible у меня также чешутся руки потрогать. Например, можно попробовать отключить видимость некоторых элементов, наличие которых в свойствах не требуется. Посмотрим, что из этого получится.

AeccParamUsage

Этот элемент не столь обширен как предыдущий, но содержит весьма интересную информацию!

В него входит несколько элементов типа AeccPartDomainCfg - конфигурации доменов частей. В их атрибутах name - имена доменов, конфигурации которых задаются. Используя соответствующие названия элементов, определяется какой параметр будет обязательным, какой опциональным и т.п. Рассмотрим подробнее одну конфигурацию:

Включаем мозг (хоть это и не просто в почти час ночи) и приступаем к расшифровке:

• <AeccPartDomainCfg domain="Pipe_Domain"> - открывающий тег, показывает, что элемент является конфигурацией домена части (части трубопроводной сети). Атрибут domain содержит имя домена, для которого приведена конфигурация - "Pipe_Domain".
• <AeccReqParam context="SweptShape"/> - первыми идут элементы, обязательные для этого домена. В данном случае - это "SweptShape". Если посмотреть в предыдущем разделе AeccParamDeclaration, то мы найдем там параметр с таким атрибутом context - это не что иное, как "Форма поперечного сечения". Логично, что для того, чтобы определить трубу, нужно задать, какой она будет формы.
• <AeccPartTypeCfg type="Pipe" desc="Труба"> - открывается тег нового элемента, показывающий, что внутри домена есть еще и типы, для каждого из которых задается своя конфигурация. В данном случае это "Труба" (как неожиданно!).
• <AeccReqParam context="WallThickness"/> - здесь мы узнаем, что единственным обязательным параметром является толщина стенки.
• <AeccShpParam context="PipeInnerDiameter"/>,<AeccShpParam context="PipeInnerHeight"/>,<AeccShpParam context="PipeInnerWidth"/> - эти параметры являются зависимыми от формы трубы - на эту мысль наводит Shp в имени. И в зависимости от формы могут потребоваться внутренний диаметр, внутренняя высота и внутренняя ширина.
• <AeccOptParam context="Material_Type"/>,<AeccOptParam context="MinCurveRadius"/>,<AeccOptParam context="FlowAnalysis_Manning"/>,<AeccOptParam context="FlowAnalysis_HazenWilliams"/>,<AeccOptParam context="FlowAnalysis_DarcyWeisbach"/> - Эти параметры являются опциональными - наличие Opt в названии просто не оставляет других вариантов. Это такие параметры как тип материала, минимальный радиус кривой (да ладно? где же он в Civil?) и три коэффициента, которые используются для гидравлических расчетов.
• </AeccPartTypeCfg> - Закрывается тег - описание типа завершено.
• </AeccPartDomainCfg> - Закрывается тег - описание домена завершено.

Аналогичная ситуация и с доменом колодца.

Попробуем проанализировать эту информацию.

Согласно этой конфигурации, есть обязательные параметры, которые должны задаваться для элемента. Есть какие-то параметры, которые определяются в зависимости от формы. Где определяется эта зависимость - пока не понятно. Возможно, что это внутренний механизм Civil. В любом случае, трогать их в этом файле категорически не рекомендую. Наряду с этим, есть опциональные параметры, которые, по идее, можно было бы и не задавать. Но, как показывает практика, в редакторе удалить эти параметры, которые вроде как опциональные, совершенно невозможно. Может быть, такое получится сделать в этом файле?

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

Фух. Большой файл, но и полезного в нем немало. Посмотрим, что еще в этой папке.

AeccPartParamCfg_old.xml

Это, как я понимаю, мои проделки. Когда я в предыдущий раз копался в каталоге, то сделал на всякий случай резервную копию файла, в котором пробовал вносить изменения. Очень советую сделать то же самое, прежде чем будете что-то пытаться изменять! Удалить, правда, забыл. Но это не так страшно, как испортить каталог.

AeccPartTemplate_RelCat.xml и AeccPartTemplate_RelPart.xml

Я решил объединить их в один подзаголовок, так как они очень похожи. Судя по всему, это шаблоны для создания чего-то. Заглянем внутрь:

Пока не понятно, для чего они нужны. Разница между ними - только в наличии атрибута pathsRelativeTo="Table" в файле AeccPartTemplate_RelPart.xml. Возможно, что изучая дальше каталог, мы найдем файлы, выполненные по этим шаблонам.

AeccuGuidList.txt

Текстовый файл, в котором перечислены GUID элементов каталога без всякого разделения на категории:

Наверное, это нужно для быстрой инициализации элементов каталога. Особо интереса не представляет.

Ну что же, на сегодня достаточно. Продолжение исследования - в следующих частях.

P.S. В дополнение к теме:
http://beingcivil.typepad.com/my_weblog/2010/07/assigning-optional-properties-to-a-part-size.html

Предварительный выбор объектов в AutoCAD C#.NET

Сегодня разбираю предварительный выбор объектов в AutoCAD с помощью C#.NET.
Ранее я уже имел дело с выбором с помощью LISP, немного сталкивался с ним и на C#.NET, но досконально не разбирался с ним. Пришло время это сделать!

Методы работы с предварительном выбором продемонстрированы тут: http://through-the-interface.typepad.com/through_the_interface/2006/09/using_the_pickf.html 

Создание элементов напорной трубопроводной сети. Часть 2.

Оригинальная статья на английском языке находится тут:
http://ideatesolutions.blogspot.ru/2012/08/civil-3d-2013-pressure-network-parts_15.html

Автор: Matt Miyamoto

Для быстрого ввода в курс дела (Часть 1): новый инструмент Напорная трубопроводная сеть использует .SQLITE файлы вместе с папками, содержащими графическую информацию для описания частей сети. Для добавления информации в этот SQLITE файл используются две новые команды и новое приложение Редактор каталога компонентов, которое поставляется вместе с Civil 3D 2013.