DesignAndCode software development thoughts..

During the last year, I have come across a few projects that I would like to download and experiment with; the stopping point has been that they use the SCM tool - Git. A comment from a recent DeepFriedBytes podcast with Jeremy Miller indicated that many Windows developers seem to use Mercurial, and that other developers (non windows being implied?) use Git.  I have used TortoiseSVN successfully, but the start-up story with Git does not appear to be  "straight forward". During the DeepFriedBytes  podcast, there was mention of using Powershell with Git - which I had seen mentioned in Ayende's blog (He wrote Rhino-Mocks, RavenDB, and a book on DSLs in Boo). So this post is to collect some research items on how what these two source control packages are and the setup dependencies they require.

As I stated at the start - my impression of Git is that it is not straight forward to get started with; Whereas Mercurial seems to be very simple to use and is supported on Codeplex. The Mercurial association with Codeplex alone, would make it be preferred by Windows developers. Codeplex works with TFS(Team Foundation System),Subversion, and Mercurial. There is a Free TekPub video demonstrating how to use Mercurial on a Codeplex project ( Tekpub has  a full Mercurial training course of 3 hours for about 20 dollars).

In listening to a podcast  - This Developers Life episode on Pressure - The Stackoverflow team discussed many things and one point they touched on was  - they went to Mercurial - and decided against using Git. The decision to use Mercurial for them was more of a workflow issue that they needed within the Stackoverflow teams shared working process.

Git - being a command line tool - has attracted some development tools to make it simpler - TortoiseGit, and Posh-Git(Powershell enabled Git). There was a series of posts on the topic of Powershell and Git by Mark Embling

• Git Environment on Windows from Jan 2010 - is a good place to start
• Git and Powershell Revisited from March 2010 - more learning on how to get them to work
  

In 2008, I attended the Microsoft Professionals meeting (Atlanta) where Shawn Wildermuth gave a presentation on Domain specific languages or DSL's. The concepts were an introduction into a Microsoft product development that used the code names   "OSLO",  "M", and "Quadrant" that was previewed in part at the PDC2008 (Professional Developer Conference) which has mostly morphed into something else by PDC2009. Shawn produced three articles for MSDN on the topics of "OSLO" and "M". In the 2008 presentation I attended, Shawn introduced the premise that we use DSL's already today; SQL, XAML, Make, Ant/Nant, MSBuild, regular-expressions, even musical notation are all examples of DSL's. From that talk, the idea of software development DSL's  was planted - even though the technologies that had prompted his discussion have been morphed into new forms within Microsoft - the conclusion  from this argument is that a set of text statements ( or specific symbols like music or regular expressions) can be declared and used to achieve a desired result - and within programming - results in how executing code processes those results. A concise grammar and syntax, that declares what you want to do but not how you do accomplish that - regular expression syntax is a great example. Software development using a DSL, is an idea that continues to cross my path. I thought I would try to capture some of the variations I have seen in how various developers and architects approach the concept of creating and using DSLs.

Martin Fowler wrote the book on Domain Specific Languages where he describes the 3 types of DSLs.
There are some early Oslo software preview videos out on the Microsoft site that show the language M being used to generate a DSL grammar within the tool called Quadrant. This is what Martin Fowler referred to as a "DSL workbench"- where the tool builds the DSL. Martin Fowler identified two other main categories of DSL; the External DSL, and the Internal, or Embedded DSL. External DSL's are often quite complex - and rarely come to general usage. Internal, or Embedded DSL's are abstractions over an API, or framework, within an application.

