Перечисление LispDataType в версиях до 2014 и после 2015

Автор Тема: Перечисление LispDataType в версиях до 2014 и после 2015  (Прочитано 5673 раз)

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

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

  • ADN
  • *
  • Сообщений: 2531
  • Карма: 737
Словил сегодня такое исключение при отладке одного из проектов:
Цитировать
An exception of type 'System.TypeLoadException' occurred in <my_dll_name>.dll but was not handled in user code
Additional information: Не удалось загрузить тип "Autodesk.AutoCAD.Runtime.LispDataType" из сборки "accoremgd, Version=20.1.0.0, Culture=neutral, PublicKeyToken=null". occurred
Если вдруг встретите такое, то:
1. В проекте используются ссылки на библиотеки AutoCAD до 2014 версии включительно.
2. Запускать пытаетесь в AutoCAD версии 2015 и выше.
3. Где-то в сборке явно используется этот тип (Autodesk.AutoCAD.Runtime.LispDataType). Например - в типе параметра метода:
Код - C# [Выбрать]
  1. public static bool TestForCode(TypedValue tVal, LispDataType code, out object value)
  2. {
  3.     value = tVal.Value;
  4.     return tVal.TypeCode == (short)code;
  5. }
  6.  
Проблема в том, что до 2015 версии LispDataType был описан в AcCoreMgd.dll, а начиная с 2015 версии - в AcDbMgd.dll.
Варианты решений:
1. Пересобрать с использованием библиотек AutoCAD 2015+.
2. Переписать методы и их вызовы таким образом, чтобы тип перечисления явно не указывался, например:
Код - C# [Выбрать]
  1. public static bool TestForCode(TypedValue tVal, short code, out object value)
  2. {
  3.     value = tVal.Value;
  4.     return tVal.TypeCode == code;
  5. }
  6.  
А вызвать таким образом:
Код - C# [Выбрать]
  1. TestForCode(argsArray[0], (short)LispDataType.Text, out object nameTmplObj)
Я так понимаю, что при компиляции в этом случае перечисление будет заменено на числовой эквивалент и данные о типе этого перечисления не будут сохраняться в сборке.
Что самое печальное, я не смог найти нигде в официальной (да и неофициальной) документации хотя бы одно упоминание о такой "миграции" типа. Есть вероятность, что не только с этим перечислением так произошло...

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

  • Administrator
  • *****
  • Сообщений: 13882
  • Карма: 1787
  • Рыцарь ObjectARX
  • Skype: rivilis
Что самое печальное, я не смог найти нигде в официальной (да и неофициальной) документации хотя бы одно упоминание о такой "миграции" типа. Есть вероятность, что не только с этим перечислением так произошло...
Насколько я помню вообще нет упоминания где он находится. Остаётся придерживаться правила одна сборка - одна версия AutoCAD, чтобы не попасть в такую западню.
Не забывайте про правильное Форматирование кода на форуме
Создание и добавление Autodesk Screencast видео в сообщение на форуме
Если Вы задали вопрос и на форуме появился правильный ответ, то не забудьте про кнопку Решение

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

  • ADN
  • *
  • Сообщений: 2531
  • Карма: 737
Насколько я помню вообще нет упоминания где он находится.
Так-то да. Но просто была надежда на то, что разработчики .NET API документируют изменения, которые могут оказывать влияние на функционирование сборок. Оказалось, что нет. Остаётся только самим находить эти изменения и делиться ими.
Остаётся придерживаться правила одна сборка - одна версия AutoCAD
Это довольно накладно. Но, конечно же, это самый безопасный вариант.

Оффлайн Александр Пекшев aka Modis

  • ADN Club
  • *****
  • Сообщений: 1658
  • Карма: 366
  • Отец modplus.org
    • ModPlus
Это довольно накладно. Но, конечно же, это самый безопасный вариант
Не так уж и накладно, учитывая, что VS позволяет использовать один cs-файл в множестве проектов. Лично у меня под каждую версию автокада (2010-2018) отдельный проект, но сам код находится только в первом (базовом) проекте (обычно это проект под 2010 автокад). А символы условной компиляции позволяют разрешить некоторые проблемы в использовании различных автокадовских API

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

  • ADN
  • *
  • Сообщений: 2531
  • Карма: 737
Понятно, что можно ссылаться всеми сборками на одни и те же файлы (кстати, не только *.cs). И символы условной компиляции тоже помогают. Но при добавлении/удалении какого то файла или папки нужно не забыть пройтись по всем этим проектам и добавить/удалить ссылку на файл. И второй момент - на выходе мы получаем "пачку" DLL вместо одной-единственной сборки. Это не проблема, но это неудобно: требует больше внимания и отнимает больше времени.