In this Two Minute WF, we’ll talk about the WorkflowRuntime.

The WorkflowRuntime is the service that coordinates the execution of workflows and the services that workflows use. Once you’ve defined a workflow using the various activities you need the workflow to perform, you tell the WorkflowRuntime to create an instance of that workflow and start it running. The WorkflowRuntime uses the various services available to it to start the workflow instance running on a thread, persist the workflow when it becomes idle, and generally manage the execution of the workflow.

The WorkflowRuntime provides events you can handle to let you know when significant things happen like when a WorkflowInstance is finished running, has thrown an exception, or has been terminated. You can also use the WorkflowRuntime to enumerate the list of currently loaded workflows or retrieve references to workflow-related services.

You can only have one WorkflowRuntime per AppDomain (generally this means you get one per application), so in more than the simplest application it can be kind of tricky to manage your WorkflowRuntime.

For example, say you have an object that needs to know when a workflow completes. You might have that object subscribe to the WorkflowRuntime.WorkflowCompleted event. Later, you might no longer need that object so you stop referencing it and assume the garbage collector will clean it up for you… but it won’t. Why? Because it’s still subscribed to the WorkflowRuntime.WorkflowCompleted event so there’s still a reference to it. This sort of thing becomes a little tricky particularly in applications like an ASP.NET web app where a page instance might need to know when a workflow it started is done running. (There are other issues with using workflows in ASP.NET that I’ll get into in a later topic.)

There’s a lot to consider when working with WorkflowRuntime, but it does a lot of the work for you. Once you get your head wrapped around it, WorkflowRuntime is your best friend in Windows Workflow Foudnation. You’ll be seeing a lot of each other, so get to know it.

Okay, folks, here are your million-dollar product ideas for April 2008. If you implement these, remember to send me a t-shirt or something.

Coffee should come in milk cartons. I can’t really remember the last time I actually measured coffee into the coffee maker. Once you’ve done it a couple of times, you know that a mound of coffee about this big is the equivalent of two scoops or whatever. But pouring coffee into the machine out of a bag is, well, sometimes troublesome. You kind of have to manually munge a “spout” on the end of the bag, too much comes out… bah. Other containers - cans, tins, etc. - are also problematic. Put it in a milk carton so I can pour it.

Combine Dance Dance Revolution and Rock Band for the ultimate music experience.I think I have like six versions of DDR at home. I know I have at least four dance pads across two different consoles. I love DDR. I also love Rock Band. They should let you hook up more than four people in Rock Band. Keep the four band members - guitar, bass, drums, vocals - but add the ability to hook up dance pads. The vocalist could dance while singing, and additional dance pads could be added for “backup dancers.” Hey, if the guitarist really wants to get crazy, dance while playing the guitar. You could combine that with the stage kit coming in June and have yourself a full production, ready to go on tour. I’d totally buy it.

The InnoTech Oregon conference is going on April 16 and 17 at the Portland Convention Center. I’ll be speaking in the Developer track on “Unit Testing with TypeMock.”

Unit testing checks the behavior of the code you write by testing just that code, isolated from the rest of the system. It’s complementary to integration testing and is an important step toward ensuring reliability of the entire system in production. Unfortunately, not everything is designed with testability in mind. Third-party dependencies can throw a wrench in the works. You may need to add tests for legacy code that isn’t easily isolated. And what if the public-facing methods and properties on your code make it easy to use but hard to test? This session will show you how to have your unit testing cake and eat it, too, using NUnit and TypeMock.

I’m the last session of the last day - April 17, 3:30p - so if you want to see some TypeMock Isolator in action, come check it out.

NDepend is a tool you can use to analyze your .NET code and find problem areas.It’s exceptionally helpful when working with a large codebase so you can see what’s going on - which components rely on which other components, which classes might not be single responsibility… that sort of thing. It gives you a lot of information.So much, you might be overwhelmed by the sheer volume at first until you start really understanding what you’re looking at. Let’s walk through it a little.

Install is easy- unzip and you’re done. Fire it up and you’ll find yourself at the Start Page.

This is where you can create a new project, open an existing project, or watch some getting started videos. The interesting thing I liked about the Start Page (aside from the video links) was that you can install some add-ins for Visual Studio and Reflector right from there.

I’ll talk about what the add-ins do in a bit, but the ability to install add-ins right from the Start Page makes it nice and convenient.You can also get to this from the Options menu, but this gets it right up in front of you.

At the bottom of the Start Page you’ll see tabs for an Error List and a Help window. The Help window has some links to additional videos to help you get started. You will want to watch these Help videos before getting too far into NDependso you have an idea about what you will need to do. NDepend is big and can be intimidating. The videos help with that.

A couple of things I noticed about the Error List and Help windows: First, there’s no way to “pin” them on the Start Page, so as soon as your cursor leaves, they auto-hide. That can get frustrating as you’re navigating around. (Once you’re past the Start Page, they’re pinnable, but on the Start Page they’re not.) Second, the Help window arranges the available videos in a giant accordion control. This isn’t immediately apparent (at least, it wasn’t to me), so once you’ve expanded one of the sections of videos, you’ll wonder where the rest went. The scroll bar at the side of the accordion control (not the window, but the control) will help you out there.

