vsvars2008.ps1

Brad Wilson — Thu, 22 Nov 2007 22:59:00 GMT

If you're an avid PowerShell user like I am, you probably want access to the equivalent of the "vsvars32.bat" that's shipped with Visual Studio. I had a version from 2005, but I don't remember where exactly it came from. I pulled most of it apart to re-work it for Visual Studio 2008, since it required extensive modification.

This version should work on both x86 and x64 systems, and gracefully handles the case where you've decided not to install VC++.

Here it is in its entirety. I put this in a file named "vsvars2008.ps1" which I call from my PowerShell profile.

$VS2008Key = $null

if (test-path HKLM:SOFTWARE\Wow6432Node\Microsoft\VisualStudio\9.0) {
    $VS2008Key = get-itemproperty HKLM:SOFTWARE\Wow6432Node\Microsoft\VisualStudio\9.0
}
else {
    if (test-path HKLM:SOFTWARE\Microsoft\VisualStudio\9.0) {
        $VS2008Key = get-itemproperty HKLM:SOFTWARE\Microsoft\VisualStudio\9.0
    }
}

if ($VS2008Key -ne $null) {
    $vsPath = split-path $VS2008Key.InstallDir -Parent | split-path -Parent
    $vcPath = join-path $vsPath "VC"

    if (test-path $vsPath) {
        write-host "Setting environment for Microsoft Visual Studio 2008."

        # Determine installation directory of Platform SDK

        $WindowsSdkDir = $null

        if (test-path "HKLM:SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\Windows") {
            $WindowsSdkDir = (get-itemproperty "HKLM:SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\Windows").CurrentInstallFolder
        }
        else {
            if (test-path "HKLM:SOFTWARE\Microsoft\Microsoft SDKs\Windows") {
                $WindowsSdkDir = (get-itemproperty "HKLM:SOFTWARE\Microsoft\Microsoft SDKs\Windows").CurrentInstallFolder
            }
            else {
                if (test-path "HKCU:SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\Windows") {
                    $WindowsSdkDir = (get-itemproperty "HKCU:SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\Windows").CurrentInstallFolder
                }
                else {
                    if (test-path "HKCU:SOFTWARE\Microsoft\Microsoft SDKs\Windows") {
                        $WindowsSdkDir = (get-itemproperty "HKCU:SOFTWARE\Microsoft\Microsoft SDKs\Windows").CurrentInstallFolder
                    }
                    else {
                        $WindowsSdkDir = join-path $vcPath "PlatformSDK"
                    }
                }
            }
        }

        $FrameworkKey = get-itemproperty HKLM:SOFTWARE\Microsoft\.NETFramework
        $env:FrameworkDir = $FrameworkKey.InstallRoot
        $env:FrameworkVersion = $VS2008Key."CLR Version"
        $env:Framework35Version = "v3.5"

        $env:DevEnvDir = $VS2008Key.InstallDir

        # PATH environment settings

        $paths = @()
        $paths += $env:DevEnvDir
        $paths += join-path $vcPath "BIN"
        $paths += join-path $vsPath "Common7\Tools"
        $paths += join-path $env:FrameworkDir $env:Framework35Version
        $paths += join-path $env:FrameworkDir $env:FrameworkVersion
        $paths += join-path $vcPath "VCPackages"
        if (test-path (join-path $WindowsSdkDir "bin"))
            { $paths += join-path $WindowsSdkDir "bin" }

        $pathText = [string]::Join(";",$paths)
        $env:PATH = $pathText + ";" + $env:PATH

        # INCLUDE environment settings

        $includes = @()

        if (test-path (join-path $vcPath "atlmfc\include"))
            { $includes += join-path $vcPath "atlmfc\include" }
        if (test-path (join-path $vcPath "include"))
            { $includes += join-path $vcPath "include" }
        if (test-path (join-path $WindowsSdkDir "include"))
            { $includes += join-path $WindowsSdkDir "include" }

        if ($includes.Count -gt 0)
        {
            $includeText = [string]::Join(";",$includes)
            $env:INCLUDE = $includeText + ";" + $env:INCLUDE
        }

        # LIB environment settings

        $libs = @()

        if (test-path (join-path $vcPath "atlmfc\lib"))
            { $libs += join-path $vcPath "atlmfc\lib" }
        if (test-path (join-path $vcPath "lib"))
            { $libs += join-path $vcPath "lib" }
        if (test-path (join-path $WindowsSdkDir "lib"))
            { $libs += join-path $WindowsSdkDir "lib" }

        if ($libs.Count -gt 0)
        {
            $libText = [string]::Join(";",$libs)
            $env:LIB = $libText + ";" + $env:LIB
        }

        # LIBPATH environment settings

        $libpaths = @()

        $libpaths += join-path $env:FrameworkDir $env:Framework35Version
        $libpaths += join-path $env:FrameworkDir $env:FrameworkVersion
        if (test-path (join-path $vcPath "atlmfc\lib"))
            { $libpaths += join-path $vcPath "atlmfc\lib" }
        if (test-path (join-path $vcPath "lib"))
            { $libpaths += join-path $vcPath "lib" }
        
        $libpathsText = [string]::Join(";",$libpaths)
        $env:LIBPATH = $libpathsText + ";" + $env:LIBPATH

        $env:VSINSTALLDIR = $vsPath
        $env:VCINSTALLDIR = $vcPath
        $env:WINDOWSSDKDIR = $WindowsSdkDir
    }
    else {
        write-error "Couldn't find the Visual Studio 2008 installation directory."
    }
}

