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 http://soinoticedthis.blogspot.com/ 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: " + 
    $MyInvocation.ScriptName);
  Write-Output("Function invoked `$MyInvocation.Path: " + 
    $MyInvocation.MyCommand.Path);  
}

Write-Output("Script invoked `$MyInvocation.ScriptName: " + 
  $MyInvocation.ScriptName);
Write-Output("Script invoked `$MyInvocation.Path: " + 
  $MyInvocation.MyCommand.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:

$MyInvocation.MyCommand.Path  

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

$MyInvocation.ScriptName

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).

Thursday, July 10, 2014

Visual Studio Online (cloud hosted TFS): Deleting a Team Project

I often create temporary projects to test automating the build. The test projects ultimately need to get deleted which is where TFSDeleteProject comes in (Delete a team project [TFSDeleteProject]). The command-line to delete a Visual Studio Online project is as follows:

TFSDeleteProject /collection:https:/<your vanity name here>.visualstudio.com/DefaultCollection "your project name"

In a previous posting, Visual Studio Online was subscribed to  using the vanity URL, admiralgracehopper.visualstudio.com. Using TFSDeleteProejct to delete a project named ATestProject from admiralgracehopper.visualstudio.com would be handled as follows:

TFSDeleteProject /collection:https:https://admiralgracehopper.visualstudio.com ATestProject

Tuesday, July 8, 2014

Visual Studio 2013 now supports Installer Projects

Desktop applications and Windows Services have relied on Visual Studio's installer projects. The installer projects (to state the obvious) allowed an installer to be created for an application. This reliance on installer projects lasted until Visual Studio 2012 when Microsoft ceased supporting installer projects.

On June 15, 2014, Microsoft released version 1.0.0.0 of Microsoft Visual Studio Installer Projects. To quote Microsoft's download web page, "This official Microsoft extension provides support for Visual Studio Installer Projects in Visual Studio 2013."

Subsequent to this, developers who had moved to Visual Studio 2012 or Visual Studio 2013 were forced to use Install Shield Limited Edition or WiX in order to create installers for "desktop applications" (non-store applications). Another approach to delivering installer projects was to build code in Visual Studio 2013 and create the installer projects using Visual Studio 2010.

There is a blog with regard to Visual Studio and specifically Visual Studio Installer Projects Extension. Numerous comments under this blog ask whether the installer projects extensions work with Visual Studio 2012. That remains to be seen -- for those unable to move from Visual Studio 2012 to Visual Studio 2013.

Wednesday, June 4, 2014

Getting Visual Studio 2010 SP1 to run on Windows 8 and Windows 8.1

A variety of projects I work on still require Visual Studio 2010 which is patched with SP1. Most machines I worked on are Windows 8.1 because Windows 8 and above supports 64-bit virtual machines under Hyper-V (the most critical feature for developers under Windows 8).

By default Visual Studio 2010 with SP1 may not run on Windows 8 or Windows 8.1. Microsoft provides a patch that allows to execute on said operating systems: Update for Microsoft Visual Studio 2010 Service Pack 1 (KB2736182).

Microsoft does provide an overview of the previous patch and the issues it addresses: A GDR update for Visual Studio 2010 SP1 is available to add compatibility support for Visual Studio 2012 and Windows 8.

Wednesday, April 23, 2014

Access 2013: Protecting the Programmatic Elements of a Database

This posting presents ways to protect an Access database so that users cannot edit the underlying database. This means a user should not be able to edit the VBA code, reports and forms of an Access database. The user should be able to run the database. Additionally, the user should not be able to edit the underlying tables.

Convert Database to Execute-Only Mode


The most straight forward way to project an Access database (*.accdb file) is to save it as an executable, namely a file with an accde extension. This is achieved by selecting Save As from access and saving the *.accdb file with an *.accde extension as follows. An example of Access 2013's Save As dialog is as follows:




Once the accde file type has been select, click on the Save As button.

The standard file extension (referred to as an Access 2007 file type) is *.accdb. This extension replaced the *.mdb extension used by per-Access 2007 versions of Access. The *.accde extension is also a valid Access 2007 extension. When a file is saved as *.accde, the file is in execute only mode. An Access database in execute only mode the following behavior:

  • The VBA code is compiled and not included in the distributed database
  • Forms cannot be modified
  • Reports cannot be modified.

Even though the Access database is converted into an executable (*.accde extension), a copy of Access is still required to run the file.

Access Runtime

It is possible to distribute an Access application without requiring Access to be physically installed. From a cost stand-point this is a tremendous savings. It also means that user cannot directly access the tables and queries of the underlying database, since Access is not installed. This does not prevent them from installing Access.

Executing an Access application without requiring Microsoft Access is achieved using the Microsoft Access Runtime found at: Microsoft Access 2010 Runtime. The Access Runtime can run database with either an *.accdb or *.accde extension.

The runtime means that the application will but a user will not have access to the design related toolsbut the Access project will execute.

Runtime Behavior on a Machine on which Access is Installed


It is possible to determine how an application behaves when running under the Access Runtime even if Accss is installed. The Access application (MSAccess.exe) supports a command line option, /Runtime. specifying the /Runtime options means Microsoft Access will run an Access application as if the application were running under the Access Runtime.

For example using full Microsoft Access 2013 it would be possible to run fun.accdb as if it was running under the Access Runtime using the following command:

"C:\Program Files\Microsoft Office 15\root\office15\MSACCESS.EXE" fun.accdb /Runtime

It would also be possible to run an Access executable such as fun.accde as if it was running under the Access Runtime using the following command:

"C:\Program Files\Microsoft Office 15\root\office15\MSACCESS.EXE" fun.accde /Runtime