Сообщество программистов Autodesk в СНГ

ADN Club => AutoCAD .NET API => Тема начата: Дмитрий Загорулькин от 11-10-2017, 03:19:25

Название: Перечисление LispDataType в версиях до 2014 и после 2015
Отправлено: Дмитрий Загорулькин от 11-10-2017, 03:19:25
Словил сегодня такое исключение при отладке одного из проектов:
Цитировать
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)
Я так понимаю, что при компиляции в этом случае перечисление будет заменено на числовой эквивалент и данные о типе этого перечисления не будут сохраняться в сборке.
Что самое печальное, я не смог найти нигде в официальной (да и неофициальной) документации хотя бы одно упоминание о такой "миграции" типа. Есть вероятность, что не только с этим перечислением так произошло...
Название: Re: Перечисление LispDataType в версиях до 2014 и после 2015
Отправлено: Александр Ривилис от 11-10-2017, 12:42:56
Что самое печальное, я не смог найти нигде в официальной (да и неофициальной) документации хотя бы одно упоминание о такой "миграции" типа. Есть вероятность, что не только с этим перечислением так произошло...
Насколько я помню вообще нет упоминания где он находится. Остаётся придерживаться правила одна сборка - одна версия AutoCAD, чтобы не попасть в такую западню.
Название: Re: Перечисление LispDataType в версиях до 2014 и после 2015
Отправлено: Дмитрий Загорулькин от 11-10-2017, 13:36:46
Насколько я помню вообще нет упоминания где он находится.
Так-то да. Но просто была надежда на то, что разработчики .NET API документируют изменения, которые могут оказывать влияние на функционирование сборок. Оказалось, что нет. Остаётся только самим находить эти изменения и делиться ими.
Остаётся придерживаться правила одна сборка - одна версия AutoCAD
Это довольно накладно. Но, конечно же, это самый безопасный вариант.
Название: Re: Перечисление LispDataType в версиях до 2014 и после 2015
Отправлено: Александр Пекшев aka Modis от 11-10-2017, 15:31:07
Это довольно накладно. Но, конечно же, это самый безопасный вариант
Не так уж и накладно, учитывая, что VS позволяет использовать один cs-файл в множестве проектов. Лично у меня под каждую версию автокада (2010-2018) отдельный проект, но сам код находится только в первом (базовом) проекте (обычно это проект под 2010 автокад). А символы условной компиляции позволяют разрешить некоторые проблемы в использовании различных автокадовских API
Название: Re: Перечисление LispDataType в версиях до 2014 и после 2015
Отправлено: Дмитрий Загорулькин от 11-10-2017, 16:00:41
Понятно, что можно ссылаться всеми сборками на одни и те же файлы (кстати, не только *.cs). И символы условной компиляции тоже помогают. Но при добавлении/удалении какого то файла или папки нужно не забыть пройтись по всем этим проектам и добавить/удалить ссылку на файл. И второй момент - на выходе мы получаем "пачку" DLL вместо одной-единственной сборки. Это не проблема, но это неудобно: требует больше внимания и отнимает больше времени.