The idea of a DSL being used was briefly touched on in the Jan 2009 DotNet Rocks episode with Aslam Khan a software architect that lives in South Africa. The company he works with uses this to achieve Domain Driven Design (DDD). "Write a story that describes a problem", and understand that little piece, to understand the domain. "Something that describes it completely - that does not bleed into the other", which build up a dependency graph, it exists in context to the other things - behind each story. A story about the problem - the domain. The more you reveal incorrect assumptions in the dependency graphs and correct them, you don't have to prune source code trees -so you get smaller source code trees, and designing API's around the stories - means changing the granularity of the stories - not modules. In the podcast (just after 38:41) they describe a misunderstood story - that would have produced an incorrect system design - but writing out a story, that the users can understand - allows for corrections can be made before hand. Understanding the user's vocabulary, and you can write it in those terms, then you have the basis to build on(this goes back to the Eric Evan's Domain-Driven-Design "ubiquitous language"). It helps other people later on to understand the language of the application. Aslam Khan uses a Wiki to capture that language - and refers to the "Wiki as code" (about 44:44 in the podcast). He refers to it as "a DSL captured in business terms - that cannot be executed - but at that point you can start writing code". After listening to that podcast(in 2009), I went to Aslam's website - and discovered his posting about using Cucumber and driving it down into Rspec. That led to my reading of a post about Ruby and the latest on Ruby testing - using cucumber. (There is a language called Gherkin used with Cucumber to create a Ruby testing framework). The dynamic nature of Ruby - and the concept of Metaprogramming - became connected to the idea of how one could produce a DSL. Aslam Khan stated it, on his blog, as "the Code is the data" behind a DSL, and he encouraged learning about AST's (Abstract Syntax Trees) which to me connected directly to .Net Expression Trees - the basis of Microsoft Dynamic Language Runtime(DLR) in .Net 4.0.  DSL's can become Expression Trees which in turn can become running code in the DLR. At least, in theory, that would be one Dynamic-Language approach to implementing a DSL(There may be some limitations on how that can occur).
 
During 2010, I picked up a copy of Orin Eini's(a.k.a Ayende Rahein) book called "DSL's in Boo - Domain Specific Languages in .Net". (he did an interview in March 2010 with DotNetRocks on this topic).Ayende is known in the .Net development world for RhinoMocks( a mocking framework), his work on NHibernate(his company makes a profiler for NHibernate and EntityFrameworks), and now his RavenDB - document database project. Somehow, he also managed to have written a book on DSL's   - the guy is prolific at producing content - whether you see his coding output(RhinoMocks,RavenDB), his blog, and now his book.  In his book, he describes how he builds his own DSL's using the .Net language Boo as the foundation, as it gives him a parser,lexer, and great extensibility points, that compile into .Net code - that is not based on the DLR. He shows how the Boo language allows for defining your own expressions that can then be compiled - statically.  Boo is based on the released ECMA standard for the CLI. Interestingly -both the Boo Language, and the ECMA CLI standard, had recent updates(at this writing) Boo 0.9.4 was updated Jan 2011, and the ECMA Standard December 2010. Boo has some capacities that make the language very powerful. It can be an object oriented language, and it can do functional composition (where functions are first class citizens like those in F#), it has 'Syntactic Macros', and it has an extensible compilation pipeline - which is what the creator, Rodrigo B. de Oliveira, wanted to have in the first place, and it can run on multiple platforms (Windows CLR and Linux Mono). Boo has its roots  based on Python Syntax and looks like it has some great potential.  To use Boo that as the basis for creating a DSL seems like a very interesting choice - here it would be a statically typed implementation of a DSL. This could be a way of generating a concise Internal, or External, DSL that works for the users and programmers alike within a given domain. Ayende's book gets into the details of using boo for creating your own DSL.

I found a few entries that related how Powershell could be used at the basis of a DSL. There is a blog post from Keith Hill on how Powershell's syntax flexibility allows you to create a internal DSL. Doug Finke, a Powershell MVP, posted something that went back to the Oslo starting point from a Powershell point of view. Doug Finke shows implementing an OSLO grammar syntax using Powershell, based on the concepts originally introduced in that early video of the M Language example. So from Dynamic Languages or Scripting tools we can find approaches to creating DSL's today.  Doug Finke connected the concepts of DSL, DRL, and Boo; all the ideas together in his post "Creating a unified programming model on top of .NET" He cites "Trends and Directions in programming languages" from Anders Hejlsberg.  DSL's could certainly be part of that mix in creating solutions.

