KeyKeeper's region

location: как всегда

mood: productive

music: Kaliya - Ritual Tibetan

Это третья заметка на тему использования скриптинга в готовых .NET приложениях. Предыдущий пост находится тут.

Как я писал ранее, ни VSTA, ни какие-либо иные готовые движки для скриптинга не подошли для применения в нашем проекте. Основные причины – "сырое" состояние движков, отсутствие возможности отладки скриптов, трудная или невозможная расширяемость продукта, неполное соответствие предъявленным к движку требованиям. Возникает резонный вопрос, что ещё можно сделать, если существующие решения нас не устраивают? И на этот вопрос есть-таки положительный ответ.

Признаюсь, идея решения, которое я очень кратко опишу ниже, принадлежит вовсе не мне. Более того, я даже не знаю, кто является его автором. Дело в том, что я получил на работе достаточно простой прототип скриптового движка. Сначала я отбросил это решение из-за его мнимой сложности, но после исследования VSTA, IronRuby, Ruby.Net, IronPython и CS-Script, я могу назвать его их достойным конкурентом. В корпоративной переписке название решения звучит как scriptProto, поэтому я так и буду его называть далее.

Идея scriptProto заключается в компиляции исходного кода, написанного на языке C# или VB.NET, с помощью классов CSharpCodeProvider и VBCodeProvider. В результате компиляции на выходе получаем обычные .NET-овские сборки, готовые к использованию. Однако помимо этой задачи, для построения нормальной IDE, мне пришлось реализовывать или искать редактор кода и отладчик.

Для реализации текстового редактора был использован компонент EditControl от Syncfusion. В версии 6.3 реализована возможность раскраски кода на языках C, C#, Delphi, Html, Java, JavaScript, SQL, VB.NET, VB Script, XML. Включается syntax highlight элементарно просто – следующим вызовом:

sourceEditControl.ApplyConfiguration(KnownLanguages.CSharp);

Кроме того доступны возможности свёртывания кода (folding) и зачаточное (но не реализованное) завершение кода (code completion). Более справедливо было бы сказать, что реализация code completion полностью ложится на плечи разработчика, а это, как вы понимаете, большой "гемор". Ради интереса я посмотрел реализацию этой фичи в SharpDevelop – бесплатной среде разработки под платформу .NET. Оказалось, что там эта задача решается с большим трудом. Причём перенести эти труды в наш проект не представляется возможным... Таким образом, code completion я решил оставить "на десерт".

Теперь про отладчик. Для того чтобы писатель скриптов мог искать жуков-навозников в своём детище, IDE просто обязана иметь в своём распоряжении отладчик. Для этой цели в scriptProto был использован MDbgEng (mini debugger). Как это ни странно, он оказался прост в использовании, а его API вполне достаточен для реализации стандартных функций типа Step Into, Step Out, Go To Cursor без особого труда.
В своём коде я использовал следующие классы и их члены:
• MDbgEngine – движок. Позволяет создавать отлаживаемые процессы;
• MDbgProcess – отлаживаемый процесс, который можно набить точками останова;
• MDbgBreakpoint – собственно, точка останова;
• BreakpointHitStopReason – тип, который помещается в свойство StopReason объекта MDbgProcess в случае остановки на брейкпоинте, а не по иной причине.
Конечно, в этом небольшом управляемом отладчике есть ещё море всего интересного, но я ограничился всего лишь таким узким API.
В MDbgEng также есть возможность осуществлять оценку переменных и выражений. Это помогло мне реализовать функциональность Watcher'а. В общем-то, это всё, что я могу рассказать про запчасти той крохотной IDE, которую я пишу. Возможно, в следующих постах я опишу то, как именно я собрал из всех этих деталей машинку, на которой можно кататься.

И ещё, пока я не забыл. Попытаюсь максимально объективно оценить описанный подход к реализации скриптинга и его наилучший возможный результат. Сильные стороны: высокая гибкость, удовлетворение (почти) всех потребностей заказчика. Слабые стороны: больший объём работ для реализации IDE, которого можно было бы избежать при использовании готовых движков. Как из этого видно, сложность решения отдельных задач для готовых движков переросла в объём работ для случая собственного движка с одновременным их упрощением. Не могу судить, насколько хорош и универсален подход scriptProto, но могу с уверенностью сказать, что в случае с моим проектом, это решение – идеально.