Brian's Find Dilemma

Brad Wilson — Thu, 22 Mar 2007 16:36:00 GMT

Brian has been searching for a PowerShell replacement to a Unix command and came up with this:

get-childitem -include foo.* -recurse | where-object { get-content $_ | select-string find_me }

Here it is, shortened for interactivity:

[1] » dir -r -i *.ps1 | ?{ gc $_ | select-string "get-childitem" }

Mode                LastWriteTime     Length Name
----                -------------     ------ ----
-a---         6/11/2006   6:10 PM         46 find-files.ps1
-a---         6/12/2006   5:39 PM        411 find-string.ps1
-a---         10/9/2005  11:22 AM        149 get-linecount.ps1
-a---         6/17/2006   1:08 PM       1173 prep-mp3s.ps1
-a---         9/27/2006   9:31 AM        668 show-signers.ps1
-a---         5/30/2006  11:49 AM       2449 TabExpansion.ps1

That's not too bad, but if you leave off the where clause, it shows you line #s and text:

[2] » dir -r -i *.ps1 | select-string "get-childitem"

find-files.ps1:1:get-childitem -force -recurse -include $ar gs
find-string.ps1:3:get-childitem -recurse -include $args[0] | [...]
get-linecount.ps1:3:(get-childitem -i $match -r | grep $re | [...]
prep-mp3s.ps1:10:get-childitem -r -i *.mp3 | foreach-object {
show-signers.ps1:1:$inputs = $(get-childitem)
TabExpansion.ps1:40:foreach ($v in Get-Childitem ('variable:'[...]

That's the right information, in a format I don't like. Maybe that's why Brian does it his way.

This is a script that I ended up with a few months ago (the bulk of which came from IanG):

get-childitem -recurse -include $args[0] |
select-string $args[1] |
group-object Path |
select-object @{Expression={$_.Name.Substring((get-location).Path.Length + 1)}; Name="Filename" }, @{Expression={$_.Group | %{ $_.LineNumber}}; Name="Line Numbers"} |
format-table -Autosize

Which works like this:

[3] » find-string *.ps1 get-childitem

Filename                               Line Numbers
--------                               ------------
find-files.ps1                                    1
find-string.ps1                                   3
get-linecount.ps1                                 3
prep-mp3s.ps1                                    10
show-signers.ps1                                  1
TabExpansion.ps1                                 40

If something occurs multiple times, the line numbers get grouped up:

[4] » find-string *.ps1 set-content

Filename                               Line Numbers
--------                               ------------
append-path.ps1                        9
Microsoft.PowerShell_profile.ps1       {30, 34, 62, 63}
prepend-path.ps1                       9

Note: While I use aliases interactively (like "dir" instead of "get-childitem"), I always use full-names in scripts, because you don't know when people will override aliases. Using full switch names isn't a bad practice, either, since your unambiguous short name for a switch might not be so unambiguous in the future (and it makes the scripts a bit easier to read, too).

Tags: PowerShell