Jeffrey Snover, the architect of Powershell, had a discussion in 2008 on DSL's with Martin Fowler and Neal Ford from Thoughtworks. (recording on Channel9). In this talk they made the point that a DSL can be an External DSL, an Internal DSL or a 'workbench' with tools wrapped around it. Martin Fowler made the point that not many successful DSL's have been done starting from the business side and working toward the API - but that is where the concept is the most powerful, they made the point that it is usually an abstraction of an existing API that simplifies the underlying API - and that DSL can be replaced with the word 'Framework' and mean the same thing. Jeffrey Snover also posted that Powershell could be used to create DSL's by limiting the syntax. The key piece he refers to is the data segment SupportedCommands - which he alludes to as a way to limit a DSL done in Powershell.

Karl Prosser referred to the Powerboots library for Powershell as a DSL in a blog post. It is a Powershell set of commands that are specific to using WPF from within Powershell - which stays with the concept that it  is limited to that specific domain.

Sometimes the use of a Fluent API - can be used to write code that is very readable and expressive - such that it becomes an internal DSL within the general purpose language(Steven Hoisee blog has some coverage on this).  I came accross a paper on how JMock was developed and how they worked toward incorporating a Fluent API as part of their own Embeded DSL within the framework.

Martin Fowler, who took the time to write the book on DSL, has a post on BusinessReadableDSLs. Where the idea is different than business-writeable DSLs. That was the impression I got from Aslam Khan's use of Cucumber - that the business could read the DSL and confirm if it was correct or not.
Martin Fowler invokes the comparison to COBOL - which was supposed to be an english way of telling the computer what to do - and begs the question - how is this one different?  My impression is that the a correct implementation of a DSL is declarative - it describes what you want to do, now how you do it - and having programmed in COBOL - it is an imperative approach, not a declarative one.

Developing a DSL, based on the Jeffrey Snover video, leads me to see that in a DSL you have vocabulary and you have grammar that must be decided on - and the idea of keeping it small seems to be important. Just enough to keep and simple - and no simpler.

Jeremy Miller(Creator of the IOC container - StructureMap, an MVC framework called FubuMVC, and a testing tool called StoryTeller) did a presentation on creating Internal DSL's at Oredev in Oslo - Nov 2010.
He  contributed to the Fluent NHibernate project, and incorporated the use of an Internal DSL in these projects - and in the presentation he goes over some of the difficulties of using and developing an Internal DSL using the C# 3.0 language features. He touches on the separation of the Runtime and Configuration model in building a DSL, and that testing an internal DSL for configuration is very difficult - you can test the runtime model more easily, and then make sure your configuration model works correctly. (the video is a bit grainy - and a few of the questions, that came from the audience, are not heard - but the concepts that were used in creating an internal DSL are shown pretty well.)

From this set of touch points - on the various flavors of DSL's, it is something that can be done in a variety of ways. The simplest form is the internal or embedded, perhaps as a Fluent API approach. This simple form of a DSL can be for a small team that produces repetitive code, or business rules that are needed in in either a static or dynamic fashion - but still being an internal abstraction - within a small domain. Then there is an external DSL - and that would need to have a the same considerations as a full blown computer language - as the publishing of an External DSL approach tends to get the syntax set in stone, unless you can absorb breaking changes later on. 

I find this an interesting research topic, that may prove to be a practical solution to some future area of work. Along these lines - I recently purchased a book that looks promising; Terrence Parr's book "Language Implementation Patterns - Create your own Domain Specific and General Programming Languages". Terrence Parr developed  ANTLR and that tool is used in the Boo compiler.  I will have more reading and learning to do in this area - and, perhaps at some point, the payoff will be when I can see an area where a DSL can be used to invoke parts of a framework. Ideally this would be in terms of the users, a readable Business DSL, or an API syntax that developers for an application can use that brings a higher level of abstraction and makes code more readable - and perhaps more declarative.  The Jeremy Miller video shows that is not a simple task, however, he shows that it can be used to develop some powerful solutions too, and that I find to be valuable.

