Thanks to everybody who came to the PowerShell talk that Matt Hester and I did at Codemash! If you haven’t heard of Codemash or attended it, it’s an extremely well-done conference in Sandusky, Ohio at a huge indoor waterpark. I brought my whole family (including in-laws) along with to enjoy a vacation. The conference itself draws in all sorts of smart people with all sorts of backgrounds, and there have been many interesting sessions, open space sessions, and conversations already. It’s worth way more than the price of admission. (WAY more.)

We tried to tailor our talk to people who have only heard of PowerShell, and people who have limited experience with it. And that worked great because I think that described the majority of people there. We got a lot of great questions, and of course we went well over our 1-hour timeslot. There’s so much to talk about! I wish we could’ve gotten into more advanced topics like the type system, etc.

For my part of the talk, I presented a few demos. You can download them and the slides below. Briefly, the demos were the following:

Using PowerShell from within applications. I extended the Family.Show example application that Vertigo Software wrote by adding “scripting support” using PowerShell. You can see a screenshot I posted here. I also wrote a simple WPF application that gets a list of processes running on the computer, only including those who have a handle count less than 200.

Simple Cmdlet. I wrote a simple Cmdlet as an example. It’s completely non-functional but I included it here for completeness.

Build Scripts with PSake. I have a simple build script with PSake that doesn’t actually build anything, but shows how to define dependencies, prerequisites, etc.

Windows Troubleshooting Platform + Reference Application. Not included in the download (because you can get the source as-is from codeplex), I briefly covered the PSSymbolStore application. It demos using the Windows Troubleshooting Platform, defining more advanced Cmdlets, and building an application on top of PowerShell at the core. You can browse (and/or download) the code here.
As a note, because of the signing requirements of the Windows Troubleshooting Framework, I will leave the code in the application but will remove any UI that invokes the Troubleshooter. It won’t work on any machine but mine unless I have a trusted certificate, which I don’t.

Download the code and slides from our presentation.

See you next year (hopefully)!

First, is an abstraction around the User Interface thread, IUserInterfaceContext. This exists today in the form of SynchronizationContext, but I favor this specific interface because

1. It’s more explicit (the SynchronizationContext applies to more than just the main UI thread) whereas this is very clear what its purpose is.
2. The API is cleaner – passing a “state” is unnecessary with nested closures.
3. It’s easier to grab out of an IoC container. Because a SynchronizationContext is only specific to the context it was created in (which could be a background thread) it’s not meaningful to put a SynchronizationContext argument in your constructor. Which one do you want?

public interface IUserInterfaceContext
{
    void Execute(Action action);
    void ExecuteAndBlock(Action action);
}

Now, any component in my application can execute code on the UI thread extremely easily. I just register the implementation of IUserInterfaceContext (which does use a SynchronizationContext) when my application is started, which is on the UI thread.

The implementation could look something like this:

public class UserInterfaceContext : IUserInterfaceContext
{
    private readonly SynchronizationContext _syncContext;

    public UserInterfaceContext(SynchronizationContext syncContext)
    {

        /* Ensure the SynchronizationContext passed in is the main UI thread context */
        _syncContext = syncContext;
    }

    public void ExecuteAndBlock(Action action)
    {
        if (_syncContext != null)
        {
            _syncContext.Send(s => action(), null);
        }
        else
        {
            action();
        }
    }

    /// <inheritdoc />
    public void Execute(Action action)
    {
        if (_syncContext != null)
        {
            _syncContext.Post(s => action(), null);
        }
        else
        {
            ThreadPool.QueueUserWorkItem(s => action(), null);
        }
    }
}

Secondly, is a more generalized example of Jeremy Miller’s ICommandExecutor, which is even more generalized as the Active Object pattern. I named mine “IAsyncExecutor” because it executes any code asynchronously. The advantage with this approach is that it drastically simplifies test activities to be able abstract multithreading (to a point) and allow a test to run single threaded. That is nothing but pure win. We’ve also found that using the interface makes the code read better than using a bunch of BeginInvoke/EndInvoke’s or the ThreadPool, or an async pattern such as “void FooAsync(AsyncCallback callback, object state);

public interface IAsyncExecutor
{
    void Execute(Action action);
    void Execute(Action action, Action after, bool callbacksOnUIThread);
    void Execute(Action action, Action after, Action<Exception> error, bool callbacksOnUIThread);
}

You’ll notice that IAsyncExecutor looks a lot like IUserInterfaceContext, and in fact, it can use it under the covers if the callbacksOnUIThread is true.

Both of these are simple interfaces, with trivial implementations, but you’d be surprised how often I’ve wished I’ve had them in the past. What are some “core” interfaces/services/etc that you *must have* in your toolbox?

#3 will be joining #2 and #1, and we are pumped.
Well, I’m pumped, my wife is just trying not to feel too sick. She’ll be pumped later, like in 5 years.

On the other hand, there are a lot of challenges like poorly named properties, confusing defaults, and possibly unexpected behavior. You really need to understand what’s going on under the covers.

For instance, if you’ve looked into .NET localizability at all, you probably know that by default resources are loaded using the CultureInfo retrieved from the System.Threading.Thread.CurrentThread.CurrentUICulture property. That’s why most guidance for manually changing the default application UI language says to set that property to a value of your choice. And well you should – it’s the only way to override the default language settings for your Windows Forms.

See, the Windows Forms designer automatically generates all sorts of useful code that you can’t (and shouldn’t) touch. Here’s an example.

