Добрый день, коллеги!

Есть модуль с кодом, который содержит всякие кастомные штуки специфичные для клиента.
Изначально мы редактировали код в нём сами, и этот модуль был просто частью проекта. В коде этого модуля естественно используются все публичные классы/сервисы/функции основного проекта.


Иногда некоторые клиенты желают самостоятельно редактировать свои специфичные процедуры в своем модуле.

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

Здравствуйте, MadHuman, Вы писали:

MH>Хочется чтоб при редактировании у них была поддержка среды (интиллисенс, проверка компилятором), но для этого необходимы все наши библиотеки.
MH>Это сложно и не вариант, мы думаем чтоб по тем классам что можно использовать в этом кастомном модуле сгенерить проект с их врапперами пустышками (чисто для интелисенса и этапа проверки ошибок компиляции) и эту сборку и давать клиенту.
По-моему это называется https://en.wikipedia.org/wiki/Application_programming_interface и в случае c# есть даже слово языка "interface".

Здравствуйте, MadHuman, Вы писали:

MH>Это сложно и не вариант, мы думаем чтоб по тем классам что можно использовать в этом кастомном модуле сгенерить проект с их врапперами пустышками (чисто для интелисенса и этапа проверки ошибок компиляции) и эту сборку и давать клиенту.
MH>Может есть какие-то тулсы облегчающие подобную задачу?...
Возможно, вам подойдут референсные сборки — это сборки, которые получаются из тех же исходников, но в них компилятор оставляет только метаданные:
— описания классов, полей, интерфейсов ...
— константы, перечисления, ...

Кода там нет, вместо методов торчат заглушки, которые выглядят так:

public static void Main(string[] args)
{
    throw null;
}

Ну плюс еще для самой сборки установлен атрибут

[assembly: ReferenceAssembly]

Microsoft ими активно пользуется. Собственно C:\Program Files\Reference Assemblies — это они

Чтобы получить такую сборку достаточно в проекты ваших библиотек добавить property

<PropertyGroup>
    <!-- Some properties  -->
    <ProduceReferenceAssembly>true</ProduceReferenceAssembly>
    <!-- Some properties  -->
</PropertyGroup>

Будет компилироваться обычная сборки и Reference

Здравствуйте, MadHuman, Вы писали:

MH>Изначально мы редактировали код в нём сами, и этот модуль был просто частью проекта.
MH>Иногда некоторые клиенты желают самостоятельно редактировать свои специфичные процедуры в своем модуле.

А поконкретнее нельзя? Пример процедуры и описание как именно организованны модули?

По функционалу похоже на обычные plugins. Ваша идея, дать им доступ к другим вашим либам — не очень хорошая. По хорошему нужно посидеть и подумать, что именно разрешить и только разрешенное явно описать и предоставить в виде интерфесов для плагина. Не говоря уже о том, что каждый плагин желательно запускать в своей песочнице (assembly), с некоей базовой защитой от зависаний (возможность прервать выполнение).

В этом случае как вы понимаете речь идет об обычной dll, в которой нет ничего кроме описания интерфейсов, которая подключена в ваше приложение и используется клиентами для написания своего кода. Ну и несколько template для клиентов можно сделать, решающих типичные задачи.

В одном проекте, вместо плагина (т.к. процедура была слишком простая, по сути формула в одну строку, но иногда несколько строк или даже циклы) вообще обошлись CodeDOM. Тоесть сделали интерфейс, где пользователь вводил свой код на C#, сдеали несколько заготовок формул и примитивную подветку синтаксиса (по ключевым словам). Intellisence не было, но сделали возможность вставлять имена переменных (используемых в формулах) в виде dropdown menu, c подробным описанием каждой в тултипе. Этот код хранился в бд в виде строки и представлял по сути тело метода. Входные параметры — поля класса и параметры методов, больше этот код ни к чему доступа не имел. Когда было необходимо, код комплился в run-time (помещался внутрь строки, описывавшей class, namespace, метод, все необходимые using и т.д.) и сохранялся в делегате. Валидация метода (когда клиент редактировал код) — это попытка скомпилировать и подсветка ошибок (CodeDOM предоставляет информацию о том, где и какая именно ошибка). Вроде бы никто не жаловался на такую реализацию. А да, в help еще добавили несколько примеров и по сути клиентам даже не нужно было знать C#, просто копировать подходящий случай, менять знаки, операции и т.д.

