Windows PowerShell: Origin and Future

Awesome video. I honestly think that PowerShell is going to be as significant as .NET, C# and LINQ. Having gotten over the initial PowerShell learning curve some time ago I now find "cmd.exe" completely low-fi. The return on investment in learning PowerShell has been huge, it's been equivalent for me to first learning C# 6 odd years ago, or say basic regular expression syntax. Life is just unimaginable without it, indeed when talking to other developers I have to stop myself from incredulously saying "What?!? You're using cmd.exe, lame."

As a developer rather than a admin the thing I love about PowerShell is that it feels like coming home. It is ".NET at the prompt". It reminds me of those 8 bit days when you turned on your computer and had your command prompt / BASIC interpreter sitting right there. I guess 90% of my PowerShell usage is issuing file / reg / env queries - but then when I need to make use of the BCL it's right there. I'm already noticing that I write dramatically fewer "throw away / run once" C# console apps.

I just can't understand why .NET 2 and PowerShell aren't included in the UI-less skew of Windows Server 2008 out of the box.

Thanks for the interesting comment, dot_tom.

I'm interested to hear a little about how you learnt PowerShell. Did you force yourself to go "cold turkey" on cmd.exe? Did you use the book above or the reference card that comes with PowerShell? What's the first time you really found yourself saving time through the use of PowerShell? Was it easier or harder than you expected to make the transition? I'd love to hear your thoughts on these and other areas of the learning curve...

bdesmet wrote:

Hi Tom,

If you're referring to Server Core concerning the exclusion of .NET Framework and PowerShell in that release, the answer is the following. Because .NET Framework today has bindings with the Windows UI APIs (e.g. System.Windows.Forms) it isn't possible to include it with Server Core. I'm sure there are some other bindings too that make it impossible to include .NET Framework 2.0 with Server Core today but over time we might see refactoring and modularization of the .NET Framework itself, eliminating these kind of issues for a subsequent release of Server Core.

Hope this helps,
-Bart

Time for .Net Framework Core!   Seems to make sense anyway for the future to get that layer built in.  Then all the other framework versions will be built from that (e.g how CE builds).

Tim Sneath wrote:



Thanks for the interesting comment, dot_tom.

I'm interested to hear a little about how you learnt PowerShell. Did you force yourself to go "cold turkey" on cmd.exe? Did you use the book above or the reference card that comes with PowerShell? What's the first time you really found yourself saving time through the use of PowerShell? Was it easier or harder than you expected to make the transition? I'd love to hear your thoughts on these and other areas of the learning curve...

Hey Doc.  I used it (and still learning) since private beta.  I pretty much went cold turkey as I wanted to force myself as if you keep using cmd.exe, you don't get in the habit of psh - and to learn second hand, you need to use it over and over again.  I sometimes still need to use cmd.exe to test things or because things like VS pre/post-build cmd lines, scheduler, (etc), still use cmd.exe.  I already knew c# and the framework, so the object model was natural.  If you come from ksh, bash, or  csh you will have to "empty your cup" first, then learn psh - otherwise you will still try to use "string" operations and not get the whole object pipeline. 

The book is great.  Buy it, read it, love it.

Cool. Thanks again.  I just started using psh the other day for Post-Build jobs.  Have not been use post build because cmd is such a pain to script anything. But now with psh, it is real nice and easy.  Here is what I did below.  Now I get things like ProjectDir, TargetFileName, ConfigName, etc sent to psh script as parameters.  I can then use the params as needed (you can add more of the VS built in params if needed).

# File:   PostBuild.ps1
# Desc: Post-Build Powershell script template.
# Add following line to "Post-build event command line:" which will start this script:
# 1) powershell -command .'$(projectdir)postbuild.ps1' -targetdir:'$(TargetDir)' -targetfile:'$(TargetFileName)' -projectdir:'$(projectdir)' -configName:'$(ConfigurationName)'
# 2) Add this script as a template to your ProjectDir. Change as needed.
#
# For a library (i.e. snapin), you may also want Debug-Run (i.e. F5) support.
# Add that support to Debug tab in your project properties:
# 1) Add "Start external program": C:\WINDOWS\system32\WindowsPowerShell\v1.0\powershell.exe
# 2) Add "Command line arguments": -noexit -command add-pssnapin <SnapinName>; cd c:\<SnapinName>\bin\debug
# Now when you hit F5, a Powershell window will open and the pssnapin will be added. The snapin
# is registered in the Post-build script below so it should already be registered in Psh.

param($targetdir,$targetfilename,$projectdir,$configName)

# Change to build dir.
echo "Target: $targetdir"
cd $targetdir

get-banner "Build Config:"
get-banner $configName

# Build Xeno assem.
$xenoDir = "${targetdir}Xeno"
echo "XenoDIR:$xenoDir"
md $xenoDir
del $xenoDir\*
if ($configName -eq "Pro") { xbuild "${projectdir}xenoproject-Pro.postbuild" /passphrase "p" /o "$xenoDir" }
if ($configName -eq "Community") { xbuild "${projectdir}xenoproject-Com.postbuild" /passphrase "p" /o "$xenoDir" }
if ( ! $? ) {beep; "XENO FAILED."; return}

# Copy required files to Xeno dir.
copy $targetdir\*.xml $xenoDir
if ($configName -eq "Pro") { copy $targetdir\*CommercialLicense.txt $xenoDir}
if ($configName -eq "Community") { copy $targetdir\*CommunityLicense.txt $xenoDir}
copy $targetdir\ReadMe.txt $xenoDir

