Like many other .NET software developers we love Visual Studio - it's fast, robust, efficient and fun to use.

With a variety of supported platforms and a rich set of standard controls (not to mention third-party controls from well-known vendors, which cover anything and everything, from simple buttons and editors to advanced controls like charts, grids and schedulers), a little bit of time and resources can let you create whatever application you can imagine.

But what about making some of the power Visual Studio provides available to the users of your application? Well, most apps out there will not need that power, but there are some, just to name a few, like Microsoft Office, Solid Works and Adobe Photoshop, which provide the Software Development Kit (SDK), so developers or power users can program custom logic for these platforms. It may be just simple macros in Microsoft Office that capture repetitive tasks in the form of a Visual Basic for Application script and replay them when needed, or full-featured Adobe Photoshop graphic filters.

Leaving aside the way these SDKs are implemented, the basic idea behind is more or less the same - there are some internal application APIs that are made available to the writer of user-defined plugins or scenarios and a set of programming tools that allows these APIs to be utilized. For some applications you might need a proper development platform, such as Visual Studio itself, but some come with their own set of tools - like the VBA for writing macros in Microsoft Office Word or Excel.

So, the real question is, what feasible options does a .NET developer if he decides that his application has to provide such functionality via some sort of scripting language (so the power users can extend that application)? Well, he will face a choice of either programming this feature himself, or shopping around and finding already existing solutions from some of the previously mentioned third-party controls and components vendors.

There are, of course, bits and pieces scattered around allowing to assemble such solutions - as an example, executing .NET scripts is actually relatively straight-forward; finding some kind of text editor enabling to write these scripts is not a problem either; however, once you go through the first few steps, different questions might rise up, like: how these scripts can be debugged; how the user can define custom user interface and hook it up to the script; how to make the code editor to recognize application-defined objects and provide valid code completion guidance as user types. Well, searching through what's available suggests that there are no simple answers to these questions.

AlterNET Extensibility Studio was developed to solve this problem - and bring all these bits and pieces together under the same umbrella. It consists of the following component libraries designed to work together:

• Scripter provides an engine to run, C# and Visual Basic scripts with an ability to access application objects, and Script Debugger engine allowing to debug these scripts.

• Code Editor supports all the features needed for efficient code editing, such as syntax highlighting, code completion, code folding, etc.

• Visual Form Designer permits creating custom user interfaces, which can be hooked up to the user code.