Здравствуйте, Sinatr, Вы писали:


S>По функционалу похоже на обычные plugins. Ваша идея, дать им доступ к другим вашим либам — не очень хорошая. По хорошему нужно посидеть и подумать, что именно разрешить и только разрешенное явно описать и предоставить в виде интерфесов для плагина.
Можно на это смотреть и как на плагины. и даже это наверно и плагины в какой-то степени. То что предназначено для "публичного" использования (классы и методы) уже соотвествующим образом и помечено.
то есть классы/методы объявленные как public — это уже и есть "подумали и разрешили к внешнему использованию".
Да, можно выделить интерфейсы, но это лишнее усложнение. таких классов много, придётся для каждого делать по сути повторяющий его интерфейс. и затем везде трудности — вместо чтоб попасть в реализацию метода и смотреть детали — попадаем в его декларацию в интерфейсе.
Всё таки интерфейс в 1-ю очередь для выделения общего интерфейса (простите за тавтологию) для разных реализаций, когда затем действительно надо единообразно работать с чем-то вне зависимости от того что там под капотом у этого "чем-то".
Выделение интерфейса в нашем случае — несколько не соотвествует его основной задумке и просто как способ решить задачу.

И главное — чем плох тот который мы рассматриваем (если условно посчитать что техническая задача с генерацией "библиотеки типов" решена)?


S>Не говоря уже о том, что каждый плагин желательно запускать в своей песочнице (assembly), с некоей базовой защитой от зависаний (возможность прервать выполнение).
Верно, но это уже следующий уровень. для него потребуется организовывать песочницу (это затраты времени/денег), если с защитой то скорее всего в другом домене/процессе (а это падение перфоманса, что для нас критично и очень нежелательно).
Пока клиентов которым это хочется не так много, и вариант с созданием "библиотеки типов" видится оптимальным решением (с учетом всех затрат).


S>В этом случае как вы понимаете речь идет об обычной dll, в которой нет ничего кроме описания интерфейсов, которая подключена в ваше приложение и используется клиентами для написания своего кода. Ну и несколько template для клиентов можно сделать, решающих типичные задачи.
да, конечно. но сгнерированная "библиотека типов" это по сути и есть эта "обычная dll".
по сути всё тоже, но не нужно зашумлять код интерефейсами которые не совсем по своему прямому назначению используются.


S>В одном проекте, вместо плагина (т.к. процедура была слишком простая, по сути формула в одну строку, но иногда несколько строк или даже циклы) вообще обошлись CodeDOM. Тоесть сделали интерфейс, где пользователь вводил свой код на C#, сдеали несколько заготовок формул и примитивную подветку синтаксиса (по ключевым словам). Intellisence не было, но сделали возможность вставлять имена переменных (используемых в формулах) в виде dropdown menu, c подробным описанием каждой в тултипе. Этот код хранился в бд в виде строки и представлял по сути тело метода. Входные параметры — поля класса и параметры методов, больше этот код ни к чему доступа не имел. Когда было необходимо, код комплился в run-time (помещался внутрь строки, описывавшей class, namespace, метод, все необходимые using и т.д.) и сохранялся в делегате. Валидация метода (когда клиент редактировал код) — это попытка скомпилировать и подсветка ошибок (CodeDOM предоставляет информацию о том, где и какая именно ошибка). Вроде бы никто не жаловался на такую реализацию. А да, в help еще добавили несколько примеров и по сути клиентам даже не нужно было знать C#, просто копировать подходящий случай, менять знаки, операции и т.д.
вот как раз чтоб с таким не заморчиваться хотим сделать "библиотеку типов" и чтоб клиент в студии нормально писал код (с интелисенсом и проверками компилятором).
кастомная логика которую надо реализовывать клиенту, может быть довольно сложна и в нашем случае однострочной формулой не обойтись.