Я бы хотел, чтобы скрипты, работающие в Jint, имели доступ к уже существующему API, который я настроил в качестве пространства имен. Под этим я подразумеваю, что у меня есть единственное пространство имен, которое содержит API, включая другие пространства имен. Я не хочу разрешать сценариям доступ к остальной части кода, включая .Net Framework.
Я уже разместил это на форуме Jint здесь: http://jint.codeplex.com/discussions/310772
Тем не менее, неуважение к ним, но форум, кажется, не очень активен, и я хотел бы иметь возможность ответить на это как можно скорее, поэтому я также публикую здесь.
Некоторое время назад ThomasMaierhofer достиг чего-то похожего на это, что я, вероятно, мог бы изменить, чтобы проработать это здесь: http://jint.codeplex.com/discussions/211291
На мой неопытный мозг это похоже на действительно аккуратный способ раскрыть API для движка, но я никогда раньше не видел, чтобы это делалось так.
Итак, мои вопросы: это сработает? И если так, то почему это не было сделано раньше? И есть ли способ, которым я мог бы достичь этого без изменения источника Jint, чтобы я мог легко обновлять Jint .dll по мере появления новых версий?
EDIT:
Текущий API у меня состоит из нескольких классов, каждый из которых имеет несколько функций. Я могу выставить конкретные экземпляры этих классов абсолютно нормально, используя SetParameter. Jint также имеет свойство AllowClr, которое позволяет сценарию получать доступ к CLR с помощью полностью определенных пространств имен. Это пример кода, который они дают, демонстрируя, что произойдет, если вы установите значение false.
Источник: http://jint.codeplex.com/wikipage?title=Using%20.NET%20classes%20from%20scripts
string stringBuilder = @"
var sb = new System.Text.StringBuilder();
return sb.ToString();
";
var engine = new JintEngine();
engine.AllowClr = false;
engine.Run(stringBuilder); // throws a SecurityException
Я хотел бы разрешить это, но только для определенного пространства имен, а не для всего остального. Надеюсь, это проясняет вопрос.
Спасибо за вашу помощь,
Сэм.
P.S. Я работаю в VB.Net, но ответы с участием C # в порядке.