Here’s a sample application that just serializes an object using the DataContractSerializer and then runs it through both message encoders and presents the results:

using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;
using System.Runtime.Serialization;
using System.ServiceModel;
using System.ServiceModel.Channels;
using System.Text;

namespace BinSerializationTest {
   [DataContract]
   class SampleDataContract {
      [DataMember]
      public string Member1;
      [DataMember]
      public int Member2;
      [DataMember]
      public string Member3;
   }

   class Program {
      static void Main(string[] args) {
         try {
            SampleDataContract dc = new SampleDataContract {
               Member1 = "Sample string 1",
               Member2 = 142234,
               Member3 = "Different data here"
            };
            byte[] xml = SerializeToXml(dc);
            Console.WriteLine("DC serialized to XML resulted in {0} bytes", xml.Length);
            byte[] bin = SerializeToBin(dc);
            Console.WriteLine("DC serialized to binary resulted in {0} bytes", bin.Length);
         } catch ( Exception ex ) {
            Console.WriteLine(ex);
         }
      }

      static byte[] SerializeToXml<T>(T obj) {
         Message msg = ObjectToMessage(obj);
         MessageEncodingBindingElement mebe = new TextMessageEncodingBindingElement();
         mebe.MessageVersion = MessageVersion.Soap12;
         return Serialize(msg, mebe.CreateMessageEncoderFactory());
      }
      static byte[] SerializeToBin<T>(T obj) {
         Message msg = ObjectToMessage(obj);
         MessageEncodingBindingElement mebe = new BinaryMessageEncodingBindingElement();
         mebe.MessageVersion = MessageVersion.Soap12;
         return Serialize(msg, mebe.CreateMessageEncoderFactory());
      }
      static byte[] Serialize(Message msg, MessageEncoderFactory factory) {
         MessageEncoder enc = factory.Encoder;
         MemoryStream stream = new MemoryStream();
         enc.WriteMessage(msg, stream);
         return stream.ToArray();
      }
      static Message ObjectToMessage<T>(T obj) {
         DataContractSerializer ser = new DataContractSerializer(typeof(T));
         return Message.CreateMessage(MessageVersion.Soap12, "", obj, ser);
      }
   }
}

Hope it’s useful!

The extension itself is pretty simple, but it was a good way to understand how adornments for the text editor worked. I think it’s a fairly elegant mechanism that offers quite a bit of potential. A couple of things that I liked quite a bit about it:

1. You can easily configure the order in which your adornment layer is rendered in, compared to the rest of the stuff in the editor. For example, you might want to render it last of all, or perhaps after the text, but before the selection mask. Like other editor extensions, the [Order] attribute on your AdornmentLayerDefinition controls this.
2. You can ask VS to position your adornment relative to the span of text it is associated with, or to the view layout, and VS will do most of the hard work of keeping it in the right place as the buffer view is scrolled and moved. It makes some things a lot easier.

The other thing I found interesting about creating the sample was how you could leverage the Classifications system to integrate with the Fonts and Colors configuration options for an extension that is not a custom classifier extension.

If you look at the extension code, you’ll notice that I have a custom ClassificationFormatDefinition named “Current Line”, which allows the user to easily change the colors used to render the current line adornment. Then, in the code, I can get the settings the user configured (or the default ones provided by the classification format) by using the IClassificationFormatMapService.

This service gives you an IClassificationFormatMap that provides two key things:

• Get the TextFormattingRunProperties that contains the brushes and other settings you need to use for drawing your adornment, and
• An event you can attach to in order to get notified when the user changes the fonts/color settings so that you can refresh your customization.

Pretty cool stuff. You can grab the code for the extension from the GitHub repository.

I will continue playing with this, but besides a significant refactoring of the code, I’ve added support for two new classifications:

• Visibility Keywords: You can now select different highlighting options for visibility keywords in code like public, private and so on. For example, you can make them less visible by changing them to a color closer to your background.
• LINQ Operators: For C#, you can select options for LINQ query operators, like select, where, groupby, etc.

