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

The blogged wandering of Robert W. Anderson

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: , , ,