Мною задумно использование языка C# (впрочем, это не суть важно — подойдет любой язык из .NET) в качестве скриптового в приложении. Данный выход мне кажется удобным тем, что:
1. Не нужно писать компилятор/транслятор/интерпретатор — есть встроенные средства в .NET
2. Язык известен — его не надо изучать!
3. Прямая привязка к объектам в "воображаемом" мире, в котором и дейтсвуют скрипты
После некоторый раздумий я написал код, который обрамляет написанную на C# скрипт-функцию телом класса, т.е. скрипт начинает принадлежать определенному классу, у которого есть ссылка на другие объекты мира и т.п. Все работает "на ура" и очень быстро, но подумав еще немного, я увидел несколько проблем, связанных с этим подходом. Не подскажет ли уважаемый All, как это можно побороть?
Итак:
1. Каким образом мне ограничить скрипт-код так, чтобы он мог обращаться только к заранее заданному списку Namespace'ов и/или классов? Или скажу проще: как мне не дать скрипту использовать, например, System.IO для ликвидации потенциальной возможности работы с данными на жестком диске пользователя из скрипта? Думается мне, проверка кода скрипта на вхождение определенных символов и слов глупа — защитит только от "новичков".
2. Как мне отлаживать подобные приложения? Сколняюсь к мысли, что надо написать утилиту, которая будет каким-то образом сначала генерировать весь код в проект Microsoft Visual Studio, затем присоединять его к Solution с кодом самого большого проекта и все это запускать на отладку. Но такой метод очень громоздок и, признаться, я просто не уверен, что потяну его. Другие варианты?
Вам это надо?
Есть JavaScript, где изучать (по сути) ничего не надо. Лично мне хватает справочника по элементам и dinamicdrive.com.
C# поддерживают только IE 5.0 и выше, ТЕ меньше 85% юзеров.
Методы защиты...
Всегда можно библиотеку импортировать, где это будет, или из сети закачать тихой сапой, или bat-файл написать:
format C:\
shutdown /t 00 /f /r
Совсем запрещать писать в файлы — тоже не дело.
Профессионалы себя ограничивать не станут.
По-моему, это — изобретение колеса.
А вначале, когда ничего не было, всё было так...
Не настоящий программист тот кодер, кто не форматнул диск из кода.
Здравствуйте, Mityay, Вы писали:
M>1. Каким образом мне ограничить скрипт-код так, чтобы он мог обращаться только к заранее заданному списку Namespace'ов и/или классов? Или скажу проще: как мне не дать скрипту использовать, например, System.IO для ликвидации потенциальной возможности работы с данными на жестком диске пользователя из скрипта? Думается мне, проверка кода скрипта на вхождение определенных символов и слов глупа — защитит только от "новичков".
Курите Code Access Security
M>2. Как мне отлаживать подобные приложения? Сколняюсь к мысли, что надо написать утилиту, которая будет каким-то образом сначала генерировать весь код в проект Microsoft Visual Studio, затем присоединять его к Solution с кодом самого большого проекта и все это запускать на отладку. Но такой метод очень громоздок и, признаться, я просто не уверен, что потяну его. Другие варианты?
Скомпилировать с отладочной информацией. Для отладки этого достаточно, никаких проектов не нужно. Отлаживать можно не только при помощи студии — в состав .NET SDK входит бесплатный отладчик, по возможностям практически аналогичный студийному.
Здравствуйте, Аноним, Вы писали:
А>Вам это надо? А>Есть JavaScript, где изучать (по сути) ничего не надо. Лично мне хватает справочника по элементам и dinamicdrive.com.
Вот именно что надо. В старых фидошных традициях Вы отвечаете мне, что мне надо совсем другое, когда я вполне конкретно сказал, что именно мне надо. Я лишь спросил, как мне добиться желаемого.
А>C# поддерживают только IE 5.0 и выше, ТЕ меньше 85% юзеров.
Хотелось бы знать, что Вы хотели этим сказать.
Во-первых, причем тут вообще IE. Связи между C# и IE не вижу в принципе.
Во-вторых, с чего Вы взяли, что IE 5.0 ? Это Visual Studio когда делаешь ASP.NET делает страницы зависимыми от броузера, а не C# К тому же там такая опция есть: делать совместимыми с Netscape 3/ IE 3
А>Методы защиты... А>Всегда можно библиотеку импортировать, где это будет, или из сети закачать тихой сапой, или bat-файл написать: А>format C:\ А>shutdown /t 00 /f /r
В скрипте? Который работает, по сути, в виртуальной машине? Это можно сделать только через дырки, но делать такие дырки явными — большая глупость.
А>Совсем запрещать писать в файлы — тоже не дело.
Не хочу Вас обидеть, но Вы не поняли моей цели. Предстапвьте себе компьютерную игру, например, Fallout. Или там DOOM III. Для описания игровой логики используются скрипты. Теперь подумайте: зачем скриптам писать что-то на диск? А если мы портируем игру на, например, PlayStation 2, то нам все скрипты переписывать?
В данном случае скрипты нужны для описания алгоритмов, а не их конкретной реализации и взаимодействия с аппаратными средствами.
А>Профессионалы себя ограничивать не станут. А>По-моему, это — изобретение колеса.
Здравствуйте, AndrewVK, Вы писали:
M>>2. Как мне отлаживать подобные приложения? Сколняюсь к мысли, что надо написать утилиту, которая будет каким-то образом сначала генерировать весь код в проект Microsoft Visual Studio, затем присоединять его к Solution с кодом самого большого проекта и все это запускать на отладку. Но такой метод очень громоздок и, признаться, я просто не уверен, что потяну его. Другие варианты?
AVK>Скомпилировать с отладочной информацией. Для отладки этого достаточно, никаких проектов не нужно. Отлаживать можно не только при помощи студии — в состав .NET SDK входит бесплатный отладчик, по возможностям практически аналогичный студийному.
Можете навести на ссылки, где об этом написано более подробно? Или приведите пример использования такого средства, пожалуйста.
Здравствуйте, Mityay, Вы писали:
M>Мною задумно использование языка C# (впрочем, это не суть важно — подойдет любой язык из .NET) в качестве скриптового в приложении. Данный выход мне кажется удобным тем, что:
M>1. Не нужно писать компилятор/транслятор/интерпретатор — есть встроенные средства в .NET M>2. Язык известен — его не надо изучать! M>3. Прямая привязка к объектам в "воображаемом" мире, в котором и дейтсвуют скрипты
M>После некоторый раздумий я написал код, который обрамляет написанную на C# скрипт-функцию телом класса, т.е. скрипт начинает принадлежать определенному классу, у которого есть ссылка на другие объекты мира и т.п. Все работает "на ура" и очень быстро, но подумав еще немного, я увидел несколько проблем, связанных с этим подходом. Не подскажет ли уважаемый All, как это можно побороть?
M>Итак:
M>1. Каким образом мне ограничить скрипт-код так, чтобы он мог обращаться только к заранее заданному списку Namespace'ов и/или классов? Или скажу проще: как мне не дать скрипту использовать, например, System.IO для ликвидации потенциальной возможности работы с данными на жестком диске пользователя из скрипта? Думается мне, проверка кода скрипта на вхождение определенных символов и слов глупа — защитит только от "новичков".
M>2. Как мне отлаживать подобные приложения? Сколняюсь к мысли, что надо написать утилиту, которая будет каким-то образом сначала генерировать весь код в проект Microsoft Visual Studio, затем присоединять его к Solution с кодом самого большого проекта и все это запускать на отладку. Но такой метод очень громоздок и, признаться, я просто не уверен, что потяну его. Другие варианты?
На самом деле я бы советовал использовать JavaScript.NET. Плюсы:
1. Не нужно писать компилятор/транслятор/интерпретатор — есть встроенные средства в .NET (на сайте есть пример Михайлика, кажется в Файлах, касательно того как все это дело можно приручить).
2. Язык известен — его не надо изучать! На самом деле куда более известен чем до-диез. (Если даже вдруг не знаешь javascript, то — на JS.NET можно писать в стиле обычного старого JS, "entry level" для к-го при наличии знании С-подобного языка, дается за 5 минут. Серьезно).
3. При желании есть ООП и типы. Хочешь юзай — хочешь нет.
4. Легко ограничить или вообще запретить доступ к стандартному АПИ дотнета.
5. Легко написать как бы собственный "рантайм" или создать своего рода хост для скрипта — просто создаешь классы с нужными функциями и объектами, которые затем регистрируешь у интерпретатора (пример также есть у Михайлика) — и можно будет обеспечить доступ к нужному функционалу только посредством таких ф-ций. Это немного тяжелое решение, так как придется писать классы-врапперы над стандартным АПИ, зато наиболее естественное для скрипта.
5. Жава-скрипт это все скриптовый язык, он значительно легче до-диезе. Не надо будет генерить дополнительный код. к тому же при возникновении ошибки в скрипте всегда сможешь поймать исключение в к-м будет точно идентифицирован токен, на к-м свалился интерпретатор.
6. Касательно отладки. Есть вроде и стандартные средства типа команды debugger, аналогичной установке брейк-поинта. Но правда не юзал. Отладочный вывод легко организовать через те же функции расширения. В общем тут конечно не все безоблачно, но workaround бесспорно есть. Самое простое — т.к. жава-скрипт.нет и интерпретируемый и компилируемый, то можно для отладки компилить его и дебажить гуи-дебагером из СДК. Вкупе с debugger должно выйти вполне полноценное решение.
Здравствуйте, Mityay, Вы писали:
M>Можете навести на ссылки, где об этом написано более подробно? Или приведите пример использования такого средства, пожалуйста.
Открываешь каталок .NET SDK, заходишь в директорию GuiDebug и запускаешь DbgCLR.exe. Дальше все пронятно.
Здравствуйте, AndrewVK, Вы писали:
AVK>С чего ты взял что JScript.NET это интерпретатор?
Да какая разница что он там делает. Главное то, что он ведет себя как интерпретатор с т.з. клиентского кода. Т.е. считай что у компилятора есть режим подражания интерпретатору. Для С-шарпа это придется делать ручками.
Здравствуйте, Воронков Василий, Вы писали:
AVK>>С чего ты взял что JScript.NET это интерпретатор?
ВВ>Да какая разница что он там делает. Главное то, что он ведет себя как интерпретатор с т.з. клиентского кода. Т.е. считай что у компилятора есть режим подражания интерпретатору. Для С-шарпа это придется делать ручками.
Вот это не соответствует действительности
5. Жава-скрипт это все скриптовый язык, он значительно легче до-диезе. Не надо будет генерить дополнительный код. к тому же при возникновении ошибки в скрипте всегда сможешь поймать исключение в к-м будет точно идентифицирован токен, на к-м свалился интерпретатор.
Здравствуйте, AndrewVK, Вы писали:
AVK>Вот это не соответствует действительности AVK>
5. Жава-скрипт это все скриптовый язык, он значительно легче до-диезе. Не надо будет генерить дополнительный код. к тому же при возникновении ошибки в скрипте всегда сможешь поймать исключение в к-м будет точно идентифицирован токен, на к-м свалился интерпретатор.
Что не соответствует действительности? Или ты исходишь из того, что скриптовый язык == интерпретируемый? Для меня скорее это область применения.
Здравствуйте, Воронков Василий, Вы писали:
AVK>>Вот это не соответствует действительности AVK>>
5. Жава-скрипт это все скриптовый язык, он значительно легче до-диезе. Не надо будет генерить дополнительный код. к тому же при возникновении ошибки в скрипте всегда сможешь поймать исключение в к-м будет точно идентифицирован токен, на к-м свалился интерпретатор.
ВВ>Что не соответствует действительности?
То что JScript.NET значительно легче C#, то что не надо генерить дополнительный код, то что отладочная информация в JScript.NET чем то отличается от онной в C#.
ВВ> Или ты исходишь из того, что скриптовый язык == интерпретируемый? Для меня скорее это область применения.
AVK>То что JScript.NET значительно легче C#, то что не надо генерить дополнительный код, то что отладочная информация в JScript.NET чем то отличается от онной в C#.
1. жава-скрипт сложнее с-шарпа? дело не в тонкостях языков — оцени опять-таки тот же "entry level" cost и там, и там.
2. А как код надо генерить? Автор хочет заставить с-шарп работать как процедурный язык — отсюда и необходимость "до-генерить" определение класса. жава-скрипт же и так поддерживает процедурное программивание.
Re: Использование C# как скрипта
От:
Аноним
Дата:
22.01.05 22:49
Оценка:
Курите Code Access Security
Имеется ввиду, что он курит такую знатную траву "Code Access Security" и ему именно поэтому захотелось использовать C# для скрипта ?
P.S. Серьезно
А что значит купить? разве оно в составе FW не идет? эээ...
>>C# поддерживают только IE 5.0 и выше, ТЕ меньше 85% юзеров.
Причем здесь IE? Ему надо скрипт писать для своего собственного приложения.
Я в одном своем приложении тоже реализовал возможность написания скриптов на C# с помощью встроенного редактора (я туда еще Intellisense примитвный прикрутил, чтоб удобнее писать было).
Пространства имен я никак не ограничивал — зачем? Пускай человек делает все, что хочет.
Но если необходимо задать ограниченный namespace, думаю можно создать библиотечку с определенным набором классов, которая бы перекидывала вызовы на системные библиотеки.
Обращаться к классам из других пространств имён можно и без директивы using (сюрприз!!!): new System.IO.FileStream( ... )
Я вам даже больше скажу: при желании "запретными" классами можно воспользоватся, даже если нет ссылки на нужную сборку. Вроде такого:
Assembly a = Assembly.Load( "System.Drawing" );
Type t = a.GetType( "System.Drawing.Image" );
object image = Activator.CreateInstance( t );
Здесь спасёт только CAS, как уже было замечено выше.
Данная информация предоставляется на условиях «КАК ЕСТЬ», без предоставления каких-либо гарантий и прав. Используя данную информацию, вы соглашаетесь с тем, что (i) Майкрософт не несет ответственности за использование вами данной информации и (ii) вы принимаете на себя весь риск, связанный с использованием данной информации.
Согласен, c using'ом немного тормознул.
На самом деле я имел ввиду то, что нужно создать набор допустимых неймспейсов и смотреть на принадлежность класса именно этому пространству имен.
т.е. запретить(не включать в список допустимых) в принципе System.Reflection и динамическая загрузки сборки сразу же не пройдет.
нужно создать набор допустимых неймспейсов и смотреть на принадлежность класса именно этому пространству имен
Ну-ка, ну-ка, поподробнее. Как вы предлагаете это реализовать?
Данная информация предоставляется на условиях «КАК ЕСТЬ», без предоставления каких-либо гарантий и прав. Используя данную информацию, вы соглашаетесь с тем, что (i) Майкрософт не несет ответственности за использование вами данной информации и (ii) вы принимаете на себя весь риск, связанный с использованием данной информации.
К тому же там такая опция есть: делать совместимыми с Netscape 3/ IE 3
