Tag Archives: Development

Tools, tips and tricks, and my own software development.

Why I’m not excited about Windows 8 Certified Store Apps

It’s come up a few times recently, and I’m frustrated enough that I thought I’d just post this here for reference.

The Windows 8 App Certification requirements has one particular requirement that makes me (as a life-long scripter) very unhappy:

3.9 All app logic must originate from, and reside in, your app package

Your app must not attempt to change or extend the packaged content through any form of dynamic inclusion of code or data that changes how the application interacts with the Windows Runtime, or behaves with regard to Store policy. It is not permissible, for example, to download a remote script and subsequently execute that script in the local context of your app package

Bottom line: you cannot write extensible apps for the Windows Store. In fact, although Windows PowerShell is shipped even on Windows RT, you can’t use it from a certified Windows 8 Store app.

I don’t know about you, but the apps that I use on a regular basis are almost all extensible, and most of them have both plugins and scripting:

  • Visual Studio (Thank goodness for NuGet, ReSharper, StyleCop, GhostDoc, NCrunch etc)
  • Notepad++ and Sublime Text 2 and PyCharm
  • PowerShell and ConEmu
  • Microsoft Office: Word, Excel
  • KeePass
  • Firefox, and even Chrome and IE
  • XChat and even Trillian

I’ve been using Windows 8 for months now, but every app pinned on my taskbar is extensible, and leaving aside video games, I can only see three apps I’ve used in the last month which aren’t readily extensible: PeaZip (which does have some scripting capabilities, but I don’t use them since I script from PowerShell), Zune, and Trillian (which is technically extensible, but all the plugins I use ship in the box).

Even Windows File Manager has shell extensions.

Now, I’m not saying I won’t use an app that’s not extensible … but without even thinking about it, most of the apps I use are scriptable and/or extensible, and I bet that’s true of most of the apps you use too. As a side note, one of the coolest new phone apps from Microsoft is on{x}, an automation app which is only available on Android (and can’t ever pass validation on the Windows Store because of this policy).

So yeah. Most of the stuff I do with computers is about automation, scripting, robotics… or gaming. I can’t see myself getting really fired up about that App Store stuff.

Let me know when 3.9 is revoked.

Now, I have faith in Microsoft. I’m sure they’re not trying to kill off running multiple windows on a desktop, but I don’t understand why they would write terms in their certification requirements that would prevent an app like Sublime Text 2, KeePass, or Firefox from being written. I certainly hope that they can be convinced to rewrite that constraint to allow for users who choose to install modules and scripts.

As a side note, there’s another point in there that I’m not too happy with either:

4.4 Your app must not be designed or marketed to perform, instruct, or encourage tasks that could cause physical harm to a customer or any other person

We would consider an app that allows for control of a device without human manipulation, or that is marketed for use to resolve emergency or lifesaving situations to violate this requirement.

At first, that one seemed fine. But when you read the detail, it’s clear that any app that is for robotics/AI and wants to interface with external devices is basically going to be refused. Your Lego Mindstorms apps are only allowed if they’re remote controls which require human manipulation, because they … might cause harm?

As long as we’ve got desktop mode and sideloading of non-certified apps, we’re ok (I guess), but Microsoft needs to stop limiting certified apps before they alienate the hackers and tinkerers. I’m a big fan (and author) of Open Source software, but I don’t want a world where all the commercial software companies lock out the geeks and our only option is Open Source.

Visual Studio Not Responding (beeping) when editing ASPX

I’m just going to share the solution, in case anyone else encounters this after installing Office 2007 or 2010

Yesterday I came across a very strange bug which was causing Visual Studio to lock up after a few (30?) seconds every time I opened an ASPX file for editing. I even uninstalled a few VS addons I thought might have caused it… but that didn’t help (I’m reinstalling Resharper as I type this).

After much frustration and a couple of Bing searches … it turned out to be a problem with MS Office 2007 components. This was a bit of a surprise, since I do not have Office 2007 installed. However, I do have Office Communicator and Live Meeting which are Office 2007 products — and I had just installed Office 2010, which may have actually caused the problem.

Rinat Abdullin wrote about the problem earlier and there’s a thread on StackOverflow which is at least related.

