Scott Hanselman & Jeffrey Snover Discuss Windows PowerShell

Download this episode

Download Video

Description

Learn how Scott Hanselman and the Corillian Corporation leverage Windows PowerShell to simplify and automate financial application management. This chat between Scott of Hanselminutes.com fame and Jeffrey Snover, Architect of Windows PowerShell and MMC, ranges from strengths and weaknesses of Windows PowerShell, how developers can easily extend Windows PowerShell to solve business problems or just explore the .NET framework, to Kierkegaard, black vs. white cats, the meaning of a Hanselminute, importance of application frameworks, and also a discussion of strongly vs. non-strongly typed languages. This chat also reveals the importance and simplicity of script blocks to the architecture of Windows PowerShell.<?


When you're done viewing this chat, download and install Windows PowerShell and check out the Windows PowerShell SDK.

Embed

Format

Available formats for this video:

Actual format may change based on video formats available and browser capability.

    The Discussion

    • User profile image
      staceyw

      Good vid guys.  Random need here I have been bumping into.  I find myself more and more needing psh in VS.  VS needs to be "powershellized" at the core (from external commands to profiles to post build to other).  The default load should have a profile, each solution should have a profile, and possibly each project. snippets could be converted to psh functions and the shortcut names will be aliases.  A whole new class of usability will explode.  I mean add-ins like ZipStudio that zip a whole solution would become bone simple if VS was psh enabled.  Vive la VS cmd gadgets!

    • User profile image
      staceyw
      Nother question.

      How is he doing this {}.RemoteInvoke("string") thing?

      Not the actual remoting, but how is he tacking on "RemoteInvoke" method to the script block object and have psh call it?  Is this setup in the profile?  Please advise.  TIA
    • User profile image
      jsnover
      > How is he doing this {}.RemoteInvoke("string") thing?


      In PowerShell, you can add methods or properties to any object or object type.   You can see how this works by doing the following:

      PS> notepad $pshome/types.ps1xml
      PS>

      This is an XML file that gets loaded upon PowerShell startup.  You can create your own file and import your extensions using the Update-TypeData cmdlet.

      Scott created a file which added the RemoteInvoke() method on the ScriptBlock type so when you include his stuff, every scriptblock now as this method.  When you call it, PowerShell dispatches the method to his code which implements the function.  

      This is one of the most powerful features of PowerShell.

      Jeffrey Snover [MSFT]
      Windows PowerShell/MMC Architect
      Visit the Windows PowerShell Team blog at:    http://blogs.msdn.com/PowerShell
      Visit the Windows PowerShell ScriptCenter at:  http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx
    • User profile image
      nektar
      Nevertheless, Powershell has some weaknesses that should be addressed:
      1. Consistency: Powershell was built to be consistent and yet object property names are often not. The process object uses processname but company not companyname, i.e. some properties have name in them and some don't. This happens with many objects and not only that. It seems to me that object properties could be made more consistent.
      2. What you think you type? Think again. Powershell was built to simplify management by the use of a set of similarly named objects using a verb-noun pattern. And yet in Powershell many management tasks require using WMI and COM and etc which is a mess and not at all "what you think is what you get". If WMI is needed for everything, then we lose the easy syntax of Powershell.
      3. COM clean-up: Create a COM object in Powershell such as Internet Explorer or Word. How do you clean it up. The COM reference is not released and setting the variable equal to $NULL does not change anything.
      4. Language documentation is not adequate: When do you use square brackets and when round ones in variables? When a comma, etc? Why does where require a script block? Why was the pipeline object named $_ which is difficult to type instead of $$ which would have been easier? Why do I need to specify $_ in a where script block anyway? Can't it be assumed? And many more. There are many language design questions are not answered in the documentation and some language featured are not clearly explained.
      Overall, however, congratulations for the new power shell.
    • User profile image
      jsnover

      Thanks for the thoughtful feedback - it was precise and helpful.

      > 1. Consistency: Powershell was built to be consistent and yet object property names are often not. The process object uses processname but company not companyname, i.e. some properties have name in them and some don't. This happens with many objects and not only that. It seems to me that object properties could be made more consistent.

      Absolutely correct.  While .NET is substantially more consistent than previous efforts, it still has inconsistencies such as this.  This is one of the reasons that PowerShell extends the .NET type system.  Look what happens when you ask for the names on Processes:

      PS> get-process |Get-Member *Name*


         TypeName: System.Diagnostics.Process

      Name            MemberType    Definition
      ----            ----------    ----------
      Name            AliasProperty Name = ProcessName
      ...
      ProcessName     Property      System.String ProcessName ...

      We have produced a property alias which maps Name to ProcessName.  This allows us to address the inconsistencies of .NET.  As a user, you can take advantage of this feature yourself adding additional properties, methods, etc to objects and object types.  It is an incredibly powerful aspect of PowerShell.


      > 2. What you think you type? Think again. Powershell was built to simplify management by the use of a set of similarly named objects using a verb-noun pattern. And yet in Powershell many management tasks require using WMI and COM and etc which is a mess and not at all "what you think is what you get". If WMI is needed for everything, then we lose the easy syntax of Powershell.
      This is a coverage issue.  Cmdlets represent the best user experience but we knew that it would take years before we had complete coverage.  We decided to provide access to things like COM, WMI, ADSI, .NET, etc even though they did not provide the level of abstarction we wanted to provide our users.  What they do is 1) ensure that you can always do what you need to do and 2) allows you to create the right level of abstractions for others using Scripts.


      > 3. COM clean-up: Create a COM object in Powershell such as Internet Explorer or Word. How do you clean it up. The COM reference is not released and setting the variable equal to $NULL does not change anything
      Setting it to $NULL deferences it but the object will continue to exist until the garbage collector (GC) disposes it.  You can control this yourself but as a general rule, it is best to let the GC handle it.

      > 4. Language documentation is not adequate: When do you use square brackets and when round ones in variables? When a comma, etc? Why does where require a script block? Why was the pipeline object named $_ which is difficult to type instead of $$ which would have been easier? Why do I need to specify $_ in a where script block anyway? Can't it be assumed? And many more. There are many language design questions are not answered in the documentation and some language featured are not clearly explained.
      Yup.  There are a number of books now available on PowerShell that fill this gap.  Bruce Payette, the developement lead on the language, as a great book focused on the language coming out this month.  It is called PowerShell In Action. 

      Jeffrey Snover [MSFT]
      Windows PowerShell/MMC Architect
      Visit the Windows PowerShell Team blog at:    http://blogs.msdn.com/PowerShell
      Visit the Windows PowerShell ScriptCenter at:  http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx



    • User profile image
      staceyw
      "1. Consistency: Powershell was built to be consistent and yet object property names are often not. The process object uses processname but company not companyname, i.e. some properties have name in them and some don't. This happens with many objects and not only that. It seems to me that object properties could be made more consistent."

      Those type of objects are .Net objects that already have well-known contracts.  You really can't go renaming every property as a whole class of .Net programmers would be lost and the cure would be worse.  The alias property is probably a good compromise.

      "2. What you think you type? Think again. Powershell was built to simplify management by the use of a set of similarly named objects using a verb-noun pattern. And yet in Powershell many management tasks require using WMI and COM and etc which is a mess and not at all "what you think is what you get". If WMI is needed for everything, then we lose the easy syntax of Powershell."

      You want those abstractions available to you when you need to go deeper, just like in c# you sometimes need pinvoke.  I agree they need more management abstractions in psh and so does .Net BCL.  So in some ways, I am not sure this is PSH's issue to fix; in other ways they should provide the spackle.  I also never really liked working with late binding in wmi, probably because strong types in .net are so nice.   I think things like LINQ will help drive some design in this area, as the dry areas will become even more obvious when you want to Linq everything.
    • User profile image
      someone
      How much ever MS does for automation/scripting/administration, all their efforts are directed towards developers. What about newbies who dont want to learn the command or scripting syntax? With the introduction of .NET, MS now focus even lesser on WSH. Will Windows users someday see something like Automator on the Mac so the average Joe can automate stuff? So far I've found http://www.scriptahead.com and http://www.automise.com quite similar, but at $400+, they're out of reach of average users.
    • User profile image
      burstingfist

      Check out this sweet PowerShell GUI.  Really great for learning PowerShell

    • User profile image
      ZippyV
      Why is Powershell still not available for Vista?
    • User profile image
      Yankee
      It is available...

    Comments closed

    Comments have been closed since this content was published more than 30 days ago, but if you'd like to send us feedback you can Contact Us.