The September meeting of the Atlanta Powershell User group was to be about Scripting GUI with PowerShell. Mark Schill, the leader of the group, indicated that if no one else  volunteered,  he would do it. The September meeting was cancelled due to the short time allowed for the topic, and I asked if anyone had volunteered. No one volunteered, and the topic was one I was interested in - so I volunteered for the October meeting presentation on Scripting GUI with PowerShell. This post reflects the research I did for the presentation.(Apologies to the group for posting this weeks after the presentation).

A "Graphical User Interface" or GUI, is to present a Graphical window to display data visually, or gather information from direct user input. Doing this from script means that it is not compiled into a frozen format, and that gives you  flexibility to change things quickly without recompiling a standalone program.  If you are providing your script for someone else to use - and they are more comfortable with point and click - creating a GUI is in one way to bridge that gap. If you are trying to isolate what a user can do within Powershell - building an application with the Powershell SDK as a standalone program might be a better option; but that also would be freezing the presentation format. With Powershell this is great - as you have options, and the issues are - that you have options - you have to figure out what you are trying to accomplish, and how, if you even want PowerShell script run with a GUI interface you have lots of options.

One key thing to point out is that, using version 2, Powershell console and the Powershell_ISE work differently in their execution threading model (this goes back to COM components and how they deal with threads) - that impacts doing a GUI  as there are Windows components that require a Static Threaded Aparment (STA) model, and will have issues with Multi-Threaded Apartment (MTA). Powershell console,  by default, is an MTA application - each command is its own thread. Powershell ISE by default uses an STA model. You can force Powershell console to start with the STA mode by adding a parameter -STA on the command line. Create a shortcut with the -STA parameter if you are planning on using the Console to spin up a GUI. Your other option is to run powershell from within powershell on an STA thread - Oisin Grehan wrote a post on how to do that.

When it comes to presenting a GUI from Script, there are options, which comes down to COM objects,Winforms, and WPF at the root of any GUI interface. COM objects that can accept data for presenting information, Winforms and WPF for user input. So I will review this in terms of "Data Presentation" and "User Input".

Data Presentation

PowerGadgets
One presentation option that starts with the Vista OS, is the Gadgets bar. There is a suite of tools that uses the Gadget bar called PowerGadgets -"Professional IT monitoring for under $100" which offers Gauges, Maps, and Graphs for use from powershell. However one blogger, James O'Neil, indicated that it was not well documented and has some issues. (Since my employer has not moved past XP, I am not able to comment from my experience).

Microsoft Chart Controls
One option that bloggers Richard MacDonald, and Chadwick Miller(aka Chad Miller of SQLPSX) write about is using MS Chart from Powershell. You have to download and install the Microsoft Chart controls for Microsoft .Net Framework 3.5 components, and it does require that you have .NET 3.5 SP1. Microsoft made these objects available as a download - and the Charting objects are provided as part of the .Net Framework 4, Microsoft acquired these charting controls(Visualizations) from Dundas, so these should be standard from now on. (The 3.5 download may not have the same number as the .Net 4 framework.)

In the approach of data presentation using the MSChart approach, you may have to understand the data binding. Alex Gorev, who worked for Dundas, and now for Microsoft, blogged on the Databinding with the controls. Chad Miller's post help make the transition of that information to Powershell - he created a function LibraryChart on PoshCode that encapsulates using the MSChart library.


PoshBoard (Powershell Dashboard)
One open source option for Data Presentation  is Poshboard - that uses Silverlight and PowerShell and the Visifire components. Poshboard has posted some great previews of what is being worked toward. From France, Antoine Habert is the developer - who says he is just a scripter. He has posted some videos on the versions he has released for Poshboard. Version 3.0 beta version multitouch video, and the video demo of the stable release of version 2.5 - but at this point in October of 2010 - you cannot build this - with Visual Studio 2008 you must install the 3.0 Silverlight extensions (at least) and there is work being done on the 4.0 extensions (no audio on either video for 2.5 or 3.0)- but you get the idea of what is going on!). I tried to follow instructions on this - with a Visual Studio 2008 SP1 on XP and could not get it to work locally. Antoine Habert's Posbhoard work attracted the attention of PowerShell architect Jeffrey Snover (Poshboard was noted in his post on ConvertTo-Hashtable). With RIA Services and Silverlight on the desktop, it will be interesting to see how this progresses. This has potential that may not be easy to appreciate at this point - but has a huge potential -the churn effect of various pieces will hopefully be worked out). I would recommend following up on this project as I think it could have great value if it presents a stable installation set of instructions that works(for XP,Vista,Win7 and Server editions).