Basically: you get “beeping” when you try to click in the text editor for aspx, or on the Solution Explorer … (sometimes, but not always, Visual Studio will actually be marked as “Not Responding” by Windows) – and, when this happens, you look in your TaskManager and see this Setup.exe process.

This one — in your %CommonProgramFiles% or %CommonProgramFiles(x86)%:
C:\Program Files (x86)\Common Files\Microsoft Shared\OFFICE12\Office Setup Controller\SETUP.EXE

Shutting down Visual Studio and then running that installer “as administrator” manually has solved the problem for me. I just hit “Repair” and that was that. Others (including Rinat) have said they had to reinstall Office — I suspect that probably depends on whether or not you had Office 2007 installed in the first place.

Reblog this post [with Zemanta]

Windows PowerShell 2.0 SDK Released

So, the Windows PowerShell 2.0 Software Development Kit is basically a collection of samples, and it has been released separately from the Windows Platform SDK for a change, making the download a tiny 2.35MB …

There are lots of examples in there in C# (no other languages), and honestly, some of them ought to make it into PSCX or some other project where people could grab pre-compiled versions ;)

  • A Template for creating PSProviders, and a sample PSProvider (for Access databases).
  • A sample of participating in Transactions (a set of “transacted comment” cmdlets for creating comments that go along with a transaction).
  • Example cmdlets: Select-Object, Select-String, Get-Process, Stop-Process
  • Dealing with issues with Serialization in PowerShell
  • PowerShell Eventing:
    • Deriving from ObjectEventRegistrationBase to create Register-FileSystemEvent
    • Receiving notifications from PowerShell Events on remote computers.
    • Hosting APIs, including (among others):
    • Restricted runspaces
    • Runspace pools
    • Remote runspaces (and remote runspace pools)
    • Running commands in parallel or sequentially
    • Calling Cmdlets and passing parameters
  • Reproducing the default PowerShell.exe output

Honestly, if you’re a developer that’s been wondering about learning to code cmdlets, or host PowerShell as a scripting engine, now’s the time.

Windows Compatability Libraries Galore (including PowerShell 2 for XP)

Microsoft has been very busy this year … and in these last couple of months before the general availability of Windows 7, they’re trying very hard to crank out the tools necessary to encourage development of Windows 7 applications.

The first tool out of the gate, of course, was the Windows API Code Pack for the .Net framework. A nice library that makes it simple to write applications that take advantage of new Windows Vista and Windows 7 features like Libraries, Task panes and jump lists. Of course, that library has a major problem: it’s got an ugly and confusing license. Rather than using one of the standard Microsoft Open Source Licenses, the team used a license from the dark ages that features the vague “Excluded Licenses” clause and other ugly terminology.

More recently, Microsoft has announced a Platform Update for Vista which is intended to allow Vista to run most applications designed for Windows 7. The Platform Update is a set of runtime libraries which includes the Windows Ribbon control; Automation Manager Library; DirectX updates for hardware acceleration; DirectCompute for hardware-accelerated parallel computing support; the XPS printing library; the Windows Automation API; and the Windows Portable Devices Platform, which standardizes data transfers across apps and portable devices. This important package will be made available through Windows Update (and applications will be able to prompt you to download it) and it is in public beta with more information on the Windows Team blog. A couple of pieces of that will be made available for Windows XP; particularly the Automation API, which allows accessibility tools and test automation tools to access Windows user interface in a consistent way — this will mean that the next release of WASP will work flawlessly across Windows XP, Vista, and Windows 7.

Also in the works is the Remote Desktop Connection 7.0 (RDC7) client for Windows XP and Windows Vista to allow these older clients to take advantage of all new server features in Windows 7 and Windows Server 2008, including multi-monitor support and media redirection. There’s more information about that on the Remote Desktop team blog.

And finally, the release candidate for the Windows Management Framework (WMF) is also available. The WMF will include WinRM (Microsoft’s implementation of the WS-Management spec), PowerShell 2.0, and BITS for Server 2008, Windows Vista, Server 2003, and of course, Windows XP. This means that if you’re on Vista, or still using Windows XP, you can now upgrade from the PowerShell 2.0 CTP 3 to this release candidate and expect remoting to work!

