Как автоматизировать сборку под разные версии AutoCAD

Автор Тема: Как автоматизировать сборку под разные версии AutoCAD  (Прочитано 12771 раз)

0 Пользователей и 2 Гостей просматривают эту тему.

Оффлайн trir

  • ADN Club
  • ****
  • Сообщений: 475
  • Карма: 63
ссылкой и вставлены

Оффлайн Александр Ривилис

  • Administrator
  • *****
  • Сообщений: 13882
  • Карма: 1787
  • Рыцарь ObjectARX
  • Skype: rivilis
а до этого как сделано как созданы проекты без папок?
Да как угодно. Можно создать пустой проект и добавить его в решение. Можно просто скопировать готовый проект, добавить его в решение и настроить. Ну и конечно не забыть добавить *.cs-файлы из общего каталога.
Но при создании проекта все равно же создается папка и как тут добавлены *.cs файлы во все проекты, вроде не как ссылкой вставлены?


Не забывайте про правильное Форматирование кода на форуме
Создание и добавление Autodesk Screencast видео в сообщение на форуме
Если Вы задали вопрос и на форуме появился правильный ответ, то не забудьте про кнопку Решение

Оффлайн Yusuf

  • ADN OPEN
  • ***
  • Сообщений: 117
  • Карма: 4
ссылкой и вставлены
у ссылок разве иконки такие?
Я до сих пор туплю кажется это все что то очевидное но не могу понять.
Пробовал пустой Solution1 создать, затем пустой проект Project1 создаю, создается папка Project с файлами и папками, переношу их  после этого вручную переношу их на одну папку вверх в папку Solution1.  Удалил в VS Project1, потом пробовал в папку Solution1 добавить существующий элемент и выбрать перенесеный вручную в папку Solution1 файл Project1.cspros то добавляется она она в папке Solution Items, а не так отдельно как в решении MgdDbg.
Пробовал добавить в решение MgdDbg добавить свой существующий проект как ссылки там иконки разные же?



Оффлайн avc

  • ADN Club
  • *****
  • Сообщений: 822
  • Карма: 166
    • Мои плагины к Автокаду
AutoCAD и .Net имеют прекрасную обратную совместимость. Все, что я компилирую для AutoCAD 2013 прекрасно работает во всех последующих версиях. Зачем разводить огород, там где он не нужен? API не измениняется (ну почти). А что изменилось - можно на крайний случай вызвать через reflection. Я не утверждаю что это лучшая практика. Конечно, тому кто "вкурил" msbilder не проблема собрать пачку проектов сразу. А на любительском уровне - вполне можно обойтись одной dll.
Есть обратная сторона медали: чем больше проектов в солюшене, тем больше тормозит VS и дольше вставлять новые файлы кода. С моими over 50 проектами ( всего по 2 на плагин) работать невозможно - минутный лаг после каждого клика. Приходится писать код в отдельном проекте, не открывая солюшн. А если б я еще добавил по 10 проектов для версий AutoCAD?...
А ссылки вы похоже вставлять не научились. Там у кнопки Добавить в форме выбора существующего файла, есть выпадающий список и в нем "Добавить как связь". А иначе копия файла в проект вставляется.

Оффлайн Yusuf

  • ADN OPEN
  • ***
  • Сообщений: 117
  • Карма: 4
А ссылки вы похоже вставлять не научились. Там у кнопки Добавить в форме выбора существующего файла, есть выпадающий список и в нем "Добавить как связь". А иначе копия файла в проект вставляется.
Я так и вставил обратите внимание на иконки

Оффлайн Дмитрий Загорулькин

  • ADN
  • *
  • Сообщений: 2531
  • Карма: 737
Все, что я компилирую для AutoCAD 2013 прекрасно работает во всех последующих версиях. Зачем разводить огород, там где он не нужен? API не измениняется (ну почти).
Я тоже так считал. Но потом столкнулся неоднократно с ситуациями, когда из-за старых ссылок ломалась работа приложения в новых версиях. Причём, в одном случае, почему-то только у некоторых пользователей. Я тогда кучу времени потратил на поиск причины. Мне пришлось посидеть плотно за ПК пользователя. Я устанавливал и переустанавливал фреймворки, полностью переустановил все продукты Autodesk, драйверы и т.п. Одна и та же ОС, одна и та же версия AutoCAD, одна и та же версия моего приложения, один и тот же чертёж. Даже ПК идентичны, т.к. из одной партии закупки! Но у одного пользователя всё ок, а у другого - не работает как надо! Причём, никаких ошибок - фаталов, исключений и тп. Просто тупо не работает! И только когда я пересобрал приложение с подходящими для версии AutoCAD Dll, всё починилось. У меня в приложении, конечно, много чего специфического используется - Overrule, P/Invoke, COM(dynamic) и т.п. Допускаю, что если бы было более простое приложение, то с такими проблемами я бы не столкнулся. Но, после этого, я стал пересобирать для каждой версии с её ссылочными DLL. Мне несложно настроить проекты, зато проблем подобного рода у пользователей уже точно не будет.

Оффлайн Дмитрий Загорулькин

  • ADN
  • *
  • Сообщений: 2531
  • Карма: 737
А так, вот, например, из последнего: https://adn-cis.org/forum/index.php?topic=9158.0

Оффлайн avc

  • ADN Club
  • *****
  • Сообщений: 822
  • Карма: 166
    • Мои плагины к Автокаду
вот, например, из последнего
Отличный пример, того, что изменения в API отлавливаются сразу и легко. В сообщении об ошибке четко написано какой именно метод изменился и как именно. И так же легко лечатся через reflection или все-таки добавлением одной сборки (но не десятков же).
Моя-то мысль о том, что надо трезво оценить свои затраты на поддержку пачки проектов вместо одного. Если делать один плагин (чтоб продать и забыть) - то вполне можно вместо одного проекта сделать 10. И совсем другое дело если проектов и так 66 и их надо будет развивать, обновлять, пересобирать, перепаковывать. Тут переход на 666 проектов внесет такие издержки, что уж лучше раз в 3 года поотлавливать один тяжелый глюк.
Ну и конечно я писал про .Net API, а не про P/Invoke, COM(dynamic), недокументированные вызовы и все такое прочее. Так-то и под каждую локализацию и под каждую Windows по хорошему надо собирать отдельный проект.

Оффлайн Дмитрий Загорулькин

  • ADN
  • *
  • Сообщений: 2531
  • Карма: 737
Отличный пример, того, что изменения в API отлавливаются сразу и легко.
Эта ошибка проявляется только во время выполнения в определённых версиях AutoCAD. Разве это "сразу и легко"?
Так-то и под каждую локализацию и под каждую Windows по хорошему надо собирать отдельный проект.
Если требуется адаптировать приложение на разные языки, то это делается с помощью локализации ресурсов. Не надо отдельный проект делать.
Под версии Windows тоже не требуется разные проекты делать, т.к. .NET приложения ориентируются не на версию Windows, а на версию .NET Framework.
Моя-то мысль о том, что надо трезво оценить свои затраты на поддержку пачки проектов вместо одного. Если делать один плагин (чтоб продать и забыть) - то вполне можно вместо одного проекта сделать 10. И совсем другое дело если проектов и так 66 и их надо будет развивать, обновлять, пересобирать, перепаковывать. Тут переход на 666 проектов внесет такие издержки, что уж лучше раз в 3 года поотлавливать один тяжелый глюк.
Так кто же спорит, делай как удобнее. Это же твои проекты ) Главное, делать это осознанно, понимая все возможные последствия.
« Последнее редактирование: 01-12-2020, 19:03:18 от Дмитрий Загорулькин »