С каждым новым релизом ANSYS пакет инструментов для автоматизации (ACT – Application Customization Toolkit) становится всё качественнее и обретает всё больше новых функций. Недавно я разработал ACT-расширение, которое можно отнести в категорию довольно больших проектов. В этой статье я хочу пролить свет на некоторые технические нюансы и дать практические рекомендации, к которым я пришёл в процессе разработки.

Почему я выбрал C#?

Большинство ACT-расширений написаны на Python, этот язык прекрасно подходит для быстрой разработки прототипов и построения приложений любой структуры и размеров. Он обладает гибкой системой типов, множеством библиотек, огромной экосистемой и встроенной поддержкой прямо в ACT-консоли – всё это делает Python наиболее подходящим выбором для работы с ACT. Так почему же я решил использовать C#?

Основные причины моего выбора C# вместо Python для работы с ACT заключались в следующем:

1. Я отдаю предпочтение большей безопасности типов, которая обеспечивается C# благодаря статической явной типизации. Кроме того, наличие чётко выраженного шага компиляции заставляет меня сначала давать мой код на проверку компилятору, и только когда (и если) компилятор может представить мой исходный код на ассемблере, я могу переходить к следующему шагу запуска и отладки программы уже в среде продуктов ANSYS. Ошибки, обнаруженные во время компиляции, обычно проще и быстрее исправить. И, по сути, они не могут остаться неисправленными (вы не сдвинетесь с места, пока не устраните ошибку…).
2. Процесс разработки программного обеспечения на C# глубоко интегрирован в среду разработки Visual Studio. Она обеспечивает не только удобный редактор кода, но и, что наиболее важно – пожалуй, лучший в мире отладчик, позволяющий быстро понять, где и когда произошла ошибка. Несмотря на то, что редактирование и отладка кода на Python под Visual Studio тоже возможны, с C# работать значительно удобнее.

Что влечёт за собой разработка ACT-расширений на C#

К сожалению, написание ACT-расширений на C# влечет за собой некоторые затраты, а именно, для обеспечения работы необходимо настроить среду разработки, в то время как для написания расширения на Python достаточно подходящего текстового редактора. К тому же, как только ACT-расширение установлено, создана и наполнена указанная в документации структура папки, становится возможным редактирование только самих текстовых файлов на Python, непосредственно в том же расположении, на которое ссылается ACT-расширение. Как вы, быть может, знаете, ACT-расширение требует XML файл, определяющий структуру формы ввода данных, а также директорию с таким же именем, которая содержит всё, что касается данного расширения (Python-скрипты, изображения и т.д.) – то, что формирует расширение.

Когда приходит время создания структуры папки ACT-расширения, написанного на C#, ситуация несколько усложняется. Как упоминалось ранее, среда разработки компилируется код на C#, в результате чего создаётся DLL-библиотека. После этого файл библиотеки надо каким-то образом загрузить в Mechanical, чтоб использовать в ACT-расширении. Ситуация усложняется ещё немного: в Visual Studio компилированные файлы (в том числе DLL-библиотеки) размещаются в рамках определенной структуры папок проекта. При этом, DLL-библиотека может оказаться в одной из нескольких папок – в зависимости от того, с какими настройками производится компиляция. С практической точки зрения, процесс отладки приложения будет наиболее простым, если оставлять DLL-библиотеку именно в том расположении, в котором её решит создать Visual Studio.

Вот итоговый список трудностей, с которыми я столкнулся при написании ACT-расширения на C#:

1. Надо каким-то образом загрузить скомпилированную библиотеку DLL в Mechanical, чтобы созданное расширение могло её использовать.
2. Существуют различные варианты расположения DLL-библиотеки.
3. ACT-расширение должно иметь определенную структуру папки и файлов на диске, которая отличается от структуры, используемой в Visual Studio.
4. Процесс отладки в Visual Studio упрощается, если оставить DLL-библиотеку там, где её размещает Visual Studio.

Решение этих проблем, которое пришло мне на ум, состояло из двух частей.

Во-первых, проблема загрузки DLL-библиотеки в Mechanical была решена заданием переменных окружения на моем компьютере и написанием кода на Python в основном скрипте ACT-расширения. Да, даже если основная часть расширения написана на C#, всё еще остается скрипт на Python для загрузки расширения в Mechanical. Ниже рассмотрим это подробнее.

Во-вторых, я решил полностью перезаписывать папку ACT-расширения при каждой компиляции проекта на C#. Для этого я задал в Visual Studio так называемые «post-build events» – они позволяют автоматически выполнить какое-нибудь действие сразу после успешного завершения компиляции. Это действие может быть вполне произвольным. В моем случае я запускаю скрипт на Python с вводом нескольких аргументов в командной строке. Ниже рассмотрим и это подробнее.