Data Interaction

Winforms and WPF are the two pieces of the .Net framework that make creation of a GUI possible from PowerShell. Winforms was the basis of the Graphical User Interface within Windows for years. The .Net framework encapsulated the Winform API in the System.Winforms.Form namespace. WPF came along with .Net 3.0 and the System.Windows.Window namespace (actually a few more than just that). These two namespaces provide the core functionality to interact with the user to capture data input from a script - if that is how you want your script interaction to operate. This does provide the flexibility of the script - and changing it as needed - pretty much on the fly - instead of re-compiling into a fixed format. The key to using these interactions - is to create an object that you add properties to within the script so that the data is available from the pipeline after the GUI interaction. The Powershell ISE exposes its script object model to the users to extend - and the Powershell ISE is a WPF application written with the Powershell SDK. So there is a great deal more control if you want to get to that level of creating a GUI for powershell. For the purpose of the presentation - and it's audience - I have tried to limit the topic to "Scripting a GUI" - as not everyone will do work in Visual Studio - Powershell scripting can be done independent of Visual Studio - and so there are areas that Developers may be familiar with, in terms of API that non-developers might find as a learning curve to work with.

Winforms

Winforms from Powershell depends on the namespace of System.Windows.Forms to gain access to the Win32 API pieces through the .Net framework. It is the API layer that gave us the windows that started years ago - built into the Windows OS. The details of the .Net usage and translating it to PowerShell is where a bit of the work lies (and that holds true for WPF too).

Bruce Payette's Powershell in Action (1st edition - Powershell 1) gives scripts that use the  WinForms abilities to put a screen before you as a user. His scripts show that it can be done, and that the details are not small to put up a GUI for data interaction. Lots of fine tuning is required in putting together a decent GUI when it starts to become complex. There is a basic set of controls provided with the 1st Edition of "Powershell in Action" - and you may find that you don't need much more than what he worked to create for his readers. If you keep things simple this is a workable solution.

Winforms from PrimalForms

Sapien Technologies created their PrimalTools.com for their tools. They have produced some Free tools and one of those is Primal Forms community edition (Free) and a professional version (currently about $150) of Primal Forms. The Free edition allows for drag and drop creation of a screen layout - and to have it take care of the fine details of the layout for free is great - but you have to figure out how to hook your scripts into the script output yourself. The Primal Forms professional edition states that you can put your scripts into events - so you don't have to figure it out on your own - and that alone could make this pay for itself. (If you are doing lots of GUI's in a winforms style, this could be a very good tool to invest in).

WPF

WPF is from the System.Windows.Window Namespace - and is possible from .Net 3.0 and afterward. The direction for the UI space from Microsoft seems to be heading toward a WPF type interface now  - Visual Studio 2010 and the Powershell ISE are good examples. Microsoft has worked on the performance of WPF as it brought out VS 2010.

WPK  
As the powershell team was working toward releasing version 2, one of the testers, James Brundage, was working on a way to use WPF from powershell - this was released as "WPK". My earlier post on learning from Powershell extensions ties right back to this idea - the Windows PowerShellpack includes the WPK PowerShell extension that gives you the basics to build a WPF screen. James Brundage, who has since left Microsoft, produced this code. It is workable however the load time is slow.


Powerboots
I recall reading Jeffrey Snover's blog post about this module, just after Jan of 2009, and was initially fascinated that someone was trying to do GUI's with WPF in powershell. I read about the basis being on the ruby "Boots". I tried an early download but it did not work for me. While I was working on the presentation, I mentioned this to Mark Schill, and he told me to Contact Joel Bennet- (who developed Powerboots), and he would help me - I did that via his website HuddledMasses.org - and I did get Powerboots to work.

