ASCII Reinvented

31. July 2008 Andy Schneider Comments (1)

I mentioned earlier that I had told a colleague about using Hashtables in PowerShell and C#.  Later on in the afternoon, he came across a situation where he needed to generate a random string of characters.

He came up with this little snippet of code.  (I think he may have a been a little high on Hash . . . . . tables)

   1: function new-array {$args}                                                                                        
   2: $CharacterArray = new-array A B C D E F G H I J K L M N O P Q R S T U V X Y Z;                                    
   3: $CharacterHashTable = new-object System.Collections.Hashtable                                                                                                                                                                     
   4: for ($i=0; $i -ilt $CharacterArray.Count; $i++) {$CharacterHashTable.Add($i, $CharacterArray[$i])}                
   5: $randomNumber = new-object System.Random                                                                          
   6: $randomCharacter = $CharacterHashTable[$randomNumber.next(0,25)]

"Wow!  That is great!  You basically reinvented ASCII !"

Then I showed him this neat little trick :)

   1: PS >  [char]65
   2: A

He came back with these two lines to generate a random character.

   1: $randomObject = New-Object System.Random
   2: $randomChar = [char]$randomObject.next(65,90)

It turns out that if you know ASCII exists, it can indeed be used to generate random characters :)

However, I have to give some credit for coming up with a neat little subset of ASCII in a couple lines of PowerShell. Not too shabby!

Using PowerShell to Demo C# and .NET

30. July 2008 Andy Schneider Comments (4)

I have an intern working with us and he is writing some PowerShell and C# WinForms to automate some of our administrative tasks. He had a problem with a C# app and when he started asking me about it, it sounded like a hash table was just what the doctor ordered.

He had seen hash tables in PowerShell but wasn't quite sure how they would work in C# (he had only cracked open C# maybe 5 weeks ago). Rather than firing up Visual Studio and typing in a bunch of "blah-blah/yadda-yadda" I was able to demo a "C# version" of hash tables in PowerShell.

Once he saw this, he was able to understand how to use hash tables in C#.  

   1: 268 >  $hash = New-Object System.Collections.Hashtable
   2: 269 >  $hash.Add("one",1)
   3: 270 >  $hash
   4:  
   5: Name                           Value
   6: ----                           -----
   7: one                            1
   8:  
   9:  
  10: 271 >  $hash.one
  11: 1
  12: 272 >

I just love how PowerShell is continuing to bridge a gap between Developers and Admins. These are obviously different disciplines and both require different skills, but the more we can learn about each one, the more effective we can be in our respective roles.

Editing Web.Config Files with PowerShell

29. July 2008 Andy Schneider Comments (5)

A couple days ago, a colleague of mine (who is a recent PowerShell convert) asked me if there was some cool way in PowerShell to update a web.config file based on the particular environment that the app was being deployed to (dev, test, or production)

I went in to this knowing config files are just XML files and I also knew that PowerShell can do some pretty cool work with XML and I figured there must be a way.

I found a great article called Deployment made simple using Powershell by Omar Al Zabir up on Code Project.

He has a script that does a number of things, but what I was particular interested in was changing the database connection string in a web.config file.

Luckily, Omar had the answer.

I tweaked it a bit and came up with the following:

   1: #Code to update a connection string on a web.config file –yes this can be used to change a lot more stuff too J
   2:  
   3: #Set the Connection String and the path to web.config (or any config file for that matter)
   4: $connectionString = "Data Source=old-db;Initial Catalog=mydb;Integrated Security=True;User Instance=True"
   5: $webConfigPath = "C:\Inetpub\wwwroot\myapp\web.config"
   6: $currentDate = (get-date).tostring("mm_dd_yyyy-hh_mm_s") # month_day_year - hours_mins_seconds
   7: $backup = $webConfigPath + "_$currentDate"
   8:  
   9: # Get the content of the config file and cast it to XML and save a backup copy labeled .bak followed by the date
  10: $xml = [xml](get-content $webConfigPath)
  11:  
  12: #save a backup copy
  13: $xml.Save($backup)
  14:  
  15: #this was the trick I had been looking for
  16: $root = $xml.get_DocumentElement();
  17:  
  18: #Change the Connection String. Add really means "replace"
  19: $root.connectionStrings.add.connectionString = $connectionString
  20:  
  21: # Save it
  22: $xml.Save($webConfigPath)

The one thing I added was the backup copy by saving the current file with the current date and time appended to the end of the file name.

So next time you are tempted to edit a config file with notepad, open up the shell and take a whack at it.

Credentials in the Console

23. July 2008 Andy Schneider Comments (2)

A while back on the Windows PowerShell Team blog, there was a post that describes how to force Get-Credential to prompt for a username and password in the console itself rather than popping up a Windows dialog box asking for a username and password.