Загрузка полученной DLL-библиотеки в Mechanical

Как упоминалось выше, даже если ACT-расширение написано на C#, для загрузки в Mechanical ему всё равно необходимо немного кода на Python. Именно в этом месте я решил указать, какую именно DLL-библиотеку загружать в расширение. Вот так выглядит код:
Этот код проверяет наличие определенной переменной окружения на локальном компьютере (название переменной выбрано так, чтобы она случайно не присутствовала на компьютере конечных пользователей расширения). Когда нужная переменная найдена и ее значение равняется 1, код определяет, какую версию DLL-библиотеки необходимо загрузить: отладочную или окончательную (зависит от типа сборки). Для определения расположения папок с этими версиями в проекте Visual Studio (debug и release соответственно) используется еще 2 дополнительных переменных окружения. И наконец, если код определил, что он запущен на пользовательском компьютере, он обращается к DLL-библиотеке по стандартному расположению в папке расширения. Благодаря такому скрипту на Python можно забыть о необходимости редактировании кода перед тем, как поделиться этим расширением с кем-либо еще.

Перезапись папки ACT-расширения

Последний фрагмент головоломки – перезапись всей папки ACT-расширения после каждой компиляции в Visual Studio. Я это делаю по нескольким причинам:

1. Я хочу, чтобы у меня на диске всегда была рабочая копия расширения – так будет проще поделиться расширением с другими.
2. Я люблю хранить все сопутствующие расширению файлы – изображения, XML-файлы, скрипты на Python и т.д. – внутри проекта Visual Studio. В таком случае, если я поменяю какой-то из этих файлов, для внесения изменений мне обязательно придётся перекомпилировать всё расширение, и нужно будет пройти этап проверки при компиляции. Особенно это полезно в работе с файлом XML-разметки для формы ввода данных в расширение.
3. Когда все файлы расширения располагаются внутри проекта Visual Studio, становится гораздо проще отслеживать изменения при помощи системы управления версиями (такой как SVN или git).

Как упоминалось ранее, для перезаписи всего расширения я использовал код на Python и настройку событий после компиляции в Visual Studio. Не думаю, что стоит приводить здесь весь код на Python – если вкратце, то он выделяет все файлы в папке C# проекта Visual Studio, необходимые для формирования ACT-расширения, удаляет старые файлы расширения, которые могли остаться от предыдущей сборки, и создаёт новые файлы и папки ACT-расширения в указанном месте. Запуск этого кода задается следующими настройками проекта Visual Studio:
Из картинки выше видно, что команда события после компиляции заключается в вызове системного интерпретатора Python и передаче ему скрипта с несколькими аргументами. Visual Studio предоставляет большое количество предварительно определенных переменных, доступных для использования в данном случае. К примеру, я передаю строку, которая точно определяет тип текущей сборки: «Debug» или «Release». Другие переменные содержат имена папок и т.д.

Работа системы в целом

Наконец, перейдем к результату, которого можно добиться благодаря комбинации двух приёмов, описанных выше. Одна из последних доработок кода события после компиляции, которую я реализовал, – редактирование некоторых текстовых файлов ACT-расширения (XML-файлы, Python-скрипты). Я понял, что мне необходимо добавить ряд элементов в XML-файл, когда я запускаю локальную отладочную версию, а не публикую расширение для использования конечным пользователем. Опять же, чтобы не держать в голове необходимость внесения необходимых правок перед релизом расширения, я решил реализовать их скриптом после компиляции. Если этот скрипт запускается в режиме «Debug», он настраивает расширение для удобной отладки, а в режиме «Release» – немного изменяет XML-файл и основной скрипт Python для оптимизации работы расширения на пользовательском компьютере. Таким образом, я могу быстро выполнить компиляцию в любой из конфигураций, и быть уверенным, что итоговое расширение будет оптимально настроено для конкретного применения.

Заключение

Теперь, когда у меня есть небольшой опыт в написании ACT-расширений на C#, могу откровенно признаться, что предпочитаю его Python’у. Да, главный минус – наличие лишнего связующего кода, необходимого для оптимизации и упрощения процесса разработки и запуска расширения на C#. Вместе с тем, эти проблемы легко решаются описанными в данной статье методами. Зато увеличенная точность отладки, безопасность типов и знание C-подобного языка обеспечивают действительно высокий уровень разработки! Также на C# можно сделать некоторые классные вещи, реализуемость которых на Python лично я ставлю под большое сомнение. Но об этом читайте в следующих статьях!

Источник: www.padtinc.com
Автор: Matt Sutton

ВОЗМОЖНО ЭТО ВАС ЗАИНТЕРЕСУЕТ:

Об учёте высших форм колебаний (missing mass effect) в расчёте спектрального отклика

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