If you do not see a full release of Powershell dated AFTER October 2010, you should download the latest software uploaded to the CodePlex site. You unzip that under your Powershell Modules folder (under your documenents/WindowsPowershell) and then rename the mangled name to be just PowerBoots. Then go into the bin folder and rename the PoshWpf.dll - to OLDPoshWPF.Dll   - then rename one of the other DLL's for PoshWPF to what you have on your system.

Joel 'JayKul' Bennet is a Powershell MVP, and certainly has earned it. He is working on Powerboots and improving its performance. He actively participates in the IRC Channel #Powershell. His working machine is a 64bit machine and working with .Net 4 - and that was part of the issue I had - working on an XP machine 32bit and only .Net 3.5 on my demonstration machine. A few instructions after contacting him, and I was generating windows with Powerboots.

There is a Samples.ps1 in the Powerboots/Samples directory - and that will have enough basic examples to show you what you can do with Powerboots. 

Joel Bennet had made a post of some code  I had an issue with - that he corrected and reposted during an IRC chat with him.  You can create XAML as an external file and use that in Powerboots if you want to - You do not have to create your XAML outside to use powerboots. This example was one I wanted to see how you could create your XAML in a tool designed for that, and then use that from your script. (Joel's original post of the script code). If you go to his Original post you should save the XAML to your local environment - and I saved mine in my "C:\Data\" folder and then point to that in the script.
You  see a very key piece in the script  - the use of the new-object followed by Add-Member using the pipeline.
That adds properties by name to the base object - very much the way that you can use Javascript prototypes - you can add Properties and Methods to Powershell objects. (You have to do 'Import-Module powerboots' to run the script below).

####################################################################################################################
## Create the window and hook the click. Make sure to use full paths
function Calculate-TripCost {
    $result = new-object psobject
    $result |  Add-Member -type NoteProperty -name Cost -value 0
    New-BootsWindow {} -FileTemplate C:\Data\Boots_MainWindow.xaml -On_Loaded {
       #If you get an old version of Boots you wont have this
       Export-NamedElement
       $Calculate.Add_Click({ 
          $Total.Text = '${0:n2}' -f (($Miles.Text -as [Double]) / ($Mpg.Text -as [Double]) * ($Cost.Text -as [Double]))
          $result.Cost = $Total.Text
		  $BootsWindow.Close()
       })
    }
   $result
}
Calculate-TripCost

The $result field is returned to the pipeline so it can be used after the function has completed.
You can create multiple properties to hold on to the UI elements. This would be the same tactic done with Winforms - so that you can use the data you capture.

Powerboots, using WPF, can do Transparent Windows - which allows you to create a control or test message on your desktop that has information - which seemed to be like PowerGadgets without writing to the API for Gadgets. Powerboots is a very active Codeplex project -and is preparing for a new release that will be far more performant that WPK and with a clean syntax. Powerboots will probably become the de-facto method of producing WPF GUI's from Powershell, as it has coverage for Graphics, DataInteraction, and has the performance. There is work is being done to make it work with .Net 4. I would keep an eye on this extension as it has great value potential long term.


That gives you a high level rundown of some GUI approaches for Powershell - and I hope that is helpful.

I have tried to package up what I presented in the zip file - you need to unzip it using folder names it expects to have a C:\PS1 and C:\Data folder on the machine for the script to run. You need to go to the PS1 directory using a Console window started with the -STA parameter and then use .\Start-Demo DemoIntroToGUIScript.txt - you have to have done the downloads for WPK, Powerboots, and MSGraph mentioned in this post for parts to work.


 

PowerShell_GUI_Demo.zip (38 KB)

Powershell V2, with no enhancements, has a good deal of functionality to begin with; however more functionality can be added to it through 'Extensions' that use Powershell Modules, which enhance, and extend the base functionality. In Version 1 of Powershell to add more functionality you would have to write cmdlets, and Snap-ins, that were done by writing them in a compiled .Net language, and added them into the Powershell environment. In Version 2, Powershell modules can be written in Powershell script, and they can perform like compiled cmdlets( which are still possible for very custom enhancements). Modules, and their flexibility, make Powershell simpler to extend, and customize.

The use of powershell by IT professionals, Database Administrators, and Developers, has provided a great base for an active community of contributors to extend powershell, and to share scripts. There are some very good books that have been produced on how to use powershell and on using powershell with products that have embraced powershell for automation of their product(VMware is an example that is most familiar to people working in IT).

I wanted to call out a few Extensions from the community that provide a good base collection, I am hoping to dig into these and understand them better for myself as part of an effort to impove my abilities. Learning Powershell requires writing your own scripts, looking at others code,viewing videos, reading books, and blogs.

The Powershell Community Extensions (PSCX) were created during the version 1 timeframe, and have been reworked to be compliant with the version 2 approach of extension. These are extensions that I have built a reliance on - the use of Get-Clipboard and Out-Clipboard are essential parts of getting data in and out of a script for 'quick and dirty' script done 'on the fly'.

In my post on 'Powershell and SMO' I mentioned the SQL Server Powershell Extensions(SQLPSX). They show the ISE can be extended through modules. Studying these extensions can be very instructional in how to approach your own development efforts.

When Powershell v2 was 'officially' released with Windows 7 in October 2009, there was also a release of the 'Windows 7 Resource Kit' that included the PowershellPack, this has 800 scripts in 10 modules included. In particular the WPK - an extension that allows for creation of XAML interfaces from powershell script. These extensions allow for the development of a graphical-user-interface(GUI) for users who might not be comfortable with running scripts, and find point-and-click to be more to their liking. This is a good option if you don't want to have to use the Powershell SDK for this type of interface, and build it out with Visual Studio - the 'Visual Studio/Powershell SDK' option is very good when you want to lock down the profiles, and commandsets that can be done within the GUI. WPK is a way to present a simple interface that will help people.

One location for reviewing individual scripts that have been shared by the community would be PoshCode.org site.

The learning curve for powershell is steep, but worth doing - Powershell feels like the swiss army knife, that you can pulled out as the tool of choice to address problems quickly, and create good repeatable solutions. Learning from others is important and these should be good sources of more powershell information.

This week, I attended the Atlanta Powershell Usergroup presentation by Aaron Nelson (aka SQLVariant on twitter). I met Aaron in January after the Atlanta MS Pros meeting where I had volunteered to get a presentation organized on Powershell - I found Hal Rotenberg (aka Halr9000 on twitter) to give people an introduction to powershell (better a local MVP to do that than a novice).Aaron told me when we met in January he was giving a presentation in a couple of weeks on using Powershell with SQL Server. I encounterd Aaron Nelson a second time during the year at SQL Saturday - where he did that presentation again, and showed a method I had not see yet- that had $_.Script(). After SQL Saturday, I researched what that Script method was. After the meeting this week, I told him that I had found that he was using a method on the SMO object. For a DBA this object gives you the power of SSMS (SQL Server Management Studio) via Powershell. For a DBA this method would be one that should certainly be in their toolbox.

In the days following the presentation, I was coding on a development project that is targeting a good number of modifications to a production system. I was fairly sure that the Development databases were partially modified, and needed to prove that to others on the team. I remembered the SMO object and that Script method, and wanted to get the defintions of the database to compare to each other.

 
$load = [reflection.assembly]::LoadWithPartialName( "Microsoft.SqlServer.Smo" )
# Derive the SMO Application Object
$smo = [Microsoft.SqlServer.Management.Smo.SmoApplication]
$server = new-object "Microsoft.SqlServer.Management.Smo.Server" $servername
$database = $server.Databases[$cfg.config.DatabaseOLD.Database]
$tables = $database.Tables
[string] $oldDatabaseDefinitions = $tables |? {$_.Name -match "T_" } |% { $_.Script()}

A few lines of powershell was able to give me the definitions in one string. I output the string to text files and with a file comparison tool could show exactly what changes were in the definitions between the databases we were dealing with.(Production,QA,two development databases, and a 'sandbox' database).

Also this week, I tried catching up on some listening of the powerscripting podcasts (last year my listening to this pocast was how I discovered Hal Rotenburg lived in the Atlanta area, and led me to recruit him for Atlanta MS Pros January presentation). In episode 106 there is an interview of Chad Miller, and they discussed the codeplex project SQLPSX(SQL Powershell Extensions)that he is involved with. From that discussion I learned more about SMO and how Microsoft had done usability studies on that object. Powershell combined with the SMO object seems to be key to those extensions. During the interview he also dicussed his extending the Powershell ISE - which I was not aware was open for extension. He extended it to interact with SQL server - the SMO object was part of the toolkit he used. I will have to start exploring some of the code out there for that project - as I am curious about how he went about this. That could make for an interesting presentation.

I saw on Chad Millers blog he did a Powershell ETL presentation for the Virtual Chapter of Pass, and between that video, and the Powerscripting interview I can tell that Chad Miller is a very capable speaker, and presenter - someone worth looking at to learn from.(Which is why he is a Powershell MVP).

Powershell combined with the power of existing functionality of the SMO object deserves more study. SMO comes with SQL Server 2005 and 2008, however they are different versions. At work I will need to make some room for SQL 2008 R2 on my workstation so I can work with the latest version. (always more to learn).

Powershell 2.0 is considered to be part of the "Windows Manangement Framework" and has a download page. Powershell 2.0, WinRM(remoting service), and BITS 4(Background Intelligent Transfer Service) makeup this management framework. Powershell 2.0 was shipped with Windows 7 and Server 2008 R2, and was made available for Windows XP SP3 and Vista SP1. Version 2 is completely compatible with version 1 - so any scripts written with version 1 will work in version 2.

On Dec 22, 2009 a new Powershell 2.0 SDK was put out for dowload by Microsoft.

There are two videos from the Micrsoft PDC2009 - SVR12 and SVR13 that show writing a simple GUI using the powershell API. During these videos it is mentioned that the powershell ISE (Integrated Scripting Environment) was developed with this same API.

There are Microsoft examples on how to host powershell within an application- which is what a developer would do to utilize powershell within their own application. This is the direction that Microsoft has started with their enterprise level tools. Now developers can embed powershell so that you can develop functionality as a cmdlet/script and the exercise that functionality from the GUI (Silverlight,Web,Windforms, or WPF).

The first hurdle in hosting powershell is getting a reference to it. System.Management.Automation does not show up in the .Net list of items. Browse to
C:\Program Files\Reference Assemblies\Microsoft\WindowsPowerShell\v1.0\
and there you find the System.Management.Automation.dll. Verify that your reference works. If you can enter the code line below in the project and Intellisense works (the create method is visible) - you have the right version of the DLL in place.

PowerShell ps = PowerShell.Create();

(Note the example line of code is from a Microsoft example.)

The Microsoft links on how to host powershell have a good number of starting projects to show the usage of some parts of the API. The examples there are only Console examples. The Code posted on the Powershell blog for the SVR12/13 did use GUI's, however I did not appreciate these exampels as much - as it added a few users onto my machine for showing the security aspects that they used in the demo. The examples are a start, however it will take more for work to get a command of using the full power of the Powershell 2.0 SDK.

Powershell SDK can also execute powershell commands on remote machines using the WinRM functionality - if the remote machine allows the execution and the credentials of the user attempting are authorized. This remote execution allows for collecting information from remote machines back to one location for reporting/processing.

The Microsoft PDC 2009 presentations were targeting development using powershell API toward the Admin community, and controlling what access a given a user - programatically controlling this based on security roles.

With functionality being stored completely in PowerShell cmdlets/scripts, the practice forces a complete seperation of Logic and Presentation - which simplifies testing. Reworking the presentation layer is also greatly simplified. The PDC2009 videos described how the Exchange 2007 team wrote their first GUI in 10 months,as they developed their powershell cmdlets- when they were asked to reskin their GUI; it took only two weeks - the Exchange team was euphoric with that result. They did not have to put everything in the GUI, as the more advanced, or special case scenarios, could be handled by a powershell cmdlet only - thereby reducing clutter in the GUI and overall simplified maintenance.