A topic came up on the newsgroup today that I thought was a good segue into a series of posts that I’ve been working on.  Paraphrased, the question was, “How do I get Monad to do stuff from another .Net language?”

There are two ways to go about this, depending on the requirement.

The first is to cleanly separate your object model from your cmdlet implementation.  You write a class that does what you need it to.  You can invoke that class from .Net like any other class, and write your Cmdlet as a thin wrapper to interact with that same object model.  Think of this as the business logic / UI separation that is so important in designing a good application.

This is the ideal solution if your task and object model do not require access to the facilities that the Monad hosting environment provides.  Those facilities include object pipelines, user interaction, other cmdlets, providers, for example.

For cmdlets that do not require access to the Monad hosting environment, the release notes for Beta 3 describe a technique of accessing them from other .Net languages.  Although it is possible, it is really a release valve.  When access to the cmdlet from outside of Monad is important, developers should strongly prefer to expose both their object model and thin cmdlet wrapper to users.

The second way is to host the Monad engine inside of your application, and have Monad execute the pipelines you specify.  This provides both their application, and their cmdlets with many of the other benefits that come along with the Monad hosting environment.

This latter approach is one that I will illustrate over the next few articles.

[Edit: Monad has now been renamed to Windows PowerShell. This script or discussion may require slight adjustments before it applies directly to newer builds.]