How do I get started designing and implementing a script interface for my .NET application?

There is VSTA (the .NET equivalent of VBA for COM), but as far as I understand I would have to pay a license fee for every installation of my application. It is an open source the application so this will not work.

There is also e.g. the embedding of interpreters (IronPython?), but I don't understand how this would allow exposing an "object model" (see below) to external (or internal) scripts.

Sub-questions:

What is the scripting interface story in .NET? Is it somehow trivial to do this in .NET?
E.g. can some .NET objects in my application and their contained objects be declared to be accessible from the outside at runtime?
How can external scripts access my application (through the object model)?

Background:

I have once designed and implemented a fairly involved script interface for a Macintosh application for acquisition and analysis of data from a mass spectrometer (Mac OS, System 7) and later a COM interface for a Windows application.

Both were designed with an "object model" and classes (that can have properties). These are overloaded words, but in a scripting interface context object model is essentially a containment hierarchy of objects of specific classes. Classes have properties, lists of contained objects and are not only data but can have verbs as well (actions/methods). E.g. in the Macintosh case the defined application object can contain an acquisition object that has properties for voltages used in the instrument and a fireLater verb - all as seen from the external script.

Note that in both cases the classes/objects in the programming language used to implement the application had nothing to do with the scripting object model. For the Macintosh case, the mechanisms used to implement the scripting interface was defined by Apple. There were also some standards defined by Apple on how to design the object model. For instance, standardized names for certain common properties in classes.

Or like in the COM interfaces exposed in Microsoft Office applications, where the application object can be used to add to its list of documents (with the side effect of creating the GUI representation of a document).

External scripts can create new objects in a container and navigate through the content of the hierarchy at any given time. In the Macintosh, case scripts could be written in e.g. AppleScript or Frontier.

On the Macintosh, the implementation of a scripting interface was very complicated. Support for it in Metroworks' C++ class library (the name escapes me right now) made it much simpler.

Solution

[EDIT: As covered at length in the comments in this, assuming you have a significant need to enable internal scripting where you are hosting snippets or functions someone gives you to customise your app, as opposed to a purely external scenario where one is providing a facaade to allow people to dig stuff out of your app on a more rigid predefined basis]

IronRuby and IronPython are very neat and appropriate for this (but as the other answer says, PowerShell may be appropriate if you have a more infrastructure-type thing).

EDIT: Other ideas for enabling internal scripting are

using Windows Workflow Foundation (exposing activities to it and/or hosting instances of workflows)
using Spring.NET's Expression Language (which is terse, easy to doc and learn but surprisingly powerful)

EDIT 2 June 2011: IronJS may also be a suitable candidate, there's a Hanselminutes that talks it thru.