почему могут не работать сборки
Microsoft.AnalysisServices / Microsoft.AnalysisServices.Core / Microsoft.AnalysisServices.Tabular (.dll)
от SQL Server 2019 (т.е. версии 15.1 и выше)
в SSIS с TargetServer = SQLServer2017 на ScriptTask компоненте (C# 2017) ?

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

Если пакет переключить в SQLServer2019 то отрабатывает отлично (C# 2019).

Пробовал разные сценарии - в т.ч. создание с нуля
(т.е. скриптовый компонент добавлялся после переключения TargetServer в 2017)

Может какие зависимые библиотеки подтянуть в References надо (или поставить другие из имеющихся)?

Просто Есть куча старых SSIS (2012~2016, да - 17го и 19го нет, но причины наверняка те-же что и при переходе на более старые)
в инфраструктуре а запрашивать новый SSIS - займёт пару месяцев (SSAS нужен именно 2019/AAS совместимый, т.е. 1500)
т.е. в итоге на VisualStudio2019 в SSIS2019 режиме как-бы работает отлично - а SSIS есть пока только более старые, следовательно выгрузить некуда.

Как решить? (в SSIS дебаг скриптового блока даже с Try/Catch C#-повскими муторно получается)

a_voronin,

деплоить на более старый сервер чисто логически нет смысла если в самой студии при запуске пакета идёт сбой
(т.е. если переключить на старую версию, хотя уже проверялось - на SQL/SSIS сервере где висит SSISDB тоже сбой).

в проблеме описано что трабл возникает именно при переключении TargetVersion на предыдущие.
(в настройках проекта Config/General/ опции Deployment Server Version поставить свойство TargetServerVersion на SQL Server 2017)

если поставить старые версии .dll под них в References - проблема (сбоя) исчезает,
но появляется слепота на обьектную модель (старые версии не видят обьекты в Tab 1500)
(речь даже навряд-ли о разных версиях остальных не SSAS системных библиотек на сервере и машине разработки)

интерес конечно приветствуется но
для понимания если честно нужен опыт хождения по этим граблям (хотя они и вроде как в некотором смысле новые),
просто сходу додумать вряд-ли получится, так что целевая аудитория скорее те кто с этим сталкивался и решал вопрос.

a_voronin,

Это табличная модель в режиме совместимости 1500, со всеми библиотеками 15.1.2x.. (. .. / .Core / .Tabular / .Tabular.JSON ..)
с планом переноса в Azure / AAS когда безопасность после тестов добро наконец даст.

Сам SSIS пакет переключается изначально под TargetServerVersion на 2017,
и уже потом в нём создаётся C# Script Task, добавляются References на эти библиотеки

т.е. всё работает если их фактически не использовать
в смысле прописывается и в References и в коде
using Microsoft.AnalysisServices...;
MessageBox.Show(..);
но ничего из SSAS по факту не вызывается..
пакет отрабатывает штатно,

но как только снимаю // комент на
Microsoft.AnalysisServices.Server SSAS_Srv=new Microsoft.AnalysisServices.Server(); (или что там по пути .. .Tabular / .Core ..)
вылет с ошибкой, и так с вызовом любой функциональности библиотеки (даже без подключения к серверу, просто декларация)
все остальные работают без проблем (System.Windows.Forms, System.Data и т.д.)

Если беру более старые ниже 15.1../15.0.. (13.../14...) в References - то работают (подключение к серверу, к базе, свойства), но естественно не видят все ветви модели
фактически может без проблем работать на старых SSAS.

Поэтому есть подозрения что какие-то Dependencies могут выбивать, типа нужны другие System... и пр.
даже сам Vsta.. переключал с .NET 4 на .NET 4.7/4.8..

По инфраструктуре у нас так:
SSIS/SQL - 2016 << для него ставлю TargetServerVersion
SSAS - 2019




Это конечно не полный затык, я могу конечно клиенту сказать :
вот Visual Studio, вот пакет, вот так работает, теперь давайте под него SSIS/SQL сервер 2019..
(всё равно системы по плану стоят в очереди на обновление, заодно сэкономят потом время на миграции)
просто думал где-то на ровном месте спотыкаюсь..

a_voronin,

там сложная логика на основе SQL таблицы с настройками на вход смешанно с SSAS_DMV и SQL таблицей для логов (более детально к родным SSIS) на выход, от создания партиций, до удаления старых, определения какие надо обновлять и какие нет, есть пути полного или частичного удаления данных/партиций, полного пересоздания, обновления дефиниций запросов по template партициям, разные режимы process с failover на более мелкие пакеты батчей и куча прочей параметризированной ерунды под разные планы обслуживания (инкрементальный/ полный, сохранение/восстановление резервных копий и пр.)
в гипотетическом архитектурном плане ферма с серверами на process/query под синхронизацию с load-balancer/fail-over но пока непонятны требования по нагрузке..
собственное создание XMLA/TMSL как-бы ad-hoc костыль а не best practices, обычно ведь рекомендуется полноценный API (который делает в принципе тоже самое), т.е. те самые dll, я с ними последние несколько лет только и работаю (xmla разве что изредка в ручную из ssms с каким-нибудь kill/clear)

это всё к тому что сложно переделывать в xmla/tmsl просто ради того чтобы чтобы работало на старых версиях не очень разумно.

короче не стал сильно париться - заказал в срочном порядке бокс на 2019, были
мелкие проблемы т.к. разработка ведётся на Win7 (да всё ещё бывают и такие)
где не стояли нужные dll (т.е. они как-бы есть - но чисто для Visual Studio в своей директории,
а те что глобально были - очень старые) отловил эту ошибку в ScriptTask через C# try/catch
скопировал dll с сервера для совпадения версий из GAC_MSIL, установил SSAS dll
на свой Win7 в GAC_MSIL через gacutil.exe (все: ./.Core/.XMLA/.Tabular/.Json)
переключил references VS проекта на них, и пошло всё как нужно..
так что вопрос закрыт.