Before you go any further, go to the Options menu (Tools -> Options) and under “Menu\Bar\Ribbon Preference,” select the ribbon interface.The ribbon felt to me like it was easier to figure out than the standard menu/toolbar interface. The ribbon also felt like it gave more “guidance” on what my available options were at any given time, and you’ll want that.

Using NDepend is covered fairly well by the screencasts you can access in the Help menu, so I won’t cover every detail of usage. I recommend you watch the Help videos because it makes all the difference.

An NDepend project is what contains of the list of assemblies you want to analyze. Creating a new NDepend project is a very flexible process.You can do it based on a Visual Studio solution, you can drag and drop assemblies, you can browse for assemblies, or do a combination of several of these.

The project saves paths to each assembly you want to analyze. There is an option to let you save paths in the project as relative paths (relative to the location of the NDepend project). The relative path option is not the default and it’s not obvious how to change your project to save relative paths.If you’re going to use this project on any machine but your own, you’ll want the relative path option set. You need to expand the folder view and select the “Relative path mode” checkbox.

Unfortunately, relative path mode seems to be “all or nothing.”While .NET framework assemblies always get an absolute path, all of the other assemblies in your project, including dependencies, are all either relative or absolute. You can’t save some assemblies with relative paths and some without, and that can be a problem when you’re looking at projects like Visual Studio add-ins that use some assemblies like EnvDTE

• they get saved with relative paths. You can fix this by manually modifying the project file (it’s XML), but NDepend won’t automatically pick up your changesif you do that - you’ll need to manually reload the project. This is probably an edge case, but the first project I analyzed was a VS add-in because that’s what I happened to be working on at the time.

Once you’ve created a project and run the analysis for the first time, that’s where the fun starts, but that’s also where it can get overwhelming. For the first time user, you’ll do the analysis, you’ll see the report come up, and then you’ll sit there for a bit wondering, “Now what? What do I do with all this information?”I think that’s my only real complaint with the product. With a tool like FxCop, you know you’ve broken some rules and it tells you what to do about it. With NDepend, the “what to do about it” is very subjective - whether or not you need to do anything at all is entirely up to you, and then what you do based on your decision is also entirely up to you. Granted, the two tools perform very different analysis, but the idea stands: There’s nothing that takes you from “I just ran analysis” to “Here’s a list of actions to take.”I think if that gap could somehow be bridged, it would make this a more accessible tool.

Once you run the analysis, you’ll be presented with a report and the GUI will update with the data.

Note: If you run the analysis again, the report will again pop up, but the GUI won’t automatically update - instead, you’ll get a dialog letting you know there’s new analysis available and asking if you want to update. That’s a little confusing - I just ran the thing; why wouldn’t I want to update?

Anyway, once you’ve got the analysis run, you’re going to get a pretty busy interface that comes up with a lot of information. If you’ve watched the videos, you have an idea of what all this means. If you haven’t watched the videos, now is the time to do that. NDepend is not a tool you can just wander around randomly and “figure out.”

Using the ribbon interface, you can pretty easily switch between views to analyze dependencies, look at various metrics, compare two sets of analysis to see what’s changed, and do some ad-hoc querying against the analysis to dig deeper and learn more about your code. Use the tabs at the top to switch the ribbon to a different mode, and the “Reset Views” button will set the various information windows up to help you better visualize what you want. You’ll use “Reset Views” a lot.The only problem with “Reset Views” is there is no way to customize the “default view” for a given “mode,”so if you set the view up slightly differently, switch to a different view (say, from “Dependencies” to “Metrics”), and you’ll never get your customized view back again. That can get frustrating, but I’ve learned to just live with the default views. I’m hoping a future version of the product lets me customize those views.

The Metrics window is the most visually strikingpart of any of the views, but it’s also the most confusing. This is that gray-block looking window:

This is an interesting visualization of the makeup of your assemblies. What the blocks represent is based on what you have the view set to at the time, but in the above example, each block is one method. The relative size of each block illustrates the relative size of the method in lines of code - larger blocks mean longer methods. Hovering your mouse over a block will let you know what that block represents, and as you query your code, this view lights up to show you which bits match the query you just entered. In all, a pretty cool way to visualize the makeup of your code.

That said, I’ve never been a big fan of the grayscale gradient boxes. The gradient makes it hard for me to see the edges of each block and when you’re looking at a really large project, this blends together to become more of a “texture” than a visualization. Throw the text on top of that and it gets a little overwhelming. I wonder if alternative visualization mechanisms might be available in the future, like a red-to-blue hot-to-cold sort of thing, or maybe just solid colors with hard lines around the edge of each block.

The major feature of NDepend is really the CQL (Code Query Language) ad-hoc querying you can do.For example, if you want to find all of the protected methods that start with “C” that have over 10 lines of code, you can do that:

SELECT METHODS WHERE IsProtected AND NbLinesOfCode> 10 AND NameLike “\^C”