All of these should be seeing final releases in the very near future, and some of them possibly by the time Windows 7 is released to the public.

Reblog this post [with Zemanta]

PowerBoots: The tutorial walkthrough

[new] Updated to PowerBoots 0.1

An introduction to PowerBoots

Please excuse me if I start by just copying the basic ideas of the Shoes Tutorial, but I figured that since PowerBoots is inspired by Shoes, that was as good a place as any to start. PowerBoots (or just “Boots”) is a PowerShell 2.0 module with functions for writing Windows Presentation Framework (WPF) applications in the PowerShell scripting language. You should get the latest version of PowerBoots before continuing, and install it by putting the “PowerBoots” folder in one of your “Modules” folders (list them by typing $Env:PSMODULEPATH in PowerShell v2).

Don’t forget to start PowerShell.exe with the STA parameter (This is no longer required in PowerBoots 0.1).

Did I hear someone ask what is WPF? It was introduced as part of .Net 3.0 (and vastly improved in .Net 3.5), so you can expect to find it preinstalled on computers from Vista on, and of course you can download and install it on XP if it’s not already installed. The only thing you really need to know about WPF for the purposes of this tutorial is that it is the new GUI toolkit for .Net, and that it is container based — you put elements into other elements to control the layout, rather like HTML and Java Swing… you can pick up the rest as we go along.

A simple Boots program