# Install snap-in
installutil "${TargetDir}Xeno\${TargetFileName}" -u
installutil "${TargetDir}Xeno\${TargetFileName}"
if ( ! $? ) {beep; "InstallUtil FAILED."; return}
else
{
    # Could start a powershell console after build. However,
    # a better method would be to use Debug option "Command line arguments:" and get F5 support.
    # invoke-item $pshome\psh.lnk # Example to start a powershell *.lnk that sets colors, buffer size, etc.
}
del $xenoDir\*.InstallLog
del $xenoDir\*.InstallState

# Create zip
if ($configName -eq "Community") { &"c:\Program Files\PACL\pacomp" -a $xenoDir\PowerLockerCv1.zip $xenoDir\*.* }
if ($configName -eq "Pro")  { &"c:\Program Files\PACL\pacomp" -a $xenoDir\PowerLockerPv1.zip $xenoDir\*.* }

get-banner "Done"
# End PostBuild.ps1

Now anytime I need Post-build logic, I can just add this file to the project and modify as needed.  I add the PostBuild.ps1 file to the Project and make sure the "Build Action" on the file is set to "None" and "Do not copy".  Then I just click on the file and edit it in VS and then click Build to run it.  Save a ton of manual steps after you get your build script working.

Output Windows then looks something like:
████  █   █  ███  █     ████         ███   ███  █   █ █████  ███   ███       
█   █ █   █   █   █     █   █       █   █ █   █ ██  █ █       █   █       █  
████  █   █   █   █     █   █       █     █   █ █ █ █ ███     █   █  ██      
█   █ █   █   █   █     █   █       █   █ █   █ █  ██ █       █   █   █      
████   ███   ███  █████ ████         ███   ███  █   █ █      ███   ███    █  

████  ████   ███ 
█   █ █   █ █   █
████  ████  █   █
█     █   █ █   █
█     █   █  ███ 

XenoDIR:C:\Documents and Settings\Administrator\My Documents\Visual Studio 2005
\Projects\PowerLocker\bin\Pro\Xeno
New-Item : Item with specified name C:\Documents and

<snip...>

Archive: C:\Documents and Settings\Administrator\My Documents\Visual Studio 2005\Projects\PowerLocker\bin\Pro\Xeno\PowerLockerPv1.zip
  preparing to compress...
  adding: C:\Documents and Settings\Administrator\M
████   ███  █    █ █████
█    █   █   █ ██  █ █    
█    █   █   █ █ █ █ ███  
█    █   █   █ █  ██ █    
████   ███ █    █ █████

I would like to see this support more deeply integrated into VS.  For example, the Pre-Build and Post-Build should allow option to use PSH instead of CMD.  If psh is selected, it would set all the VS parms automatically.  This would eliminate some stuff above and generally be a better experience imo.  Enjoy your builds.
--William

+1 for what dot_tom says. And +1 for the request for VS Orcas to allow Pre/Post Build events to be executed as PowerShell script. 

I've played with PowerShell since the early, early betas (post PDC 2003) and it has been my primary shell since September 2005.  I think the name is very fitting because it sets expectations appropriately.  PowerShell is very powerful but it takes a bit of investment to learn.  It is definitely not like your father's shell.  However that investment pays big dividends as you are then able to solve quite complex and/or tedious tasks with PowerShell very easily. 

I totally agree with Bruce on WMI.  It seemed mysterious and weird to me until PowerShell totally lowered the barrier to entry with Get-WmiObject.  Now I'm blown away by how much information there is about a computer in WMI.  Since then I've taken those PowerShell learnings and have used them in my production C# code.

As a .NET developer I really appreicate the REPL (read-eval-print loop) nature of PowerShell.  I rarely have to write one-off VS projects (ConsoleApplication42 anyone?) to experiment with some .NET type or formatting string.  This saves me quite a bit of time.  Most developers realize that to get ahead and set themselves apart from the average developer is to have mastered the right toolset.

I've said this before and I'll say it again, it strikes me as ironic that one of the most innovative products to come out of Microsoft in the past year is a new command line interface.

i love powershell... check out my humble blog: http://scriptingkid.blogspot.com

Very cool video. I'm becoming increasinly obsessed with PowerShell at work because it's a lot more fun than writing documentation and drawing diagrams.

psyphen wrote:

Very cool video. I'm becoming increasinly obsessed with PowerShell at work because it's a lot more fun than writing documentation and drawing diagrams.

Agreed.  You may find PowerPad and/or PowerLocker useful for your tool set.  http://www.powerlocker.com

Interesting video.  How do UI's feature in PowerShell...?

Recently I have been playing with a number of Windows Scripty/ish  things: Asim Jalis' CSBAT and Holger Schwichtenberg's DOTNET Scripting Host (DSH) as well as vbscript (WSH) and vbscript-based html applications which I am more familiar with.

The first two tools make it really easy to script C# or vb.net (DSH only) and you get pretty much the same speed as if you had used  Visual Studio or Jeff Key's SnippetCompiler or even csc.exe to create an exe.  However,  I'm not sure yet how to bring a full UI  on the scene without going for VS.
UI's  aside, they strike me as potentially very good ways to prototype - even if you have already come across Powershell. 

For vbscript or javascript, html apps can work quite well for UI's and
I wondered how UI's fit into or get utilised by Powershell.
In the video Bruce stated that Powershell can be used for UI's and I wondered how this is done.

Is there a powershell equivalent to html apps?
If not, are there standalone tools to design them?

Thanks for any comments / replies.

blue.

Well, it seems that unix/linux shells are going bye bye