Wearing my admin hat.
I personally don't know either one well enough to have a preference.
I do need some GUI fuctionality in the scripts I need to create, but a lot of them will be ad-hoc creations to meet a temporary situation and/or be used infrequently.
I can't justify spending 4 hours on a script that might only get run 50 times before it's obsolete, and doesn't do anything that couldn't be done without it.
Give me whatever will get me the most functionality in the amount of time you're willing to devote to it. I will come back for more if I can't get it done with that.
In V3, Show-Command and Out-Gridview offer some capabilites that can agruably qualify as "GUI". They provide a lot of functionality that's very easy for someone who's already fluent in Powershell to pick up. I would include them, if nothing else.
I am in the same boat... I don't know enough about either one to have a preference.
This got me thinking is a GUI the correct place, why not a web page and use HTML or whatever it takes to draw up a simple web page. A couple of inputboxs, a drop down, and/or some radio buttons. Maybe this is because it has always been a dream of mine to take the time and make a "tools" web page that would take input from a user, run my script(s) (if needed with elevated privs), and send back some type of output to the user that the script was successful or had errors. I am not aware of anything in powershell that makes this easier than any other scripting language, but this has always been a goal of mine.
If WinForms or WPF are the options then I guess I could make that "tools" page with links out to the file system to run these fancy looking powershell scripts and get close to the same result. In either case, I am thankful that there are people out there trying to make my job easier, since I am the "scripting guy" in the group and everyone comes to me to automate. Building some scripts that don't look like scripts should allow others to reuse what I create.
I don't know .NET, php, or any other web language. My comfort is in VBscript and I'm slowly migrating to powershell with the help of blogs like this and the "PowerShell in a month of Lunches book."(too bad I only get a couple of chapters done in a month).
Check out Sapiens PrimalForms. They have a free version called community edition.
It allows you to create a gui in designmode so you do not have to spend more than a few minutes or maximum an hour to get everything right.
No, there isn't really a way to combine HTML and PowerShell the way that you can with VBScript. That's kind of the point of the discussion - the 'replacement' for those HTAs.
The context of the question is what should be included in a book on the subject, given a limited amount of space to devote to it.
Third party products may be a good solution at the moment, but there is no guarantee that solution will be available in the future.
The vendor can render the time and effort spent writing that chapter, and the information contained in it useless at any time.
That is the risk you take when writing a technology book, *including* books on Microsoft technology. You can’t be overly concerned if a vendor will no longer exist or if the technology will change. You always have to be prepared to update the book when it comes to technology. When PowerShell v3 ships, the v2 books will instantly become outdated. The same thing will happen again with every version thereafter. My point being, it’s the nature of the beast. The life span of a tech book is probably 2 to 3 years, and possibly less, before it needs to be updated.
Just a side note SAPIEN has been around a bit longer then PowerShell itself ;-)
It's a given that a book on V3 will be rendered obsolete in whole when V4 ships.
If you limit the material covered to native capabilities of Powershell you have a reasonable expectation that until that happens, everything in the book will be current and valid.
When you start throwing in other products / vendors then you start running the risk of parts of the book becoming obsolete before then, as those products may undergo revisions or updates on an entirely different cycle.
The short lifecycle makes it unlikely that those parts will be updated before the rest of the book becomes obsolete, too.
One thing he can be sure of is WinForms will not change. Anything he writes about the content will remain valid. The tool may incrementally change by adding new features, but chances are there will be a new version of PowerShell before the tool has evolved so much that it needs a complete rewrite. Remember the scope of what he is writing. The designer and WinForms has been consistent for years now.
A book is not necessarily rendered obsolete just because a new version of the product is available. For instance my PowerShell in Practice was written across the v1/v2 transition so covers both. V3 wasn't even a twinkle in anyones eye at that point but I think everything in that book can be utilised in v3.
Same with other books - if you are dealing with what you can do with PowerShell ie adminsitering components of your infrastructure such as DNS, AD, EXchange or SQL then the PowerShell version change in many cases will not affect the solution. What may change is that some new functionality such as the DNS cmdlets in Windows 2012 give you an improved experience managing that component. You may still need those old techniques from a down level cleint though.
If you are talking about a pure PowerShell language book then a version change will mean that some update to the book will be necessary either to address new functionality or to address breaking changes in the new version.
I'd hang on to the v2 books until you have a complete v3 environemnt and you have investigated and understand the new features and breaking changes
@DavidC My comments about bringing other products into it were in reference to Primal Forms. As I said earlier, I don't know either Winforms or WPF, and I don't know how much of the book Don is willing to commit to building GUI's. My preference is for whatever gets me the most functionality in amount of space he's willing to devote to it.
@RSiddaway The comments about manuals being rendered obsolete was more from the perspective of an author or publisher. I still have books laying around from older versions that have useful information in them, but someone looking to buy an new book on Powershell will want the latest version.