Expert Texture Home Contact me About Subscribe Digipede Connect on LinkedIn rwandering on Twitter rwandering on FriendFeed

The blogged wandering of Robert W. Anderson

.NET on Server Core

Dmitry Sotnikov provides the steps to get PowerShell — and of more general interest, .NET 2.0 –  running on Windows Server 2008 Server core.

While this is a stopgap until Microsoft officially supports this configuration, it could still be useful. 

Now the question for me is, will this work for running Digipede components?

Tags: , , , ,

Narrowing the Semantic Gap

Last week, PowerShell Architect Jeffrey Snover wrote an excellent post titled the Semantic Gap.  He writes about the gap as . . .

. . . 2 worlds:

  1. The world as we think about it.
  2. The world as we can manipulate it.

The difference between these two is what is called the semantic gap

This is a great working definition. 

Jeff writes about this specifically regarding PowerShell and instrumentation providers and asks the question,

So why do instrumentation providers close or not close the semantic gap?

Yes, some do, and some don’t.  This isn’t just about hierarchy of needs, but also about prioritization.  How important to the provider is a narrow semantic gap for product X when used through interface Y? 

In the case of X := Digipede Network and Y:= PowerShell, we thought it pretty important.

But how do you decide if narrowing the gap is worth it?  Engineering costs aside, understanding what your interface could look like in PowerShell can help you decide.  Internally, we answered these questions:

  1. What would a PowerShell script look like just using your .NET or COM APIs? 
  2. What could it look like with Cmdlets? 
  3. Would these Cmdlets support how we think about the Digipede Network (i.e., small gap?).

I already said the answer to #3 turned out to be yes and in a previous post, I gave an example of the gap in Why a SnapIn for the Command-Line?  This example highlights the gap for a common operation on the Digipede Network: get the description of a pool of resources.

If you are thinking about supporting PowerShell in your product, take a look at my post.

I hope this helps you decide.

Tags: , , , ,

PowerShell v2 CTP

Congratulations to the PowerShell team for getting out their CTP.  I grabbed it this morning to make sure the Digipede AddIn works against it.   Yes it does.

Cool stuff.

Couple of things:

  1. WS-MAN needs to be installed before installing the CTP (this What’s New post implies that the remote-shell features need it, but not that it is required).  I hope this is only for the CTP and will not be required in the eventual release.  Any extra requirements make it harder for ISVs to integrate PowerShell into their products.  If you do not have WS-MAN installed yet, go here to get it:×409
  2. This new version comes with a “Graphical PowerShell”.  This appears to be similar to the Shell Tools PowerShell Analyzer product, and not a replacement console.  If you are looking for a better console, check out the other Shell Tools product, PowerShell+.

I will spend more time with the CTP soon and likely have more comments then. 

Tags: , , , , ,

Why a SnapIn for the Command-Line?

On Tuesday I posted about the new Digipede SnapIn for PowerShell. 

One question I didn’t get into is, why write a SnapIn when PowerShell supports full scripting for .NET APIs?  The short answer is that we can provide a better command-line experience with PowerShell cmdlets than the “out of the box” PowerShell experience.  Windows PowerShell Architect, Jeffrey Snover, did a great post on this a few months back: Cmdlets vs. APIs

I thought I’d give an example of the difference as it relates to the new Digipede SnapIn. 

For example,  suppose you want to enumerate the pools on a Digipede Network.  Natively in PowerShell, you can do the following:

[System.Reflection.Assembly]::LoadFrom("C:\\Program Files\\Digipede" +
  "\\Framework SDK\\v2.0\\Net2.0\\Digipede.Framework.dll")
$DigipedeClient = New-Object -TypeName Digipede.Framework.Api.DigipedeClient
$DigipedeClient.Management.GetPools() | ft 

That is pretty verbose (note the first line is split in two to improve readability in my blog). This same operation becomes much simpler with the Digipede SnapIn:

Add-PSSnapIn DigipedeSnapIn
$DigipedeClient = New-DNClient -Network MYSERVER

And what about the output?  Without any extra information, PowerShell will format output on its own — a very cool feature.  The former example produces a default table output:

IsReadO  PoolId Name    Descrip Collect Schedul Potenti TotalCo JobTota TaskTot
    nly                 tion    ion     ingAlgo   alGhz mputeRe lComple alCompl
                                          rithm         sources     ted    eted