New-BootsWindow -SizeToContent WidthAndHeight -Content {
   Button -Content "Push Me"

I’ve recently changed this first example to pass a script block to the content instead of using parentheses, because although PowerBoots supports running in an MTA PowerShell host, the only UI-creation command that is MTA-safe is the New-BootsWindow command. All of the “new” functions must then be inside of a scriptblock which is passed to the New-BootsWindow cmdlet and executed on that STA thread. You can use parenthesis ( and ) as a container instead, but that requires the host to be in STA threading mode (run: PowerShell -STA) so the controls can be created:

New-BootsWindow -SizeToContent WidthAndHeight -Content (
   Button -Content "Push Me"

This first example is a bit uglier than the Shoes syntax, so lets see if we can’t clean it up some. The -Content parameter is positional, so the first non-named argument you pass will be used for that. The same is true for the -Children parameter of panels, and in fact, each of the other similar parameters: Items, Blocks, and Inlines.

We have used a function New-BootsWindow which has an alias Boots. Boots takes all the same parameters as the Window function mentioned previously, but it uses slightly more useful defaults, and has a few other major benefits as well, the first of which is that it automatically “shows” the window, and the second is that it supports an -Async parameter which allows the window to come out in a new thread so that you can continue using PowerShell while the window remains alive and responsive. There is one catch: New-BootsWindow cannot take it’s content on the pipeline (the old function, now renamed “Out-BootsWindow” can take pipeline content, but is a script function, and requires -STA mode) — you have to specify it as a ScriptBlock. So now that we know this, we can rewrite our first example like this:

Boots { Button "Push Me" }

Just for the record, the simplest Boots program would just be a simple popup dialog to put some text in a Window, like: Boots { $msg }

We can put controls in a stack

Boots {
   StackPanel {
      Button "A bed of clams"
      Button "A coalition of cheetas"
      Button "A gulp of swallows"

StackPanels are awesome. So are WrapPanels. Try that code with a WrapPanel instead of a StackPanel and see what the difference is. This brings up another point: those positional parameters we mentioned earlier: Content, Children, Items, Blocks, and Inlines, are also set to accept the value from the pipeline. Not only that, but they are intelligent about whether or not the content model accepts multiple items! So we can actually rewrite that script like this, and get the same results:

Boots { "A bed of clams", "A coalition of cheetas", "A gulp of swallows" | Button | StackPanel }

Now we’re really onto something! Continue reading

A guide to PowerShell’s Advanced Functions

Someone asked on the PowerShell Newsgroup about writing Advanced Functions, and specifically:

looking for a … guide to putting together an advanced function that is visible and usable every time I start Powershell. By visible I mean that when I do a ‘get-command’ I want my [advanced function]s to be listed alongside all the regular cmdlets. What makes that possible? ... what do I need to do to make that happen? Whats the difference between an [advanced function] and a module?

There are lots of articles on the Microsoft PowerShell team blog about both topics, but it seems there’s not really been any sort of step-by-step written, so I posted this to the newsgroup, and since the person who asked the original question said he found it useful, I figured I’d share it here…

Continue reading

PowerBoots: Loading XAML Windows in PowerShell 1.0 or 2.0

Awhile back I wrote a series of posts about WPF From PowerShell From PowerShell” which were about how you could load XAML in previous PowerShell 2 CTPs to create WPF user interfaces … a few people have mentioned loading XAML in PowerBoots, and a couple of people have posted other samples showing XAML even since I published the most recent release, so I figure it’s time to point out that you really can load that XAML into Boots, and get all the threading and other support.

Just for fun, I’m going to rehash an earlier post about updating windows to show how you can go about this using PowerBoots, and hopefully show that it’s a little easier (and a lot more async). Compare and contrast the code in this article with that one, just for fun.

This works with any version of PowerShell

Unlike the original article, most this code (except where explicitly mentioned) works on either PowerShell v2 with PowerBoots, or PowerShell 1.0 with PoshWPF, a snapin that is part of the PowerBoots module but is also released separately… Also, unlike those previous posts, this does not require you to be running PowerShell.exe with the -STA switch, since the New-BootsWindow cmdlet takes care of threading for us.

Continue reading

PowerBoots and Attached Properties

WPF uses a concept called “Attached Properties” to handle certain things, like when you put controls into a DockPanel. Basically, anything you put inside a DockPanel has a property “Dock” which you can set … but because the property is actually defined by the DockPanel, it doesn’t show up in PowerBoots, so you can’t just say -Dock "Bottom" when you create the child items … at least, not yet.

I’m still thinking about the best way for me to expose this in PowerBoots, because the problem is that attached properties can get attached several ways, and not just on direct children of an element. So I wanted to show you a way that you can do it for now so you can at least use the DockPanel effectively:

Boots {
   DockPanel -LastChildFill $true {
      DockPanel -LastChildFill $true {
         Button "OK" -Padding "2,0,2,0" |
            ForEach-Object { $_.SetValue(
         TextBox -HorizontalAlignment Stretch
      } | ForEach-Object { $_.SetValue(
      TextBox -AcceptsReturn $true -minWidth 300 -minHeight 200

A better way …

Here’s what I’m thinking about for the next release of PowerBoots (you can take this and use it now, if you like it, but I’m really looking for, uhm … better ideas). Basically, I have written a function: Set-AttachedProperty, which takes an attached property and a value, and passes through the element on the pipeline. You may want to use this in conjunction with the module I published awhile back for creating type accelerators, because it lets you run a line like this:

Add-Accelerator DockPanel System.Windows.Controls.DockPanel

Which will let you substitute [DockPanel] for [System.Windows.Controls.DockPanel] … and of course, you can use it for all the types you want to use attached properties from, and it’s a real lifesaver if you need to use a bunch of them. Of course, in this particular example, we really only need to use a single attached property, so it’s enough to define that property ahead of time:

$DockProperty = [System.Windows.Controls.DockPanel]::DockProperty

Then you can use the Set-AttachedProperty function through an alias sap, and rewrite that huge block above like this:

Boots {
   DockPanel -LastChildFill $true {
      DockPanel -LastChildFill $true {
         Button "OK" -Padding "2,0,2,0" | sap $DockProperty Right
         TextBox -HorizontalAlignment Stretch
      } | sap $DockProperty Bottom
      TextBox -AcceptsReturn $true -minWidth 300 -minHeight 200

Pretty slick, right? And it will even print out the list of values in the error message if you invoke it with an invalid value against an enum property like dock: sap $DockProperty "" … The problem I have with it is that you have to predefine your $DockProperty variable, and you can’t just define it against the root class. So I’m trying to find a way to tweak the dynamic property generation to make it so that the pipe into | sap $DockProperty Bottom can just be a parameter to the original element: -Dock Bottom … if I can’t find that, in the worst case scenario, I’ll just add an -AttachedProperties parameter with a hashtable of $DockProperty,“Bottom” or something … what do you think?

In any case, here’s the sap function, for now, and remember to use it as part of the pipeline:

function Set-AttachedProperty {
   $paramDictionary = new-object System.Management.Automation.RuntimeDefinedParameterDictionary
   $Param1 = new-object System.Management.Automation.RuntimeDefinedParameter
   $Param1.Name = "Value"
   # $Param1.Attributes.Add( (New-ParameterAttribute -Position 1) )
   $Param1.Attributes.Add( (New-Object System.Management.Automation.ParameterAttribute -Property @{ Position = 1 }) )
   $Param1.ParameterType = $Property.PropertyType
   $paramDictionary.Add("Value", $Param1)
   return $paramDictionary
   $Element.SetValue($Property, $Param1.Value)

New-Alias sap Set-AttachedProperty

PowerBoots: PowerShell GUIs are now multi-threading

Announcing the release of PowerBoots 0.1

This release of PowerBoots is the most exciting release software I’ve cranked out in awhile. It finally has almost all of the features that I have thought of so far (we’re still missing proper support for attached properties).

  • You can create pretty much any WPF element, including ones I haven’t thought of adding yet (use Add-BootsFunction to add a new assembly or a single type).
  • You can create graphical user interfaces from PowerShell 1.0 all the way to the latest PowerShell 2.0 CTP.
  • You can create your WPF GUIs -Async in their own threads, or inline in PoshConsole, or as synchronous dialogs that return values when they close.
  • You can capture screenshots of your UIs (eg: generate .jpg charts from Visifire). You can even do so without displaying them!
  • You can take advantage of XAML Data Templates to generate graphical representations of any objects in the PowerShell pipeline.
  • You can add to, or modify your running GUIs from the command line.

You can read the “and much much more” between the lines right?

Continue reading

PowerShell Modules, Metadata, and Mysteries

I’ve finally finished the first public release of PoshWpf, and was getting ready to ship it as part of a new release of my PowerBoots module. The idea is that I need PoshWpf itself to be a stand-alone module so that it can be used in production with PowerShell 1.0, until such time as PowerShell 2.0 goes gold, and we can get that into production use, so we can use PowerBoots. PowerBoots is a script module, and it uses dynamic parameters, so most of it can’t really be done in v1, but you can use PoshWpf as a snapin, including the New-PowerBoots cmdlet, to do asynchronous multi-threaded UIs like my “ping monitor demo.”

So I need to update the .psd1 Module Metadata file for PowerBoots to include PoshWpf … I read up on Oisin Grehan’s blog about the possible properties in the module manifest, and decide that I could do this by packaging PoshWpf as a NestedModule in PowerBoots. There’s not a whole lot of point in distributing PoshWpf as it’s own module — Version 1 users will need to install it as a Snapin anyway, since PowerShell 1.0 doesn’t support modules, and I expect PowerShell 2.0 users to use it with PowerBoots.

Nested Modules

So I open up the PowerBoots.psd1 file, and add the line: NestedModules="PoshWpf" and fire up PowerShell and run Import-Module PowerBoots … and get this Error:
Import-Module : The module to process ‘PowerBoots’, listed in module manifest ‘C:\Users\Joel\Documents\WindowsPowerShell\Modules\PowerBoots\PowerBoots.psd1’ was not processed because no valid module was found in any module directory.

Now, I have no idea what that’s supposed to mean, except that I know the way that the PowerBoots.psm1 script gets parsed is that the PowerBoots.psd1 metadata includes a line: ModuleToProcess="PowerBoots.psm1" … I don’t know why the error doesn’t say “.psm1”, and I don’t know why that would be the error when what I added was the PoshWpf line, but I comment my line out and everything works, so I decide that maybe I need to say “PoshWpf.dll” (following the example that works of loading the PowerBoots script by specifying the full extension).

So I move PoshWpf.dll from it’s subdirectory right into the PowerBoots folder, and I change my line to: NestedModules="PoshWpf.dll" and fire up PowerShell and run Import-Module PowerBoots … and get this Error: Import-Module : An item with the same key has already been added.

Wow, I’m two for two: two attempts to load my module, two completely incomprehensible errors.

Continue reading