Author: Jason Kemp

Scott Hanselman’s recent zeal for MSH has motivated me to take another look at Monad.

I saw the original Jeffrey Snover Channel 9 video and downloaded the beta then; he just about drop kicks you with his enthusiasm, so I had to try it. My first two co-op terms (internships is another term) were spent as a system administrator, so there will always be a soft spot for a powerful command line\scripting platform in my heart. So I took a look, played around, saw that it was WAY too much to learn, and quickly dropped it. Now that Scott has extolled the virtues of Monad in recordable audio format, I figured I’d give it another try.

Scott’s right when he says it’s rough to start with; there definitely is a learning curve and I don’t think I’m out of the dark yet. But I’ve decided to take the first steps by customizing the bejeezus out of it. The first thing I wanted to do was start every instance with the VS/.NET SDK tools set up. I’m not a huge command line guy in my day-to-day work, but I tend to use the .NET SDK tools when I do. So it would be more convenient to load them every time I run MSH.

You, of course, know the “Visual Studio Command Prompt” menu option in the Visual Studio Tools start menu group is merely a call to cmd.exe with a batch file loaded. Well, I figured my first task would be to rewrite that as a msh script (although not strictly necessary – at least, I think – I figured it was a good place to start scripting), then set it be called whenever I start an instance of msh.exe.

So that’s what I did.

See ya.

Why aren’t you leaving?

Oh alright.

The first part, writing the script, was pretty easy. I opened TextPad with a new document and opened the vsvars32.bat file (located in “%PROGRAMFILES%\Microsoft Visual Studio 8\Common7\Tools”) side by side and started converting.

The file in its entirety is provided below. Download it here. It’s not a very complex script and certainly doesn’t take advantage of the power of the msh script engine, but I still took away a lot from doing this script. First, I forgot what a pain in the ass it is to debug scripts if you’re just learning the syntax. I’m sure once I get going, I’ll be more productive with this, but typos really killed me.

I really like setting variables in msh. You’ll note the syntax for setting variables in different scopes makes it very clear to read. For example, $env:Path is the %PATH% environment variable; $script:tools sets the tools variable for the whole script. One gotcha that I’m not used to is that functions have to be declared before they’re used. I know that dates me as a young’un, but whatever, so I’m not old enough to use C so much. JScript and VBScript don’t have that restriction, and that’s where I’ve done most of my scripting. Another thing I like is variable expansion. If you embed the variable name in a string, msh will expand it for you. That’s very handy for writing file paths as you’ll note below. I put in a few different ways of doing it, just because.

The second part of the problem is to load this for every msh.exe instance. I could do what MS does for the Windows SDK and a have a shortcut that calls msh.exe with some command line arguments, notably the script, but that would mean I have to open every instance from the same shortcut; that’s inconvenient, especially if you’re used to, like I am, opening it up from the Run dialog. The best way to do this for my needs (yours may differ) was to set it up in my profile.msh file located at “My Documents\msh\profile.msh”. This is a place for users to set their own preferences for the shell. I found this post about calling multiple msh scripts from profile.msh but it didn’t quite work for me. I set a variable to the full path of the vsvars32.msh file location and then called . $vsvars, which loads the script for me. I think that’s a unix shell command – the ‘.’ – but it’s been so long since I’ve used unix, so I don’t know. Run gacutil or xsd and watch in churn out the usage message. Sweet, huh?

# vsvars32.msh
# This is a re-write of the vsvars32.bat file that is
# installed by Visual Studio 2005. I did this to learn
# msh script. Your mileage may vary. This is not supported.

$script:VsInstall = "${env:ProgramFiles}\Microsoft Visual Studio 8"
$script:tools = "$script:VsInstall\Common7\Tools"
$script:vc = "$script:VsInstall\VC"

$env:VSINSTALLDIR = $script:VsInstall
$env:VCINSTALLDIR = $script:vc
$env:FrameworkDir = "${env:windir}\Microsoft.NET\Framework"
$env:FrameworkVersion = "v2.0.50727"
$env:FrameworkSDKDir = $script:VsInstall + "\SDK\v2.0"

write-host "Setting environment for using Microsoft Visual Studio 2005 x86 tools."

$env:DevEnvDir = $script:VsInstall + "\Common7\IDE"
$script:FxDir = $env:FrameworkDir + "\" + $env:FrameworkVersion

# ------------------------------------------------------------------
# Prepend a directory to a semi-colon delimited list of directories
# I stole this function from the SetEnv.msh script provided by the Windows SDK
# ------------------------------------------------------------------
function PrependToVar
{
param ([string]$list, [string]$newdir)
	return "$newDir;$list"
}

$Path = PrependToVar $env:Path $env:DevEnvDir
$Path = PrependToVar $Path "$script:vc\bin"
$Path = PrependToVar $Path $script:tools
$Path = PrependToVar $Path "$script:tools\bin"
$Path = PrependToVar $Path "$script:vc\PlatformSDK\bin"
$Path = PrependToVar $Path "$env:FrameworkSDKDir\bin"
$Path = PrependToVar $Path $script:FxDir
$Path = PrependToVar $Path "$script:vc\VCPackages"

$Include = PrependToVar $Include "$script:vc\atlmfc\include"
$Include = PrependToVar $Include "$script:vc\INCLUDE"
$Include = PrependToVar $Include "$script:vc\PlatformSDK\INCLUDE"
$Include = PrependToVar $Include "$script:FrameworkSDKDir\INCLUDE"

$Lib = PrependToVar $Lib "$script:vc\atlmfc\lib"
$Lib = PrependToVar $Lib "$script:vc\lib"
$Lib = PrependToVar $Lib "$script:vc\platformsdk\lib"
$Lib = PrependToVar $Lib "$script:FrameworkSDKDir\lib"

$env:Path = $script:Path
$env:Include = $script:Include
$env:Lib = $script:Lib
$env:LibPath = "$script:FxDir;$script:vc\atlmfc\lib"

Searching the internet for version numbers is largely pointless: the hits are useless. I’ve tried variations on “version numbers daily build.”

However, I, in my voracious blog reading, remembered a few posts by some bloggers I read so I figured I’d link to them here so they are all in one spot.

• Jensen Harris’ post explaining Office build numbers. This post is only a couple of weeks old at the time of this post. The Office team uses a date-based build number.
• The next was the hardest to find because I know he posted about it; turns out he talked about it in the context of another subject, where I thought it was a specific post on the boring subject of version numbers. Wesner Moise has a quick breakdown of CLR version numbers. So quick I’ll quote it here:
  

  Longhorn use version 2.0.31113.25 of the CLR, whereas the CTP is a much more recent build, 2.0.40301.9. The third number is the build number. It likely indicates the day the build was made (under the format YMMDD). The last number most likely reflects the number of attempts made to stabilize that build. That Longhorn’s 25 is almost triple that of the CTP’s 9 is a good indication of how much more stable Longhorn’s earlier version of the CLR is compared to the CTP. The PDC build used build 30703, which had been prepared for months before PDC.

• The last link I found was the most appropriate to my query: Suzanne Cook, who unfortunately looks like she stopped blogging last year, has a post on what to do with internal builds versus external builds. She is in the latter camp, it appears. 

Now playing: Headstones – Tiny Teddy