-------  ------ ----    ------- ------- ------- ------- ------- ------- -------
   True       1 Mast... Mast... {Mas... ...rity      66      19     665   57584
   True     601 Fifo            {Mas... ...tOut      18       3       0       0

PowerShell can’t determine which properties should be included, so it makes a guess.  The DigipedeSnapIn includes formatting information to give much more readable (and useful) default output:

PoolId Name                 Description                    Resources Potential
------ ----                 -----------                    --------- ---------
     1 Master Pool          Master Pool                           19        66
   601 Fifo                                                        3        18 

So, the SnapIn definitely provides a better command-line experience.  And the great thing?  These two worlds are not mutually exclusive.  For example, suppose you want to specify the default pool for a DigipedeClient object?  We haven’t exposed that as a property on New-DNClient nor provided a cmdlet for this purpose, but the API includes the PoolId property.  Just do this:

$DigipedeClient.PoolId = (Get-DNPool -Name "Fifo").PoolId

Now, the default pool is a pool named “FIFO”.

This brings me back to something I wrote in my previous post:  PowerShell is cool.

Tags: , , , ,

PowerShell SnapIn for the Digipede Network

deetle2ps Today we posted a preview of our PowerShell SnapIn for the Digipede Network — go to the Digipede community site for details and download instructions.

This preview provides a functioning command-line interface to much of the available Digipede Network management APIs.  This functionality will continue to be enhanced along with the underlying APIs (more on this in a future post).

This preview is a little bit of a departure for us at Digipede.  While we have targeted previews to customers in the past, this is the first time we have made one publicly available.  A bigger departure, though, is that we are also including full source code to this preview.

Digipede is not open-source, so why release the SnapIn code?

  • The SnapIn provides excellent examples for the Digipede Management APIs.  The SnapIn is also a good example of a PowerShell SnapIn.
  • By providing a sample as a SnapIn we are reducing the startup costs for our customers to develop their own cmdlets (for the Digipede Network and otherwise).
  • We hope that some community members will provide feedback in the form of suggestions, fixes and maybe even new cmdlets — this will help make the SnapIn better faster. 

Another question might be, why do a PowerShell SnapIn at all?  After all, PowerShell does a great job with .NET APIs without any additional support.

  • PowerShell does do an excellent job with .NET APIs (and COM APIs too, for that matter).  But this support is better suited to scripting than to a great command-line interface.  I will post an example of this difference later this week.
  • For some customers, a command-line interface is important.  PowerShell provides a standard framework into which such interfaces can be built — the days of writing one’s own custom command-line interfaces are thankfully past.
  • PowerShell is really cool.

If you are interested in PowerShell, the Digipede API, or a command-line interface to the Digipede Network, please take the time to try out the preview.  We would love to get feedback from you on what else it needs, any problems you find, and ideas for other cmdlets — implementations even better!

To learn more about Windows PowerShell, visit the Microsoft Windows PowerShell home page as well as the PowerShell Team blog.

Tags: , , , ,

Digipede Network 2.0

image The software is done, the press releases out, John and Dan talking about it in New York.  I can’t say I’m the first to announce it, but I may be the most glad that it is finished and released.


What is new?  A bunch of stuff, but I am most excited about . . .

  • Many changes have been made to Digipede Control — it is easier to use and looks better
  • The Digipede SDK now has tighter integration with Visual Studio 2005: now it is really easy to debug both sides of your Digipede applications.
  • Integrated Windows security

Of course, there are also improvements to the API, performance improvements, and more. 

Soon I will also be announcing the release of Java and PowerShell support in the form of fully functional samples with binaries (for those of you not interested in the details).

And now with 2.0 out, maybe I can find the time to blog a bit more ;)

Tags: , ,

PowerShell 1.0 Released!

Releases are coming like crazy out of Redmond.  Congratulations to the whole PowerShell team and specifically to Jeffrey Snover for getting this done.

I guess this means we should finish our PowerShell CmdLets for the Digipede Network.

Tags: , ,

PowerShell for ISVs

Since my conversation with Jeffrey Snover at the ISV CTO Summit (blogged here), I have wanted to post on some benefits of adopting PowerShell as an ISV.

Many products can be greatly improved by the addition of a rich commandline interface. Obviously this enables a user to type commands at the console, but this can also enable more advanced scripting of your application. The typical way an ISV provides such an interface is to develop a custom set of console application(s). Alternatively, a Microsoft ISV can build on top of PowerShell (using CmdLets) and get so much more.

Here are some pros and cons of these two approaches (with a nod to J. LeRoy for using Mind Maps in posts):

Custom (console applications)

Pro Multi-platform: includes any version of Windows (or anything else for that matter) that you target.
Con Design “from scratch”: Every aspect of the commandline (e.g., argument naming and syntax, formatting, etc.) needs to be designed. As there are few clear guidelines and virtually no consistency on the Windows platform, you will have to design this with a “least-worst” mindset.

Con Lots of coding: You have to write a fair amount of code for even simple use cases to enforce / interpret your arguments and to format your a report properly.

Con Advanced use cases hard (Lots more coding): Enabling complex user scenarios through your commandline may require a lot of development. For example, if you already have a rich API and want to expose this through your commandline, you may need to painstakingly map new commands to existing methods.

PowerShell CmdLets
Recent Windows only: Windows XP, Windows 2003, Vista, Longhorn Server (and specifically not Windows 2000).
Pro Easy design: Since PowerShell includes clear guidance on CmdLet design (e.g., argument naming) it is much easier to design your entire commandline with few design decisions.
Pro Object pipeline. PowerShell supports an object pipeline. This greatly eases the scripting use cases. For example, instead of having to make sure that your command outputs a piece of text that can be interpreted for use in a subsequent command, you simply need to return a .NET object.
Pro Formatting. The output formatting is not only automatic but plugs directly into other PowerShell utilities to format your output as tables, lists, to sort it, etc.

Pro Advanced use cases are easy. Combining the object pipeline with PowerShell’s ability to script .NET objects, you get a commandline that enables advanced use cases without you having to design for them directly. For example, the Digipede API already enables advanced use cases. With PowerShell we don’t have to design in each of those use cases. By making it easy for a PowerShell user to get an instance of our DigipedeClient object, we have enabled all (or nearly all) of the use cases enabled through our API.

Pro Simpler docs. Less documentation needs to be written to explain the basic use cases for your interface, because of the PowerShell design guidelines.


PowerShell is a really good choice for Microsoft ISVs. It delivers a lot of value to the ISV in exchange for relatively little effort.

From my perspective, PowerShell is yet another example of how Microsoft provides a terrific platform for ISVs: we get a great command line for the Digipede Network with little effort and can focus on the core value our product brings to the market.

Tags: ,

VS2005 PowerShell Prompt

If you are like me, you use the Visual Studio Command Prompt frequently, because you need the environment that gets set up by the vcvarsall batch. I’m using the PowerShell now exclusively, but still need this environment. Just calling the batch file doesn’t get the variables set in PowerShell. Adam Barr has a good explanation and solution here (and the interesting bit below is taken from his blog and credited there to Bruce Payette).

My goal was to have these environment variables set for every instance of PowerShell. Not rocket-science, but not terribly straight forward to a newbie PowerShell user either. To do that, I needed to add a script that will get run on every invocation of PowerShell. Here is what I did.

If you don’t yet have a profile set up, then create the required directory (explanation of profile naming is here):

mkdir "$home/My Documents/WindowsPowerShell"

Open your profile (or create if it doesn’t exist):

notepad "$home/My Documents/WindowsPowerShell/Microsoft.PowerShell_profile.ps1"

Paste the following into your profile:

pushd 'C:\\Program Files\\Microsoft Visual Studio 8\\vc'
cmd /c “vcvarsall.bat&set” |
foreach {
  if ($_ -match “=”) {
    $v = $_.split(“=”); set-item -force -path "ENV:\\$($v[0])"  -value "$($v[1])"

And then start a new PowerShell. Now the environment should be set properly.

Update: I fixed the path to the default profile.  Thanks to dreamlusion for pointing out that my info was pre-release and out of date.

Tags: , , ,

Playing with PowerShell

I finally jumped into making my own PowerShell (nee Monad) CmdLets. I took the name change and, more importantly, promotion to release-candidate status, as the impetus to try it out. A rich command-line interface to the Digipede Network is on our future-list and I’m doing some prototyping now — it seemed as good a time as any.

I won’t go into what the PowerShell is, much has been written about it. I do want to commend the PowerShell team, though. I wrote a CmdLet and found how very easy and powerful their model is.

I started by writing a CmdLet to present simple job status. Turns out, the meat of the code is just this:

protected override void ProcessRecord() {
    foreach (int jobId in mJobIds) {
        WriteObject(mClient.GetJobStatus(jobId), true);

This code goes through all of the Job IDs passed on the command-line (or from the pipe), gets JobStatusSummary objects representing their state, and writes each one to the receiving pipe. Those of you familiar with our API will recognize the DigipedeClient.GetJobStatus() method. ProcessRecord() and WriteObject() are parts of the PowerShell API.

OK, granted, there are a bunch of lines of code required to wrap around all of this, but not too many. It all took a couple of hours start to finish (including reading and grokking). The result looks like this:

PS C:\> get-job-status -credential $me -host localhost -jobid 1

IsReadOnly            : False
Collection            :
JobId                 : 1
TimeCreated           : 4/26/2006 1:10:32 PM
TimeModified          : 1/1/0001 12:00:00 AM
StatusChangeTime      : 1/1/0001 12:00:00 AM
Status                : Waiting
LastTaskTimeFetched   : 1/1/0001 12:00:00 AM
LastTaskTimeCompleted : 1/1/0001 12:00:00 AM
TaskTotal             : 100
TaskTotalAssigned     : 0
TaskTotalCompleted    : 0
TaskTotalFailed       : 0
TaskTotalActive       : 0
TaskTotalWaiting      : 100
TimeStarted           : 1/1/0001 12:00:00 AM
TimeEnded             : 1/1/0001 12:00:00 AM
EstimatedTimeEnd      : 1/1/0001 12:00:00 AM
IsFinished            : False
TaskStatusSummaries   : {}
FailureReason         : None
FailureMessage        :

Again, if you are familiar with the Digipede API, you’ll recognize this as a JobStatusSummary. I wrote zero lines of code to do this, because PowerShell uses .NET Reflection to interrogate the object directly. Of course, this can all be reformatted with built-in PowerShell commands. This is excellent — we can layer CmdLets on top of our existing APIs without having to write a bunch of formatting code.

Now I know how easy this is, the next step is to step back and look at the bigger design.

Thanks to the PowerShell team for such a cool product.

Tags: , , ,