Комментарии 5
Добавление новых таблиц в БД орагинзации МС позиционирует как ансаппортную правку. И при апдейте системы оставляет за собой право менять произвольным образом структуру таблиц. Так что при таком решении вы:
1. Лишаетесь возможности заводить тикеты в саппорт вендора при нештатном поведении платформы;
2. Рискуете при апдейте потерять все свои кастомные сборки.
И не совсем понял плюс по поводу переезда. При мердже сторонняя ддл живет внутри вашей. А ваша — в БД организации. Т.е. все всегда переезжает вместе с организацией.
1. Лишаетесь возможности заводить тикеты в саппорт вендора при нештатном поведении платформы;
2. Рискуете при апдейте потерять все свои кастомные сборки.
И не совсем понял плюс по поводу переезда. При мердже сторонняя ддл живет внутри вашей. А ваша — в БД организации. Т.е. все всегда переезжает вместе с организацией.
1. Обновляли CRM с по версиям: 4, 2011, 2013, 2015, 2016. В базе помимо этой существуют другие кастомные таблицы и абсолютно не мешают CRM. CRM по сути делает при апдейтах только в таблицах созданных из под CRM. Описание этих таблиц CRM хранит у себя в метаданных, на все сторонние ему всё равно, он о их существовании не знает.
2. При апдейте как описано в ответе 1 кастомные таблицы игнорируются.
По поводу переезда, элементарно если вы хотите использовать Dapper или NewtonsoftJson, вы их можете использовать в разных плагинах, и в каждом вам придётся мержить сборку плагина с той которую вы хотите юзать. На моём примере я использовал бесплатную пакет FreeSpire для конвертации документов. Этот пакет необходим весь, и если его мержить то плагин выходит размером 135 мб из которых моего плагина только 80 кб, остальное офис freespire, и если это плагин повесть не в песочнице а в none. Ваш sql мягко говоря не скажет вам спасибо, такой плагин грузить в потоки. Я понимаю что CLR оптимизирует и грузит только то на что есть референсы в зборках, но в любом случае такой плагин грузить постоянно в каждый поток это издевательство над сервером.
2. При апдейте как описано в ответе 1 кастомные таблицы игнорируются.
По поводу переезда, элементарно если вы хотите использовать Dapper или NewtonsoftJson, вы их можете использовать в разных плагинах, и в каждом вам придётся мержить сборку плагина с той которую вы хотите юзать. На моём примере я использовал бесплатную пакет FreeSpire для конвертации документов. Этот пакет необходим весь, и если его мержить то плагин выходит размером 135 мб из которых моего плагина только 80 кб, остальное офис freespire, и если это плагин повесть не в песочнице а в none. Ваш sql мягко говоря не скажет вам спасибо, такой плагин грузить в потоки. Я понимаю что CLR оптимизирует и грузит только то на что есть референсы в зборках, но в любом случае такой плагин грузить постоянно в каждый поток это издевательство над сервером.
Механизм апдейтов — черный ящик. Вендор может делать все, что хочет. То, что вы провели ансаппортные правки и это не вызывало явных проблем — это хорошо. Но пользоваться этим систематически крайне нежелательно.
Если речь о какой-то инхаус разработке под собственные нужды, это полбеды. Может аукнуться разве что при привлечении для крупной задачи подрядчика, который проаудирует имеющуюся систему и все возможные риски выставит в стоимость работ.
А вот если это энтерпрайзная разработка для заказчика, то тут уже могут провести аудит и выставить хорошую претензию.
Еще, кстати, попробуйте ради интереса импортнуть такую организацию в облако. Посмотрите, как там с игнорирование лишних таблиц с бинарниками.
Вы что, под каждый плагин отдельную библиотеку собираете? А почему не хотите просто одну сборку плагинов сделать, один раз добавив нужные зависимости? В крайнем случае, если вам зачем-то нужны не сендбоксовые плагины, то две.
Ох. 135 метров я бы не стал пиахть ни внутрь сборки, ни в кастомную таблицу. Или искать что-то более легкое, или делать внешний компонент, к которому обращаться из системы.
А как вы, кстати, обеспечиваете обновление сборок при выходе новых версий пакетов?
Если речь о какой-то инхаус разработке под собственные нужды, это полбеды. Может аукнуться разве что при привлечении для крупной задачи подрядчика, который проаудирует имеющуюся систему и все возможные риски выставит в стоимость работ.
А вот если это энтерпрайзная разработка для заказчика, то тут уже могут провести аудит и выставить хорошую претензию.
Еще, кстати, попробуйте ради интереса импортнуть такую организацию в облако. Посмотрите, как там с игнорирование лишних таблиц с бинарниками.
По поводу переезда, элементарно если вы хотите использовать Dapper или NewtonsoftJson, вы их можете использовать в разных плагинах, и в каждом вам придётся мержить сборку плагина с той которую вы хотите юзать.
Вы что, под каждый плагин отдельную библиотеку собираете? А почему не хотите просто одну сборку плагинов сделать, один раз добавив нужные зависимости? В крайнем случае, если вам зачем-то нужны не сендбоксовые плагины, то две.
На моём примере я использовал бесплатную пакет FreeSpire для конвертации документов. Этот пакет необходим весь, и если его мержить то плагин выходит размером 135 мб из которых моего плагина только 80 кб, остальное офис freespire, и если это плагин повесть не в песочнице а в none.
Ох. 135 метров я бы не стал пиахть ни внутрь сборки, ни в кастомную таблицу. Или искать что-то более легкое, или делать внешний компонент, к которому обращаться из системы.
А как вы, кстати, обеспечиваете обновление сборок при выходе новых версий пакетов?
Механизм апдейтов — черный ящик. Вендор может делать все, что хочет. То, что вы провели ансаппортные правки и это не вызывало.....
Работаю напрямую на вендора, система автоматически не обновляется, обновления происходят только через тест сервер.
Если речь о какой-то инхаус разработке под собственные нужды, это полбеды.Так и есть.
Вы что, под каждый плагин отдельную библиотеку собираете? А почему не хотите просто одну сборку плагинов сделать, один раз добавив нужные зависимости?Нет конечно не для каждого пчиха, скажем так плагины разбиты по проектам.
Вы что, под каждый плагин отдельную библиотеку собираете? А почему не хотите просто одну сборку плагинов сделать, один раз добавив нужные зависимости? В крайнем случае, если вам зачем-то нужны не сендбоксовые плагины, то две.Всё в одной сборке не удобно, честно нигде даже не видел на практике что бы так делали, но тут спорить нет смысла, тут как кому удобно, мне ребята говорили что видели как сертифицированные MS девы вообще под каждое действие Action бизнес процесс делали, вместо того что бы сделать один Action для проекта и в него имя метода просто параметром передавать + json.
Ох. 135 метров я бы не стал пиахть ни внутрь сборки, ни в кастомную таблицу. Или искать что-то более легкое, или делать внешний компонент, к которому обращаться из системы.
Увы, для работы в word, pdf, excel нормальных сборок мало, выбор тут не велик, есть конечно ещё Microsoft.Iterop.Office но она может конвертить файлы только с файловой системы а мне важно было именно работа с MemoryStream.
А как вы, кстати, обеспечиваете обновление сборок при выходе новых версий пакетов?над версионностью надо ещё подумать я об этом в посте писал.
В крайнем случае, если вам зачем-то нужны не сендбоксовые плагины
Из sandbox нет прямого доступа к базе, в моём случае это необходимо. Повторюсь у меня не online версия и перехода на online не будет. Плюс sandbox однопоточный насколько я знаю.
А так конечно это ансапорт, если бы МС нормально сами это реализовали не приходилось бы это делать, веб ресурсы же они сделали? Могли бы и dll сборки в виде веб ресурса сделать. Только для back.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как использовать сторонние сборки в Plug-In