Pretty cool, eh? When you do that, you’ll see a query result window that lists the items that match your query, and the Metrics window will highlight the items so you can see the results visually. Oh, and don’t worry too much about the trouble of learning CQL - it’s a lot like SQL, and there’s some great IntelliSense in the query window:

Once you’ve gotten your queries set up (and there are lots of good ones that come out-of-the-box when you create your project), you’ll probably want to integrate this into your continuous integration build. NDepend comes with both NAnt and MSBuild tasks to help you get this going in CI.It’s not hard to get going, but the documentation on the tasks is light(almost non-existent) so you may need to use Reflector to see what parameters the tasks allow you to pass in. It’d be nice to see a little more robust doc on these.

The reports that NDepend generates are very robust and fully customizable.You can either select some out-of-the-box options (recommended, particularly at the start) or you can customize everything down to the look and feel using XSL. The report itself takes the form of an HTML page with lots of charts and graphs. My favorite part of the report is the Abstractness vs. Instabilitygraph (which is also the easiest to understand) where you can see which assemblies you have may need some refactoring to get them out of the “Zone of Pain” or the “Zone of Uselessness.”

The only issue I really had with the reports was, when viewing them with IE, I got the “security warning” telling me the HTML could be harmful to my computer. That could be fixed pretty easily with a Mark of the Web, so if you want to customize your report, you can probably get rid of that.

Finally, the Visual Studio and Reflector add-ins bring all this full circle. As you’re working on your code, you may be interested in doing some analysis on that code. You might wonder, for example, “Who’s using this method?” Rather than having to write that CQL yourself, you can right-click your way to freedom and leisure.

You can do this same right-click action in Reflector.Again, very easy, and very cool.

I love NDepend, and I highly recommend it.It tells you all sorts of things that you really do need to know about your code. It’s a little tough to get started, so you have to be patient, but once you’re in, you’re flying. Learn about your code and make it better. It’ll be well worth your time, I promise.

We painted the master bathroom this weekend and I realized that painting, for me, is a lot like Twizzlers. Stick with me.

I love red licorice. It’s so tasty and chewy and wonderful that I’m sure it’s got to be good for me. Twizzlers, on the other hand… Twizzlers looks like red licorice, it smells like red licorice, but it is not, by any stretch of the imagination, red licorice. It’s waxy and nasty and probably contains petrochemicals of some sort. Twizzlers is like processed cheese food compared to the Brie de Meaux of red licorice.

The problem is that Twizzlers so convincingly resembles red licorice from the outside that I forget how nasty it is. I’ll be craving red licorice, see a Twizzler, grab it, eat it, want to die, and remember how bad it is. I might remember it for like six months or so, until one day my red licorice craving gets the better of me and I see a Twizzler, take a bite, then smack myself repeatedly in the forehead Rain Man style screaming, “STUPID! STUPID! STUPID! Twizzlers is not red licorice!” And another six months will go by before I forget how bad it is again. Rinse and repeat.

I hate painting. Hate it. It’s messy and it takes a long time and I always underestimate the amount of effort it’s going to take to get the job done. My attitude over the course of a painting job changes for the worse, too. I’ll start out sort of cheerful, singing my Happy Working Song, and six hours later I’m ready to kill.

But, like Twizzlers, after about six to nine months, I always forget.

This time, we were looking at the master bathroom, thinking how drab it was. It was painted in the color “Arbor White,” which is a special off-white color that Arbor Custom Homes uses when it builds houses. (If you want touch-up paint, if you go to Home Depot and ask for “Arbor White,” they know. There’s no paint chip or anything, they just know.) The problem is, if you hold real white up to it, you would probably want to call it “Arbor Brown” because it’s not remotely white.

Anyway, we were gazing into the gaping Arbor Brown maw that was our master bathroom, thinking how drab it was, when we decided it needed a coat of paint. It having been probably a year or more since I last painted, I forgot that I vowed not to paint again, so we ran down to the Home Depot and picked up some paint. We ended up with a scheme similar to the following, with “Drowsy Lavender” as the main color. (This isn’t exactly it, but I don’t remember the exact colors. It doesn’t really matter.)

We started painting on Saturday and we got about halfway done in five hours or so. Some primer and a first coat on the walls and the ceiling. At the end of Saturday I was in Twizzlers-land: “STUPID! STUPID! STUPID! Painting sucks!” Of course, we were sort of committed by then, so we had to finish.

We spent several more hours on Sunday trying desperately to finish but failing miserably. We got the second coat on the walls and the ceiling and we started on the trim.

It was about this time where we really started noticing that the door and the blinds were Arbor White but the ceiling was true white and… hmmm. Screw it. We’re SO NOT painting the door and the blinds.

So we’ve got to finish the trim this week and do some touch-ups. Probably another couple of hours’ worth of work. I wondered how people on Trading Spaces did all of this in two days, but then Jenn reminded me that it’s not just two people - there’s a team of people behind the scenes. Maybe if Laurie showed up it would be better, but probably not.

I swear I’m going to remember this time: Hire someone to paint. Painting sucks. It’s always more work than you anticipate and it makes you grumpy.

Eh. That’ll last, what, six months?