Notice the ComponentResourceManager? It’s a local variable in the InitializeComponent method. The only way to alter it’s behavior is to alter the current thread’s UI culture information.

So that’s great, and even better it’s easy. When your application starts, you can load culture/language information from whatever persistence mechanism you prefer, and essentially "set it and forget it", since all Controls should be created on the same thread.

But there’s one problem with this: it only applies to UI elements (Controls).

It’s also common to load objects outside the context of the UI, perhaps with the intention of later presenting them to the user, or persisting to a file, or something else "user visible". For this, you can add an arbitrary number of resx files that contain images, strings, serialized objects, etc.

With Visual Studio 2005 and higher, these resources are available as strongly-typed properties, giving you compile-time checking and ease of use.

But here’s where our problem comes in. Overriding the default UI culture on the main thread applies only to that thread. If you load any resources from a background thread of any kind, they will be the resources for the default windows UI language.

The strongly-typed class ("Resources", in my example) offers us some relief, however, in the form of a static "Culture" property on the auto generated class. If you never touch the property, resources will be loaded using the current thread value. But if you assign your own value, you can explicitly control which resources are loaded.

Consider this debugging example where I’m stopped in the execution of a background thread. I’ve created a global static "Localization" class with a "CurrentCulture" property that I use to maintain the current UI language for my application. You can compare and contrast the values set for the current thread and the auto generated Resource static class, which my application has initialized. (I’m running the English UI for Windows, by the way.)

So, why am I posting this? Because I myself was unsure about how to correctly accomplish the goal of enabling users to select their own UI language until I noticed the auto generated "Culture" property on the Resources class. And it took me embarrassingly long to find it. Hopefully this post keeps somebody else from wasting an evening, or more.

In summary, it’s actually simple once you understand all the details. To enable a specific "non-default" language in your application:

• Set the System.Threading.Thread.CurrentThread.CurrentUICulture property to the appropriate culture, and
• Initialize all auto generated resource classes (or any custom uses of the ResourceManager class) to the appropriate culture, before loading any resources.

Some Books and Stuff to be Donated

Apparently our Visual Studio friend the “Go To Find Combo” (weird name, I know–from this point on I’m just going to call the dang thing the “Find” combo) is like Mr. Ripley–adaptive, talented, and full of secrets. If you don’t recognize it by name, the “Go To Find Combo” is the “Find” combo box in the Standard toolbar. (Shortcut: CTRL+/ or CTRL+D, depending on who you believe.)

In the recent Mastering .NET Debugging class I took, John Robbins clued us in to some of the crazy stuff this combo can do. I’m sure under the covers in the key processing code for this dialog there’s a huge “if/else if/else” statement. Just kidding.

Find

Okay, this is what we all know it does. Type in a search term, press enter, and it searches within the current document. Or press the “Find in Files” button () and it will display the Find in Files dialog with your search term pre-populated. It probably does so much more relating to searching, but that’s primarily how I use it.

Open A File By Name

Type the name of a file into the “Find” combo, then press CTRL+SHIFT+G (“Open File”), it will find and open the file you specified.

(Imagine me pressing CTRL+SHIFT+G in the screen shot above)

Create a New File By Name

Similar to opening a file, create a new file by typing a file name into the “Find” combo and pressing CTRL+N (“New File”). A new file with the specified name will be opened, but it’ll be up to you to save it to the correct place.

Set Breakpoints Instantly

Probably the coolest “hidden feature”, type the name of a Method into the “Find” combo and press F9. Notice that a breakpoint was automatically set on the opening brace of the method! And, if you’ve got overloads, notice that a breakpoint was set on every overload. For example, let’s say I have a “Show” method that has 3 overloads. Typing “Show” and pressing F9 sets these breakpoints:

But check out just how talented Edit.GoToFindCombo really is… using my example above, I’m going to type in “Show(Control)” and press F9 to set a breakpoint specifically on the Show(Control control) method. What happens?

It sets a breakpoint on both the Show(IWin32Window) and Show(Control) overloads. Why? Because the Control class implements the IWin32Window interface! So my “search term” for the breakpoint matched two possible overloads, and it was smart enough to know that. Great stuff.

Commands

Anything you can type into the command window you can also type into the Find combo. Just prefix it with “>” and intellisense will guide you. For example, to open a file, type “>open ” plus the first letter of a file. Or you can execute macros, etc. The sky is the limit!

Execute a command window command

 
Execute a macro, custom or otherwise

Update: Sara Ford shows us one more useful feature. Type in a line number and press CTRL+G to jump to the line. Is there no end to the madness??

• Online – I demand a reader that is available everywhere. I want to install as little software as I can.
• Keyboard support – if I want to quickly skim through my feeds, I don’t want to click around. I use the j/k keys to jump between posts, and the space bar (pages down) to read a particular post further.
• Online – did I already mention this? This is huge.

Well, yesterday Google released some new Google Reader features, including Search. You can read about them on the official Google Reader blog.

• Search – you can search within All Items, Starred Items, Shared Items, folders, or individual subscriptions. One word: nice! I like the type-ahead feature to let you quickly find a folder or subscription you want to search in.
• Collapsible splitter – hide your folders for maximum reading real estate.
• Unread counts to 1000 – previously it only showed a maximum of 100 unread items in the subscription/folder name.
• Forward and Back browser buttons work as intended – this was a pain for me, I’m glad they’ve “fixed” it. I am trained (less so these days, thanks to AJAX) to click “Back” to go back. Go figure!