Saturday, August 30, 2014

PowerShell: Getting the Drive Letter for a PowerShell Script

A quick search online reveals there are a large number of ways to return the current path of the PowerShell script being run. PowerShell 3 introduced the automatic variable, $PSCommandPath. An example is as follows (script file, ShowPathInfo.ps1):

Write-Output "`$PSCommandPath:  $PSCommandPath";

The output from this command is as follows:

In previous snippet of PowerShell note the use of the Grave accent character before $PSCommandPath (e,.g. `$PSCommandPath). This escape character suppresses $PSCommandPath being interpreted as a variable and instead prints the string literal. For those who cannot find the grave accent (it is to the left of the 1 key or as shows in one blog post):

Displaying the drive letter is a matter of executing (script file, ShowDriveLetter.ps1):

$DriveLetter = $PSCommandPath[0];
Write-Output "Drive Letter:  $DriveLetter";

The output from this is as follows:

The $PSCommandPath automatic variable will not work if you are using PowerShell 2. This version of PowerShell is native to Windows 7 and Windows Server 2008 R2. PowerShell 2 is available in Windows XP upgrade to Service Pack 3, Windows Server 2003 upgraded to Service Pack 2 and Windows Vista upgraded to Service Pack 1.

If you are limited to PowerShell 2 consider the following (script: ShowPathInfoPowerShell2.ps1):

function WhatHappensNestedInAFunction()
  Write-Output("Function invoked `$MyInvocation.ScriptName: " + 
  Write-Output("Function invoked `$MyInvocation.Path: " + 

Write-Output("Script invoked `$MyInvocation.ScriptName: " + 
Write-Output("Script invoked `$MyInvocation.Path: " + 
WhatHappensNestedInAFunction ;

The output from the script is as follows:

This means in PowerShell 2 you have to use the following to get the script name within the script:'s body:


It also means in PowerShell 2 you have to use the following to get the script name within a function:


To simplify this, it is simpler to just create a function that uses $MyInvocation.ScriptName to return the script path:

function GetScriptPath()
  return $MyInvocation.ScriptName;

Once the script path is know, getting the driver letter is trivial (as was previously demonstrated).

Friday, August 29, 2014

Visual Studio Online (cloud hosted TFS): Unlimited (no cost) users can Create/Access Bugs/Tasks

Microsoft has created a new category of free users for Visual Studio Online (VSOL), namely Stakeholders. This user type has the ability create bugs/tasks and view the status of bugs/tasks including generating reports with regard to bugs/tasks. Even a company that has no desire to use VSOL for source code control has a free, cloud-based bug/tracking and project management software provided by Microsoft.

Thus far the lowest tier of licenses for Visual Studio Online was the "Basic License." Each VSOL account comes with five Basic user accounts for free and each additional is $20 per month (as of August 2014, see: Visual Studio Online User Plans). With this minimum account type comes access to source code control and the project management aspects of VSOL found under a project's Work menu item. This includes creating bugs/tasks and generating reports related to bugs/tasks. An example of the Work menu for a project configured with process template "Microsoft Visual Studio Scrum 2013.3:

For every engineer requiring access to source code control there is a plethora of product managers, QA engineers, non-coding managers and other "stack holders" who require access to the functionality found under the Work menu. Add to this alpha and beta users that require bug creating capabilities and the cost used to be significant. As stated an unlimited number of such users can be added at no cost, simply assign the user to the free Stackholder license type (see below):

The previous screenshot shows user Keyser Soeze being converted from a Basic user (with source code access) to a Stackholder.

S. Somasegar (Corporate vice president of the Developer Division at Microsoft) wrote an excellent blog entry introducing this new feature of VSOL: Visual Studio Online - Stakeholder License

There is no free service comparable to Visual Studio Online that provides the following:
  • 5 free Basic users with access to source code and Work functionality (tasks/bugs)
  • Unlimited free Stackholder users with access to Work functionality (tasks/bugs)

Thursday, August 7, 2014

Managing the size of Screen Artifacts for High Resolution Displays

Most Windows users set the size of their screen artifacts (text and other displayed items) to small. For the case of a high resolution display, the icons on the screen (for example) would appear to be microscopic if a size of small were specified.  The article addresses how to manage the size of displayed elements.

Evolution: from a Behemoth CRT to 4K 39-inch LCD

A large number of developer remember paying $2000 for a 21-inch CRT style monitor. This leviathan of a tube-based monitor weighed eighty pounds and sported a resolution of 1600x1200. Within a few years, a large number of developers shelled out $2000 for a 1920x1200 24-inch LCD.

Comparatively, monitors are so cheap now they are almost free. The norm for a monitor now is a twenty-four inch LCD running at 1920x1080 albeit at about a 7% of the cost originally paid for such a monitor. If we take this resolution and double both the horizontal and vertical dimension we get 3840x2160 or a 4K monitor. A quality 39-inch 4K monitor is actually quite reasonably priced $339.

NewEgg, Walmart and Amazon (along with other merchants) sell Seiki’s SE39UY04 39-Inch 4K Ultra HD 120Hz LED TV at $339:

Seiki’s SE39UY04 is an excellent development monitor. I cannot critique it as a “gaming monitor” as I write code and rarely play games.

A 39-inch monitor 4K is not the only trend in high resolution displays. Microsoft’s Surface 3 Pro is a 12-inch screen at a resolution of 2160x1440. Both of these displays require that screen artifacts be set to larger versus small.

Managing the Size of Screen Artifacts

Windows is designed to handle this resolution by changing Control Panel | Appearance and Personalization:

From the Appearance and Personalization dialog select Make text and other items larger or smaller:

Clicking on Make text and other items larger or smaller shows the Display dialog:

For a standard 1920x1080 monitor, the value for “Change the size of all items” is typically set to Smaller. For the Microsoft Surface 3 Pro, the value for “Change the size of all items” is set as demonstrated above. For a monitor such as 39-inch 4K monitor. The value of “Change the size of all items” should be set to Larger.

The Caveat: You must logout for settings to take affect

On Windows 8.1 and Windows 8, changing the value of “the size of all items” requires a user to log in and log out in order to have the change in setting be recognized. This seems like an innocuous requirement, but consider a developer with a 39-inch 4K monitor at home running a half dozen applications (currently set to display large text). When he arrives at work, he uses remote desktop to log in to his home machine. His work monitor is 1920x1080. Under this level of resolution the text appears gargantuan. In order to make the screen readable, he has to change “the size of all items” which requires a log out and a re-log in. All the currently running applications will be exited (such as a long running debugging session that cannot easily be saved).