The change is a key in the registry, and is permanent, unless of course you change it back to the original setting. The other minor complaint was that the there was no space between where the user needs to type a username and password, and the text prompting for the text.

   1: 119 >  $c = Get-Credential
   2:  
   3: cmdlet Get-Credential at command pipeline position 1
   4: Supply values for the following parameters:
   5: Credential
   6: PromptForCredential_UserAndy
   7: PromptForCredential_Password********
   8:  
   9: 120 >

You can see that the "PromptForCredential" and my username - "Andy" just run together. 

You can accomplish this another way with much more control over the user experience and you don't have to hack the registry.

So here is my quick and dirty function. I put in a very basic check to see if someone added their domain or not, and added it if necessary.

   1: function Get-Cred {
   2:     Write-Host "";
   3:     $username = Read-Host "Enter username to access some resource (no domain required)"
   4:     if ($username -notlike "MYDOMAIN\*"){$username = "MYDOMAIN\$username"}
   5:         
   6:     Write-Host ""
   7:     $password = Read-Host  -AsSecureString "Password to access some resource"
   8:     
   9:     $credential = New-Object System.Management.Automation.PSCredential($username,$password)
  10:     return $credential
  11: }

And here it is in action:

   1: 130 >  $cred = Get-Cred
   2:  
   3: Enter username to access some resource (no domain required): andy
   4:  
   5: Password to access some resource: **************
   6: 131 >
   7: 131 >  $cred.GetNetworkCredential() | fl *
   8:  
   9:  
  10: UserName : andy
  11: Password : secretpassword
  12: Domain   : MYDOMAIN

Check a file into Team Foundation Server with PowerShell

14. July 2008 Andy Schneider Comments (1)

We have recently started using Microsoft's Team Foundation Server for our projects. We are using SCRUM for our infrastructure projects (which has been an interesting learning endeavor and quite possibly deserves a blog post of its own sometime in the future)

Anyway, on the infra side, we typically don't use source control.  We use TFS mostly to manage our tasks for each sprint and our backlog items. However, we are starting to use PowerShell more and more in our build guides and giving our ops team PowerShell Scripts for deployments. Its only a matter of time until we will become just as dependent on Source Control as our development team is.

So I figured I would check into this. TFS actually has quite a nice little API that you can use with any .NET language, and so I started looking to see if I could use PowerShell to check in a script. Looks like its not that hard.

You need to install the Visual Studio 2008 SDK to get at the TFS assemblies, but that is not too hard.

In the SDK there are a few example solutions written in C# that show you how the basics for interacting with the API. I used the "VersionControlExample.cs" file and worked on re-writing some of it in PowerShell.

So here is my first crack at New-TFSItem

   1: param (
   2:     [string]$tfsServer = "TFSServerName",
   3:     [string]$tfsLocation = "$/TFS/Project",
   4:     [string]$localFolder ="c:\scripts",
   5:     [string]$file,
   6:     [string]$checkInComments = "Checked in from PowerShell"
   7: )
   8: $clientDll = "C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\Microsoft.TeamFoundation.Client.dll"
   9: $versionControlClientDll = "C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\Microsoft.TeamFoundation.VersionControl.Client.dll"
  10: $versionControlCommonDll = "C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\Microsoft.TeamFoundation.VersionControl.Common.dll"
  11:  
  12: #Load the Assemblies
  13: [Reflection.Assembly]::LoadFrom($clientDll)
  14: [Reflection.Assembly]::LoadFrom($versionControlClientDll)
  15: [Reflection.Assembly]::LoadFrom($versionControlCommonDll)
  16:  
  17: #Set up connection to TFS Server and get version control
  18: $tfs = [Microsoft.TeamFoundation.Client.TeamFoundationServerFactory]::GetServer($tfsServer)
  19: $versionControlType = [Microsoft.TeamFoundation.VersionControl.Client.VersionControlServer]
  20: $versionControlServer = $tfs.GetService($versionControlType)
  21:  
  22: #Create a "workspace" and map a local folder to a TFS location
  23: $workspace = $versionControlServer.CreateWorkspace("PowerShell Workspace",$versionControlServer.AuthenticatedUser)
  24: $workingfolder = New-Object Microsoft.TeamFoundation.VersionControl.Client.WorkingFolder($tfsLocation,$localFolder)
  25: $workspace.CreateMapping($workingFolder)
  26: $filePath = $localFolder + "\" + $file
  27:  
  28: #Submit file as a Pending Change and submit the change
  29: $workspace.PendAdd($filePath)
  30: $pendingChanges = $workspace.GetPendingChanges()
  31: $workspace.CheckIn($pendingChanges,$checkInComments)
  32:  
  33: #Delete the temp workspace
  34: $workspace.Delete()

There's probably a cool way to programmatically figure out where the dll's that need to be registered are, but I leave that as an exercise to the reader :)