Here’s a screenshot of some of the extension C# code showing all three of our supported classifications:

Enjoy!

My first sample extension is a custom Classifier that changes how flow control keywords get rendered in the editor in C# and C/C++ so that they are easy to separate at a glance from other, more structural keywords. This is a common feature in other IDEs, but Visual Studio has always lumped all language keywords in a single category, which is a bit less useful.

Here’s how code might look with the Flow Control Classifier installed (C#):

One of the really nice things about how classifiers work in VS2010 is that they get recognized by the IDE automatically and new entries for any custom classificatios are added  in the Fonts And Colors dialog so that the user can tweak the appearance. After installing the sample, you can adjust the settings for the “Flow Control Keyword” category to make the colors match your Visual Studio theme.

Much of the code in this sample is based on the Custom Classifier project template that comes with the VS2010 SDK, but I tweaked it quite a bit to make it easier to work with. You can find the code for the sample on the FlowControlClassifier repository at GitHub.

There are some interesting aspects about this extension that are worth commenting so that I remember them later on:

Controlling which Editors are Extended

The Visual Studio extensibility model provides an easy way to control on which editors your custom classifier runs, through the [ContentType] attribute on your Classifier Provider class.

The default project generated by the project template specifies the “text” content type, which causes it to run always. However, for this sample, I changed that and added the attribute twice; once for C# (which uses the “CSharp” content type), and once for C++ (which uses the “C/C++” content type).

The second aspect of this is, of course, checking the type of context you’re running in at runtime. For the FlowControlClassifier, I wanted to be able to use different lists of keywords to highlight for each language. Though C# and C/C++ are largely similar, this made it easier to support other languages later.

The way to do this is simple: When the classifier runs, I check the ContentType property of the TextBuffer instance associated to the span the classifier is currently classifying:

string[] keywords =
   GetKeywordsByContentType(span.Snapshot.TextBuffer.ContentType);

Overriding the Default Look

Another cool thing that the new classifier model provides is that the format specifications provided by classifications are merged together before rendering. That means that a single span in the editor might get classified two different ways by two different classifiers, and the editor can merge those together to produce a single look.

For example, one classifier might say it wants it in bold, while the other might only say it wants it in blue. The editor can then make the span bold and blue.

Fortunately, you can tell the editor how you want that merging process to work. In the FlowControlClassifier, I wanted to always override the default look already provided by the language service classification (i.e. the format specified in the Keyword option in the Fonts And Colors dialog). To do this, I tell VS that I want my classification format to be applied after the default classifier and with a high priority:

Parsing the Content

From what I can see, the way the editor interacts with the classifier is such that you will basically get a call to your GetClassificationSpans() method for each visible line in the buffer at a given time. Although the editor gives you a span covering a single line of text at a time while, you can ask for the text before/beyond the span given, though there’s good reason to avoid doing that as much as possible.

Obviously you can’t really rely that it will be exactly so (many things can affect when it gets called), but that does tell us a lot about how the editor works. In particular, only classifying the visible portion of the buffer should definitely keep the editor snappy when possible.

In my initial attempt at writing the classifier, I started manually parsing the text given (which can be retrieved by calling span.GetText()) to look for keywords and generate ClassificationSpans for each one I found.

This seemed to work at first, until I realized this was undesirable for a very simple reason: I couldn’t just look for the words in the text, without being aware of the context they were used in.

For example, “for” is a keyword I’m interested in, but obviously not if it appears inside a quoted string or a comment. I could work around that with a bit of work, but that even that fell apart real quick, since I couldn’t handle multi-line comments or multi-line string literals when I was just seeing the text one line at a time. And parsing back through the buffer to check for context was simply not an appealing option.

Fortunately, after wondering aloud on twitter if there might be a way to reuse the classifications already done by the underlying language service, Noah Richards came to the rescue and provided a fantastic sample on how to do just that: http://gist.github.com/125540

Basically the sample shows how to call use the Classifier Aggregator service provided by the IDE, which aggregates and merges all the classifications returned by the registered classifiers, and ask it to run the classifiers on the selected span of text. Now all you have to do is go through the classifications returned, look for those the language service marked as keywords, and filter those down based on our own list.

The only tricky part about it is some work on our classifier provider implementation so that when we’re calling into the aggregator ourselves, we exclude our own classifier from the process. Very important, otherwise we’d get the editor stuck in an infinite recursion and blow it up real quick.

All the credit for this goes to Noah, I wouldn’t even have known where to start to make this happen .

Conclusion

All in all, I’ve been having lots of fun working on this little extension, and I’m looking forward to extend it to support a number of other things as well. It’s pretty cool that you can do things like this with relative ease in the new editor, and this one is one I sure plan on using day to day.

Everything is not rosy, of course. It takes a while to get used to the extensibility model, as it’s pretty big, and despite the support that MEF provides for hooking stuff together, you still have to be pretty careful about the values you provide in the attributes: If some things don’t match, you might find that things don’t work correctly and there’s no easy way to figure out what’s going on.

Update: I’ve renamed the project to Keyword Classifier and extended it to support new features. Details here.

You can create them by hovering the mouse over an expression. Like in previous versions, you’ll get the watch popup with the details and value of the expression, but notice the little Note-icon on the right:

If you click on it, the watch expression window will be moved to turn yellow and get detached. It keeps around during your debugging and works just like any expression in the real watch window (that is, it’s context sensitive and insensitive at the same time).

I think this is pretty nifty for some debugging helpers. They will even persist across debugger sessions! More interesting, you can add a brief descriptive text to each watch note and keep it visible (or hidden).

I think these will be very useful when debugging complex issues in small pieces of code, because for general debugging sessions when you go through lots of places in the code, they will get a bit in the way.

Something Fishy

Something I did not like, though, is that the note icon used to create these gets hidden away whenever you look into a complex expression that can be drilled down (i.e. one that has [+] next to it):

As soon as the expression properties is expanded, the note icon disappears, and since they always expand automatically as soon as you hover the the cursor over the expression and you need to move over it anyway to reach the note icon (otherwise, the whole popup disappears), then you have to go right away to collapse the properties before being able to create a watch note from the expression. This can get annoying real quick.

I’ve noticed something that’s nagging me a bit, and that’s full line highlights when you’ve got elements that have an explicit background set. In my current VS2010 color scheme, I’ve got strings set up so that they will be rendered with a dark green background, different from the almost black, default background color:

If I put a breakpoint on that line, the line will be marked with the usual (default) crimson background. But here’s what happens with the string:

So now the string background is preserved, but the foreground color is set to white. It’s readable (by happy change), but it might also blind you.

Now let’s try debugging and see what happens when that line is the current statement:

Again, the background color is preserved, but now text is black and completely unreadable.

Now, I don’t know if this can be considered a bug or a feature. In general, the VS2010 editor does a much better job of dealing with syntax coloring, and I love that text selection is now semi-translucent and keeps syntax highlighting visible. It’s a simple thing, but it makes the editor much nicer to use.

Given the issues exhibited above, what I really wished happened is that both kinds of line highlighting were handled exactly like text selection: Make the marker a semi-translucent background and don’t force the foreground text color. It’s bound to be rather ugly.

Because of this, I’m constantly switching between the two, depending on which VM I need to use to try something. I’m finding myself using VirtualBox a lot lately because of the need to run a couple of VMs at the same time, which is something that it does quite a bit better than VirtualPC.

I don’t try to run both of them at the same time, nor do I need them to. I take advantage of hardware virtualization support in my desktop machine (which has an Intel Q6600 processor) in both platforms, which can speed things quite a bit.

The problem, however, is that both tools seem to pretty much assume that they are the only ones that will try to probe the processor virtualization support.

Occasionally, I’ll make a mistake and click on the wrong icon in the Quick Launch toolbar and end up starting the wrong application. Sometimes I end up starting VPC when I’m already working on VBox, and sometimes I’ll end up starting VBox when I’ve already got a VM in VPC open.

The end result is almost always the same: Windows crashing right away with a Blue Screen of Death (BSOD), usually with a fault in vmm.sys.

Again, I have no need to use both tools at the same time, but it sure would be nice if accidentally clicking the wrong icon didn’t force me to spend 10 minutes while my machine comes back up and I can setup my environment as it was before the crash, and probably lose some recent work, as well!

What I like

• It’s hard to argue that the new designer isn’t a big improvement in the looks category. It sports a somewhat minimalistic view, making much less use of gradients and other bling that was common in its previous incarnation.
• The option to zoom in/out of the current workflow view is great. Not only is it useful, it’s very smooth as well.
• The mini-map rocks when navigating a large map, and I find it particularly useful when I’m working on a zoomed designer window:
  
• I like the breadcrumbs navigation list at the top-left of the designer as you dive deeper into nested activities. It could be a bit more visible, though.
  
• The variables and arguments windows are useful, and certainly the underlying concept is, in general, far more solid than the activity binding model supported in previous versions of the runtime.
• The new Flowchart workflows types, and it’s associated designer is, in my humble opinion, a massive improvement over the previous models. It feels a lot more natural to write flows like this and it’s a lot easier to organize the workflow visually into something that makes sense.
• There’s a Save As Image option in the designer popup menu that can be used to save a JPG file with an image of the workflow as it’s currently shown in the designer. It’s useful, though not thrilled that warnings/errors are rendered into the saved image.

What I don’t like

Unfortunately, this might very well be a far longer list:

The overall way of writing workflows through the designer remains extremely clunky, and it’s a pretty slow and awkward process. Maybe it’s just me, but I don’t find the overall experience very pleasant.

To start with, doing almost anything requires way too many clicks here and there. You find yourself constantly jumping between the workflow window, the variables window, the properties window and one or more popup tool windows to enter data and edit data.

To make things a bit worse, I find the lack of connections between all these to be somewhat unsettling, because no part of the process is oriented towards doing tasks but just small parts of tasks at a time. Because they are not connected across the entire process, I would find myself jumping back and forth between windows.

For example, let’s say I add a new activity and want to bind some data to one of it’s properties. When I go to the properties window and fire up the expression window, I realize I needed to move data from somewhere else and would like a workflow variable for that. So now I have to back out of the current spot, go back to the Variables window, add the variable, back to the properties window and into the expression window. Too many steps!

Another thing I’m not a big fan of is having activities provide lots of built-in editing windows right on the designer surface. For example, the InvokeMethod<T> activity allows you to enter the expressions for Target Type, Target Object and Method Name right into the designer.

At first glance, this would seem like a good thing; after all, it saves you from a few trips to the properties window. But later, it becomes a bit more cumbersome, as it is data that you’re simply not interested in looking at the whole time. Also, most of the time the activity’s display surface will be too small to display entire values, so it’s not even that useful then.

Tool Windows

Tool Windows in the current beta are horrible to work with; they have very poor usability. I’m referring to windows such as the expression editor, the type selection window and so forth.

The first problem I ran into is that almost none of the popup windows are resizable. For most windows, this is really annoying, and what’s worse is that this includes the all around common Expression Editor window. Seriously, have we learned nothing from all the complaints around this from the BizTalk Orchestration designer?

For some windows, though, it gets even worse. Some windows, such as those that have grids, are not only not resizable by the user, but they also change size on their own. Drives me nuts!

A good example of this is the window that comes up when you try to edit the Parameters property of the InvokePowerShell activity: Initially, it contains just enough space to display a single row. After adding one row, the window resizes to show the original row and a blank new row, and keeps doing that as you add data to it. If you delete a row, the window becomes smaller again. There’s also no built-in scrolling at all, so if you need to add more rows than fit vertically on your screen, well, you’re hosed.

Another thing that gives a bad initial impression is that some windows react strangely to input from the user. For example, consider the Expression Editor Window. When it comes up, it has one size. Click on the actual text box to change the expression, and the window jumps around resizing itself twice (to end up with the initial size). Annoying.

To be fair to the Expression Editor window, user input isn’t always handled correctly in other places. For example, try to enter an expression for the default value of a new variable in the Variables window and try selecting the “All” button under the IntelliSense window when it pops up. Yep, it all goes away.

Here’s another that doesn’t make much sense to me: The Browse for Types window that comes up when selecting the type for a variable lists types by assembly, and inside each one ordered by type name, without consideration for namespaces. Yes, types are not grouped around namespaces at all.

Oh, and while we’re at it: All those new tool windows have nice and shiny white backgrounds all over the place. Considering plucking my eyes out as a workaround.

The Flowchart Designer

Flowcharts are (to me) the single most important feature in WF 4. They are a much nicer model to work with, I think. That said, the designer is not without faults:

• Connection points are too sensitive, making them hard to target and pinpoint accurately. Sometimes links just end up going where you don’t want them to.
• Arrows are too small, making it hard to grasp the flow at a glance (particularly when the view is zoomed out).
• The automatic routing of arrows is sometimes quirky (though I guess it’s OK).
• Sometimes selection isn’t handled correctly. Many times I’ve selected an arrow, seen it clearly rendered as selected, hit the Delete key only to find the entire workflow is deleted. At least Undo seems to work.
• I love that you can resize the flowchart designer area. I hate that you have to scroll all the way to the bottom right to do it.

Variable Scope

In WF 4.0, Variables are scoped to composite activities. That is, you can define a variable either on the top level workflow, or on a specific activity, like a Sequence or a CancellationScope already in the workflow.

Unfortunately, the way this is exposed at the designer level is incredibly clunky:

• The scope is not represented visually in the Variables window. Instead all you get is the Scope column in the variables list:
  
  Even BizTalk 2004 got it right: It needs to be shown visually. Nested scopes are a tree, don’t try to represent it with a list; it doesn’t work.
• The variable window will show / hide variables based on the scope. If you select a composite activity, it will only show variables declared at its scope and that of its ancestors. Variables defined in children of the activity are not included.
  I understand it’s trying to be useful, but this just gets in the way. If you want to define or look at a variable defined 3 levels deep, then you get to first navigate all the workflow to get there just to be able to get the Variables window to show you the definition. Gah!
• When adding a new variable, scope defaults to the activity currently selected in the designer. This almost makes sense, but if you decide that’s not right, well, surprise! Scopes shown in the drop down list for the Scope column follow the same rules as above. That means you can’t add a new variable in a scope without being physically nested within it (i.e. can’t add to a sibling activity). Annoying.

Conclusion

Many of the issues I’ve brought up here are basic usability problems, but many correctable. One can hope there’s still time in the Visual Studio 2010 timeframe to see some of those UX issues addressed.

I’m not very hopeful, though, about having a designer that’s really more pleasurable to use and that addresses the bigger issues related to the experience of creating and editing a workflow more conveniently and with less clicking, as those might very well require rethinking the entire process over. It’s really more of a conceptual issue than a technical issue, in a way.

Don’t get me wrong, the new designer is an improvement over the old one. Unfortunately, that’s all it is: An improvement. It provides an interesting foundation to address some of the technical shortcomings that the original Workflow Designer has, but it doesn’t really provide a more meaningful/powerfull way of designing workflows. In that sense, I do think it’s a bit of a missed opportunity.

There are two different activities: InvokePowerShell and InvokePowerShell<T>. The difference (as far as I can see) is that the latter allows you to capture the output of the PowerShell command being executed (that is, the results from the pipeline). I can understand why both variants might be needed, but not thrilled about the naming. At the least, it’s not immediately obvious what the difference between the two is, so it’s going to be confusing.

Using InvokePowerShell

I struggled a bit understanding how the InvokePowerShell activity was meant to be used. In particular, I didn’t grasp immediately the significance of the IsScript property of the activity:

If I understand it correctly, here’s the key difference: If IsScript is not checked (the default), then CommandText cannot be an arbitrary PowerShell expression. Instead it must be the name of the PowerShell cmdlet to invoke, but you cannot add any extra information there (such as the value of a parameter). By contrast, if IsScript is checked, then CommandText can be a list of (more or less) arbitrary PowerShell expressions, including variable declarations and all.

I believe that for a lot of people, enabling IsScript will make the activity behave in a more natural way.

There are a few more interesting details about the PowerShell activities:

Passing Data into PowerShell

There are two ways to pass data into the PowerShell script to execute:

1. If you’re executing a cmdlet, then the Parameters collection can be used to provide input arguments to the cmdlet call. For example, if CommandText is “Get-Process”, then you can add a Name parameter to the Parameters collection with the value set to an expression returning a string, and it will be the same as if you had invoked “Get-Process -Name <value>”. I’m not 100% sure yet, but it would seem like this would only really apply if IsScript is unchecked (otherwise, it’s not very clear what you’re passing the parameters to).
2. You can have WF push variables into the PowerShell runspace before the invocation. This is what the PowerShellVariables property is for. If you add a variable there call Error, then the PowerShell expression in CommandText can reference the value by using $Error. Again, this would appear to be mostly useful when IsScript is checked.

Based on this, one might suspect that the Parameters and PowerShellVariables properties are basically there to support both modes of operation of the activity: One when invoking a cmdlet directly and one when executing a more free-form script. Is this good? I’m not sure yet. I can see a sort of logic to both ways of using the InvokePowerShell activity, but it seems a bit complex and potentially confusing. I sure know I was confused the first time I tried to use it.

Pipeline Input

It should be obvious by now that I wasn’t exactly right when I said there were two ways to pass data into the PowerShell script. There’s a third (main?) one: Provide an object (or collection of objects) as the pipeline input, which is what the Input property of the activity is for.

It should be fairly obvious how to use it: If the command is a cmdlet, then the input will be feed just like if you had piped something to it in PowerShell. You might expect that if the command is a free-form script, then you’d be able to access it the inputs $_; however, I haven’t been successful in that so not sure if it’s supported.

Pipeline Output

Handling pipeline output is only done in the InvokePowerShell<T> activity, and it’s basically very simple: When adding the activity to your workflow, the designer will ask you to bind T to a type, and that’s what you expect your PowerShell command to return. I can imagine that in most cases, this should be some sort of collection (like IEnumerable) since most PowerShell commands will return multiple objects.

Then, just bind the Output property of the activity to a variable in your workflow that will receive the pipeline output after the activity executes.

Pipeline Errors

Errors resulting from executing the InvokePowerShell activity can surface in one of two ways:

• Certain errors, such as trying to invoke a malformed expression or a non-existent cmdlet will result in an exception being thrown and the Workflow faulting, unless you have the activity inside try/catch blocks.
• Anything that gets written by the command to the error stream (through the Write-Error cmdlet) will get exposed through the Errors property of the InvokePowerShell activity. To handle those, you’ll want to create a new variable in your workflow (of type Collection<ErrorRecord> or just IEnumerable), and then bind it to the Errors property.  Now you should be able to simply iterate over your variable right after InvokePowerShell finishes executing.

Designer Support

I’m not totally happy with the designer support for the PowerShell activities. Besides my general complaints about the Workflow Designer (a subject for another blog post), there’s something that really bugs me: There’s no proper editor support for entering the CommandText in the activity.

Sure, you can attempt to write your script directly into the text editor in the activity designer, but that’s way too small for anything more complex than, say, calling Get-Process. You could also attempt to use the property window, but that’s even worse because all it has is a single-line text box. At the very least, it needs to popup into a multi-line text editor window.