Я интегрировал (lua) скриптинг в приложения, и я также использовал сам c # как «язык скриптов» ", компилируя динамические сборки на лету из кода, предоставленного пользователем. Я также реализовал «подключаемые» системы с использованием предоставленных пользователем сборок, которые соответствуют определенным интерфейсам или базовым классам.

Есть много вещей, которые необходимо учитывать, от безопасности до производительности и путаницы конечного пользователя. Я не думаю, что вы могли бы сделать общее утверждение типа «языки сценариев не принадлежат приложениям» или даже «языки сценариев принадлежат приложениям». Любой конкретный случай требует тщательного рассмотрения всех вариантов и их последствий, прежде чем убегать и делать что-то, о чем вы, возможно, пожалеете позже.

В зависимости от того, чего вы пытаетесь достичь, вам может понравиться то, что может предложить PowerShell , Вы можете сделать свое приложение настраиваемым хостом сценариев PowerShell или просто предоставить командлеты, управляющие приложением.

В любом случае ваши пользователи получат выгоду от богатого, мощного и разумного языка сценариев со встроенным .NET / COM / WMI. поддержка, но они не должны быть разработчиками, чтобы использовать его.

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

Exchange Server 2007 реализует пользовательский хост сценариев, если вы хотите увидеть пример того, как это работает .

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

Мне нравится возможность писать сценарии для расширения функциональности приложения. Еще лучше, когда язык сценариев хорошо известен.

Я бы не стал ограничивать функциональность, которую может выполнять скрипт, исходя из соображений производительности. Вы не знаете, как что-то будет вести себя на будущем оборудовании, например; однако, вы должны ограничить то, что он может сделать для безопасности / функциональности.

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

Редактировать

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

Принудительное выполнение расширений с помощью скомпилированного кода позволяет использовать механизмы для предотвращения атак. Например, вы можете проверить сборку (при условии .net здесь). легко искать вредоносный код (да, вы можете сделать это и с помощью сценариев), или вы можете запретить доступ к определенным ресурсам, например Code Access Security. Вы также можете использовать подписывание кода и загружать плагины только от доверенных издателей.

Например, вы можете проверить сборку (при условии .net здесь). легко искать вредоносный код (да, вы можете сделать это и с помощью сценариев), или вы можете запретить доступ к определенным ресурсам, например Code Access Security. Вы также можете использовать подписывание кода и загружать плагины только от доверенных издателей.

Например, вы можете проверить сборку (при условии .net здесь). легко искать вредоносный код (да, вы можете сделать это и с помощью сценариев), или вы можете запретить доступ к определенным ресурсам, например Code Access Security. Вы также можете использовать подписывание кода и загружать плагины только от доверенных издателей.